What is the minimum allowed negative value for the text-indent property?
I was using a bizarrely huge value in my site (something like text-indent: -99999999px), and it stopped working with the last Google Chrome update. IE still works fine, but I may need to remove a couple of 9's from there to make it work with Chrome again.
Disclaimer: yes, this value is a bit too paranoid, I used it for fun and copmletely forgot about it until the text popped out on the screen today. But the usually suggested text-indent: -9999px might easily fail at some point in (not so) distant future?
A safe value is probably -32768px, however this is not part of spec but rather an observation of a (possibly outdated) implementation-specific legacy restriction.
Before CSS property values can be applied to elements at render-time, those declarations have to be parsed into something more operable and abstract than, effectively, a string. I mean, you can type almost anything as a property value:
.a {text-indent: -999px;}
.b {text-indent: -99999999px;}
.c {text-indent: medium potato;}
The first example would, fingers crossed, get parsed correctly; the last one is invalid and would be ignored (since a medium potato is not currently part of w3c CSS spec); but the middle one would be quirky should it overflow (not "fit" in memory as allocated by the browser). I've put together a fiddle and these are the text-indent values at which the browsers "choked" and defaulted to zero:
#On OSX 10.8 Lion 64bit:
Safari 6 -2^31
Chrome 22 -2^26 #your original -99999999px would have failed here
Firefox 14 -2^70
Opera 12 -2^70
#On Win Server 2008 64bit:
Firefox 13 -2^70
Chrome 21 -2^70
IE 9 -2^70
This got me curious, I'll run more tests on another box tomorrow. Results above updated, nothing too excited. You can also run your own test using this fiddle - the first item that remains visible would show the value applied that got ignored. I'm assuming the values would vary depending on the browser/OS used as well as possibly hardware.
I remember first seeing a practical reference of such a limitation in an article on styling faux columns^ that suggested a conservative constraint to be that of a 16-bit signed integer (from -32768 to +32767) - which would apply to not only text indents but other length values. I'm not aware of how consistent this value is across different browsers and their versions, nor how applicable it would be to fractions or values expressed in different units.
There is no Minimum text indent - I have used just a couple of pixels before but that is bad practice to use for layout/design, ensure it scrolls off the screen when viewing on say Plasma sized layouts 99999px - is more than enough - use margins paddings and positions if you still want to see the text and are using for styling.
I have issues in ipad safari using a number of 99999em, fixed for me setting it to 9999em.
So maybe there is not limit, but should be one for avoid this mistakes.
Related
I've been researching about the use of pt vs. px on web development and after reading this article from W3C, it's clear to me that using pt can cause problems depending on the user's screen display.
Even so, there's one thing that's puzzling me. I've tested properties with pt as unit measures in Chrome, Firefox, Edge and IE and the four of them convert pt to px correctly (meaning that the value computed for each property is in px, even though I declared it as pt).
In the right: declared property; in the left: computed property.
If the browser is computing the values as px, I assume the problem with pt and screen displays is resolved, right? If it's not resolved, can someone explain to me why?
I'm trying to decide if it's ok to use pt in a project or if it's better for the developers to convert from pt to px while coding. Any new information about this topic is welcome, since it will improve the quality of our team's argument.
I am having an issue with a specific mac that is not displaying a certain website I have built correctly. Every other mac and pc I have tested displays the website correctly but this one specific mac in all browsers on it is displaying incorrectly the issue I am getting is inline block elements are not next to each other, I have all the 'hacks' in place and like mentioned this displays correctly on every other computer.
This question here is the exact same issue but it doesnt seem to have been resolved.
https://discussions.apple.com/thread/6650689?start=0&tstart=0
I know I could try floats but I would rather find the route of this cause, does anyone know of any reason this might be happening?
If browser renderings vary only on a single or a few machines, fonts are a possible culprit. Make sure all computers use the same fonts to render your page, actually even that the same version of the font is used.
A lot of fonts get slightly modified over time, often the kerning (space between two characters) or the hinting (how the curves that describe fonts should be mapped to pixels on the screen) might change, resulting in very minor differences in the width some text consumes when being displayed.
If indeed the font version is the culprit: Remember that visitors of your page might also have this "bad" version of the font. So it is advisable to try to improve your HTML layout.
I've often observed that leaving a few percentages empty helps to deal with such font issues. For example: having a div (width=100%) that contains two elements in each "row", the first one a label of about 1/3rd the width, and the second one being some control, taking up the rest of the space. Having them defined with width:33% and width:67% often results in the case that the second part is laid out below the first part instead next to each other. Changing the widths to something like width:32% and width:65% often fixes this, as it allows for some rounding errors in the browsers when laying out the elements.
Does "text-justify" work only in IE as stated here?
http://www.w3schools.com/cssref/css3_pr_text-justify.asp
If so, is there any way to change the way the spacing/kerning between words render in most browsers?
I've been testing some paragraphs of text formatted with "text-align: justify" and with "text-justify: (inter-word, distribute, newspaper, etc.)" and none of them makes any difference to the text.
I tested it using an iMac on Google Chrome, Firefox and Safari.
Any ideas? Thank you!
The text-justify property is IE-only. Its description in Microsoft documentation is rather vague; see my comparison of their statements with observed behavior. For texts in Latin letters, the only real difference seems to be that the values distribute and newspaper causes some of the added spacing to be directed between letters of words. (On IE. On other browsers, no effect.)
The property is included in CSS Text Module Level 3 (Last Call Working Draft), with just the values auto, none, inter-word, and distribute. It is marked as being “at risk”, which means that it “may be cut from the spec during its CR period if there are no (correct) implementations”. Other browser vendors seem to be reluctant to implement this property.
On the practical side, hyphenation is usually much more important than the tuning of justification methods. Hyphenation prevents most of the nasty problems (need for a large amount of added spacing) that the tuning tries to fix.
P.S. Justification does not involve kerning.
The vertical position of text rendered in Helvetica and the size of its content area differ between Firefox and Chrome for Mac. For example, in Chrome, the descenders are clipped if the line-height is identical to font-size.
(I’ve adjusted the position of the block elements in this picture—keeping the baseline consistent—to illustrate the difference in size and text positioning). If you have a Mac, you can see what I’m talking about in this JS Bin.
Now, I'm not directly interested in how to fix this specific discrepancy. I realize there are hand-tuned reset stylesheets that attempt to eliminate or paper-over the differences, but I'm specifically interested in the factors that caused these browsers to render differently in the first place.
I'm making some assumptions here:
Standards exist for both the rendering of fonts and the sizing and positioning of glyphs within the standard box model, but may be unspecified in terms of how they interact.
Bugs exist in browser-makers interpretations of the aforementioned standards, which may influence how text is sized, positioned and rendered.
For these specific browsers, much of the design discussion and actual implementation is public in some form. Therefore, it is possible to learn the source of such discrepancies, if one knows where to look.
Both browsers start in the same place - the markup, styles and font definitions are consistent between them. At some point, they diverge in how they use these to produce the final output.
Therefore, my specific question is: where in the process does this divergence occur, and what causes it to occur?
I feel that, armed with this knowledge, I can better understand how to correct for such discrepancies. Both in this case specifically, and in similar situations that I may encounter in the future.
Unfortunately, re: rendering of the content area based on the font, CSS2.1 does not say much at all:
The height of the content area should be based on the font, but this specification does not specify how. A UA may, e.g., use the em-box or the maximum ascender and descender of the font. (The latter would ensure that glyphs with parts above or below the em-box still fall within the content area, but leads to differently sized boxes for different fonts; the former would ensure authors can control background styling relative to the 'line-height', but leads to glyphs painting outside their content area.)
In other words, typesetting, and how exactly to draw and position the content area of a line box, is left up to the browser's own implementation, at least in CSS2.1. This may however be better defined in a future specification (likely the Fonts module, if not a separate module1).
Section 10.8.1 contains some details on how the line-height property affects the rendering of the content area around text that flows inline, but again it depends on the height of the content area itself, which as stated above is undefined in CSS2.1.
Note that auto is not a valid value for line-height; you probably meant to use normal, which incidentally is also its initial value (but not necessarily the browser default). Also, this is what the spec says about the value normal:
normal
Tells user agents to set the used value to a "reasonable" value based on the font of the element. The value has the same meaning as . We recommend a used value for 'normal' between 1.0 to 1.2. The computed value is 'normal'.
As you can see, there's not much to go on, even with regards to comparing line-height: normal and line-height: 1 (or 1em or 100%), because what constitutes a "normal" line height is up to the browser to decide as well. However, it looks like Chrome and Firefox do a good job of keeping glyphs within reasonable boundaries when asked to use a normal line height.
By the way, Chrome does not clip the descenders. It does render them outside of the content box, but it should never clip them to the bounds of the box unless you set overflow: hidden.
1 A CSS3 definition of the line-height property currently resides in this module, but it's immediately obvious that it's been long abandoned, or at least pending a rewrite. The module in its current state is extremely detailed, but suffice it to say that it's been largely ignored by both browser vendors and the working group.
'Line height is auto' => the browser gets to choose.
'Line height = font size' => user error: the text will be illegible, and again it is reasonable, indeed essential, for the browser to make some adjustment.
You must use some leading. Books for example may be set 10pt on 12pt line spacing.
OK, I've searched far and wide and come up with nothing more than anecdotal evidence to suggest that there is no recommended standard behaviour in the CSS specification for the precision of floating point numbers.
N.B. I'm not asking about the well known sub-pixel rounding problem.
The reason I'm asking is that IE seems to round percentage-based floating point values down to 2 decimal places, whereas Webkit and Gecko allow at least 3, or even more (I haven't tested).
For example:
li {
width: 14.768%;
}
When inspected in Chrome's Web Inspector or Firebug, the <li>s are correctly shown to have a width of 14.768%. However, in IE dev tools (IE9/8/7 mode), they have a width of 14.76%. This causes the actual pixel-based values to be completely out as well.
Can anyone shed any light on this behaviour, or provide a suitable workaround? I'd rather not have to resort to pixel-based values if possible, as the content needs to be fluid width.
I know it's pretty gnarly dealing with this many decimal places, but I'd be very interested to know which, if any, of these browsers is "correct"?
EDIT
Firefox seems to use the correct percentage values when shown in the inspector (not rounded to 2 decimal places), but is displaying the same behaviour as IE in terms of actual pixel placement.
There are probably many solutions for your problem, I would suggest these:
Round on 2 decimals by yourself for all but one, than reduce from
total width for last one.
Use table or display: table, than the
browser will fix the widths by itself.
For anyone coming upon this question, this article goes into depth about what different browsers do for percentages with decimal points: https://cruft.io/posts/percentage-calculations-in-ie/
As for which browser is correct, according to that article:
The HTML5 Specification doesn’t mention truncating or rounding decimal
places. Point 11 deals with decimal places, and says to keep looping
until “position is past the end of input, then return value as a
length”.