-
200807 Jan
Much of the editorial work done on the various CSS3 modules is done in private. Due to this, there is often the impression that no progress is being made. This impression is deepened if you look at the date of publication for many of the public drafts. However, the perception is not always the same as reality. Some of the editorial work has been made public on the W3C Public CVS Repository for a few modules, and there has been some nice progress.
I’ll start with the module that seems to have the most demand from developers – Backgrounds & Borders. The Working draft that I’ve just linked was last updated in 2005, but as you can see the Editors draft has moved on somewhat, with its last update on Christmas Day (someone was busy giving us a Christmas present). It also has an additional editor, which should speed things up.
So what is new here? Well one of the most demanded properties is
border-radius. WebKit and Gecko both implement this, but implemented it in different ways. This has been resolved in this latest draft, to define it to be the same as how Gecko implemented it, but with the addition of a / notation so that both the x and the y radius can be specified in theborder-radiusshorthand notation. An example of this would be as follows:border-radius: 1em 2em 3em / 2em 1em;This would give the top left corner a radius of 1em for the horizontal radius and 2em for the vertical radius. For the top right, it is quite clear that this would be 2em for the horizontal and 1 em for the verticle. As there isn’t a radius value for the verticle bottom right, it takes the value of the top left (opposite corner) which is 2em, and the same for the bottom left corner for both values (2em / 1em).
You can also see the spec defines what happens when the intersecting borders are a different thickness. This property should be more or less ready for implementation, or adapting to the new spec in the case of Safari and Firefox. As always test cases are important, so that implementations can be made interoperable. If any developers want to make any then that would be higly useful.
The
box-shadowproperty has been split in this draft toborder-shadowandbackground-shadow, but I’ve been told this will be changed back to be more inline with what Safari does. Theborder-imageand comma notation for multiple background images are pretty much stable now too.The Backgrounds and Borders module isn’t the only one to go through changes however. The Namespaces module was also updated on Christmas day and can be found here in Editorial draft form. This has also gained an additional editor. As this module is brief and has already been included in the 2007 CSS snapshot, I assume the changes are just trivial tidying up. I didn’t notice any glaring changes when briefly checking it out. This module is also widely implemented (except IE), so likely doesn’t need much updating.
Grid positioning module is something that has also been in high demand. The fine folks over at Microsoft have been busy on updating this spec, with the editors draft last published in October. You can see a lot of new pretty pictures in the spec. Props for the use of Khoi Vinh’s Yahoo!-a-like Yeaaah example. I look forward to when this reaches an implementable state.
Also updates recently and included on the public server are Paged media, Text and Text Layout. I’ll leave it as an exercise to the reader to see what has changed here.
As well as CSS3 modules, are APIs for the CSS Object Model and CSSOM View module. This is designed to replace DOM Level 2 Style in due course, and are very early level drafts.
As all of these modules are editorial drafts, it should be pointed out that they may change at any time, and any changes are not finalised or offical W3C specs. It is exciting however that there is clear signs of progress, and that the important Backgrounds & Borders module is maturing.
You can skip to the end and leave a response.
-
Comments
-
01.
Dave,
i’ve been meaning to put my thoughts about CSS3 in terms of development strategies for the standards down on paper for some time, but this gives me as good a chance as any to do so – and as it is a comment, no need to edit it :-)
It seems to me that there are two distinct aspects of CSS.next
There are things that are not backwards compatible, and things which are. Or to put it in web design terms, there are things which degrade reasonably gracefully (as much from the developers perspective as the readers) and things which, particularly from, the developers perspective do not.
For example box-shadow and text-shadow. If a browser does not support these, there’s little or no impact on the reader (they don’t even know what they are missing) or the developer – no need to do a workaround for browsers which don’t support the feature.
But, let’s take something like the new layout model. At best, the developer will almost certainly need to have two layouts, one for browsers which do support the model, and one for those which don’t.
Old folks like me still recall the pain of Ie3/4 Netscape 3/4 days, where absolute positioning was kinda sorta supported by the 4’s, but not the 3’s. To do this day, a significant percentage (arguably a majority) of sites still sue tables for layout as much as because it used to be a cross platform technique for doing layouts (do Dreamweaver and GoLive still explicitly support this approach as they did for a long time?)
I think that the development of CSS.next should take on board these categorical differences. Things which by their nature degrade gracefully should be identified, separated out from things which don’t (even where they may logically fall into the same module) and these can move ahead far more rapidly than those which are in essence not backwards compatible with older browsers.
What Safari is doing with its novel CSS seems to me the right way to go – like Opera and Mozilla they use the proprietary experimental prefix (-o- -moz- and -webkit- respectively) but are probably most aggressively both implementing draft features and their own experimental features, while concentrating their efforts on things which are backwards compatible. Even quite complex things like animations and transitions, and multi column text (which explictly don’t break the existing layout model) conform to this approach, it’s not just “simple” things like text-stroke and box-shadow.
CS3 introduced a fairly sensible strategic approach to new CSS features, by modularizing them. Hopefully, by concentrating on features which augment the web as it is, as distinct from features of the web as it may be, we’ll start seeing some real innovation on th web in the next year or so, rather than the next decade or so.
-
02.
Here’s hoping border-radius will soon be a candidate recommendation, so browsers can implement the property with no prefix…
Not long ago, the bug that made it so background images spilled beyond rounded borders has been fixed in Firefox 3, so supporting the real border-radius property would let us use that feature, while at the same time ensuring our pages will still degrade gracefully in Firefox 2, by simply not supporting the -moz equivalent. -
03.
John,
What you say makes sense. Even though there seems to be a good amound of interest in Grid layout, it can’t be used in a meaningful way until at least the OS release from Microsoft after their release of IE that supports it (or most likely the OS it comes with). And only when that OS becomes popular. In Grid layout’s favour is that the spec is written by two MS employees. At least Markus is on the IE team, and probably Alex too. I would guess that if they wrote the module it will give them more motivation to implement it.
For some of CSS3 it depends on how it is used. Many of the new selectors (some of which are fairly widely supported) will be difficult to use due to backwards compatibility reasons, but can be used in a backwards compatibile way. I’ve used
p:first-of-type::first-letterto add drops caps for example, ortr:nth-child(odd)for tiger stripes on tables to aid they eye when looking at tables.A lot of the stuff that in the majority of cases is backwards compatible are included in the Backgrounds and borders module. Some still depends on how you use it of course, like multiple background images. A lot of this stuff are what I’d like Opera to implement, and the spec is now reaching a stage where this becomes more feasible. Then it is more a case of release schedules etc (which are things I’m sure you know about during your experiences with Style Master).
I’d also agree with you that a majority of sites still use table based layout, including some companies that should know better. Opera is fortunate that are users upgrade quickly. I’d guess it would also be the same for Mozilla, but that will slow down as they move more mainstream. Microsoft doesn’t have that luxuary as many of their users don’t even know what a browser is (they surf Google with the Blue E), never mind that it needs updating.
I think I disagree with you on Safari though. Opera probably has more draft CSS3 features, but the Safari only features worry me. If It was IE and MS people would be up in arms. I’m not following the internal communication of the working group, so if they propose the features then implement them to show how it could be done then that is a little different. But many people will remmember things like IE only CSS filters. These were impossible to implement by other browsers as they tapped into Direct-X. Then there is the whole Active X issue. The animations in Safari probably hook straight into core Animation, which is only available on OS X, and certainly not phone like the RAZR or other such devices. It probably only takes them a few lines of code. For other browsers this would be none trivial. Opera of course has animation in SVG. It would make more sense (to me at least) to make sure any animation in CSS was compatible with that in SVG, so authors can transfer knowledge and implementers don’t have to implement the code from scratch twice, for two different technologies, to get the same end effect. I don’t think any other browser than Opera has SVG animations though.
Lets also not forget that vendor only solutions cause compatibility issues. We get all sorts of problems because sites use CSS Filters (not standards aware developers in the most part, but many real world sites still use them), or Mozilla extensions to the DOM. Safari can’t really cause problems like this because it doesn’t have enough market share – or so you’d think. It is though, as rightly or wrongly, many developers think the only phone that can surf the web is iPhone (wel Steve more or less said so in his keynote ;)). Thus mobile sites are using the -webkit- prepend without the none prepend version. This in itself is unfortunate, but when they use the properties Safari invented that have no standards fallback to even use, then we (Opera) can do nothing about it. We can’t even really implement the Safari only property, until it has been put in a spec. There is more than enough real CSS3 to implement, that at least tell us how it works and will be test suites. Reverse engineering is expensive. It is a dangerous game people are playing when they wish for more vendor only innovation in the rendering engine field.
Opera actually invents a lot of things ourself, but that goes more unnoticed as we push to standardise them quickly. I believe for example that Sever-sent events and Web Forms 2 from HTML5 were Opera inventions, and possibly cleint side storage (but I’m not sure about that one. Widgets 1.0 was certainly a Opera technology we worked to standardise from the start. I think this is the approach that should be taken (even if you get less credit for it). If Apple are taking this approach then the issues I outlined become less of an issue, and we just need to get developers to five up the blind Apple faith and include the none prepended versions of properties instead of just the -webkit- one. The current iPhone only web development practice is a sad chapter in the web standards movement, that is hopefully dying out. Luckly people like Roger Johansson and Eric Meyer have spoken out against it. I wish ther was more work in WaSP on this, but then again there are a lot of Apple fans in WaSP ;) Anyway, sorry for the rant. Working on site compatibility day in, day out, some of this stuff is starting to fustrate me.
-
04.
“I’d guess it would also be the same for Mozilla, but that will slow down as they move more mainstream.”
Not really, Firefox’s update mechanism is really seriously good at getting users to upgrade.
-
05.
Robin: As far as I understand it only updates to a later browser of that major version (unless they’ve changed this). If this is the case then users wont automatically get FF3 if they have FF2. I could be wrong though.
-
06.
David: basically, users are only prompted to update to the next major version after a while. Maybe once support for a certain branch has ended, or a little before.
Here’s an old quote that shows this:
“A final update, 1.5.0.12, however is in development and should be available around the end of May. After that Mozilla is planning to push the first major Firefox update, so Firefox 1.5.0.12 users will be prompted to update to, then current, 2.0.0.4.” -
07.
You are very right noticing that CSS draft are being moved into publicly visible CVS repository. In fact there is little or zero technical discussions at this point that are not held in [email protected], and majority of editing actually happens at http://dev.w3.org/csswg/
-
08.
I’m not sure how frequently this draft is updated, but there’s a new version dated January 14th available now; seems to be the same as what you’ve written, however.
-
09.
It gets updated whenever someone checks in changes. How often that is depends on whether one of us is working on the draft that day. :) Since this is our working copy, most of the changes will be minor: fixing typos, adding detail to a definition, or changing a feature’s syntax: each one of these is likely to be checked in as a separate change. You can see CVS’s record of what’s happening through the CVSWeb view.
-
10.
Changes from CSS 2.1
‘Background-clip’, ‘background-break’, and ‘background-origin’ are new. Also there are changes to the ‘background’ shorthand property.‘Background-attachment’ has a new value ‘local’.
The background can now have multiple images. As a consequence, several properties now accept a comma-separated list of values.
‘Box-shadow’, ‘border-image’, ‘border-break’ and ‘border-radius’ are new.
This module will have its own test suite
http://dev.w3.org/cvsweb/~checkout~/csswg/css3-background/Overview.html?rev=1.28&content-type=text/plain#context -
11.
From Legacy to Web 2.0 » Blog Archive » Are you afraid of shadows? says:Comment » March 14th, 2009 at 7:50 am
[…] how iTunes manages all those cool effects with the iPhone App images? The neat text shadows and box shadows for images, the curved corners… I thought it was something they were using an image tool for, […]
-
01.
