CSS3

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!

Opera have just announced version 9.5 of their desktop browser, currently codenamed ‘Kestrel’ – and as you can see from the screenshot they’ve chosen, it passes the CSS 3 selectors test with flying colours!

They mention that CSS 3 support will be improved (text-shadow is provided as an example), as well as superior SVG support, and a new Javascript engine will allow better access to websites with wonky coding.

This sounds like a really exciting release, and should give Opera the accolade of being the most CSS 3 compliant cross-platform browser. Weekly builds will be available shortly.

With the release of Safari 3, there are now two browsers with (browser-specific) implementations of border-radius; unfortunately, the two implementations are different. The problem is that there is an unresolved ambiguity in the CSS 3 working draft.

The draft proposes four declarations, which describe the four corners of a block:

border-top-left-radius
border-top-right-radius
border-bottom-right-radius
border-bottom-left-radius

Each of them should accept two values, which define the radii of a quarter ellipse that defines the shape of the corner; this allows for irregular curves (take a look at the diagram in the draft if you need clarification, or see this example of a box with border-radius: 5px 20px, horribly rendered in Safari for Windows).

Safari, with the prefix -webkit-, accepts these. Mozilla, with the prefix -moz- (and differing declarations), accepts only a single value and, therefore, only regular curves.

At first glance, it would appear that Mozilla are in the wrong; however, their implementation is due to the ambiguity I mentioned earlier.

This ambiguity comes about in the border-radius shorthand property; if you enter a double value in this you’d expect to apply the irregular curves to all four corners:

border-radius: 5px 10px;

If you wanted to have four different irregular curves on the box, you’d have to provide eight values to the declaration:

border-radius: 5px 20px 10px 5px 10px 20px 20px 5px;

But what if you wanted to have two corners with one value, and two corners with a different value?

border-radius: 5px 10px 10px 20px;

The problem is that this could be confused for four corners with regular curves. In order to get around this, you’d still have to provide eight values:

border-radius: 5px 5px 10px 10px 10px 10px 20px 20px;

In fact, from the brief testing I’ve done (and I can’t find any documentation), it seems you can’t do any of that; unless I’m missing something, the shorthand declaration in Safari accepts only 1 or 2 values, to provide either regular or irregular curves which are applied to all four corners. If you want different irregular corners, you have to supply values to all four declarations:

border-top-left-radius: 5px 20px;
border-top-right-radius: 10px 5px;
border-bottom-right-radius:  10px 20px;
border-bottom-left-radius:  20px 5px;

Mozilla avoid this by going against the spec and allowing only regular curves; so you can provide 1, 2, 3 or 4 values and it’s all perfectly clear.

This problem is down to interpretation of the draft. I personally think Mozilla’s non-standard solution is better – it’s less flexible, but easier to understand – but can’t blame the Safari team for following the standard in their implementation.

It will be interesting to see which comes out on top; in the meantime, if you want to use border-radius in your code the only way to get them to appear the same on both browsers is with a single value for four regular corners:

-moz-border-radius: 10px;
-webkit-border-radius: 10px;

Apple has released Safari 3 in beta to the public, running both on Mac OS X and on Windows! This enables all of our fans to now have a look at the wonderful CSS3 stuff that’s in there, as it’s based on a very very recent version of Webkit.

I’ve updated the Preview pages to say Safari 3 instead of webkit, which will probably save me dozens of questions :). Go forth and try it out!

I’m at @media 2007 at the moment, and just watched a very interesting presentation by Håkon Wium Lie – who, as we know, wrote the original specification for CSS, 13 years ago.

In his presentation he talked about Opera on different platforms, then went into the future of HTML and CSS, talking about the HTML 5 spec, the new <video> element, @media queries, the CSS 3 paged content modules, multiple-columns, and much more.

I asked him what he thought of Andy Budd’s call for a CSS2.2 specification, and he said that he was all for it – now that’s an influential ally!

He also let slip a heavy hint that the next release of Opera (or at least an imminent release) will support the @font-face declaration, enabling us to finally break free of the limited font set!

It was a very interesting talk that touched on many more subjects, some of which I may return to later.

The W3C announced yesterday that they released new versions of the Multi-Column Layout module and the Media Queries module.

The last version of the Media Queries module dated back to July 8th 2002, so some time had passes since. The Multi-column layout module had been updated somewhat more recently, on the 15th of December 2005.

Changes to the Media Queries module

Other than quite a few new examples and the module being updated to the new look and feel, I can’t find much changes to this module…

Changes to the Multi-column layout module

This new version removes the property column-break-inside, which basically worked the same as column-break-before or column-break-after but for the inside (hah, you weren’t expecting that, where you?), and “replaces” it with column-fill.

It also adds the column-span property, which makes a lot more sense to me, allowing an element to span multiple columns. Example:

h2 { column-span: all; }

Good to see those modules updated, let’s hope they make it to final soon(-ish).

This post was written by fantasai on 23-5-2007 on her weblog, she e-mailed us and asked us to put it up here for the greater public to enjoy and be able to comment.

Lately there’s been a lot of talk about the CSS Working Group and about how we’re closed, out-of-date, slow, and/or dysfunctional. I’m acknowledging Andy Budd’s post here and other comments. It’s not very clear what we’re working on or why it’s taking so long, so I decided to write a couple posts, from my perspective as a CSS Working Group Invited Expert, on where we are,why we’re here, and where I think we should be going.

Disclaimer: This is my personal viewpoint and does not necessarily represent the perspective of anyone else.

In my last post, I explained a little about what we’re doing and how we operate. In this post, I’ll cover the problems I think we have and how I think we should address them.

What needs to change

(Besides companies allocating more man hours to working on css specs. ;)

Problem 1: Lack of web designer perspective

In my opinion, the CSS Working Group has been too dominated by browser implementors and gives too little weight to what web designers really want. For most of my time on the working group, the only representation we had from the web design community was from AOL: from Kimberly Blessing and Kevin Lawver. When Andy Clarke joined the CSS Working Group as an Invited Expert last year, I was really excited: finally some more web designer perspective. But Andy and Kevin are both too busy to be regular participants,and when they are around, they’re not technical enough to really follow the discussions and understand the impact some silly sentence in the spec has on what web designers are trying to do. Therefore our decisions tend to get made from the implementors’ perspective, even when it goes against common sense. Bert and I try to represent common sense, since neither of us represents anything else, but if there’s an impasse between us and the implementors, we’ll get voted down. Very often the working group would seriously consider the position of the web design community if they knew it, but Bert and I cannot represent to them how important an issue is for web designers, and the web designers aren’t there to speak for themselves.

Recently the increased participation of Adobe (Steve Zilles), HP (Melinda Grant), and even Microsoft has helped a lot to balance the excessive bugwards-compatibility bias we had for several years, but we’re still not aligning our work with the needs of the web design community as well as we should. It’s not an easy problem to fix. We need more dialogue between the CSS Working Group and the web design community, but simply putting some web designers on the working group doesn’t make that happen.

Problem 2: Poor communication with the public

Ian Hickson and Anne van Kesteren keep saying that the CSSWG should be restructured like the new HTMLWG, where anyone who wants to can join, and are disgusted that we aren’t seriously considering it. I’m far from convinced that this is a good idea. Making the HTML Working Group actually work is going to be an exercise in herding lots of very opinionated cats. I’m optimistic that as the undisputed master of the HTML5 spec (and an ardent cat-lover), Ian Hickson can pull that off, but we don’t have anyone with comparable ability, commitment, and sense of direction for CSS, and it would also set us up with a single, hard-to-replace point of failure. Ian has made himself indispensable before; it doesn’t work so well when he gets busy doing something else.

Another model that’s often brought up is the WHATWG. But the WHATWG isn’t actually structured more openly than the CSSWG. Its structure is more closed: it’s the communication lines that are more open. Consider:

• The WHATWG has open participation for discussion, and a dictator-editor who writes the spec.
• The CSSWG has open participation for discussion, and a dictator-committee who writes the specs.

It’s not possible to “join” a dictator-editor, but it is possible for somebody to join a dictator-committee. Therefore technically, structurally, the CSSWG is more open. But practically, that’s not what makes the difference in how open the spec-writing process is. The WHATWG’s process is more open because the WHATWG’s dictator-editor has set up multiple communication channels for feedback and responds quickly to that feedback, both with messages to the mailing list and with instantly-public updated drafts. The CSSWG publishes only snapshot drafts, posts little to the www-style list, doesn’t respond readily to feedback, and often doesn’t even acknowledge that feedback until the next working draft. I’ve tracked the CSSWG from the outside before, its a very frustrating situation. I’m glad the W3C is getting pressure to open up and that some of that pressure is being directed at us.

But I don’t think adopting the HTMLWG model is the best way forward. Critical people like Boris Zbarsky (Mozilla) and Markus Mielke (Microsoft) have already commented that they can’t keep up with the influx of mail there, and feedback from people like them isn’t something we can afford to lose. Above all else, the spec has to be something the implementors scan and want to implement.

The CSSWG doesn’t need a radical restructuring to be more open. We have a structure that, IMHO, works reasonably well, and we have a working group culture that is internally pretty open, amicable, and flexible. What’s missing is collaboration with talented and knowledgeable people outside the working group and an open, two-way, quality conversation with the web design community.

I think the best way for the CSS Working Group to open up is simply to communicate better with the public. I would like to see us

• Revamp our website to be more informative and more relevant.
• Publish a CSS Working Group weblog where we can post ideas, explain our work, and invite feedback from the web design community.
• Set up a public wiki where we can share information, keep track of our open issues and our resolutions, collect ideas submitted to the working group for consideration, and collaborate with people outside the working group to improve our test suites.
• Keep editors’ drafts in a public location so people can see our latest version and how we’re attempting to address their feedback.
• Interact more with sites like css3.info.
• Shift all our internal technical discussion to a public mailing list where others can read our comments, decisions, and rationale and themselves contribute to the spec-writing process. Currently www-style is primarily where we take in feedback and have open discussions, and the internal list is primarily where we process feedback into spec text. If we set up some guidelines to enforce that, the traffic on the new list should remain at a tolerable level.
• Open up the entire test suite development process and make it an independent open source project with contributors and leadership and a peer-review system of its own. The CSSWG itself doesn’t have the time, and doesn’t really need, to be running that show.

We discussed some of these issues at our last face-to-face meeting, and so far have already agreed

• To start a weblog! We’ve even got a couple posts on deck (including a less opinionated remix of my last one). Andy Clarke and Jason Teague have volunteered to cook up a hip, cool, and totally accessible new design in the near future, so stay tuned.
• To set up a wiki to track our work. (I set up an unofficial dokuwiki as a demo before the meeting, which I’m still using for test suite work; the official version may have to be a MoinMoin installation, yuck.)
• To maintain our issues lists in a public space, probably the wiki.
• To make it possible for CSS module editors to put their editor’s drafts in public CVS space. (Not all specs will move there, because some of our editors are uncomfortable editing in public, but you can expect anything I edit and anything David Baron edits to wind up there and hopefully most others as well. As David Baron says, he’s uncomfortable not editing in public.)
• To move most of our discussion to a public mailing list once we’ve sorted out the necessary IPR issues. Basically, anyone contributing significantly to the spec would need to agree to the W3C Patent Policy. This will probably take the form of something like a W3C Interest Group: editorship and decision-making power will rest with the CSS Working Group (but as I mentioned before we can always pull specific members of the public in as Invited Experts if we want to let them edit).
• To accept new test suite tests, assuming they at least conform to the guidelines, as correct until proven incorrect.

So we’re slowly making progress on this front, and the main blockers right now are technical, legal, and temporal, not organizational.Hopefully by the end of the year we’ll have set everything up and be working together with the web designers, implementors, and random techies towards a more inclusive CSS future.

As for the CSS2.1 Test Suite, I’ve acquired write access so I can edit it. So far I’ve fixed a few bugs, imported a handful of tests Microsoft submitted, and set up some indexing scripts to make a proper table of contents. I’ll probably be spending much more time there once Mozilla 1.9Beta is out. I plan to set up framework for turning it into an open source project rather than just open-sourced code, and hopefully we’ll be able to get the Mozilla, Microsoft, Opera, Webkit, and Hewlett-Packard QA teams, along with random volunteers, to all contribute tests.

This post was written by fantasai on 23-5-2007 on her weblog, she e-mailed us and asked us to put it up here for the greater public to enjoy and be able to comment.

Lately there’s been a lot of talk about the CSS Working Group and about how we’re closed, out-of-date, slow, and/or dysfunctional. I’m acknowledging Andy Budd’s post here and other comments. It’s not very clear what we’re working on or why it’s taking so long, so I decided to write couple posts, from my perspective as a CSS Working Group Invited Expert, on where we are, why we’re here, and where I think we should be going.

Disclaimer: This is my personal viewpoint and does not necessarily represent the perspective of anyone else.

First I’m going to answer a few questions that seem to be floating around.

What is the CSS Working Group doing these days? Why not a CSS2.2?

For those who think CSS2 was finished quickly and now CSS3 is taking forever… CSS2 wasn’t finished. It was published as a W3C Recommendation because back then, a Recommendation was the same as a Candidate Recommendation is now and got even less scrutiny from experts like David Baron and implementors like Boris Zbarsky. So CSS2 will actually be finished when CSS2.1 is finished. It’s not done yet.

The CSS Working Group is working on three things these days:

CSS2.1

Unless you’re tracking every issue, it’s hard to understand how much work has gone into CSS2.1. It’s not just taking a “snapshot” of CSS support as of 2002: most of the work is going into fixing hundreds of loopholes, mistakes, and conflicts between the spec and implementations or the spec and itself. There’s no immediate practical benefit to web authors, but the implementors need a super-precise spec in order to all aim at the same behavior. Minor cross-browser incompatibilities drive web designers nuts. Having a common goal for each of these will help implementors make those go away.

“CSS2.2”

We’re not working on a CSS2.2 as such, but that’s because CSS3 is modular. We’re working instead on cutting down and/or refining features in earlier CSS3 drafts in order to get some CSS3 modules into a stable, implementable state. Selectors has already made it, CSS Namespaces is almost there, and believe it or not, CSS Backgrounds and Borders is pretty close.

CSS3

Some of the CSS3 modules out there are “concept albums”: specs that are sketching out the future of CSS. Among these explorative specs are CSS Advanced Layout, the outdated CSS Generated Content, and the more recent CSS GCPM (a miscellaneous collection of print-oriented features).

Most of our focus as a group has been on CSS2.1. Progress on otherdrafts depends entirely on whether we have an interested editor who’s putting in the time.

Drafts that have been pulled back from CR were pulled back due to problems in the CR. If a specification needs substantive changes,even minor ones, it has to be returned to working draft status.Selectors was pulled back for relatively minor changes; CSS2.1was pulled back for lots of tiny to medium-size changes; and CSS3 Text was pulled back for a complete rewrite (see e.g. my comments from 2003).

Why is the CSS Working Group so slow? Wouldn’t being more like the WHATWG speed it up?

It’s mainly about time. The active CSS Working Group members all have very busy full-time jobs, many of them at the manager level. These members would love to spend more time on moving CSS forward, but due to their many other responsibilities, just can’t. It’s been argued by some that being a committee rather than a dictatorship is inefficient,but aside from CSS2.1 and other CR-level drafts where we need to make sure all the implementors are on board with any changes, the CSS WG only exercises loose oversight on a spec editor’s work: ultimately the bottleneck is the total amount of time×skill spent banging at the keyboard.

(Notice that the WHATWG has an extraordinarily talented and knowledgeable spec-writer working more or less full time on the HTML5 spec, and the draft is still in the unfettered-development working draft stage.)

I have time and technical ability. How can I help?

Comment on our work

Our specs are open to public comment. Look them over and give us feedback. Tell us about our grammar mistakes and logical loopholes, or pros and cons about a particular feature’s design and how to improve it. Send us examples we can add to better explain the prose, or suggestions for features that would really make your day (and make sure you explain the inspiring scenario that’s giving you a headache right now). Most of us aren’t web designers ourselves, so we need well thought-out comments from that perspective.

Help with the test suite

Each stable CSS spec has an associated test suite. The test suite serves several purposes: it helps implementors see their bugs and fix them; it helps spec writers see their bugs and fix them; and it lets the spec qualify for Recommendation once two implementations pass it. The CSS2.1 test suite needs many more tests to be complete. It also needs people to review each test and make sure it’s still correct with respect to the updated specification. So if you’re not up to writing new tests, point your favorite browser at the CSS2.1 Conformance Test Suite and see where it fails. If a test fails in more than one of Opera, Mozilla, or Safari and you’re not sure the spec’s prose is backing up the test’s failure, send an email to [email protected] asking for it to be reviewed and I’ll take a look.

Become an editor

While anyone can comment or contribute to the test suite, becoming an editor is not as simple. Writing good specs is a skill, just like programming is a skill. Even just reading specs and interpreting them correctly is a skill. If you have that down and feel you know CSS and its design principles inside-out, you can consider becoming an editor. If there’s a spec that isn’t moving and you really want to help push it forward, start by commenting. Review it as if you already are the junior editor, and the current editor is your senior co-editor. Post emails to www-style explaining what needs to be fixed and why with specific replacement text that will solve the problem. If you’re good, and we feel we can give you responsibility for the spec without needing to look over your shoulder, we’ll make you an invited expert and assign you to the spec. David Baron, Ian Hickson, and I all started out by commenting in www-style and from there became invited experts.

Why can’t you Just Ship CSS2.1 and fix the problems later?

You can Just Ship software with bugs in it to put out a new stable release because it’s versioned. The next version replaces the old. You can always fix the leftover bugs in the next version. CSS doesn’t have versions. Any problems there are in the way CSS2.1 defines things can’t be fixed in CSS3 except maybe by adding really confusing sets of switches. CSS3 cannot change anything in CSS2.1, it can only build on top of it.

CSS Working Group Myths

Next, I want to set the record straight on a few things:

Myth 1: The CSS Working Group doesn’t invite feedback from the web community.

The W3C has had an open, archived mailing list dedicated to getting feedback on style sheets from the public since before there was a CSS Working Group. It’s called [email protected] and anyone can join, post, and participate in discussions as long asthey agree to let the W3C archive their comments. We publish public drafts of our specs precisely so that we can get comments from web designers, implementors and random techies.

If you’re posting a weblog entry about one of our specs, whether you’re famous or not, chances are we won’t see it. Post the URL to www-style, or at least private-message it to someone and ask them to post it for you. Don’t be shy: we do want to hear your opinion, good or bad.

Myth 2: The CSS Working Group members want to be closed and insular.

The W3C standards development process has historically been somewhat closed: public mailing lists were available for discussion, but decisions were made behind the scenes by committees of paying W3C members. From what Bert (our chair) has been saying over the years, there seem to be several reasons for this:

• The W3C needs cashflow to operate, and it gets this by signing up members. The companies obviously want some benefit for forking over so much money, so they get
  • early access to drafts
  • access to the W3C’s internal archives
  • decision-making power in the working group
• Since the decision records are member-confidential, there’s no public record of who blocked or pushed for which feature, only a final resulting spec.
• Since discussion records are member-confidential, reps can share not-quite-public information from their companies as necessary.
• Participation in the W3C requires agreement to the W3C Patent Policy, so that W3C technologies can be implemented royalty-free. The agreement encompasses not just the individual representatives or departments involved, but all the patents owned by the member company. (This is why the W3C refuses to sign up invited experts who work for companies that operate in the same domain. They instead demand that the company as a whole pay the membership fee and join, because an invited expert is only responsible for the patents he or she personally owns.)

As Daniel Glazman would have one believe with his stories of confrontation at the table and smoky-backroom negotiations in the hallways back during the Netscape-Microsoft browser wars, reasons #2 and #3 were probably much more important in the past. Nowadays, the CSS Working Group makes almost all its decisions by consensus. Very few decisions have come to a vote. Very little confidential information is shared. We’d be happy to open up more of our records to the public, and we resolved at the last face-to-face meeting that we want to shift all our technical discussion to a public mailing list if we can just sort out the inevitable IPR issues.

I do believe the CSS Working Group can and should be more open, but the reason we’re not more open is a lack of time and pressure to overcome the bureaucratic overhead and inertia, not a lack of desire to interact with the rest of the world.

Myth 3: Microsoft is holding back CSS standards development and/or doesn’t care.

I have no idea what Microsoft Corporation’s agenda is, but ever since they rejoined the CSS Working Group, the Internet Explorer team has been actively participating in the working group. Markus Mielke has been consistently pushing us to spell things out explicitly one way or the other rather than leave anything undefined, and most recently Paul Nelson, whose expertise is in internationalization and fonts, has volunteered to pick up some of the specs whose editors left the working group years ago. That’s not the behavior of a group that wants to hold back standardization. Markus’s team wanted to fix more bugs inIE7, but the release schedule didn’t give them the chance to make many of the changes they wanted. The company as a whole may be trying to undermine the Web’s openness, but the reps they send to the CSS Working Group genuinely believe in cooperating through the W3C and moving forward with web standards.

Continue: problems I see and how I think we should address them.

The header of my own blog (still in development; please don’t judge me!) features a single image which spans two columns, with a semi-opaque panel featuring text over the top of it. I wanted the image to be clearly visible in the left column, and faintly visible in the central column. I could have done this by designing it that way in a graphics package, but as I intend to swap the image around in future, I wanted to come up with a client-side solution.

I could have just used a semi-opaque background image, which would have worked immediately with all major browsers bar IE6. But I didn’t want to use an extra image and I wanted to play around with CSS 3, so this is what I came up with:

Firstly, I put the image as a background property on the <body> element. Next I created an empty, presentational <div> with a class of ‘header’. To this I assigned the colours and border colours, then gave it a large left-margin to allow the image to completely show through on the left column, and an opacity of 0.9 in order to allow the image behind to faintly show through on the central column.

The problem with opacity is that it is inherited by all child elements, so if I had put text inside div.header, the text would also have become semi-opaque. To get around this I assigned position: relative to the <body>, then wrapped another <div> called .title around <h1> and <h2>, put it after .header, then absolutely positioned it where I wanted it to appear:

<body>
<div class="header"></div>
	<div class="title">	
	<h1></h1>
	<h2></h2>
	</div>
</body>

body { background: white url(images/header.png) no-repeat; }

.header {
background-color:#8DCC3A;
border-top:60px solid #4A5C61;
margin-left:20%;
opacity:0.9;
}

.title {
left:21.5%;
position:absolute;
top:80px;
width:57%;
}

Opacity doesn’t work in Internet Explorer, of course; I could have used a proprietary filter, but decided that the 19% of visitors to my site who use Internet Explorer wouldn’t suffer by not being able to see the whole image; it would be a little ‘bonus’ for whoever uses a better browser (here’s an image if you’re using IE and want to see what other users see).

Another solution was available to me; keep the <h1> and<h2> inside .header, and use rgba values on it instead. This would be better semantically as I could drop .title, and wouldn’t involve any positioning as rgba values are not inherited. I could have used the following code:

<body>
<div class="header">
<h1></h1>
<h2></h2>
</div>
</body>

body { background: white url(images/header.png) no-repeat; }

.header {
background-color: rgba(141,204,58,0.9);
border-top: 60px solid rgba(74,92,97,0.9);
margin-left: 20%;
padding-top: 20px;
}

h1, h2 { padding: 0 7%; }

While this is obviously leaner and quicker, support for it is not as widespread; at the time of writing this, perhaps only 4% of my visitors would see the effect I wanted.

My two most extreme options were to have added extra styles and conditional comments to the document in order to getting working across all browsers, or to use the purer, smaller CSS3 to get it working on only a tiny amount of current browsers. In the end I did what we’ve been doing for so long now, and made a compromise.

I’ve put the new layout online! Of course I know work needs to be done on it, but I know myself: I’ll only do that when I put the new thing live :). The sidebar is widgetized, and I’ve tried to use as much css3 features as I could ;). I’ll be adding fallbacks for all the different css3 stuff in the coming days, for now, it looks best in a WebKit nightly build, and it looks pretty good in Firefox too… Let me know what you think!

Of course I need to thank Laurens, from TND media, for creating the design in Photoshop!