‘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

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.”

Not really, Firefox’s update mechanism is really seriously good at getting users to upgrade.

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-letter to add drops caps for example, or tr: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.