Posts Tagged ‘CSS3.info’
A first Alpha of Mozilla’s new browser is due for release shortly (probably tomorrow). Firefox 3 saw a lot of work go into speed, stability and the interface, but was slightly disappointing for front-end developers and saw CSS implementation overtaken by Safari and Opera.
3.1 will make up for that with a whole raft of features on their way. Implemented in the current nightlies (and therefore, most likely, in the Alpha) are:
Planned for implementation but not yet landed features include:
For the stat-hungry amongst us, 3.1 currently scores 84 on the Acid 3 test, and the implementation of Media Queries should take that up to 85.
There’s no indication of it, but I personally would like to see their border-radius syntax brought into line with the standard, and Transitions implemented to complement Transforms. I’ve been playing with Transitions recently, and they’re very cool.
What new CSS features would you like to see in Firefox 3.1?
Opera has one of the better levels of support for CSS3 (and other standards), making it an ideal platform for experimenting with future technologies and new techniques that these standards will offer. However, this has always been let down by the fact that Opera is very lacking in the web developer tools segment. To be frank, Firebug and the Web Developer Toolbar blow away anything Opera has offered in this realm.
This short coming is about to change soon. Opera has just announced today, with the release of Opera 95 beta 2, that Opera Dragonfly will be Opera’s web developer tools. These will be released as an alpha on the 6th of May. In line with their alpha status, the tools will not be feature complete, but they will show a good foundation of Opera’s developer tool vision.
Once released, Opera is looking for feedback on the tools, to make sure they fit the needs of real world web developers and designers. I’m looking forward to web developers getting their hands on the Opera Dragonfly and finding out what the impressions are. If you are interested then go the the Opera Dragonfly website on the 6th or just open the Web Developer menu item from the tools menu. In the mean time, Opera 9.5 beta 2 (Kestrel) has been released today, so it is a good time to check out what CSS3 properties it supports.
One of the interesting things about Acid 3 is that it tests parts of the CSS3 Colour and CSS3 Selectors modules, that are a part of the 2007 CSS snapshot. Now that both Opera and WebKit pass the standards part of the Acid 3 test, the support for the snapshot has now also improved. The CSS 2007 snapshot is the state of play in CSS at the end of 2007.
WebKit used to lack support for many CSS3 selectors, but now passes the CSS3 Selectors test on this site, and supports all of these selectors. Opera already supported these, but didn’t support HSLA, RGBA and the CSS3 values for
transparent. These were added to pass Acid 3 in a post Kestrel build (which may or may not be back ported). Due to these improvements, support in these two browsers for the CSS 2007 snapshot looks healthy.
Ignoring CSS2.1 for now (which Opera has very good support for), both browsers fully support the Selectors Level 3 spec and the CSS Namespaces spec. For CSS3 Colour, the support isn’t quite as clear cut. Everything is supported in Opera, except the
flavorkeyword and the various related colour profile properties. These properties are at risk of being dropped by the spec however. WebKit has the same support except it doesn’t support
currentColoryet, and has some bugs with allowing mixed values in RGB and RGBA. Firefox has had similar CSS3 Colour support to Opera for a while now
Away from the 2007 snapshot, ACID3 also tests Media Queries. These were already supported in Opera and WebKit, but are not yet supported in Gecko or the IE engine. Web Fonts (
@font-face) are in the test and were already supported by WebKit, while Opera was developing support, but speeded up development to pass the test. Finally
cursorfrom CSS3 Basic User Interface was added by Opera to pass Acid 3. I’m unsure if this was already supported by WebKit or not.
Although CSS3 UI is not part of the CSS 2007 snapshot, the spec is close to being complete–apart from lacking an editor or a test suite–and support in one or more browsers exists for many of the properties. The features supported by one or more browsers now includes
box-sizing(Opera, Safari, Firefox and IE8),
outline-offset(Opera, Safari and Firefox),
cursor(Opera, Safari and Firefox).
Update by David: Opera has now released a public WinGogi build of Opera passing the DOM test and with pixel perfect rendering. We don’t believe we have passed the test yet, as there are performance issues with a couple of tests. This puts Opera and Safari neck and neck. It is fantastic to see both the Apple and Opera teams taking this test seriously and pushing each other to improve our standards support. Who ever wins the race doesn’t really matter, the main point is that there are now two engines with the required standards support to pass Acid 3. This could be a shot in the arm for both CSS3 and SVG.
Update by David: Although the Acid 3 test was updated to allow WebKit to pass by the letter of the test, they still seem to fail by the spirit of the competition. One of the sections of the Acid 3 test checks SVG Animation. WebKit have added the interface to allow the test to pass, but not fully implemented the feature it was testing. See Jeff Schiller’s blog for more information.
Update by Joost: While Opera might have been the first to pass the test in laboratory conditions, for which I applaud them and I hope they release it ASAP, you can download a WebKit nightly right now and enjoy the full 100/100!
Update In the last few minutes (while I was eating lunch) the final 2% was reaching, making Opera the first browser to reach 100%. There are still some rendering issues, but things are well on track to passing the test. A preview build will be released on Opera Labs shortly. Thanks to our developers in Scandinavia that have been working into the evening to reach 100%.
Safari has been making great gains in its Acid3 score in recent weeks, currently residing on 96%. Opera however has come out of the chasing pack and moved from 77% in the latest weekly release of Kestrel, to
98%in the latest internal builds. As part of this it also includes the long requested CSS3 HSLA and RGBA support, and Web Fonts.
These improvements wont be included in a weekly Kestrel build any time soon. Opera, like Mozilla, are at a stage on our development process where we are closing in on a release, and thus regression testing and stability are critically important. This work will most likely (although not confirmed) go into a post Kestrel release, in case it causes regressions and the like. There will probably be an experimental alpha release showing this improved support in the not too distant future.
Is there ever a time when you wish CSS allowed you to apply style in ways that either are not currently possible, or require hacks and extra markup to make it possible? Well now is the chance to let the working group know exactly what you want. Bruce Lawson is collecting your feedback on the WaSP site. Go there and leave a comment outlining what effects you’d like to achieve. You can also leave feedback on the CSS3 Soapbox.
Remember that the Working Group want examples of what you are trying to achieve, so that they know if current proposals fit that need, or they can think about adding new functionality. Also state why you want to be able to do that, if it isn’t obvious. They are not looking for feedback on syntax, so just leaving a list of new properties you want added won’t be helpful. Also try to check the latest draft modules to see if your proposal is already possible. Things like rounded corners (
border-radius) and striped tables (
nth-child(even);etc.) are already possible. There may be things that you want to be able to do with a property that isn’t possible in the current spec (such as being able to have an inverted rounded corner using border-radius for an example off the top of my head). If this is the case then the suggestion will be very much worthwhile.
Also remember that there is no guarantee that things you suggest will be added to the spec, even if it makes sense, and is technically realistic to achieve.
We at CSS3.info are planning to have a wiki (or similar system) to collate feedback on CSS3 in one place, which can be referenced easier than a mailing list. We will include the most popular suggestions from the WaSP post (with full attribution) when the wiki is in place, and open it up to the public to edit. If suggestions get added to the spec, we can also include the syntax that will achieve that suggestion, and eventually a demo that will produce the same result, once it gets implemented.
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 the
border-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.
box-shadowproperty has been split in this draft to
background-shadow, but I’ve been told this will be changed back to be more inline with what Safari does. The
border-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.
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.
Disclaimer: The following post is my personal opinion, and not necessarily those of my employers. My colleague, Chris Mills provided feedback and suggestions for this post.
Since Opera’s antitrust complaint to the EC, some people have used the complaint as a catalyst to promote their agenda against the W3C and the CSS Working Group, with arguments flying on either side. There is no doubt that there are issues there, and action is needed. Transparency is one such issue, with many CSS3 modules not having been publicly updated since 2002. This gives the impression that it is moving at an unacceptably slow pace. There are also accusations that in fighting is delaying progress to suit various parties’ own agendas. I’m not a member of the W3C CSS Working Group, so I can’t comment on how true this is, as I don’t know. I do know however that something has to be done, and the W3C has starting to make progress on remedying this issue. In this post I state where I feel the working group is right now, and propose some changes that I feel will help move things forward.
The current state of proceedings
Lets start with what they have done. They recently started a blog, in which they report on progress and issues. They’ve also created an aggregated feed of blogs and sites to report on CSS3 so that they can hear the voice of people that are discussing CSS3 outside the W3C, ie real world developers. They’ve also started working closely with css3.info. We have a CSS Soap box to let everyone get their issues off their chest, and they have written posts requesting feedback from designers saying what they want from certain properties. Is that far enough? Maybe not, but it is a beginning and I commend the work that Fantasai has done on this outreach.
Transparency of the Working Group
If this is where we are, where do we want to go? Firstly, transparency and accountability have to be greatly improved, so that if anyone is trying to hold up the process or are playing politics this is exposed, whether it is Opera, Microsoft, Mozilla or anyone else. I propose that minutes to meetings and any important documents or drafts are published on the working group blog.
Who should be represented on the Working Group?
Next, there are calls for browser vendors to be removed from the group. This is unworkable (disclaimer: I work for a browser vendor), for many reasons already exposed. I do strongly believe however that a better balance between designers, browser vendors and other parties has to be reached. Gibson or Fender don’t get guitar players to design their guitars – that would be ridiculous, as guitar players can play guitar, but the vast majority of them have very little knowledge of the processes involved in actually building a guitar. They design them themselves, with input from guitar players on what they want. Writing specifications is very difficult, especially when making sure they are implementable in not only a cross platform, device and browser independent way, but also cross culture and language. Test cases are difficult to write. Browser vendors have many of the best people in the business for writing these specs, as they are the kind of people we hire. Ian Hickson is widely regarded as one of the best specification writers of our generation, and he used to work for a browser vendor.
Keeping browser vendors out of the Working Group would also be difficult to police. For example Fantasai works for HP (I believe), but has close ties to Mozilla. Would she be counted as a representative of a browser vendor? Also, would designers be willing to give up what they are passionate about (designing web pages and other media) in order to work full time writing technical specifications? Why also should browser vendors be reduced to an advisory role, for technologies they have to do the hard work in implementing? If this were to happen, we would probably end up with a break away group similar to the WHAT-WG, of browser vendors that don’t want to be told what to do by designers.
A power struggle isn’t what is needed – instead, we need a balance between vendors and designers. The specs should be left to the people that are good at writing specs, and enjoy it, the designers should be there to comment on if the proposals are useful in the real world, and the browser vendors should be there to comment on their side of things – whether the proposals are realistic to implement in their rendering engines.
The designers included could be part of an advisory panel of respected designers (CSS11 for example), adding more invited experts that are willing to spend their time on this and/or having a place where designers can post and discuss mock ups of what they want to be able to do with CSS3. CSS3.info for example could create a wiki where screenshots of desired effects for CSS3 properties could be added by designers, and the merits debated. New proposals could also be added. The WG could then refer to that site for ideas and to solicit feedback. I personally think that the HTML5 working group has far too many invited experts, so limiting the group to a select number, but allowing anyone to leave feedback would be more ideal. It is important that feedback is gained from multiple sources however – the needs of a Japanese designer is probably very different to the needs of a British designer, for example.
Speed of CSS3 development and relevancy of proposals
Furthermore, the speed of development of CSS3 must improve. Making the process more open to inspection will help this by making it harder to use stalling tactics. Action needs to be taken here – I’ve tried to get designers to send me feedback on what standards features they’d like to see in Opera first, but this is difficult, and I received little response. What we need to do is set clear priorities of CSS3. First we need to get the ’07 snapshot finalised (it is currently in Working Draft) and get browser vendors to implement those modules. This is going fairly well at present in three out of the four major browsers. It could also be going well in IE8, but we’ll have to wait to find this out.
In parallel we need to get a list of what properties designers most want to be able to use. Gather the most talented spec writers in the group to work full time, or as much as their employers allow, to mature those specs. It can be finer grained than a whole module, if other parts of that module have issues and are not related to the core properties that are needed. At each iteration, designers should review the progress to see if is moving in the right direction, and the feedback solicited from the working group if there are questions. Properties that have reached proposed final form should be marked as such, even if the rest of the module isn’t ready. These should then be given to the vendors to implement with the dash vendor prefix. Test cases should be built in parallel. Vendors should submit all that they have, while designers should help with this process if possible. The more test cases, the more likely it will be interoperable and the standard will be finalised sooner. These properties or modules should then be added to the CSS snapshot for the current or next year.
One question will be definitely be asked –
which modules should be made a priority?Vendors will have an opinion on this, as it depends on the aim of the browser. Apple and Opera will care more about Media Queries than a vendor without a mobile browser, for example, but largely I think this should be down to the design community. If we had a public wiki to discuss this on, I’d suggest the modules or properties with the most active suggestions would be up there, while ones with no activity would be pushed to the bottom. Through the feedback I have collated, designers preferences seem to be borders & backgrounds, selectors, multi-column layout and web fonts, and there has also been interest in the grid layout (although this seems to be the furthest back in terms of both spec and implementations).
Another issue is who will work on these. That isn’t a question I can answer, but if we can somehow get the existing working group to be able to spend more time on it that will help. I’m willing to help out if desired. It should be easier for big companies such as Yahoo! to supply people to represent designers as they have the resources. The problem is that many of the most highly regarded and vocal designers are freelancers that can’t afford to give their time for free. We need to find a solution for this, be it through sponsorship or other means.
Can browser vendors work together?
The other concern that has been raised is that, in light of Opera’s complaint against Microsoft, the browser vendors wont be able to work together. I don’t believe this to be the case. Håkon has stated he has no problems with Microsoft employees, and I’ve personally heard him say he has great respect for the likes of Chris Wilson. I’ve also heard the same coming from Chris. I know or have worked with the likes of Chris, Markus Mielke and Joshua Allen for a while now, and I very much hope that continues. I’m sure they’ll also agree.
Conclusions and the way forward
What we need most of all is action and not talk. I propose the following:
- Get a priority list of CSS3 modules or properties hammered out for both the W3C and the browser vendors
- Get the modules included in the ’07 CSS snapshot to recommendation stage, and push browser vendors to implement them
- Aim to get these priority modules ready for the next CSS3 snapshot (’08)
- Put a mechanism (such as a Wiki mentioned above) in place to give feedback on the issues the WG come up with
- Promote the said mechanism to developers in multiple countries, such as those that use none-latin scripts, and right to left text
- Re-engage the Web Standards Project (WaSP) to take an active role in the activities
- Get the W3C to open up the private communications of the WG, so there is transparency for all to see. Post communication on the Working Group blog or another suitable medium
- Get an official statement from each of the browser vendors on the working group that they are willing to work together in a co-operative and unhindered manor
- To ensure a fair balance between designers and browser vendors on the working group, build a short list of respected designers or developers who should represent designers on the working group. We can get a respected designer like Molly or Zeldman to propose people, again making sure there is diversity of opinion.
- Find a way to fund these designers, either through W3C funds or corporate sponsorship
- Ensure the chosen designers can commit the required time to the project
- Ensure there is at least one designer assigned to each of the modules that are deemed a priority
Generated content via the
contentproperty has been available since CSS2. However this was only available using the
:afterpseudo-classes. In CSS3 this support has been expanded to be useable on any element, without needing to use these pseudo-classes. Unfortunately this only works in Opera 9 (and above) at the time of writing.
I use this capability in my iTunes interface demo that I’m currently building to show off how powerful current and future web standards are for building application interfaces. This currently isn’t finished yet, and is very buggy (no min-width, missing features, no scrolling on the source list, content jumps, and no actual music support to name but a few). but you can take a sneak peak here. Due to MyOpera hot linking restrictions, you’ll need to press enter (or return) in the URL field to reload the page. This currently only works in Opera Kestrel due to missing standards support in other browsers, so download the latest weekly before trying it out.
contentproperty is used here so that the buttons and the playing column on the song list can contain their text labels. This is important for accessibility and if the page is styled differently and the design requires text instead of icons. The text is then set to empty using
content: "";for the relevant element. I’m sure there is a more cross-browser way of doing this, but the site is a demo so advanced properties and technologies were chosen to showcase them. To complete the buttons, and other parts of the interface, a SVG background was used. I plan to add
border-radiusto make the view buttons, and the head and footer of the interface have rounded corners. The screen needs to use SVG as the border uses a gradient to add the perception of depth. I suppose a border image can be used, but I like this approach. Other CSS3 properties used include
overflow-y(The Genre, Artist and Album lists, and eventually the song list table),
text-shadow(many of the headings), and CSS3 selectors (the song list and the button buttons). Other advanced technology used include SVG and HTML5 (
For those of you that haven’t seen, Dev Opera has just published a two part article series on styling form controls, by Christopher Schmitt. The first part covers using attribute selectors (which work in IE7, Opera, Safari and Firefox) to slim down your markup by providing a way to identify certain form controls without the addition of a class value. An example of this is using
input[type="text"]in the CSS, rather than adding
class="text"to the HTML file. The second part takes this further, by taking advantage of the
:checkedpseudo-classes, and a dash of
opacity. The browser support for these pseudo-classes are not as strong however. According to Christopher, Opera is the only browser that supports all three correctly.
If you are not aware of Dev Opera (known lovingly as Devo internally at Opera), it is Opera’s new developer site. Look out for a fantastic article on CSS3 from CSS3.info’s very own Peter Gasston in the near future.