Should I avoid using "text-align: justify;"? - css

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 super­awesome 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.

Related

Can't see any difference with text-justify

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.

Break Lines by Whitespace Only

Is there a way to word wrap only when there's white space? Right now I have it breaking one some special characters (?-!) but I only want to it to break at the tabs to keep the columns straight.
Example:
gw5g7#IVKNcvP02r pFJxywU#B-L.Qp.f u#hGsrr8g.S4,GtR !t1oa(2%?tb()lML -cky!YT8-/*xsCfT nbjAekWZenH8udR8 sM*e#aSM#89C#$4Z (r6+$]1j9mw)U72+ !V2O2_UO7(mMM6HP o6u?D&97&QNJ93D1 .a,,hg%vtl[^PGLO F(v*CP#aJD13_m&. /9?[OL?ktCmv8gRP 6CSZuRuu98MT3*,R O/cclHD+HrG4G^h9 JI]edN.F]hRg8,&n -6S/S9U[Ai]Sh[8D LM+Gpkk7-BP1pgpR -XX4EZjb24Kl9Kgm j!eK#0?i&kwo&ADg lvZ#)T%xRFYOV#-.
No, there is currently no way in CSS way to word wrap only when there’s white space. The reason is that browsers apply, rather inconsistently, some of the Unicode line breaking rules. The rules allow line breaks at many points, e.g. after some punctuation characters in some contexts. In the CSS3 Text draft, there are some proposed additions that would let authors have better control over such issues, but mainly as regards to rendering East Asian languages.
You would need to wrap pieces of text in elements (like span) and set white-space: nowrap on them, or use the more concise nonstandard but widely supported nobr element. In the example case, this would be rather straightforward and could be done with a small piece of JavaScript code (or server-side or in a preprocessor when the page is generated):
<nobr>gw5g7#IVKNcvP02r</nobr> <nobr>pFJxywU#B-L.Qp.f</nobr>...
However, it is not clear whether the multiple spaces should be preserved and what the rendering context is (pre? textarea?). This is a different problem and best addressed as a separate question.

Balancing columns

I have some content set to be in 3 columns, but as it wraps from column to column in Chrome, it adds the margin at the top of the next column, which makes sense in one way, but looks very bad.
Here is an example of what I'm talking about: http://www.sanguinediabetes.com/wp/concept/
How can I style this so there is not an ugly gap at the top of some of the columns, but still space between the paragraphs that end midcolumn?
What you're seeing is arguably the correct behavior for multicolumn elements. The bottom margin you've set on each paragraph will push down subsequent paragraphs, even when there's a column break just before those paragraphs. Yeah, it's arguably weird, but hey, there are even bigger issues with this layout model that need fixing right now.
One way to address your problem would be to remove all paragraph margins and force a column break after certain selected paragraphs. The revised draft of the spec from last year provides for a column-break declaration. But support so far is literally nil, the MDN article on the topic is nonexistent, and chrome doesn't even pretend to support it. Basically, you're in some pretty new territory, and the tools aren't quite there yet.
While I'm here, there are other pressing problems with your layout. To see the most basic one, try sizing the viewport narrow, around 500 pixels. Your columns become painfully thin and unreadable, really just a stack of individual words. Considering that your text says "Mobile phones have helped to popularize the primary concept of interface design: it shouldn’t be the duty of the user to muddle through complex procedures and hidden options to achieve simple tasks, or even complex ones. It is the duty of the software to be designed in such a way that every operation is simple, obvious and fast."? This is kind of funny. Have you tried looking at this on a mobile phone? I would recommend it, considering the content.
Column-count is awesome and all but if you're looking for any real browser compatibility you're much better off with good old floated columns for now. Perhaps try some variation of the one true layout.

Chrome, CSS - zoom sensitive layout

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.

What are the differences between the CSS and Latex box models?

What are the differences between how CSS and Latex organize boxes? (Either paragraph or graphical elements.)
The general scheme, of having a hierarchical boxed representation of page layout produced from processing of input language, and that is then turned into the rendered page, is basically similar between the two models. The four differences that are most impressed on me are:
The CSS boxes model is a robust abstraction, whilst the layout of boxes in the Tex model is operationally determined: as boxes are being laid out in the Tex model, the code can break apart and re-layout earlier boxes.
While Tex's layout model is text-oriented, like the CSS boxes model —and as opposed, to, say Adobe's InDesign page-oriented layout model that's very much about fitting together blocks to cover each page— it still has quite a few page-oriented abstractions, like determining "badness" of vertical space in order to place footnotes - there's nothing like that in the CSS boxes model that I can see. Context has a more sophisticated page layout model, that allows both text-oriented and grid-oriented layout together.
Both the CSS model and the Tex model have notions of block-level boxes (vboxes) and inline boxes (hboxes). However, while you can specify using CSS that a block-level box occurs inside an inline box, section 9.2.1 of the CSS2 standard says that the semantics of this is to turn the outer inline box into a block-level box, so the CSS box model basically forbid block-level boxes from occurring within inline boxes. Tex, by contrast, is happy to have vboxes inside hboxes, which offers power to do things like place pieces of text above text inside a paragraph's text.
Most importantly, the CSS box model has no notion of flexible glue, making scaleable page layout much trickier, and is, I guess, the reason why fixed-width webpage design is dominant.
The specs for CSS are not hard to find and of course they contain a chapter on the box model.
The information is somewhat harder to find for LaTeX, but you can look here, where you can read:
LaTeX builds up its pages by pushing around boxes. At first, each letter is a little box, which is then glued to other letters to form words. These are again glued to other words, but with special glue, which is elastic so that a series of words can be squeezed or stretched as to exactly fill a line on the page.
I admit, this is a very simplistic version of what really happens, but the point is that TeX operates on glue and boxes. Letters are not the only things that can be boxes. You can put virtually everything into a box, including other boxes. Each box will then be handled by LaTeX as if it were a single letter.
I think this is very different from CSS, but for details I'm afraid you have to read books, e.g. The TeX book by Knuth, or the LaTeX companion by Mittelbach et. al.
Miel.
There is a dearth of discussion on this important matter.
There is one key reason I wish that HTML/CSS layout was based on TeX: the lack of glue or springs.
TeX didn't really need to use this feature as the use of TeX was always to lay out content on fixed pages. But the most natural thing on a web browser (ever since screen sizes have gone beyond 640 x 480 pixels) is to resize it, especially the width.
It is impressively difficult in CSS to lay out something like a slide-show, with a frame in the center occupying most of the space and 2 thin stripes of forward and backward buttons, right and left respectively, that then resizes gracefully, especially as we get to the narrow end of the spectrum. But also, on the wide end without wasting all the space in margin as many modern CSS layouts do.
In TeX that is easy. You have an hbox, with a grow- and shrink-able center frame, and the forward and backward button are fixed size.
As you increase the page width, only the center frame expands, and as you reduce the width, only the center frame becomes narrower, until all its shrink value is used up (minimal width) then it stops (and supposedly a horizontal scrollbar would appear.
This is the one key aspect I feel is badly missing from CSS. It is so much more natural, and amazing that Knuth had invented it at a time when dynamic screen layout was decades away from becoming reality. And it is sad that this genius was forgotten.
I assume that the box and glue model was argued to be
too hard on real-time computation capacity of earlier web clients
too "difficult" to implement for Microsoft programmers
too "confusing" for beginners to use.
All of this are very weak arguments IMO.
The same issue appears in Java/Swing Layout schemes. I remember I implemented a real Box and Glue Layout in Java to use with SWT on a project some 15 years ago. Once you have it is's so awesome.
I am awaiting a real box and glue layout option to appear in some next generation of CSS before the end of my programmer career, and I hope soon, so I can still use it for a few years.

Resources