I'm releasing it under the Open Font License here:'design is released under GPL:
...and thanks to ALA (A List Apart) for the lovely 'Max-Width' Post which I used during all 18 hours of experimentation.'
Finally invented 'Jamie Reid' *Sex Pistols Typography Ransom Style! Thanks CSS3!
Should you be interested in adopting this (or taking the ball and running with it, please do so with my blessing...just make sure and tell me what i did to make it look this way (*well, not in Posterous, but at any of the other CSS Experiment blogs of mine which served as laboratories for this and all my daily Greatest CSShits' and as always, a big CSShout-out to my Number 1 Fan, Eric Meyerfor his GREAT REVIEW!'-- See the Almost Ready layout with this Ransom Note Style font at my number 1 CSS Blog Lab, CRAM!--SOMETHING NEW TO SEE DAILY'
The Parisian font embedded in this theme is by George Wilson, and is distributed under OFL (the Open Font License)
We are pleased to present a portion of Chapter 3 of Responsive Web Design by Ethan Marcotte (A Book Apart, 2011). This chapter follows a previous chapter on fluid grids, expanding upon that grid with fluid images. -Ed.
Things are looking good so far: we've got a grid-based layout, one that doesn't sacrifice complexity for flexibility. I have to admit that the first time I figured out how to build a fluid grid, I was feeling pretty proud of myself.
Fig 3.0: Our flexible grid is finally finished. not a pixel value in sight, and we didn't have to skimp on the aesthetics.
But then, as often happens with web design, despair set in. Currently, our page is awash in words, and little else. Actually, nothing else: our page is nothing but text. Why is this a problem? Well, text reflows effortlessly within a flexible container-and I don't know if you've noticed, but the Internet seems to have one or two of those "image" things lying around. None of which we've incorporated into our fluid grid.
So what happens when we introduce fixed-width images into our flexible design?
Going back, back to markup, markup
To find an answer, let's do a quick experiment: let's drop an image directly into our blog module, and see how our layout responds. The first thing we'll need to do is to clear some space for it in our markup.
Remember our little
blockquote, comfortably tucked into our blog article? Well, we've got way too much text on this darned page, so let's replace it with an inset image:<div class="figure"> <p> <img src="robot.jpg" alt="" /> <b class="figcaption">Lo, the robot walks</b> </p> </div>
Nothing fancy: an
img element, followed by a brief but descriptive caption wrapped in a b element. I'm actually appropriating the HTML5 figure/figcaption tags as class names in this snippet, which makes for a solidly semantic foundation.(Sharp-eyed readers will note that I'm using a
b element for a non-semantic hook. Now, some designers might use a span element instead. Me, I like the terseness of shorter tags like b or i for non-semantic markup.)With that HTML finished, let's drop in some basic CSS:
.figure { float: right; margin-bottom: 0.5em; margin-left: 2.53164557%; /* 12px / 474px */ width: 48.7341772%; /* 231px / 474px */ }
Fig 3.1: An appropriately botty robot pic, courtesy of Jeremy Noble.
We're creating a nice inset effect for our figure. It'll be floated to the right, and will span roughly half the width of our article, or four columns of our flexible grid. Markup: check; style: check. Of course, all this HTML and CSS is for naught if there isn't an actual image available.
Now, because I love you (and robots) dearly, not just any image will do. And after scouring the web for whole minutes, I found a fantastically imposing robo-portrait (fig 3.1). The beautiful thing about this image (aside from the robot, of course) is that it's huge. I've cropped it slightly, but I haven't scaled it down at all, leaving it at its native resolution of 655×655. This image is much larger than we know its flexible container will be, making it a perfect case to test how robust our flexible layout is.
So let's drop our oversized image onto the server, reload the page, and-oh. Well. That's pretty much the worst thing on the internet.
Fig 3.2: Our huge image is huge. Our broken layout is broken.
Actually, the result isn't that surprising. Our layout isn't broken per se-our flexible container is working just fine, and the proportions of our grid's columns remain intact. But because our image is much wider than its containing
.figure, the excess content simply overflows its container, and is visible to the user. There simply aren't any constraints applied to our image that could make it aware of its flexible environment.Fluid images
But what if we could introduce such a constraint? What if we could write a rule that prevents images from exceeding the width of their container?
Well, here's the good news: that's very easy to do:
img { max-width: 100%; }First discovered by designer Richard Rutter, this one rule immediately provides an incredibly handy constraint for every image in our document. Now, our
img element will render at whatever size it wants, as long as it's narrower than its containing element. But if it happens to be wider than its container, then the max-width: 100% directive forces the image's width to match the width of its container. And as you can see, our image has snapped into place.
Fig 3.3: Just by including
max-width: 100%, we've prevented our image from escaping its flexible container. On a related note, I love max-width: 100%.What's more, modern browsers have evolved to the point where they resize the images proportionally: as our flexible container resizes itself, shrinking or enlarging our image, the image's aspect ratio remains intact.
Fig 3.4: Regardless of how wide or small its flexible container becomes, the image resizes proportionally. Magic? Who can say.
I hope you're not tired of all this good news because as it happens, the
max-width: 100% rule can also apply to most fixed-width elements, like video and other rich media. In fact, we can beef up our selector to cover other media-ready elements, like so:img, embed, object, video { max-width: 100%; }Whether it's a cute little Flash video, some other embedded media, or a humble
img, browsers do a fair job of resizing the content proportionally in a flexible layout. All thanks to our lightweight max-width constraint.
Fig 3.5: Other media play nicely with
max-width: 100%, becoming flexible themselves. Did I mention I love max-width: 100%?So we've cracked the problem of flexible images and media-right? One CSS rule and we're done?
Because this job is never easy
Time to let the healing begin: we need to work through the pain, the tears, the rending of garments, and talk about a few browser-specific issues around flexible images.
max-width in Internet Explorer
The cold, hard truth is that Internet Explorer 6 and below don't support the
max-width property. IE7 version and above? Oh, it is positively brimming with support for max-width. But if you're stuck supporting the (cough) venerable IE6 or lower, our approach needs refinement.Now, there are several documented ways to get
max-width support working in IE6. Most are JavaScript-driven, usually relying on Microsoft's proprietary expression filter to dynamically evaluate the width of an element, and to manually resize it if it exceeds a certain threshold. For an example of these decidedly non-standard workarounds, I'd recommend Svend Tofte's classic blog entry on the subject.Me? I tend to favor a more lo-fi, CSS-driven approach. Namely, all modern browsers get our
max-width constraint:img, embed, object, video { max-width: 100%; }But in a separate IE6-specific stylesheet, I'll include the following:
img, embed, object, video { width: 100%; }See the difference? IE6 and lower get
width: 100%, rather than the max-width: 100% rule.A word of warning: tread carefully here, for these are drastically different rules. Whereas
max-width: 100% instructs our images to never exceed the width of their containers, width: 100% forces our images to always match the width of their containing elements.Most of the time, this approach will work just fine. For example, it's safe to assume that our oversized
robot.jpg image will always be larger than its containing element, so the width: 100% rule works beautifully.But for smaller images like thumbnails, or most embedded movies, it might not be appropriate to blindly up-scale them with CSS. If that's the case, then a bit more specificity might be warranted for IE:
img.full, object.full, .main img, .main object { width: 100%; }If you don't want the
width: 100% rule to apply to every piece of fixed-width media in your page, we can simply write a list of selectors that target certain kinds of images or video (img.full), or certain areas of your document where you know you'll be dealing with oversized media (.main img, .main object). Think of this like a whitelist: if images or other media appear on this list, then they'll be flexible; otherwise, they'll be fixed in their stodgy old pixel-y ways.So if you're still supporting legacy versions of Internet Explorer, a carefully applied
width: 100% rule can get those flexible images working beautifully. But with that bug sorted, we've still got one to go.And boy, it's a doozy.
In which it becomes clear that Windows hates us
Fig 3.6: Seen here in IE6, our robot image has developed some unsightly artifacts. Guess Windows doesn't much care for our flexible images.
If you look at our blog module with certain Windows-based browsers, our
robot.jpg has gone from looking imposing to looking, well, broken). But this isn't a browser-specific issue as much as a platform-specific one: Windows doesn't scale images that well. In fact, when they're resized via CSS, images quickly develop artifacts on Windows, dramatically impacting their quality. And not in a good way.For a quick test case, I've tossed a text-heavy graphic into a flexible container, and then resized our image with the
max-width: 100% fix, while IE6 and below receive the width: 100% workaround. Now, you'd never actually put this amount of text in an image. But it perfectly illustrates just how badly things can get in IE7 or lower. As you can see, the image looks-if you'll pardon the technical term-downright nasty.But before you give up on the promise of scaleable, flexible images, it's worth noting that this bug doesn't affect every Windows-based browser. In fact, only Internet Explorer 7 and lower are affected, as is Firefox 2 and lower on Windows. More modern browsers like Safari, Firefox 3+, and IE8+ don't exhibit a single problem with flexible images. What's more, the bug seems to have been fixed in Windows 7, so that's more good news.
Fig 3.7: In certain Windows-based browsers, the image quickly develops too many artifacts to be readable.
So with the scope of the problem defined, surely there's a patch we can apply? Thankfully, there is-with the exception of Firefox 2.
Now, this grizzled old browser was released in 2006, so I think it's safe to assume it isn't exactly clogging up your site's traffic logs. At any rate, a patch for Firefox 2 would require some fairly involved browser-sniffing to target specific versions on a specific platform-and browser-sniffing is unreliable at best. But even if we did want to perform that kind of detection, these older versions of Firefox don't have a switch that could fix our busted-looking images.
Internet Explorer, however, does have such a toggle. (Pardon me whilst I swallow my pride for this next section title.)
Hail AlphaImageLoader, the conquering hero
Ever tried to get transparent PNGs working in IE6 and below? Chances are good you've encountered
AlphaImageLoader, one of Microsoft's proprietary CSS filters. There have since been more robust patches created for IE's lack of support for the PNG alpha channel (Drew Diller's DD_belatedPNG library is a current favorite of mine), but historically, if you had a PNG attached to an element's background, you could drop the following rule into an IE-specific stylesheet: (Line wraps marked » -Ed.).logo { background: none; filter: progid:DXImageTransform.Microsoft.AlphaImageLoader» (src="/path/to/logo.png", sizingMethod="scale"); }This
AlphaImageLoader patch does a few things. First, it removes the background image from the element, then inserts it into an AlphaImageLoader object that sits "between" the proper background layer and the element's content. But the sizingMethod property is the clever bit, dictating whether the AlphaImageLoader object should crop any parts of the image that overflow its container, treat it like a regular image, or scale it to fit it within its containing element.I can hear you stifling your yawns by now: after all, what does an IE-specific PNG fix have to do with our broken image rendering?
Quite a bit, as it turns out. At one point I discovered that applying
AlphaImageLoader to an image dramatically improves its rendering quality in IE, bringing it up to par with, well, every other browser on the planet. Furthermore, by setting the sizingMethod property to scale, we can use our AlphaImageLoader object to create the illusion of a flexible image.So I whipped up some JavaScript to automate that process. Simply download the script and include it on any page with flexible images; it will scour your document to create a series of flexible, high-quality
AlphaImageLoader objects.And with that fix applied, the difference in our rendered images is noticeable: in our example we've gone from an impossibly distorted image to an immaculately rendered one. And it works wonderfully in a flexible context.
Fig 3.8: Our image is now perfectly legible, and resizing wonderfully. A dab of
AlphaImageLoader'll do ya.(It's worth mentioning that many of Microsoft's proprietary filters, and
AlphaImageLoader in particular, have some performance overhead associated with them-Stoyan Stefanov covers the pitfalls in more detail on the YUI blog. What does this mean for you? Just be sure to test the fix thoroughly on your site, gauge its effect on your users, and evaluate whether or not the improved rendering is worth the performance tradeoff.)With the
max-width: 100% fix in place (and aided by our width: 100% and AlphaImageLoader patches), our inset image is resizing beautifully across our target browsers. No matter the size of the browser window, our image scales harmoniously along with the proportions of our flexible grid.But what about images that aren't actually in our markup?
Flexibly tiled background images
Let's say our dearly esteemed designer sends over a revised mockup of our blog module. Notice anything different about it?
Fig 3.9: Our blog's sidebar is now sporting a background graphic. Hot.
Up until now, our blog's content has been sitting on a rather unassuming near-white background. But now the design has been modified slightly, adding a two-toned background to the blog entry to provide more contrast between the left- and right-hand columns. What's more, there's actually a subtle level of noise added to the background, adding an extra level of texture to our design:
Fig 3.10: A detailed look at our new background treatment.
So: how do we actually add this new background image to our template?
Back in 2004, Dan Cederholm wrote a brilliant article showing how a vertically repeating background graphic could be used to create a "faux column" effect. The technique's genius is in its simplicity: by tiling a colored background graphic vertically behind our content, we can create the illusion of equal height columns.
In Dan's original technique, the background graphic was simply centered at the top of the content area and then tiled vertically, like so:
.blog { background: #F8F5F2 url("blog-bg.png") repeat-y 50% 0; }And that technique works beautifully. But Dan's technique assumes that your design is a fixed width, creating a graphic that matches the width of your design. Then how, pray, are we supposed to work in a background image that tiles over two flexible columns?
Thanks to some early research by designer Doug Bowman, we can still apply the faux column technique. It just requires a little bit of extra planning, as well as a dash of your favorite formula,
target ÷ context = result.First, we'll begin by taking a look at our mockup, to find the transition point in our background graphic, the exact pixel at which our white column transitions into the gray. And from the look of things, that switch happens at the 568 pixel mark.
Fig 3.11: Our white column switches over to gray at the 568px mark. That's our transition point.
Armed with that information, we can now adapt the "faux columns" approach to our fluid grid. First, we'll convert that transition point into a percentage-based value relative to our blog module's width. And to do so, our
target ÷ context = result formula comes into play yet again. We have our target value of 568px, and the width of the design-our context-is 900px. And if we plug those two values into our stalwart formula:568 ÷ 900 = 0.631111111111111
That's right: another impossibly long number, which converts to a percentage of
63.1111111111111%.Keep that percentage in the back of your mind for a moment. Now, let's open up your favorite image editor, and create a foolishly wide document-say, one that's 3000 pixels across. And since we're going to tile this image vertically, its height is only
160px tall.
Fig 3.12: A monstrously large canvas that we'll (shortly) turn into our background graphic.
In a moment, we're going to turn this blank document into our background graphic. But why is it so large? Well, this image needs to be larger than we can reasonably assume the browser window will ever be. And unless you're reading this from the 25th century on your wall-sized display made of, I don't know, holograms or whatever, I'm assuming your monitor's not quite that wide.
To create the columns themselves, we'll need to apply the transition point percentage (
63.1111111111111%) to our new, wider canvas. So if we're working with a graphic that's 3000px across, we simply need to multiply that width by the percentage, like so:3000 x 0.631111111111111 = 1893.333333333333
We're left with
1893.333333333333 as our result. And since Photoshop doesn't deal in anything less than whole pixels, let's round that down to 1893 pixels. Armed with that number, we'll recreate our textures in our blank image, switching from white to gray at the 1893rd pixel.
Fig 3.13: We've applied that percentage to our oh-so-wide background graphic, creating our tile-ready columns.
How does that help us? Well, what we've just done is to proportionally scale our transition point up to this new, wider canvas. So we can take that new pixel value, and use it to create our columns: the white column will be
1893px wide, with the gray column filling up the remainder.So now there's only one thing left to do: drop our newly minted graphic into our stylesheet.
.blog { background: #F8F5F2 url("blog-bg.png") repeat-y 63.1111111111111% 0; /* 568px / 900px */ }As in Dan's original technique, we're still positioning the graphic at the very top of our blog, and then repeating it vertically down the width of the module (
repeat-y). But the background-position value reuses our transition point percentage (63.1111111111111% 0), keeping the columns firmly in place as our design resizes itself.And with that, we've got faux columns working beautifully in a fluid layout. All thanks to Dan Cederholm's original approach, augmented with a little proportional thinking.
fig 3.14: Our flexibly faux columns.
Fully flexible background images?
Of course, our flexible faux column isn't really flexible: we're simply using percentages to position a background image in such a way that the columns appear to resize with their container. The image's dimensions haven't changed at all.
But what about a background image that actually does need to resize with the layout? Perhaps you've placed a logo on an
h1 element's background, or used sprites to create rollovers for your site's navigation. Can we resize images that need to live in the background?Well, sort of. There is a CSS3 property called
In the interim, there are some rather ingenious JavaScript-based solutions out there: for example, Scott Robbin's jQuery Backstretch plugin simulates resizable background images on the body element. And as you'll see in the next chapter, CSS3 media queries could also be used to apply different background images tailored to different resolution ranges. So while 
background-size might not be available yet, the sky is, as the kids say, the limit. 
Theme Name: Beardsley
Description: A black and white art nouveau theme. Graphics are taken from the work of Aubrey Beardsley, the famous British illustrator associated with Oscar Wilde, among others. Try reloading the page to see a new border in the bottom corner of the page, from Beardsley's illuminations for the 1893 Dent edition of Mallory's 'King Arthur'
Author: Sash Lewis
Sash
© 2010 Twitter, Inc.
Endless randomly chosen personal videos
- What is the Intubator?
- The Intubator distills YouTube down to its core: an endless stream of randomly selected, unedited personal videos. When one ends, another one will begin.
- Who made it?
- Hello. I'm Tom Scott. I live at
tomscott.com. You can 
email me, 
follow me on Twitter, or 
subscribe to me on YouTube. - What am I seeing?
- Videos that no-one bothered to tag, title, or describe: they're just assigned a random filename by the digital camera that recorded them. They might be from anyone, anywhere in the world, and be about anything - they're also not filtered, so be aware that some clips may be unsuitable for all audiences. These clips almost always have no views, no comments and no context, and you're one of the very few people to have seen them. You're welcome to try to find out more by clicking on the name, but it's usually fruitless.
- Can't I skip forward through them?
- Progress bars and arbitrary skips would spoil the effect. You can skip to an entirely new video if you must, by clicking the "Validate someone else's existence" link.
- I've been watching this for a while, and I'm feeling a bit weird.
- That's the realisation that you're just one solitary person among more than six billion on the planet hitting you.
- Damn.
- Bear in mind, though, that this isn't a representative sample of those billions: most of the clips you'll see here will be from the developed world and uploaded by those who can afford the luxuries of a digital camera and broadband internet access.
- Actually, it's not an existential crisis, I just feel a bit woozy.
- Get off your seat. Go for a walk. There's an entire planet out there, go and have a look at it with your own eyes instead of ruining them here.
- I think this is broken.
- It happens occasionally if YouTube's having issues. Come back in a few hours, and if it's still happening, email me. If you use FlashBlock, then you're right, it won't work for you: that's the trade-off for having rounded corners and a clickable canvas on the Flash player.
- Aren't these videos private?
- It might seem like some of them should be. But no - all these videos have been uploaded for public viewing. They've just not been tagged.
- I have another question!
- Email me. I'm friendly.
- Wed 6 Apr 2011
- 1711
- Books
CSS - 12 responses
I just shipped off the last of my drafts for CSS Pocket Reference, 4th Edition to my editor. In the process of writing the entries, I set up an ad-hoc test suite and made determinations about what to document and what to cut. That's what you do with a book, particularly a book that's meant to fit into a pocket. My general guide was to cut anything that isn't supported in any rendering engine, though in a few cases I decided to cut properties that were supported by a lone browser but had no apparent prospects of being supported by anyone else, ever.
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.
rotationandrotation-pointfrom 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-elementpseudo-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, andword-break. - The following properties from the Basic User Interface module, dated 2004:
appearance,icon,nav-down,nav-left,nav-right,nav-up, andnav-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!
Inconsistent Transitions
- Thu 24 Mar 2011
- 1624
- Browsers
CSS - 14 responses
Here's an interesting little test case for transitions. Obviously you'll need to visit it in a browser that supports CSS transitions, and additionally also CSS 2D transforms. (I'm not aware of a browser that supports the latter without supporting the former, but your rendering may vary.)
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.
I just shipped off the last of my drafts for CSS Pocket Reference, 4th Edition to my editor. In the process of writing the entries, I set up an ad-hoc test suite and made determinations about what to document and what to cut. That's what you do with a book, particularly a book that's meant to fit into a pocket. My general guide was to cut anything that isn't supported in any rendering engine, though in a few cases I decided to cut properties that were supported by a lone browser but had no apparent prospects of being supported by anyone else, ever. 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! Inconsistent Transitions Thu 24 Mar 2011 1624 Browsers CSS 14 responses Here's an interesting little test case for transitions. Obviously you'll need to visit it in a browser that supports CSS transitions, and additionally also CSS 2D transforms. (I'm not aware of a browser that supports the latter without supporting the former, but your rendering may vary.) 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.
