Since the beginning of February there were some proposals for the CSS3 specification. These proposals are not yet part of the specification and will likely be changed until they get adopted by the CSSWG. One of these drafts is the CSS Hierarchies Module Level 3.
So what’s the Hierarchies Module? And why “Level 3″?
The Hierarchies Module is not exactly new. It exists since the very first steps of CSS and was first released in Dezember 1996 with CSS1. The CSS1 specification is still up, so check it out if you want to.
When you write CSS you always use selectors to target the element you want to style. This works pretty much straight-forward: The right-most simple selector is the one which get the declarations assigned that are defined in the ruleset.
These selectors define a certain hierarchy in your stylesheet. Note: Please make sure to read Tab Atkins’ Reference for CSS Spec Terms.
An example
Today you would target some links in a navigation like this:
#nav ul li a {color:#000;}
If you’re smart and your markup allows you to do so, you may write:
#nav a {color:#000;}
The li-elements need to be inlined as you want a horizontal navigation:
#nav ul li {display:inline;}
Furthermore the navigation should be aligned on the right and all the links centered:
#nav ul {text-align:right;}#nav ul li {text-align:center;}
This leaves us with a lot of repetition for the selectors.
#nav ul {text-align:right;}#nav ul li {text-align:center;display:inline;}#nav ul li a {color:#000;}
With the Level 3 proposal by Tab Atkins Jr and Shane Stephens (working for Google) this is about to get a little bit easier. The existing system will be extended with some new functionality. This is why it’s called Level 3. (Also it will likely be part of CSS 3 – and not 4 or 10 or something.)
What’s new in there?
Lately you saw the rise of CSS Preprocessors. Everyone hasan opinionon this. The thing why so many developers use them is that they help to organize the CSS-code you are writing.
Preprocessors have brought up another idea of CSS hierarchies. And with the CSS Hierarchies Module Level 3 this has been adopted.
The specification draft allows you to nest your rules and use the &-character to reference a parent selector in a certain rule.
Here’s the example from above with the new hierarchy:
#nav ul {text-align:right;
& li {text-align:center;display:inline;
& a {color:#000;}}}
As you can see there are no repetitions for the selectors as you can reference them by just writing & and nest them properly.
How can we use this today and when will it be ready for the “real world”?
As you may guess this is not implemented in any browser yet.
As this spec is written by two Google-guys it’s likely that this will be implemented in Chrome in the near future. At the moment this is not working with Chrome 19 (Canary) or WebKit Nightly.
I’ve made this Dabblet to check if the module is supported in a browser or not. caniuse.com does not provide any data for the Hierarchies Module yet. Aside: Check my Dabblet Chrome App to view all your latest dabblets if you’re a Chrome user.
Tab Atkins proposed another style for nesting. To reference the parent selector you use @this instead of the &-character. Peter Beverloo wrote about this a year ago. Also Tab Atkins has an article about his further plans. This variant was not implement either and is replaced with the new draft for the specification. Anyway you could view the dabblet I’ve made for this propose.
Preprocessors
As mentioned above CSS preprocessors offer the chance to use something like hierarchies in there own way. Here are two examples:
SCSS (aka. SASS)
#nav ul {text-align:right;
li {display:inline;
a {color:#000;
&:hover {color:gray;}}}}
Stylus
#nav ul
text-alignright
li
displayinline
a
color#000
&:hover
color grey
As you can see there is a difference in how preprocessors treat the &-character as a reference: In the CSS specification draft & is obligatory in every nested rule you write to reference the parent selector. Preprocessors need them only if there is a pseudo-class or -element or a combinator (such as ~ or >) used for a specific selector.
As I stated in the introduction it may happen that the specification will be changed until it becomes final or is adopted by the CSS Working Group. I recommend you follow the discussions about this topic in order to stay up to date.
When this specification will be implemented by one of the browser vendors it’s just a matter of weeks until it will be adopted by the others I guess.
But, as the draft states, this is not yet part of CSS:
This document is purely an Editor’s Draft. It has not yet been adopted by the Working Group, and should not be considered to be part of CSS.
Personally I hope that referencing the parent selector with & will not be in the final specification as it is now. It’s not needed as the rules are nested anyway and preprocessors nowadays treat them better.
Anyway the new nesting is pretty useful as it reduces the redundancy of writing selectors in CSS. In connection with other upcoming specifications like the CSS Variables Module Level 1 this is what is needed and will be helpful for every web-developer once it will be implemented in browsers.
There is a big discussion going on at the moment covering the actual point of how to deal with images and media et al. on mobile-phones and other devices as there are some things that don’t work as on a desktop computer:
Bandwidth
Screen size
Performance / Velocity
The question is how to deliver responsive images on a mobile website.
You maybe use something like img { max-width: 100%; height: auto; } in your responsive design to prevent images from being bigger then the screen of a mobile device.
In most of the cases this shrinks images in its displayed size, which is a processor intensive thing to do – especially when you are on a mobile device and don’t have endless processor capacity this hurts.
The shrinking itself does not change the file-size that has to be loaded; it remains the same as on a desktop for example. As bandwidth is the bottleneck these days if you are on a mobile device, this is the issue where people want to see some improvement.
What can we do about it?
There are a couple of proposals and known techniques on how to solve the problem:
1. Resize images with PHP
This is something you could only do if you know the screen-size before you load the images them self. So you have to inject HTML through JavaScript for example and change the sources for images accordingly.
Please have a look at the article for detailed information.
An idea that goes beyond the replacement of images with the attr()-function is the usage of content: url(myimage.jpg) replaced;. This is something suggested by Tab Atkins Jr. on the W3C www-styles mailing list – called replaced content.
Something about replaced content appears in the CSS-spec but it does not look to be exactly what Tab is referring to.
3. Introduce new attributes to the <img>-tag
Anselm Hannemannshares the idea of introducing a media-attribute that has some sort of “sizing-parameter”. It is supposed to be combined with the media-src-attribute which also has the sizing-parameter.
The HTML could look something like this:
<imgsrc="myimage_xs.jpg"media-xs="(min-device-width:320px and max-device-width:640px)"media-src-xs="myimage_xs.jpg"media-m="(min-device-width:640px and max-device-width:1024px)"media-src-m="myimage_m.jpg"media-xl="(min-device-width:1024px)"media-src-xl="myimage_xsl.jpg">
As you can see the media-attributes contain media-queries which describe when to take a certain image-source.
4. Using JavaScript
There are some ideas on how to deal with this topic using JavaScript.
The FilamentGroup for example published its “Responsive Images”-project on GitHub. They are using “Mobile-First” to present a small-sized image on every device and replace this with JavaScript on window load.
You can find out more about how it works on their blog. They also published a demo.
Peter-Paul Koch presented a possible way on how to combine media queries with JavaScript. Which is not really new I think but a good summery.
Another approach could be a new attribute for the script-tag: Scott Jehl suggested to call it preparse. The script could then be used to replace sources in HTML fitting the current client-need.
5. A new image-format containing different sizes
People aso had the idea of creating an own image-format which contains for example four layers with different image sizes. The image then “decides” which format to take and serves this to the client without its three sibling-layers.
At the moment there is a format called MrSID developed by LizardTech which can have one or more compression rates.
Another approach is the JPEG 2000 file-format. It can carry out different optimization-levels for images. Read more about it on the Wikipedia-page I linked above.
Media? But this was only about images…
Yup, right! Images are just one aspect when it comes to responsive media.
Videos for example are another thing. YouTube offers different video-sizes for watching. You have to choose manually which one to use. A possibility to select this resource automatically, build into the browser would be awesome!
JPEG 2000 has a video-equivalent developed by the same group of people as the JPEG-format called Motion JPEG 2000. Find more information about this here.
Conclusion
As it turns out many developers are not aware of the problems that come up with a real responsive design – even HTML5-specification writer are calling it “a niche problem”. This is why it is hard to develop a specification for a native API as for example Anselm Hannemann suggests.
But maybe the decision which technique might be best for solving the problem of serving responsive media has to be finished first before anything is spec’d up.
Moar!
Some more resources where the topic is discussed:
A List Apart started the whole “Responsive Design”-discussion with an article by Ethan Marcotte
As you might have heard the <time>-element was removed from the HTML5 specification last saturday by Ian “Hixie” Hickson, the editor of the spec. Hixie decided to remove <time> and replace it by the more general <data>-element.
A question that came up: Why got<time> removed and why did nobody stop Hixie?
Well: There was a discussion on the bug-tracker about replacing <time> with <data>. But nothing about it on the mailing-list and stuff… and Hixie decided to drop <time> and replace it by the power he has as the editor.
Not only <time> was removed from the specification but also its attributes datetime and pubdate. pubdate was the only way to indicate when a blog post or web-page was published.
As I'm not into the processes at W3C and WHATWG I decided to dig a little bit into it and keep track of what was going on about that issue with <time>.
Steve Faulkner was the first one (for what I noticed) that tweetedaboutthat intensively and was really upset by the dropping. Furthermore it was his tweet that encouraged me to keep track of the whole story.
As so many people where effected by the change that was made to the spec and many people though it was a bad decision there was hope that this story was not over yet… And it wasn't.
Again Steve Faulkner tweeted:
"I feel confident that <time> will be back in the W3C HTML5 specification by the end of the week"
This was a decent statement as you can say by today.
There were proposals on how to deal with <time> and how to improve it for the future and get it back into the spec. A leading role in this process is held by Tantek Çelik. Read his comment on Bruce Lawson's post. Also Stephanie Sullivan Rewis has some interesting thoughts.
And then - the Turningpoint
Currently the TPAC 2011 is happening which is a conference and meeting of the W3C and its members.
At (Please notice my use of <time> in this case. Nice, right… right?) people of the W3C HTML Working Group met and discussed about <time> and its removal. You could have followed the discussion on IRC on W3C's channel #html-wg. Here you can find the "minutes" (a transcription) of it. Tantek added this as a point for discussion to the Agenda.
As this all was said, there was a mail on the mailing-list by the Chairs of the HTML WG asking the editor of the spec (Hixie) "for a revert of this change to be completed no later than the end of day on Tuesday 8th of November". If Hixie will not change this until Tuesday the Chairs will ask the W3C staff "to make this change". What ever this means then… I have no idea.
Today Tantek began to define some new requirements for the <time>-element and its attribute datetime (especially the syntax of the mentioned attribute).
So what's the conclusion now?
All the things I mentioned above show how strong the community is and how many people try to get the best out of the tools we have.
Hixie's decision to remove the <time>-element in favor of the <data>-element was not found democratically by everyone contributing to the HTML5 spec but was a bossy behavior.
Personally I learnd a lot about the process within the W3C, the WHATWG, how the specification is build, and so on asf… This was pretty good and I feel good about how things work.
I hope there are more people who like keep a little bit more track of what is going on with all the new stuff and be part of decisions that are made.
Thank you for reading all the words I wrote.
Thank you Steve, Tantek, thank you Eric Eggers, Shelley Powers, thank you everyone who was able to do something about the odd removal of <time>. You guys rockkk!
The CSS3-spec is full of wonderful things. Sometimes things that are not so desperately needed as others but anyway… good to have them.
One of these more or less needed properties might be resize. It is part of the CSS3 Basic User Interface Module. What is really useful with resize is the ability to restrict the resizing of textarea for example. But it is possible to resize every element you’d like to as this demo by Simurai shows.
There are four values for resize that are kinda logical:
This morning @t3node asked me about something CSS-related. This was kinda new for me because he never did this before I guess… He showed me a website he had printed and asked me to explain him, how it is possible to show links in printed websites with their reference printed next to it. He was kinda upset why not every frontend-developer includes this in his/her stylesheet when it comes to designing a new website. I wanted to explain everything that’s related to this topic that I’ve ever heard of but he asked me to write this blogpost as heisnot pretty used to CSS and stuff.
Styles dedicated to print
To get this feature for a website you need to define some print styles.
1. link-Tag
It is possible to load up a stylesheet that is dedicated to server styles only for media print with
Where media="print" is the important part here as it tells the browser to apply all styles it contains only for print-views of the website. I do not recommend this method because of some drawbacks for performace:
The client has to load the CSS-file even if it does not need it
This implies another HTTP-request
Even though it is not a lot: the browser needs to render the styles
2. @import in CSS-file
Another possible way to render styles only in print is to include a file with @import url("some-print-styles.css") print. This also has drawbacks on performance. Even more as the link-method as files get blocked for downloading in your browser if @importis used.
My favorite method to include styles for print are media-queries. It is possible to add styles for print via @media print. Maybe you are familiar with this because of media-queries dedicated to mobile devices. Once you’ve set up this environment you can start adding some styles for any print of your site. I recommend to add display: none;for elements that are not pretty important in a printed-version. This could be the sidebar and the footer or the navigation. The thing why I’m originally writing this is how to include the reference of a link in a printed version of a website. So I’m just going for it. It is just one pretty little rule!
Pseudo-Elements for generated content
A good use-case for pseudo-elements:
a[href]:after {content:" (" attr(href)")";}
a[href] selects all links with the attribute href set and creates content :after it. attr(href) tells the browser to use this attribute as content. You may want to select a little bit different as you don’t want to display references in the navigation or so for instance. HTML5 Boilerplate makes use of this, too. These little features are why I love it so much. Go check it out and contribute. Chris Coyier has a pretty awesome article, tutorial and demo at CSS-Tricks which has nothing to do with print but describes the use of pseudo-elements and contentreally good. You should definitely read this.
Browsersupport
@media print is supported in all browsers for what I know. Except Internet Explorer 7 every browser supports :after at least good enough that content works with it. The bottleneck here seems to be attr(href). As I researched this it turned out that generated content with attr() is valid CSS 2.1. The spec adds a warningon this vary topic:
In CSS 2.1, it is not possible to refer to attribute values for other elements than the subject of the selector.
You will find more information on attr()in the CSS3 Specification. It seems as every browser (that is actually used) is going to support this except IE7 and below. I’ve set up this demo so you can test it in your favorite browser and edit it yourself. I would be glad if you share your results and thoughts on this topic in the comments.
Conclusion
As it turns out it’s kind of the right to support straightforward things. I believe everybody could at least add some default styles for print to a new website like HTML5 Boilerplate does by default. The little trick with pseudo-elements can also be pretty useful for other elements like abbr aso. Later on I noticed that @t3nodes website does not support this feature for print either. Maybe it will after he has read this post. My website and this blog do not make any special use of printed styles as I think it is not necessary that anyone prints out my blogposts. I don’t like to print thinks for myself as I believe that you could save some paper in regards to environment. But this is your decision – or the one of your customer. Edit Thanks to Nicolas for his hint about the difference between pseudo-elements and pseudo-classes. You should also consider using ::after instead of :after. But be aware that IE8 does not support this.
When you link to a file like an image or a PDF-document it will be displayed within the browser normally. The download-attribute in links prevents this behavior and offers the file as a download in your browser.
Definition
The spec allows the attribute for having a value. This value can be a string which defines the name of the downloaded file. As a default the browser takes the file’s original name.
And this is what it could look like in HTML:
<ahref="path/to/file/file.png"download="a-nice-image.png">Download this file</a>
The value of the download-attribute overwrites the filename with a-nice-image.png.
The Content-Disposition-header can overwrite the name for the file.
This really nice demo exports a written text and offers it as download (but be aware of browser-support – see below).
Browsersupport
The download-attribute is not supported very good at the moment of writing this article.
Chrome supports it since its version 14. Version 14 is only a view weeks away from the stable release.
Firefox 8alpha (Aurora-channel) does not support it as far as I experienced it. I did not find anything about any intensions when Mozilla will include it.
And the other ones? No support yet!
So, what’s the fallback?
There are other techniques to serve a file that will be offered as a downloads in the browser. For instance you can use an HTTP-Header that’s a mime-type that the browser does not know.
In browsers we do not have the ability to automatically hyphenate continuous text. This is an issue when you are using text-align: justify; for instance because the text may look really bad.
Hyphenation means splitting words to improve the layout of paragraphs.
CSS3 Properties
CSS3 adds six properties to the list of useful thing. These are:
The most important one is hyphens. More to this one later.
You can add dictionary-files with hyphenate-resource so the browser has a better chance to render your text with the right hyphenation.
hyphenate-before sets a minimum number of characters before the hyphenation.
hyphenate-after does the same as hyphenate-before but for characters after the hyphenation.
hyphenate-lines defines about how many lines a hyphenated word is written at a maximum.
with hyphenate-character you can specify which HTML-entity should be used, e.g. \2010.
The main property of this stack is hyphens. It accepts one of three values: none, manual or auto. The default one is manual, where you can set hyphens via ­. auto it the better one for continuous text while words get split if possible and available. And none does not hyphenate at all even if there is a character set for a possible line break in a certain word.
There is one thing you have to be aware of if you use this property: You have to define a lang-attribute on an element that carries text that should be hyphenated.
Currently hyphens is supported in Safari 5.1 and Firefox 6. For Firefox 6 the lang-attribute must be set as mentioned above. Also it only supports english.
It is not working in Chrome 15.
You have to add some vendor-prefixes for support in browsers:
Edit:
Thanks to Ash for letting me know about my mistake using hyphen instead of hyphens.
Update
I just found this issue at the Modernizr issue-tracker where a test for the hyphens-attribute is discussed. There is a test in the latest GitHub-Version for it. Search for csshyphens.