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 (
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.
- 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!
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.
(Besides companies allocating more man hours to working on css specs. ;)
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.
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.
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.
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:
- 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.
- 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.
- 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).
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.)
- 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.
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.
Next, I want to set the record straight on a few things:
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.
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.
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.