The other was the publication of the minutes of the CSS Working Group meeting in Paris, where it was revealed that several vendors are about to support the -webkit- vendor prefix in their own very non-WebKit browsers. Thus, to pick but a single random example, Firefox would throw a drop shadow on a heading whose entire author CSS is h1 {-webkit-box-shadow: 2px 5px 3px gray;}.

As an author, it sounds good as long as you haven’t really thought about it very hard, or if perhaps you have a very weak sense of the history of web standards and browser development. It fits right in with the recurring question, “Why are we screwing around with prefixes when vendors should just implement properties completely correctly, or not at all?” Those idealized end-states always sound great, but years of evidence (and reams upon reams of bug-charting material) indicate it’s an unrealistic approach.

As a vendor, it may be the least bad choice available in an ever-competitive marketplace. After all, if there were a few million sites that you could render as intended if only the authors used your prefix instead of just one, which would you rather: embark on a protracted, massive awareness campaign that would probably be contradicted to death by people with their own axes to grind; or just support the damn prefix and move on with life?

The practical upshot is that browsers “supporting alien CSS vendor prefixes”, as Craig Grannell put it, seriously cripples the whole concept of vendor prefixes. It may well reduce them to outright pointlessness. I am on record as being a fan of vendor prefixes, and furthermore as someone who advocated for the formalization of prefixing as a part of the specification-approval process. Of course I still think I had good ideas, but those ideas are currently being sliced to death on the shoals of reality. Fingers can point all they like, but in the end what matters is what happened, not what should have happened if only we’d been a little smarter, a little more angelic, whatever.

I’ve seen a proposal that vendors agree to only support other prefixes in cases where they are un-prefixing their own support. To continue the previous example, that would mean that when Firefox starts supporting the bare box-shadow, they will also support -webkit-box-shadow (and, one presumes, -ms-box-shadow and -o-box-shadow and so on). That would mitigate the worst of the damage, and it’s probably worth trying. It could well buy us a few years.

Developers are also trying to help repair the damage before it’s too late. Christian Heilmann has launched an effort to get GitHub-based projects updated to stop being WebKit-only, and Aarron Gustafson has published a UNIX command to find all your CSS files containing webkit along with a call to update anything that’s not cross-browser friendly. Others are making similar calls and recommendations. You could use PrefixFree as a quick stopgap while going through the effort of doing manual updates. You could make sure your CSS pre-processor, if that’s how you swing, is set up to do auto-prefixing.

Non-WebKit vendors are in a corner, and we helped put them there. If the proposed prefix change is going to be forestalled, we have to get them out. Doing that will take a lot of time and effort and awareness and, above all, widespread interest in doing the right thing.

Thus my fairly deep pessimism. I’d love to be proven wrong, but I have to assume the vendors will push ahead with this regardless. It’s what we did at Netscape ten years ago, and almost certainly would have done despite any outcry. I don’t mean to denigrate or undermine any of the efforts I mentioned before—they’re absolutely worth doing even if every non-WebKit browser starts supporting -webkit- properties next week. If nothing else, it will serve as evidence of your commitment to professional craftsmanship. The real question is: how many of your fellow developers come close to that level of commitment?

And I identify that as the real question because it’s the question vendors are asking—must ask—themselves, and the answer serves as the compass for their course.

I’ll warn you up front that as of this writing the user interaction is not ideal, and in some places the presentation suffers from too much content overlap. This happens in timelines where lots of drafts were released in a short period of time. (In one case, two related drafts were released on the same day!) I intend to clean up the presentation, but for the moment I’m still fiddling with ideas. The obvious one is to rotate every other spec name by -45 degrees, but that looked kind of awful. I suspect I’ll end up doing some sort of timestamp comparison and if they’re too close together, toss on a class that invokes a -45deg rotation. Or maybe I’ll get fancier!

The interaction is a little tougher to improve, given what’s being done here, but I have a few ideas for making things, if not perfect, at least less twitchy.

I should also note that not every module is listed as I write this: I intentionally left off modules whose last update was 2006 or earlier. I may add them at the end, or put them into a separate set of timelines. The historian in me definitely wants to see them included, but the shadow of a UX person who dwells somewhere in the furthest corners of my head wanted to avoid as much clutter as possible. We’ll see which one wins.

Anyway, somewhat like the browser release timeline, which is probably going to freeze in the face of the rapid-versioning schemes that are all the rage these days, I had fun combining my love of the web and my love of history. I should do it more often, really. The irony is that I don’t really have the time.

Put simply: as per the Introduction of the latest CSS 2D Transforms draft, a transformed element creates a containing block for all its positioned descendants. This occurs in the absence of any explicit positioning of the transformed element.

Let’s walk through that. Say you have a document whose body contains nothing except a position: static (normal-flow) div that contains some absolutely-positioned descendants. The containing block for those positioned elements will be the root element. Nothing unusual or unexpected there.

But then you decide to declare div {transform: rotate(10deg);}. (Or even 0deg, which will have the same result.) Now the div is the containing block for the absolutely-positioned elements that descend from it. It’s as though transforming an element force-adds position: relative. The positioned elements will rotate with their ancestor and be placed according to its containing block—not that of the root element.

Okay, so that’s a little unusual but perhaps not unexpected. I could make arguments both ways, and some of the arguments could get pretty complex. To pick one example, if the transformed element didn’t generate a containing block, how would translate transforms be handled?

Either way, here’s where things got really troublesome for me: a transformed element creates a containing block even for descendants that have been set to position: fixed. In other words, the containing block for a fixed-position descendant of a transformed element is the transformed element, not the viewport. Furthermore, if the transformed element is in the normal flow, it will scroll with the document and the fixed-position descendants will scroll with it. You can see my test case, where the red and blue boxes would overlap each other and stay fixed in place, except the second green div has been rotated.

Obviously this makes the fixed-position elements something less than fixed-position. In effect, not only does the transformed element act as if it’s been force-assigned position: relative, the fixed descendants behave as if they’ve been force-changed to position: absolute.

I find this not only unusual and unexpected, but also a wee bit unsettling. Personally, I think it goes too far. Fixed-position elements should be fixed to the viewport, regardless of the transformation of their ancestors. Of course, if you agree with my thinking there, realize that opens a whole new debate about how, or even whether, transforms of ancestors should be carried to fixed-position descendants.

I have my own intuitions about that, but this is definitely territory where intuitions are to be treated with caution. There are a lot of interacting behaviors no matter what you do, and no matter what you do someone’s going to find the results baffling in some way or other.

But since I do have intuitions, here’s what they are: transformed elements in the normal flow or floated do not establish containing blocks for absolutely- and fixed-position descendants. This means that any transforms you apply to the transformed element are not applied to the positioned descendants, because transforms don’t inherit.

What if you want a normal-flow transformed element to be a containing block? Use position: relative, same as you would if there were no transform. And if you want the transforms to be passed on to the descendants even though no containing block is established? The inherit value would work in some cases, though not all. That’s where my approach runs aground, and I’m not yet sure how to get it back to sea.

Okay, so that’s what I think. What do you think?

To be clear, when I say “Can CSS create art?” I don’t mean that in the sense of wondering if art, or artful designs, can be accomplished with CSS. I think we all know the answer there, and have known at least since the Zen Garden got rolling. What I’m doing here is using some basic CSS to generate art, using web sites as the medium. For the series I linked, I spun all of the elements on a page using transform: rotate() to see what resulted. Any time I saw something I liked, I took a screenshot. After I was done, I winnowed the shots down to the best ones.

As some of you old-schoolers will probably have recognized, I’m absolutely following in the footsteps of Joshua Davis here, and in fact my working title for this effort was “Once Upon a Browser”. I saw Josh speak years ago, and clearly remember his description of how he generated a lot of his art. My process is almost identical, albeit with a bit less automation and computational complexity.

Because this is me, I built a little commentary joke into the first images in the series. It’s not terribly subtle, but with luck one or two of you will get the same chuckle I did.

I’m already thinking about variants on this theme, so there may be more series to come. In the meantime, as I surf around I’ll stop every now and again to spin what I see. I’ll definitely mention any new additions via Twitter, and new series both there and here. And of course if you follow me on Flickr, you’ll see new pieces as they go up.

I hope you enjoy them half as much as I enjoyed creating them. And if anyone wants to use the originals as desktop wallpapers, as Tim proposed, feel free!

The way it works is you input a series of transform functions, such as translateX(22px) rotate(33deg) scale(1.13). The end-state and its matrix() equivalent should update whenever you hit the space bar or the return key, or else explicitly elect to take the red pill. If you want to wipe out what you’ve input and go back to a state of blissful ignorance, take the blue pill.

There is one thing to note: the matrix() value you get from the tool is equivalent to the end-state placement of all the transforms you input. That value most likely does not create an equivalent animation, particularly if you do any rotation. For example, animating translateX(75px) rotate(1590deg) translateY(-75px) will not appear the same as animating matrix(-0.866025, 0.5, -0.5, -0.866025, 112.5, 64.9519). The two values will get the element to the same destination, but via very different paths. If you’re just transforming, not animating, then that’s irrelevant. If you are, then you may want to stick to the transforms.

This tool grew out of the first Retreats 4 Geeks (which was AWESOME) just outside of Gatlinburg, TN. After some side conversations betwen me and Aaron during the CSS training program, we hacked this together in a few hours on Saturday night. Hey, who knows how to party? Aaron of course wrote the JavaScript. Early on we came up with the punny name, and of course once we did that the visual design was pretty well chosen for us. A free TTF webfont (for the page title), a few background images, and a whole bunch of RGBa colors later we had arrived. Creating the visual appearance was a lot of fun, I have to say. CSS geeks, please feel free to view source and enjoy. No need to say “whoa”—it’s actually not that complicated.

So anyway, there you go. If you want to see the matrix(), remember: we can only show you the door. You’re the one that has to walk through it.

For fun, and also to give fans of this or that property a chance to petition for re-inclusion, here are the properties and modules I cut. Think of it as the blooper reel, which can be taken more than one way. I’ve organized them by module because it’s easier that way.

• The backface-visibility property from the 3D Transforms module. This is one I’m already reconsidering, but I haven’t found any indication that anyone besides Webkit will be picking it up in the near future. Still, I did document the rest of the 3D Transforms module so I may add this back in during the tech review stage.
• rotation and rotation-point from the CSS3 Box module. These have been effectively replaced by the 2D Transforms module, but the Box module hasn’t been updated since that happened.
• Everything in the Flexible Box Layout module. There are, as of now, just too many sections bearing notes, warnings, questions, and general feelings of instability and future change for me to feel comfortable including the properties from this module. I’m probably going to catch some flak for that.
• grid-columns and grid-rows from the Grid Positioning Module Level 3, which effectively means means excluding the entire module. Some day maybe I’ll write a separate pocket reference just for the various CSS layout systems.
• font-stretch. Its continued exclusion saddens me, because I am exactly the sort of sheep-stealing lowlife who would programmatically stretch and compress font faces and like it, but so far as I can tell nobody’s supporting the property. Alas.
• Basically, the entirety of the Generated Content for Paged Media module.
• The Behavioral Extensions module, which means the binding property as well as the :bound-element pseudo-class.
• All the properties in CSS Marquee module. I’d love to see someone make a compelling case for re-instating them.
• The following properties from CSS Text Level 3: hanging-punctuation, punctuation-trim, text-align-last, text-emphasis-position, text-emphasis-style, text-emphasis, text-justify, text-outline, text-wrap, white-space-collapsing, and word-break.
• The following properties from the Basic User Interface module, dated 2004: appearance, icon, nav-down, nav-left, nav-right, nav-up, and nav-index.
• The Hyperlink Presentation module, dated 2004.
• The Presentation Levels module, dated 2003.
• move-to and crop from the CSS3 Generated and Replaced Content module, dated 2003.
• The Line module, dated 2002 and bearing my name for no reason I can recall. The one property listed there which I kept is vertical-align, and I just used the CSS2.1 definition.

After all that, I imagine you’re going to laugh uproariously when I tell what I did include: paged and aural properties. I know—I’m kind of poleaxed by my own double standard on that score. I included them for historical reasons (they’ve long been included) and also because they’re potentially very useful to a more accessible future. Besides, if we run out of pages, they’re in their own section and so very easy to cut.

I’m pretty sure I listed everything that I explicitly dropped, so if you spot something that I absolutely have to reinstate, here’s your chance to let me know!

In Webkit and Gecko, hovering the first div causes the span to animate a 270 degree rotation over one second, but when you unhover the div the span immediately snaps back to its starting position. In Opera 11, the span is instantly transformed when you hover and instantly restored to its starting position when you unhover.

In all three (Webkit, Gecko, and Opera), hovering the second div triggers a one-second 270-degree rotation of the span. Unhovering causes the rotation animation to be reversed; that is, a one-second minus-270-degree rotation—or, if you mouseout from the div before the animation finishes, an rotation from that angle back to the starting position. Either way, it’s completely consistent across browsers.

The difference is that in the first test case, both the transform and the transition are declared on hover. Like this (edited for clarity):

div:hover span {
	transition: 1s transform;
	transform: rotate(270deg);
}

In the second test case, the transform and the transition are split up like so:

div span {
	transition: 1s transform;
}
div:hover span {
	transform: rotate(270deg);
}

It’s an interesting set of results. Only the second case is consistently animated across the tested browsers, but the first case only animates one direction in Webkit and Gecko. I’m not sure which, if any, of these results is more correct than the other. It could well be that they’re all correct, even if not consistent; or that they’re all wrong, just in different ways.

At any rate, the takeaway here is that you probably don’t want to apply your transition properties to the hover state of the thing you’re transitioning, but to the unhovered state instead. I say “probably” because maybe you like that it transitions on mouseover and instantly resets on mouseout. I don’t know that I’d rely on that behavior, though. It feels like the kind of thing that programmer action, or even spec changes, will take away.

See, the trick as posted involves editing style elements that have been embedded into the body. That is of course valid in HTML5 when you scope the style element, but scoping wasn’t the point of the proffered demo. And I I’ve long known that it’s simple to display style elements from within the head; it’s what I did for the CSS3 tests I recently published, used in demos of diagnostic styles, and so on. Why not do the same thing here and avoid the invalidity of an unscoped body-embedded style element?

Accordingly, I created my own variant demo, where you can edit the head-embedded styles directly. While I was at it, I used another favorite trick of mine: I took the CSS used to make the styles appear in the browser and put them in their own style sheet that doesn’t get shown. Usually I id the style sheet to be displayed and style based on that. This time I had a better hook, in that the style element to be edited already had a contenteditable attribute. So:

head, style[contenteditable] {display: block;}
style[contenteditable] {
  font-family: monospace; white-space: pre; padding: 0.5em;
  border: 1px dotted red; background: white;}

Yay attribute selection!

Feel free to have fun editing the styles embedded in the document from within the document. As usual, do so at your own risk, no warranty is expressed or implied, not liable for damages arising from your use or failure to use, not a flying toy, blah blah blah. Share and enjoy!

(Incidentally, if anyone knows a markup- or CSS-based way to get around the Shift-Return-for-newline requirement in Gecko browsers, I’d love to hear about it.)

I was especially interested by the results for list-style-type, where I found some small spots of support for various types in various browsers. In contrast, WebKit supports most of the CSS3 types, so far as I can tell, though in my install several types were apparently mangled by a lack of appropriate fonts.

If you dig in, you’ll discover that the individual tests are all poured through some PHP. The reason for this is that the base test pages (which are straight HTML; see for example the list-style-type base) include neither navigation links nor vendor prefixes. That’s what the PHP handles. It’s a bit clumsy, URL-wise, and that’s why the index page of the tests warns that the tests’ URLs could change in the future. Not the index page: that will remain cool for as long as I have anything to say about it. I just can’t swear off tinkering with the URLs of the tests for the time being. It’s entirely possible that at some point in the future I’ll ice them down, but no guarantees.

I’m tossing these into the public sphere for three reasons. The first is that they might be useful to other people, and I’m always in favor of sharing stuff that might be useful. The second is that I may have committed grievous errors of fact, and many eyes make errors obvious. If you find an error, please let me know. I prefer that such reports be left as comments here since it lets many eyes evaluate the error reports too, but I’ll accept private mail as well.

The third is that it represents another turn of the wheel. I started my CSS career building tests to see what browsers got right and wrong, and every so often I come back to that same fundamental act. The other times I’ve done so, I’ve published what resulted. This time, I’m publishing a little earlier and little more in the raw, so to speak, but it’s still the same impulse—and by now, it’s Tradition.

So I hope you enjoy, or at least find useful, these tests and whatever other tests get built in the future!

One thing of note: I decided to write the leaderboard script so that it directly parses an HTML file to figure out the rankings. You can see the file yourself, if you like. At the moment it’s just a bunch of dls, but at some point I suspect I’ll convert it to a table. The advantage is that it’s easier for other people to fact-check the source data this way: just load it up in a browser.

I thought about just parsing specs directly but it seemed like overkill to load the entirety of the CSS2.1 module just to figure out the process status, publication date, and editor list. And then do that same thing for every one of the 38 tracked modules. This way I have the leaderboard and a central summary of the modules’ status, and hopefully the latter will be even more human-readable in the future.

Anyway, it was a fun little project and now it’s loose in the world. Enjoy.

There is one small change I made between 2.0b2 and 2.0 final, which is the replacement of the “THIS IS BETA” warning text with an explicit lack of license. The reset CSS has been in the public domain ever since I first published it, and the Reset CSS page explicitly said it was, but the file itself never said one way or the other. Now it does.

Thanks to everyone who contributed their thoughts and perspectives on the new reset. Here’s to progress!

Note that allowing a 3×3 grid pattern for border-image is potentially very useful, as it permits the creation of sophisticated border ‘frames’ with a single image. The objection I have is that it’s required, even in simple cases like the one I described in the previous post.

The reason this 3×3 pattern is required is found in the description of border-image-slice, which states:

The regions given by the ‘border-image-slice‘ values may overlap. However if the sum of the right and left widths is equal to or greater than the width of the image, the images for the top and bottom edge and the middle part are empty, which has the same effect as if a nonempty transparent image had been specified for those parts. Analogously for the top and bottom values.

That means that if you specify, for example, a slice distance of 100% (the default) then the top, bottom, and side portions of the border will be completely empty. Only the corners will get the image. The same thing will happen in any case where the sum of two slices along the same axis exceeds the dimension of the image along that same axis. In other words, if the defined left and right slice distances add up to more than the width of the image, then both slices are made completely transparent. Ditto for top, bottom, and height.

It seems to me that the easy way to make it possible to repeat a single-symbol image is to change that bit to instead say something along these lines:

The regions given by the ‘border-image-slice‘ values may overlap. Values greater than the intrinsic dimensions of the image are “clipped” to the intrinsic dimensions of the image. Values greater than 100% are treated as 100%. Negative values are treated as 0.

Or maybe going beyond 100% or the image dimension means filling the remainder with transparency—I’m not sure yet which would be better. I’d be interested to know if anyone has a compelling use case for the “fill transparent past 100%” behavior.

Anyway, when I raised the beginnings of this as a possibility on www-style, I was told that an “older and less mature” draft did exactly that, but it was at some point changed to the current behavior. My inquiry as to the reasons for that change have so far been met with silence, so if necessary I’ll raise it again in a few days.

Commenters found that WebKit browsers can be made, with a very specific value pattern, be made to repeat a single-symbol image all the way around a border. It turns out that’s only because WebKit implements the earlier version of the specification and it hasn’t since been updated. Personally, I hope it retains its behavior (with improvements to make it less finicky) and the other rendering engines change to match it, not the other way around. But to make that happen, I suspect the spec will need to be changed. Here’s hoping.

So allow me to pose this to you as a challenge. Given the following ideal rendering, how would you arrive at the depicted result using the single 5-pixel-by-5-pixel image shown within the content?

Note that it doesn’t have to be quite as clean as this—if there are partial diamonds adjacent to the corners where repeated images get clipped, that’s fine.

Should you answer, please be clear which type of answer you’re giving:

1. What the specification says you should write to make this happen. Note to those tackling this fresh: I think the descriptive prose for border-image-slice (yes, -slice) makes this harder than it seems, but I could be wrong.
2. What you wrote to get browsers to do it consistently. (Safari, Firefox, and Opera at a minimum. Did IE9 get border images yet? Vendor prefixes not required unless you had to write different values for different browsers.)
3. Both spec- and browser-friendly, which is of course what we really want.

I’m really curious to see if anyone cracks this one, because that person I will grill mercilessly until either I understand what’s happening or one of us starts plotting to have the other killed.

The W3C unveiled a new logo and branding strategy today. (You might have heard.) It brings all the deliciousness of a Soviet-era Transformers logo to the yummy conflation of several related technologies! Did you get your WOFF in my HTML, or did I get my CSS all over your HTML?

As per usual, a lot of people have said a lot of things about this. For my part, I figure, hey, given that CSS3 is now a branded part of your nutritious HTML5 breakfast, why not go with the flow? So I did. You’re welcome.

(Disclaimer: it’ll look best in recent WebKit, Gecko, or Opera browsers, but it’s at least comprehensible in them what doesn’t yet support CSS transforms. May not be valid in all jurisdictions. Not a flying toy.)

Personally I’m looking forward to this for many reasons, but two stand out: this sort of very-small-group training and team project work setup is a new thing for me, and it’s the sort of thing I’ve thought about doing on and off for more than a decade but never quite found the time to do. Aaron, thankfully, did find the time and I’m honored that he asked me to take part. I hope I’ll see some of you this April in Tennessee!