Printed newspapers use justification for paragraphs most of the time, as it is simply easier to read. But even though we have the declaration text-align: justify; for quite some time now, if you want to use it with text blocks in the web you usually end up having big gaps between words. That's because long words drop into the next line leaving whitespace and therefore gaps between the previous words. With CSS3 hyphens1 this finally changes - for many languages at least2.
First of all - to use this feature, you must set the language for your HTML document - which you are doing already anyway, aren't you?
Just in case you are not sure what I am talking about, here a quick example:
<html lang="en">
This is how you set your document's root language to English3. You could also be more specific and set to British or American English "en-GB" or "en-US". Swedish would be set with "sv", simplified Chinese with “zh-cn”, etc.
Once this is done, we can start using the hyphens declaration to control the flow of our content. With all the required vendor-prefixes4 this will look like this.
p {
-webkit-hyphens: auto; // Safari
-moz-hyphens: auto; // Firefox
-ms-hyphens: auto; // IE 10+
hyphens: auto; // W3C WD (net yet supported by any browser)
text-align: justify;
}
Chrome and therefore Opera are the only major browsers that don’t yet support hyphens. They do support a new feature querie - the @supports5 rule, though, which we can use to set text-align to left targeting currently only them. And this method is even future proof. Once Chromium implements the feature, this rule will be ignored and the text becomes justified.
/* set text alignment to left for Chrome and Opera */
@supports not (( -webkit-hyphens: auto )
or ( -moz-hyphens: auto )
or ( -ms-hyphens: auto )
or ( hyphens: auto )) {
p {
text-align: left;
}
}
If the numbers of visitors on your webiste using IE8 or 9 is high enough, conditional comments could be used to adjust the reading experience for them as well.
You might have guessed it, I use it in this blog. So check out the paragraphs and hyphens here with the latest Firefox, Safari or IE to see it all in action.
Six month have passed since the last article about this topic. During that time the bug received around 30 new comments from the community supporting the implementation. That or at least that as well have somehow convinced the Chrome team to get Pointer Events back onto the agenda.
On March the 25th this comment was added:
Thanks for all the feedback everyone. We've heard it loud and clear and are working on a plan to hopefully allow us to ship pointer events in Chrome.
See https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/ODWmcKNQl0I
Because of the amount of comments a new bug was filed for the actual implementation: issue 471824.
Some of the low hanging fruits have even already been fixed - check the list of blocking tasks to the right.
jQuery team calling in meeting after Chrome team stops work on Pointer Events
September 06, 2014
Pointer Events are a proposal brought forward by the IE team to create and API for all the different input models we currently have and for new once that might come. They put a lot of work into the developers hands, e.g. by providing/creating big chunks of the implementation for Firefox through MS Open Tech, etc. So there was a moment were we had IE, Firefox, Chrome and Opera on board.
With Apple/Safari being completely opposed to the new proposal Google now backed out after it already started with the work.
Now the "jQuery Foundation recently pulled together a meeting of representatives from IE, Chrome, Firefox, Dojo, IBM and the different jQuery project teams."
(login with your Google account and hit the star next to the bug's subject line)
One less prefix - Firefox is dropping the ‘-moz-‘ from ‘box-sizing’
April 12, 2014
The CSS ’box-sizing’ property was welcome by the community as it gives the possibility to change the way width and height of elements are calculated.
In the standard box model the set width applies to the content area adding padding and border on top of it. For example, if you set an element’s width to 100% and add padding and border, the overall width of the whole container is greater than these 100%. This is making it difficult to specify an element’s dimensions with fixed padding and/or border and a flexible content.
Internet Explorer up to version 5.5 implemented a non-standard version where the width included padding and border. Obviously this caused confusion for developers - having browsers calculating the width of an element differently. However, some developers preferred IE’s old implementation as the more logic approach for designers and so the ‘box-sizing’ property was added to CSS3 and implemented as early as IE8.
The default value is still 'content-box', meaning the width is set within the content area. The 2nd value is 'border-box', that now includes padding and border within the set width of the element.
Firefox supports a 3rd value - 'padding-box', which has been added to the specifications later and is not supported by any other browser yet.
With Firefox 29 moving to release week of April 29, the last prefix falls. This is good news as it will be one less thing to worry about when developing the next site. Or it might mean updating the LESS and SCSS mixins.
Anyway, I would rather wait for version 30, as it seems that the adaption of a new version takes up to 4 weeks after it’s release. If your project is supporting the ESR version you might even want to wait until version 31 is out.
And on a site note: You might still need the -webkit- prefix if you want to support e.g. older versions of the Android Browser. Find the full list at http://caniuse.com/css3-boxsizing
