Summer is nearing its inevitable end and this column has taken a small vacation (as many of you have noticed, there was no 'Hot in web standards' for July). To redeem ourselves, expect some juicy content in this instalment.
In the two months since the last article, yours truly joined the W3C to work in developer relations and web education. In addition, I am now officially a part of the CSS WG and the HTML WG so hopefully I will have a more informed perspective. However, any opinions I express in these articles are personal and do not necessarily represent W3C.
The CSS Working Group had its third face to face (F2F) meeting for this year in San Diego, CA on 13-15 August. F2F meetings are basically a few days filled with multiple hour-long meetings between the most active members of the Working Group. Every meeting has a certain topic (for example: CSS Variables) and usually many resolutions are made over its course. Not all of these decisions are interesting for authors, because they often concern edge cases that only few people will ever encounter. However, a significant percentage of them are, so this month’s 'Hot in web standards' will be more CSS-heavy than usual.
The end of -prefix-ing?
We’re all familiar with the problems that prefixes entail. Most of us see the benefits they offer, but they still bother us when we have to repeat a declaration five times to get the result we want. The experimental features policy was one of the topics discussed in the F2F. While no formal resolution was made, the consensus in the group was to adopt a new policy, proposed by David Baron and fantasai of Mozilla.
The new policy, in a nutshell:
- Ship experimental features unprefixed but only in beta and nightly builds of browsers. Once three browsers implement the same feature, and it works in roughly the same way, all three of them are allowed to ship it in a stable build, so that developers can start using it in production.
- When that happens, both prefixed and unprefixed versions of the feature will be supported. This will enable you to make adjustments for specific browsers if you discover an incompatibility (after you report it of course). This part of the policy is still under debate.
- If a browser breaks the rules and releases experimental features in stable builds, other browsers can follow, as long as it’s not a completely terrible idea.
If you are interested in the nitty-gritty, you can read the detailed policy and the whole discussion in the minutes.
First Public Working Draft (FPWD) of SVG 2
The previous version of SVG, SVG 1.1 was last updated in 2011. Since then, the SVG WG was hard at work, fleshing out the next major version of the language: SVG 2. On 28 August, the efforts were mature enough to be published in a promising public Working Draft of SVG 2. For anyone following the progress on SVG, this is big news. SVG 2 adds new features and solves many of the issues that SVG 1.1 suffered from. Not all planned changes are already in the SVG 2 draft. Many of them will be added in the future, as their details become more concrete.
Get the Creative Bloq Newsletter
Daily design news, reviews, how-tos and more, as picked by the editors.
New draft from Adobe: CSS Masking
Following its newfound tradition of bringing Photoshop-style effects to CSS with a simplified syntax over their SVG counterpart, Adobe put forward a CSS Masking proposal. The draft attempts to not only bring SVG masks to HTML content, but also provide a simplified syntax for them that doesn’t involve SVG markup at all. This simplified syntax is heavily based on the proprietary -webkit-mask shorthand.
New draft: Intrinsic Sizing
The prolific duo, Tab Atkins and fantasai published yet another draft: CSS Intrinsic & Extrinsic Sizing Module. If you are wondering what these terms mean, here’s the gist:
Intrinsic size: The size an element has based on its own contents and not any surroundings. For example PNG images have a certain width and height, which is their intrinsic size. On the other hand, SVG images can have an intrinsic size (if both width and height are specified), an intrinsic ratio or no intrinsic dimensions at all.
Extrinsic size: The size that an element’s surroundings force on it (context-based). For example, an unstyled paragraph with no set dimensions will get the width of all the available space its parent provides: This is extrinsic sizing.
This new draft adds some pretty cool features that solve very common use cases. To name a few:
- Remember the ugly hacks to contain floats? In a few years, you can free up the space they occupy in your brain. In the future it will be as simple as min-height: contain-floats
- Remember those times when you wanted to give something a height: 100% but it didn’t work as expected? Soon you’ll be able to use things like height: fill-available
- Remember when you inline-blocked, floated or absolutely positioned an element just to get it to automatically adjust its width based on its content? Soon you’ll be able to have your cake and eat it too, with width: fit-content
Work starting on Image Values 4
Remember linear-gradient(), radial-gradient() and co? Cutting edge stuff, right? Um, not quite. They belong to Image Values 3, which is in CR and fairly mature by now. The new kid on the block is Image Values 4, still only an Editor’s Draft (ED).
Image Values is one of my favourite CSS modules, because it’s very visual. Level 4 adds some very exciting new stuff:
- Conical gradients. I’ve been wishing for conical gradients ever since I first used a CSS gradient. They enable so many effects we now need SVG files for. I even wrote a proposal for them in 2011, which this draft is based on.
- cross-fade() which will enable you to mix and blend different images. For example, cross-fade(50% url(foo.png), url(bar.png)) is midway between the two images, both in dimensions and in the actual pixels.Fun fact: this function was first specified in Image Values 3, but was deferred to Level 4 owing to the lack of implementations. Ironically, shortly after that, WebKit implemented an experimental version of cross-fade(). I made an example of an animation that takes advantage of cross-fade so you can see it in action. Notice how there is no cross-fade() call in the CSS code. It’s used by the browser behind the scenes, to represent the intermediate values between the two images.
New proposal: Cascading Attribute Sheets (CAS) — Like CSS, but for attributes!
Tab Atkins recently made a bold proposal to the WebApps WG: An entire new language, although based in existing ones. The syntax of CAS is exactly the same as CSS, but instead of setting CSS properties, it configures HTML attributes. To make implementations easier and faster, the attributes are applied when the element is added on the page and not dynamically. This limits this language’s usefulness, but it’s still a lot simpler than the JavaScript equivalent.
New proposal: Responsive Images Extension
If you’ve been following the news on HTML5 (or this column), you may remember the turmoil on responsive images. Recently, Microsoft’s Adrian Bateman and Responsive Images CG leader Mat Marquis co-authored a proposal for a Responsive Images Extension. It attempts to combine both prevailing proposals (<picture> element and srcset attribute) into one spec.
Some online media publicised this story with headlines such as 'W3C Publishes First Draft of HTML Responsive Images Extension'. However, this is inaccurate on a number of different levels. Editor Drafts (EDs) are not necessarily endorsed by W3C. Any WG member can post an ED about anything. EDs are basically proposals, not specifications or drafts. The existence of an ED does not imply endorsement by either W3C or even the Working Group it belongs to.
New Adobe proposal: multiple pseudo-elements
If you’ve been keeping a vigilant eye on ways to minimise wrapper elements in your HTML, you’ve surely taken notice of all the crazy things you can do by utilizing the ::before and ::after pseudo-elements. If you’ve also used those techniques in practice, you’ve probably faced their limitations: We cannot combine multiples of them, because we only have two pseudo-elements we can use.
This problem was originally tackled as early as 2003, in the CSS3 Generated and Replaced Content Module. However, the draft was abandoned and nobody implemented it, so it was forgotten in a dusty corner of w3.org/TR. Adobe recently started efforts to resurrect the idea of multiple ::before/::after pseudo-elements with a new proposal.
The proposal was discussed extensively in the San Diego F2F. A few concerns were raised, which you can read in that meeting’s minutes. The decision was to work on a more concrete proposal, but there is no consensus yet about whether multiple ::before and ::after pseudos is a desirable feature.
Fresh in Selectors 4: drag-and-drop pseudo-classes
The community often requested CSS pseudo-classes to make working with the drag and drop API easier. Three new pseudo-classes were recently added in Selectors 4 to facilitate that use case:
- :active-drop-target
- :valid-drop-target
- :invalid-drop-target
Admittedly the names are pretty verbose and the CSS WG is looking for shorter alternatives. Your help can be useful here: Review the possible options and reply to the mailing list indicating your preference, ideally explaining why you think so. If you think you have any better names to suggest, that would be welcome too!
Values and Units goes to CR
Values and Units defines which data types (such as <image>, <url> or <number>) and units (eg px, em, or cm) CSS supports. Admittedly, most authors aren't excited by this spec. This is unfortunate, because it includes some pretty damn cool new functionality: Viewport-relative lengths, a rem unit that behaves like em but always refers to the <html> element’s font size and a ch element that is relative to the font width, to name a few.
Values and Units has been pretty stable for a while, so it’s great to see its status officially advance to reflect that.
How many classes can override an ID?
This was the question that Chris Coyier set out to answer a few weeks ago. The answer was 256, in most browsers. Consistently, 256 tag selectors can override a class. Of course, if you’ve ever consulted the spec on specificity, you know this is incorrect behaviour. No number of classes should be able to override an id and no number of tags should be able to override a class. This flaw in browsers is caused by a simple reason: The number of IDs, classes and tags is stored in 8-bit 'slices' of the same 32bit number. However, 8-bit integers only go up to 255. Once they become 256, they overflow into the next 8-bit 'slice'. If that still seems unclear, Ryan Seddon wrote about it in more detail.
The CSS WG discussed the issue and several ideas of what should happen: should the section be changed in Selectors4 to be easier to implement? So far, the resolution seems to be that counts over a certain number will be clipped to that number. With that in effect, 256 classes would be treated like 255 classes. Same with one million, six trillion or one gazillion classes.
W3Conf 2012 in November
W3C is hard at work with planning this year’s W3Conf, which will be W3C’s second conference targeted to web developers and designers. It will take place in the Bay Area (aka Silicon Valley) sometime in mid or late November and will be mostly focused on how to take advantage of web standards today, rather than what’s coming in the future. If you think that sounds interesting, keep an eye on it!
Thanks to fantasai, Tab Atkins and David Baron for their valuable feedback
Words: Lea Verou
Lea works as a developer advocate for the W3C. She has a long-standing passion for open web standards, which she fulfills by researching new ways to use them, blogging, speaking, writing, and coding popular open source projects to help fellow developers.
