I have a small <p> about 140px wide aligned next to a picture. In total there is space for four lines of text. The first two lines are reserved for the title and there are two lines of other info.
I want the title to be cut if it spans more than two lines else it will push the other info out of line with the bottom of the image.
The only solution I could think of was to create a div the height of two lines with an overflow to hidden. However, if the title is only one line it leaves a big gap.
The solution can be Jquery, plain javascript, CSS or even PHP (if its possible).
TIA
Set the title to have a max-height of two lines
Keep in mind that the property max-height is not supported in IE6. In addition, limiting the size of text boxes can cause accessibility issues, and is generally not recommended.
As this is more of a content issue than a display issue, it's probably best to deal with it on the back end - if it's dynamic text, limit your database field to an appropriate character count, or chop it with some php (or whatever server side situation you're set up in). It's tough to establish a character count with a non-monospaced font, but if you don't limit it on the content side, you run the risk of upsetting your less visually-inclined users who may be using older browsers that don't zoom all fancy like the latest releases of safari and chrome.
Related
I have different text areas in my form, which have different maxLengths. Therefore, I am trying to size my textares in the beginning so that the max characters can fit there without resizing the box. My first attempt was to fix the amount of columns and then calculate the amount if rows. This works until css comes into play and my textboxes are always to big, because they are wider than the value in columns.
What I am trying to achieve is that the textbox is just big enough to fit the text (not like in the picture).
First of all, as far as I know, there is no browser capability for this and then you have a few issues here. You cannot set the textarea to a definite height because it heavily depends on the CSS you use and the text you write.
In your screenshot, you do not use a monospace font, that means depending on what your users write, the text will be longer or shorter, even if they use the same amount if characters. Take these 2 examples:
Text 1:
iiiii
Text 2:
WWWWW
both of these quotes have 5 letters and have different length if you don't choose to use a monospace font.
If you do use a monospace font the size of your textarea still depends on the specific font you use. Courier is wider than Monaco, I think, just as an example.
Then of course, depending on the width of your textarea its height must change.
Back in the day, this problem had to be tackled by JavaScript under the keyword of an auto-resizing textarea. There are various techniques for this. Basically what they do is
Add a keydown event listener to your textarea
Whenever a user types, use some "magic" to measure your text
Resize your textarea to fit your text
This would be an example of this: https://codepen.io/vsync/pen/czgrf
Now you can use that example and depending on your specific application only have that execute once on page load with a maximum number of letters, or, if you know the size of the letters of your font already, do some calculations in beforehand and bake (hard code) the sizes (for multiple viewports) in your code.
I think that last thing would be the sanest solution.
I'm looking on how to implement pagination/page breaks with page formats (A4, letter, etc.) using a rich text editor (like the Medium Editor).
The font family, font size, line height, margins are going to be fixed, as this is a very specific case study. I'm thinking of handling zoom levels in pure CSS (scale), instead of directly modifying widths, heights, etc.
Also, for the sake of the experiment, say I'll be running this in Chrome only & browser rendering differences aren't really an issue (but even if I were building this for various browsers, I'd try and use more precise units, such as "px", "em" for the font-sizes, page widths, margins between elements, etc. - probably just "px").
Keep in mind I'm not asking about "#page" rules or print rules, I know how to achieve what I want with those when I print out a PDF, but rather direct in-browser implementation. Printing should (and will) be handled by "#page" and I got no issue to handle page breaks there when I need them.
In the end, my question is - where do I start?
I imagine taking into account word-count and "h(1,2,3...)", "p" tag margins, along with case-specific CSS rules (break-after, break-word, break-line, etc) - even though taking those into account with js probably won't be very easy.
Probably even include the page height? Say, if the format is A4: 596px x 842px (72dpi) - take it into account when the total height of "each" element inside the page == height of page - [sum of bottom and top page margins]?
Other than the latter (with a simple js loop), if someone has any pointers, or maybe even a code snippet (or a plugin?), I'd be very grateful! Thank you!
I'm looking to calculate the number of terminal columns various printing and non-printing ascii/unicode characters will occupy in a terminal view.
For example, horizontal tab (\t) occupies 8 columns, color codes (i.e. \x1b32m) occupy 0 columns, and fixed-size wide-character strings (i.e. 한) might occupy 2 columns. Of course there are many in the primary ASCII set that only occupy 1 column (ie. a-Z/0-9, punctuation etc.).
I've come across the node.js module, wcwidth, that seems to help calculate wide-character strings, but doesn't do what I'd expect for other characters, like color codes, and tabs.
For example:
var wcwidth = require('wcwidth');
console.log("TAB WIDTH", wcwidth('\t'));
console.log("한 WIDTH", wcwidth('한'));
console.log("Color Code WIDTH", wcwidth('\x1b32m'));
console.log("X WIDTH", wcwidth('X'));
Outputs:
TAB WIDTH 0
한 WIDTH 2
Color Code WIDTH 3
X WIDTH 1
I can't seem to find any information about this anywhere, though I'd imagine it would be a common thing people have had to solve in the ancient past.
If there might be a way using a bash script, or any library, application or tool, I'm totally open to that as well.
Any help much appreciated! :)
Thanks
A tab does not occupy 8 columns. It outputs a single space and then enough spaces to ensure that the next character will be output at the next column whose index is 0 mod 8 (Or 1 mod 8 if you count from 1.) In other words, you cannot tell how wide a tab is unless you know where you are on the line.
A color code (\x1b[32m) might occupy zero space, but it also might not; it depends on the nature of the terminal emulator for the console. Most terminal emulators will recognize the CSI[Pm code but there are other codes which are quite a bit more idiosyncratic. For example,
printf $'\x1b]2;A window\x1b\\'
will set the window title in xterm, and hence will produce no output. But in a Linux console, the text ;A window will be displayed, occupying 9 characters.
In short, it is not so easy a problem, and you can only answer it with a lot of context because there is no absolute answer.
This is indeed an issue for any program that needs to know where the cursor is on screen, from tabular output in ls through editable command lines to full-screen applications. As you've noticed, it's not solved by wcwidth or wcswidth, which are defined only for (strings of) printable characters. (Even that is not well defined for many characters.) Also, control sequences can not only change colours but also cursor positioning and even, where supported, font size effects.
Instead, terminal control libraries such as ncurses [npm search] are sometimes used. These don't seem to tell you string widths either, but because they track text attributes such as colour separately, and generate control sequences themselves to position and style text, they provide some assistance in putting things on screen in given locations.
Unfortunately I don't believe there's much available beyond that, with applications either ignoring the complexities or handling them in ad hoc ways.
To clear up a common misconception: Horizontal Tab (HT, \t) doesn't have a width as such; it's a 'format effector', like Carriage Return or Form Feed, that repositions the cursor according to certain rules.
HT (Horizontal Tabulation): A format effector which controls the
movement of the printing position to the next in a series of
predetermined positions along the printing line. (Applicable also to
display devices and the skip function on punched cards.)
— USA Standard Code for Information Interchange [ASCII], 1968, as reprinted in RFC 20
The most common implementation is to have fixed tab stops every eight columns:
1 2
1.......9.......7.......5.....
1\tXYZ 1 XYZ
12\tXYZ 12 XYZ
1234567\tXYZ 1234567 XYZ
12345678\tXYZ 12345678 XYZ
123456789\tXYZ 123456789 XYZ
though some systems support control sequences or other ways to set the positions of the tab stops at arbitrary distances, like the ruler bar in some word processors.
I have a piece of HTML which I am displaying inside a UIWebView using Webkit stylesheet attributes. I use Webkit to display the HTML in columns in order to simulate a book.
Only one column is visible at a time (one column represents one page). Now, I am trying to find the range of the visible HTML so that I can insert a span element right before the first visible word.
I managed to get the HTML element which contains the first visible word by using the JavaScript function, document.elementAtPoint(I might have the function name wrong), and changed its CSS class. but that just isn't accurate enough for me. I need it to be accurate up to the first visible word.
The idea is the create a column break at the first visible word when the fontsize is increased or decreased. I can using JavaScript to figure out in which column the element is, and programmatically scroll the user to that column, but first I need to get the element in there.
Can anyone help me?
The CSSOM View Module specification adds caretPositionFromPoint(x, y) to the Document interface, which returns a caret position for the specified x and y co-ordinates. WebKit supports caretRangeFromPoint, a close analogue from an earlier specification, which returns a Range.
It is possible that the word has been hyphenated and thus spans two columns, so rather than wrapping the first word in a span you may wish to consider the more naive approach of inserting the span directly at the cursor point. Here's an example:
var caretPos = document.caretRangeFromPoint(x, y);
if (caretPos)
caretPos.insertNode(document.createElement('span'));
Demo (WebKit only—click to insert spans): http://jsfiddle.net/Jordan/Aw9aV/
One final consideration: it is possible that WebKit will eventually stop supporting caretRangeFromPoint in lieu of caretPositionFromPoint; if so, you will need to adapt your code. Also note that the latter returns a CaretPosition which may not implement the insertNode method. The spec is still at WD, so be mindful that it is still in flux.
Ok, nog entirely sure what you are currently doing, but at the very least I should be able to give some useful tips, as I have some experience building page browsing systems in javascript.
First of all, in CSS3 you can define columns https://developer.mozilla.org/en/CSS3_Columns , which will automatically split up the content into different columns within a single element (where a single column has the full width of the uiwebview) and next add browsing controls which move the entire element containing the element (using css3 3d translations for smooth hardware accelerated motion and you know the width of the columns so you don't need to worry about what the first word on the page is). In which case you don't need to worry about splitting up the column breaks yourself. (Though, as I said, I am not sure to what extend you are already doing this).
Alternatively you may decide to wrap all your content in small inline-blocks (as older column implementations did) or even up to the point of single inline elements, each containing a single word. (Though this doesn't seem necessary anymore)
Lastly, work is being done on http://www.w3.org/TR/css3-regions/ which will make this even easier in the future, but for now it's only available in chrome and ie10
On the other hand, you might already be doing this or I might be missing the point, in which case I would need to see some code before I can give you a more specific answer. (I can think of various javascript tricks to work with letters within a text, but none seem necessary in your case)
I'm developing a web-based text editor without any contentEditable, textarea or input things. The biggest portion of my work is to measure widths of text on the left (right) side from the current caret position and moving the caret in the text.
For example when user presse the DOWN key a current left-offset of the caret must be computed and on the line below a character which's position is most similar must be found.
One very convenient way to do is to use one DOM element per character - I can just look at the offsetLeft property. Also, positioning the caret is much easier. Actually, everything is easier.
However I'm very unsure about the performance implications. I have seen this technique (or similar) used on some web-based JavaScript "IDE"s and it works just fine there.
Do you have any hints, tips?
Do you know some other fast way how to measure width of text. I want to avoid putting sections of a line to a DOM element and measuring its width each time as I think it will be much slower.
EDIT: I'm mostly asking about the main fact of EXISTENCE of many dom elements. How to do the measuring is a different thing.
I've seen this done (unfortunately can't find the link now) by using a canvas object and its measureText() method - basically you can ask a canvas "what size would this piece of text be if i rendered it in this style?" and use that to determine your caret position on the surrounding lines. This is performant, but of course it will only work in HTML5-capable browsers, and maybe not all of them.
But frankly this sounds like a big pain in the neck and probably more trouble than it's worth for an in-browser editor :)
You might be interested in this, which is a javascript implementation of the VI text editor. Unfortunately it does use a textarea, however not in the typical manner.