CSS3Feature

Exclusive preview of the hottest CSS specs

Divya Manian, web opener for Opera Software, provides an exclusive look behind the CSS Working Group and the lowdown on 13 exciting CSS3 specs being discussed right now. If you want to know the future of CSS, read on!

Most of the fancy CSS features that you use in your style sheets are defined by a group of people who form the part of the CSS Working Group. Typically this occurs when members of the group/web developers bring a proposal for a feature in a CSS specifications — on the www-style mailing list typically — or a change in the definition, it gets discussed and then a few implementors (typically browsers such as Opera, Chrome, Safari or Firefox) implement it (or implementations are brought to discussions to become part of a specification), more discussions ensue and so on.

It’s hard to keep up with the latest in the CSS Working Group world, given the kind of intense conversations that occur daily. Typically most of the communication occurs over the mailing list and the working group also meets online once a week to push resolutions over some of these mailing list discussions. The group also meets a few times face to face over the year at various venues.

I recently joined the CSS Working Group, and spent a few hours catching up on various specifications at my first face-to-face meeting of the Working Group that was in active discussion. I’ve written a summary of what I learned: if you haven’t read that post, please do so before you continue to the exciting finish to the whodunnit described there!

Advertisement

1. Flexbox

Flexbox has changed significantly since the earlier implementations, which would make existing implementations break. Ideally, you should wait till the new syntaxes are implemented before you start using this. Flexbox is mostly stable but has critical blockers such as:

  1. Representing Flexbox item flow directions as a property Basically, figure out a way to specify the display order of elements within a Flexbox. There is no consensus on this, but Alex Mogilevsky, Tab Atkins and Fantasai have worked out a solution, so there might be a resolution soon!
  2. Alignment of Flexbox items This becomes especially hairy with baseline alignment and the interaction of alignment and the flex.
2. Selectors 4

Fear not: we still have Selectors 3, but a lot of work is also going on in a spec called Selectors 4. It is an extension of Selectors 3 without pseudo-elements but with additional features. This way, we could move some of the features that much less implementation support into this spec and make sure Selectors 3 reaches recommendation status quicker. Some interesting properties that are found here are:

  1. :any-link Unfortunately due to some quirk of fate, :link was defined to exclude selecting visited links. Which meant if you overrode a :link, it would not override :visited, so you would have to redefine both every time. Now, with :any-link you would simply do a:any-link { color: red; /* or whichever colour you want to override with */ } instead of a:visited, a:link { color: red; }.
  2. :local-link This would allow you to style all anchors that are linking to within the same document. No longer do you have to do apply regexes to figure out if links are referring to local positions in the page or another page entirely.
  3. :matches How many times have you had to type div p em, div p b, div p strong etc. So now you can choose among many handily with :matches. For the previous selector list, you can simply do div p :matches(em, b, strong) {} (note the space between p and :matches). Or how about applying a single style to multiple classes? p:matches(.error, .valid, .insane) {} has your back. Sometimes you want descendants of multiple parents to get the same style like .header p, .footer p, .header li, .footer li {}, you can do that with :matches(.header, .footer) :matches(p, li) {}

    I think this is the hottest pseudo-selector ever.

Do note that these properties are subject to change when implementors start considering them seriously for implementations.

3. CSS3 Text

CSS3 Text is pretty much a super-human effort by fantasai from Mozilla, Koji Ishii and Shinyu Murakami that tries to fix historically insufficient text properties while also accounting for features that would allow more control over the style of non-Latin languages.

There are also interesting properties that would apply to all languages in general, like:

  1. tab-size This allows you to set the width of a tab character when rendered. Originally it only accepted an integer value that stood for the width of a unicode space character, but during the face-to-face meeting it was decided we add a length value too, so now your tab characters can be 20px or 1rem in width. Sadly, the length unit is at-risk and might not make the Candidate Recommendation.
  2. hyphenate-resource You might have seen articles that mention this keyword, but this has now been dropped.
  3. word-wrap Your favourite property now got a name makeover! word-wrap was a notoriously incorrect name for a property that technically only set the overflow of text, so now it gets a new name called overflow-wrap. But fear not! You can continue to use word-wrap, because there is no implementation out yet for overflow-wrap and browsers will, when they get around to implementing overflow-wrap — for backwards compatibility — continue accepting word-wrap.
4. CSS3 Conditional Rules

CSS3 Conditional Rules, edited by David Baron, provides ways to detect support for CSS properties. When this specification is implemented, you could do @supports (transition-property: color) or (animation-name:red) { body { background: blue; } } This would be like Modernizr's CSS features but within the browser!

To truly replace Modernizr, this would require an extensive API, but hopefully it is coming soon.

5. CSS OM

The CSS Object Model has been long wished for, but needs further implementation support before it can be widely used. Opera's Anne Van Kesteren is editing it. Primarily, it defines the Object Model for all the style sheet rules and their associated APIs. This would give a standard way to refer to the rules within the style sheet instead of referring to each browser's custom/reverse engineered implementation.

The Values API that would allow you to parse a value as an object with properties rather than as a string. When this is implemented, you would not have to use fancy regexes to get the value without the units when you’re manipulating them in your script.

6. CSS Floats

There were two proposals (here is the other) for providing similar features (wrapping) which are now a single proposal: CSS3 Floats (name subject to change). Basically this will allow you to wrap content of one element around another and do cool things like this Adobe demo screenshots show. The new draft is not out yet but broadly CSS Floats would remain as it is. We will know more when the new Editor's Draft is published.

7. CSS3 Image Values

CSS3 Image Values has seen active discussions in the gradients section, especially over these topics:

  1. Syntax of corner-to-corner gradients After a lot of arguments and back and forth, the syntax has been decided to be the following: linear-gradient(to top right, indianred 10%, aliceblue 90%);

    Do note that while the keywords top, right, left, bottom can be used, you cannot use center.

  2. Bearing Angles The angle used in the gradients have also been switched to be measured always from the north (top) rather than from the right. There is no implementation yet that implements this yet, but this does mean if you have used angles to specify gradients, when implementations roll out you would have to change them.
8. CSS Image Values 4

As with the Selectors 4, a few of the properties from CSS3 Image Values have been moved here so CSS3 Image Values can get to Recommended status quicker and we don't have to use the damned prefixes for gradients any more. Some of the things to look forward to in Image Values 4 are:

  1. Using SVG paint servers in CSS Basically refer to a section in an SVG element and use that alone as a background image ( background-image: url("#h"); ). The basic idea was first proposed by Robert O'Callahan
  2. Angle gradients There is no way to provide gradients that are conical (we only have linear and radial), a syntax that works for angle gradients would be cool to have especially when you want some stage lighting effects. The main hold up seems to be the lack of graphics library support in certain rendering engines. Most likely this would appear in CSS4 Images.

The spec is not ready yet but should be out soon.

9. CSS3 UI

The biggest change in CSS3 UI would be to define the scope of hit testing and refine it. A lot of HTML5 games have sprites and want the ability to control which areas of an image get to be clickable and which do not. For example, if you have a circle with transparent background as an image, when you click on it, the click appears to the whole box that contains the image and not just to the opaque circle itself. The idea is to have properties such as alpha transparency that would allow you to select the transparency levels to which the click should apply. It is likely that some aspects of this would appear in a CSS4 specification.

10. Compositing

With the appearance of filters in CSS, there is a need to define a specification for interactions between elements that have various effects applied on them. For example, if you have an element with a sand filter and a translucent background, how would the backgrounds of elements underneath it appear? What would be the net graphical rendering of such elements? Those interactions need to be defined not just for CSS but also for SVG and possibly for HTML too. Here is the current proposal for compositing, and it will be expanded to define this more universally.

Another interesting tidbit from a meeting of the CSS SVG working group was the willingness of the SVG Working Group to drop SVG Animations altogether in favour of CSS animations provided most of the features that SVG animation provides would be replicated within the CSS Animations. Dean Jackson from Apple will be writing a priority list of features to make that happen.

11. Transforms

The CSS transforms could quite as easily be applied to SVG as with CSS, so Adobe's Vincent Hardy will be working with Mozilla's Cameron McCormack, Dean Jackson and Simon Fraser to come up with a more universal Transforms spec.

12. Filters

Did you want sandy backgrounds? Or blurry ones? This spec has features that would allow that. Here are some filters you could possibly see in the future and existing implementations that do something similar.

The best part of the specification is that this would enable you to apply filters to elements as well and not just to images, so you could expect to blur elements on hover or other interactions. Do note that filters already exist for SVG and this spec would make it available for CSS too.

13. Printing Backgrounds

Tab Atkins from Google has been leading the charge on providing a way for developers to more fully control print styles. Currently, no browser will print backgrounds even if you specify it in your print style sheet. The majority are of the opinion that something needs to be provided but are strongly in disagreement over what that solution would be. Tab has proposed to spec and implement something in Chrome, and then bring that to the table to discuss further and make refinements.

So that’s what is being discussed at this moment. Feel free to send your feedback or ask the Working Group on Twitter or the individual editors your questions or suggestions.

The changes are being made to help YOU style your pages better, so we would be grateful for all the suggestions and feedback we can get!

Acknowledgements

Special thanks to Tab Atkins, Fantasai and others for reviewing this article and for their valuable feedback.

If you liked this article, be sure to also check out The Future of CSS Layouts, by Peter Gasston.

Advert

Log in to Creative Bloq with your preferred social network to comment

OR

Log in with your Creative Bloq account

site stat collection