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.
Related
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.
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.
So I know that my question is pretty technical, but basically I would like to know specifically how the following CSS affects the display of text in <p> tags.
p {
letter-spacing:2px;
font-family:"Georgia";
}
I know that Georgia is a proportional font, that the designer has spent time crafting the spaces between letters to make the font more readable and visually pleasing.
But my question is how does the letter-spacing property affect this proportionality? Does this code add two pixels onto the spacing already defined by the type designer, or does it reset that spacing to two pixels?
This property is additive to what the font would normally use. So, 1px will increase it by a pixel. Sitepoint calls it "extra" space (with negative values allowed).
The W3C docs say the same thing:
"This value indicates inter-character space in addition to the default space between characters. Values may be negative..."
It is in addition to any default spacing.
See: https://developer.mozilla.org/en-US/docs/CSS/letter-spacing
From my experiment on Firefox on OSX, using a kerned font (Arial) as opposed to Georgia which does not appear to have kerning on my machine, I can testify that the spacing is in addition to existing spacing, and kerning, and can be either additive, or subtractive.
It is also worth mentioning that different browsers and operating systems replace fonts, and handle them slightly differently to each other, making it impossible to predict 100% how any font will be rendered.
Setup:
I have a simple box with rounded corners, that has a header and expands according to the amount of text, as discussed in Dan Cederholm's Bullet Proof Web Design (ISBN 0-321-34693-9).
Works great, EXCEPT when zooming in Google Chrome. Then the right margin of the box disappears.
It works in IE and FireFox without problems.
Example:
Example in jsFiddle
In chrome, it fails at zoom 110% and other zooms too. No problems in IE or FireFox.
Questions:
Any ideas what is causing this?
In general, what makes layouts zoom-sensitive (if any such general rule exists...)?
Is Dan Cederholm's book really bullet proof...?
How far back do you need to be compatible?
I mean, if you can drop IE7/8 you should be using css3 rounded corners. If you need to support IE8/7 you should definitely considder using graceful degradation in this case. It is probably not worth the time and effort to strive for perfection everywhere. That is simply a goal which cannot be met when browsers will never get updated again.
1) What may be causing this
That is a fairly broad question, I couldn't reproduce the problem, or really find one in Chrome 20 (beta) so I will just list a things that can mess it up.
General browser rounding errors, browsers aren't precise, weren't designed to be precise sub-pixel
Mixing px values with other values, different roudings make values add up differently..
Positioning of in-flow elements which get influenced by other in-flow elements on the page (these are hard to track down usually)
Parent element properties (parents with overflow hidden, fixed sizes, for example, I think this might be the problem here in the jsfiddle)
Bugs in browsers
Combination of the above
In this case jsfiddle has a crapload of containers and frames (with overflows set to hidden, fixed heights/widths, px based) etc on the page, even in 'full screen' view. So if you really want to make sure, make a html file on your own pc open/test with that.
2) In general, what makes layouts zoom-sensitive (if any such general rule exists...)?
In todays browsers this may not be all that relevant because zoom functionality is often very advanced and can even scale full-px based layouts without much problems. The only real problem browser which is still used today is IE7. The zoom capability of IE7 is atrocious, and for that reason you should only use % or em based values for text.
The only 'official' related guidelines can be found in WCAG 2.0, the w3 accessibility guidelines/techniques writeup:
http://www.w3.org/TR/WCAG20-TECHS/G142.html
So browsers can scale, modern ones have no problem here, but weren't designed to be accurate, it's also an impossible task with mixed units (em, %, px).
3) Is Dan Cederholm's book really bullet proof...?
Before I start here, I haven't read the book... I never read a CSS book (plenty other resources) in my life, but my first and foremost skill is dreaming it.
Let's start with "What is bulletproof?". Bulletproof in web-design means it will work, everywhere, and will not break, anywhere. This alone should give you a clue.
It might have very well been bulletproof when he wrote that book, but the web is a dynamic place, and even if I take the latest announcement blogpost for the book it dates from December last year. Since then at least 3 new Chrome versions came out (rough estimation) and even more Firefox versions. Microsoft sat on his ass that this time (we would've been in big trouble if they decided to do rapid release schedules).
Things changed, new bugs have definitely been introduced since then.
Regardless of what is breaking it, nothing is ever bullet proof, just very, very close to what you want to always happen, with slight variations between browsers.
That doesn't mean it is a terrible book, looking at his CV he's definitely and a guru on web-design, so he's probably right about a lot of things in that field. I just hope he explains why things are done in a certain way, because that makes you a lot wiser than just learning to do things.
A: "You always use EMs for text! EMs are annoying! Why do you do that anyway?!"
B: "I dunno, read somewhere I should..."
A: "Lets just use pixels! Pixels always work."
B: "Hmmm ok."
You just lost IE7 support. (whether that's a bad thing, is another discussion)
First of all, you're using a background-image, something I would have loved you to have mentioned.
1) So yah, as mentioned in the comments below your post, it's just rounding errors of the div, which crops the background-image.
2) I have no sources sadly, but in my experience, objects using text as a measurement are zoom-sensitive, pictures sometimes not zooming relative to everything else, and content with a predetermined 'set' size (such as textareas, radios buttons, etc).
3) Nothing is bullet proof, especially with something as ever-changing as the web that also behaves differently on different browsers. Hazards of the trade.
Is there any reason to avoid using text-align: justify;?
Does it reduce readability or cause problems?
Firstly, this is purely a design-related problem and solution. The design of your grid specifies if justifying text is needed. I think justify align alone has no major effect on usability. Bad typography that makes text illegible is what decreases usability. That said, make sure you have solid contrasts and a good balance of spacing in your type. Font-size matters too.
This site is a successful attempt at justifying text online. Since you can't control the spaces between letters and words nearly as much with CSS as you can with InDesign, it's a lot harder to justify text and not have 'rivers' of whitespace run down your rows, which happens when the spaces between words exceeds the spaces between lines. Things that make justifying text difficult: long words, row widths that don't hold enough words, and too much contrast between the text and the background colors; they make the rivers appear wider and more apparent.
The typographic ideal is to have an even text-block, where if you squint the text block becomes a uniform solid shade. So if you keep text at about 10px and 60% gray on white background, and have rows that fit about 20 words, justify align shouldn't look ugly. But keep in mind this does nothing to improve usability. Small, relatively light text annoys a lot of people, especially the older readers.
I should note that with (soft hyphenation) correctly separating long troublesome words like superawesome you can mimic proper typesetting (e.g. InDesign). There's a lot of stuff out there to help you do this. I would recommend the logic for hiding, manipulating, and displaying the text to be done on the client side, perhaps with this.
Edit: As others mention below, css hyphens are possible now, except not feasible (not in Chrome). Plus, css4 offers even more control.
text-align: justify shouldn't be used in browsers at the moment. They aren't good at handling the minute details within and the output ends up containing lots of rivers and there's no support for hyphenation (other than soft hyphens).
Note above was written 4.5 years ago. Things are slowly changing... http://caniuse.com/#feat=css-hyphens
Edit:
Hyphenator was brought to my attention in this answer's comments. It looks like it makes text-align justify worth using, check out the sites that use it. You may want to use javascript to apply text-align justify before using this script so that those without javascript don't get caught out.
Edit 2:
CSS now allows for hyphenation with the hyphens property [browser support]. PPK is now saying to add it to your stylesheets, whilst Eric Meyer says just add it for mobile.
Edit 3:
A good little overview of things available to us now, with some SASS.
The problems brought up by others about justify alignment are more prevalent with narrow columns. If your columns are wide enough in relation to the size of your fonts and other parameters then it's ok to justify the text. Let's say you'd want a minimum of 12 to 15 words per line in average. More is better.
There's no technical reason not to - it's purely a design decision. Many people find that justified text is harder to read, but I guess it depends on your situation. Though it works fine for print, generally web browsers do not give enough control over the eventual output of text to guarantee that what you're serving won't look like crap on some people's screens.
Your best option is to avoid justification.
I cant think of a compelling reason why not to justify text - at a certain point the volume and width of content almost demand that it be justified. Of course, you'll get issues with content consisting of certain word combinations, but to my mind if you're seeing rivers and unusually large spaces between words you have a different problem altogether - one of readability and clarity.
What I would avoid, at all costs, is centered body text. I don't think there's a greater red flag of ammateurish web design than that.
I prefer left justification (text-align: left) because it's generally more readable. It's also quicker to read evenly-spaced words, so I hear. Unless you have a stylistic reason for using justify, keep it left, right, or center. Especially for body text, use left. (Actually, you'd want something like "forward" for text in the other direction (e.g. Hebrew)...)
Justification should not be used without hyphenation. Here is a PHP based hyphenation library, and a port of this library to a WordPress plugin: wp-Typography.
Like any web design question... it depends. As has been suggested, justified text does not usually end up looking good in narrow columns. I'd recommend against it as a general rule in sidebars as sidebars are usually narrow.
With body copy at the often recommended 10 words per line (or with any amount above that) you will probably be able to get away with justified text and have it look reasonably good most of the time unless you're using a lot of really long words and/or strings.
I think I've pimped this site on StackOverflow before, but Jon Tan uses justified text in his body copy (within articles) and it looks great 99.99% of the time.
Erhh... No...!
[seriously] WordPress uses justify, and I think that's a pretty strong statement in regards to whether or not it decreases readability...
You can also use text-justify:newspaper. The text-justify css tag helps you control how you wrap the text when you justify
Text justification can be done in several ways.
Couple of definitions: Adjusting the spacing between words is "tracking" Adjusting the spacing between characters is "kerning" Good layout programs do some kerning automatically, and it varies by letter pair. The va of variable can be kerned closer than the xa in exact. Good fonts have built in tables of kerning hints to aid in this process.
In early days of monospace fonts it was done by inserting extra spaces between words. This made for very clunky looking output. If you had 4 spaces at the end of the line, and 6 spaces in the line, 4 of them would become double spaces.
Monospace fonts shouldn't be justified.
With variable width fonts, we have em spaces, en spaces, etc, and so the space could be better distributed.
I think this is where most browsers are now. It works reasonably well most of the time. For it to work well the following conditions need to hold:
You need a reasonable number of words on a line.
A large word at the end of the line can make problems.
The average word in English is 5 characters. So on the average you will have 5 characters (the 5 character word plus space wouldn't fit so gets bumped to the next line)
If you have 10 words on the line, then you need to add about half a standard space to each interword gap.
If the last word is a long one, like "headaches" and there isn't room for it, now you have 10 spaces to distribute. This starts to look bad.
This is where a hyphenation dictionary comes into play. Hyphenation can be done by algorithm, but there are enough exceptions that having a dictionary helps a lot. (There is a special character for soft hyphens for words not in your dictionary.)
Hyphenation can split a word so that the the line fills more evenly.
Empirically I decided that a 65 em line length made a good compromise. This gives 11-13 words per line a lot of the time.
Another approach to justification is to split the space up between characters. This avoids some of the problems above, but still looks odd if you are distributing a lot of space in not enough line. You see this in newspapers now and then where a word seems to have a full space between each character. This is a good argument for a longer line.
Good typesetting programs (InDesign, *TeX, Framemaker) do a combination of extra space in interword gaps, and tiny extra spaces between characters.
There is a new kid on the block, text-justify that can be used in CSS to modify the use of text-align: justify. Nominally it accepts the options
auto (default)
interword
inter-character (+ distribute for legacy reasons)
none
CanIuse https://caniuse.com/#search=text-justify
CSS working group https://drafts.csswg.org/css-text-3/#text-justify-property
CanIuse reports compliance only for Firefox right now, Chrome supports it but requires that you enable experimental features. CanIuse claims that support is buggy. Going to the Chromium bug tracking site, claims that it's fixed. Go figure. Haven't tested.
Other pragmatic points:
I made four changes to my site's style sheet:
Maximum line length of 65 rem
body font increase to 110%
leading increase to 125%
Justified text.
The result was that time on site and pages per session doubled.
Anecdotal, but may be worth your own test.
I think it is perfectly OK on print, but it is clunky on most Web browsers, by lack of fine control of spacing and hyphenation. Typographers can even play slightly on letter spacing or font contraction in some cases, as pages/columns (at least in magazines) can be finely tuned.
It should be mentioned that Internet Explorer (at least) up to version 8 does not render text-align: justify correctly. Instead it is interpreted as text-align: center.
Here is more info: text-align: justify
Caused me some headaches to find out why IE kept centering stuff. Maybe it saves somebody else some time.