CSS3

If you’ve been reading this blog, you’ll know that Opera has been making great progress on the CSS3 selectors front in the latest version of its engine – Presto Core-2. While Opera 9.5 does pass every test in the CSS3.info selectors test, it wasn’t without issues. The test doesn’t test the ::selection pseudo element. It also doesn’t test what happens when manipulating the markup through the DOM. Both of these were not supported in Core-2, but that is now not the case.

If you go to this test page (Warning Geocities) with the latest Opera weekly, you’ll notice it is now working correctly. This is the last selector that Opera didn’t support. The dynamic behaviour of the selectors have also been fixed. If you head off to Quirksmode and try out either the :first-child and :last-child, :only-child, :first-line and :first-letter or the :empty tests, you’ll find that they all work. Although it is most likely not without bugs (what software is?), it seems Opera 9.5 will be the first browser that fully supports all selectors in CSS correctly. It could be that Konqueror has fixed the issues high-lighted on PPK’s blog, but I don’t have a copy to test. Leave a comment if that is the case. Konqueror does fantastically well even if it doesn’t support everything.

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 content property has been available since CSS2. However this was only available using the :before or :after pseudo-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.

The content property 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-radius to 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 (getElementsByClassName).

This is a sponsored post for my employer, Onetomarket, I don’t usually do sponsored posts here, but since this could ease my work life a bit :) , I’ll make an exception.

We’re looking for a full time developer here at Onetomarket to help us in automating a lot of our work.

If you:

• Are a good PHP / MySQL developer.
• Can develop an application based on different API’s on your own.
• Have ideas on how to improve stuff and can explain them to us.
• Would like to work with a team of young and enthusiastic internet professionals.

Then maybe you should join us in our office in Arnhem, the Netherlands or in Barcelona, Spain. Mail me at joost ” at ” joostdevalk dot nl, and I’ll set you up for a meeting!

To create a coherent collection of blog discussion about CSS3 and the future of CSS, the CSSWG and the css3.info team have teamed up to create a W3C-hosted aggregate feed, The Future of Style, and an associated css3.info-hosted open community blog, the CSS3 Soapbox.

We’re starting off The Future of Style by pulling in the CSS Working Group Blog, css3.info, and the CSS3 Soapbox. If you have a post you want to add to this feed, post a link (or the whole thing) on the CSS3 Soapbox. If you own a blog with frequent posts about the future of CSS, and want to be added to The Future of Style, contact fantasai.

The CSS3 Soapbox is meant to give you as a developer, designer or whatever, a voice in css development. This feed will be read by all those involved in CSS development, so you can get your message across easily.

We want you to join the conversation!

With the latest weekly of Opera, Opera will support the HSL colour unit. With HSL added, there are only three units missing, HSLA, RGBA and flavor. I don’t really understand flavor, or why it would be useful and no browser currently supports it. I’d suspect now that Opera Kestrel supports RGB and HSL, that the two colour models with added alpha channel support will both be added at the same time. I can’t confirm when these will be added yet however. You can test out support for this here.

I’m working on a support chart for the colour module, that just needs testing to be finalised in IE, as I currently don’t have access to IE7. This should be added to the Module Status page shortly.

We’re busy here at css3.info! Our interview with H&kon was cool of course, but then Opera 9.5 was released and we had to update and add quite a few pages… Because all these pages were still static html, that was quite a bit of work. Tonight I took the time to move all of them into WordPress, and after I’d done that, I’ve refined the search function and results a bit, so it now shows the pages in the searches as well!

We’ll probably be adding new preview pages in the coming days, I’ve already updated the existing ones which Opera 9.5 supports now (cool, cool stuff, you should really have a look at it).

Ow and because of the many complaints about it, I removed the text-shadow from the text in the menu tabs.

You’ve probably seen the ad for them on the right hand side by now if you’ve visited this site before, but we thought it would be good to introduce them in a post as well: a warm welcome to FreshBooks!

FreshBooks let’s you send out invoices through a great online interface, has a nice API, automatically accept all sorts of payments, etc. etc. etc.! I seriously suggest checking out their tools if you do a lot of invoicing, especially as they are NOT expensive.

When you’re at it, check out the great design of their site… It’s one of the best looking commercial sites I’ve seen in a while.

Now that got your attention, didn’t it? You’ve probably never seen a site where Safari has a market share of 84%… Well neither had I. Until I looked at the browser stats for this site… I just had to share it with you all:

As liquidat points out quite correctly, it is NOT Opera that is the first to support all the tests in our CSS Selectors test. Those bragging rights go to Konqueror, as we pointed out in January already. Release 3.5.6 of KHTML was the first to support all the tests, not any other browser, sorry David :) .

We, the CSS3.info team, are very very proud to see our Selectors Test being used as the de facto test of selectors compatibility though, and we hope that other browser projects will be using it too!

While I’m at it, please remember that our preview section is only a showcase of css3 properties that are currently implemented in any browser. If any browser were to support all the things in that section, this does not constitute “full css3 support”, as there is no such thing yet. This also means that it could be that we are missing features in that section that are currently implemented in a browser, if that’s true, please drop us a line!