1. Launch Safari 4 or Chrome 4.

2. Drag Videotate to the bookmarks bar.

3. Go opt into the YouTube HTML5 beta.

4. Find your favorite YouTube video. Or maybe your least favorite. Here’s one of my favorites: Walk Don’t Run. Here’s another that’s not necessarily a favorite, but it seems like a fairly appropriate choice.

   Note: not all videos are available via HTML5, even when you’re opted in. If you get a Flash video, the bookmarklet won’t work.

5. Once the video has started playing, activate the “Videotate” bookmarklet.

6. Enjoy.

Thanks to Simon WIllison for tweeting the JS I modified, and Jeremy Keith for helping me realize it would be easy to do during the HTML5 portion of A Day Apart.

Here’s an example of what I’m talking about:

p::after {content: " -\2761-"; font-size: smaller;}

Drop that style into any document that has paragraphs. Load it up in your favorite development browser. Now inspect a paragraph. You will not see the generated content in the DOM view, and you won’t see the pseudo-element rule in the Styles tab (except in IE, where you get the latter, though not the former).

The problem isn’t that I used an escaped Unicode reference; take that out and you’ll still see the same results, as on the test page I threw together. It isn’t the double-colon syntax, either, which all modern browsers handle just fine; and anyway, I can take it back to a single colon and still see the same results. ::first-letter, ::first-line, ::before, and ::after are all basically invisible in most inspectors.

This can be a problem when developing, especially in cases such as having a forgotten, runaway generated-content clearfix making hash of the layout. No matter how many times you inspect the elements that are behaving strangely, you aren’t going to see anything in the inspector that tells you why the weirdness is happening.

The same is largely true for dynamic pseudo-classes. If you style all five link states, only two will show up in most inspectors—either :link or :visited, depending on whether you’ve visited the link’s target; and :focus. (You can sometimes also get :hover in Dragonfly, though I’ve not been able to do so reliably. IE8′s Developer Tool always shows a:link even when the link is visited, and doesn’t appear to show any other link states. …yes, this is getting complicated.)

The more static pseudo-classes, like :first-child, do show up pretty well across the board (except in IE, which doesn’t support all the advanced static pseudo-classes; e.g., :last-child).

I can appreciate that inspectors face an interesting challenge here. Pseudo-elements are just that, and aren’t part of the actual structure. And yet Internet Explorer’s Developer Tool manages to find those rules and display them without any fuss, even if it doesn’t show generated content in its DOM view. Some inspectors do better than others with dynamic pseudo-classes, but the fact remains that you basically can’t see some of them even though they will potentially apply to the inspected link at some point.

I’d be very interested to know what inspector teams encountered in trying to solve this problem, or if they’ve never tried. I’d be especially interested to know why IE shows pseudo-elements when the others don’t—is it made simple by their rendering engine’s internals, or did someone on the Developer Tool team go to the extra effort of special-casing those rules?

For me, however, the overriding question is this: what will it take for the various inspectors to behave more like IE’s does, and show pseudo-element and pseudo-class rules that are associated with the element currently being inspected? And as a bonus, to get them to show in the DOM view where the pseudo-elements actually live, so to speak?

(Addendum: when I talk about IE and the Developer Tool in this post, I mean the tool built into IE8. I did not test the Developer Toolbar that was available for IE6 and IE7. Thanks to Jeff L for pointing out the need to be clear about that.)

And then, after breakfast, I fired up my feed reader and saw Simon Willison‘s link to John Resig’s nascent Sizzle project.

I swear to Ged this is how it happened.

Personally, I can’t wait for Sizzle to be finished, because I’m absolutely going to use it and recommend its use far and wide. As far as I’m concerned, though, it’s a first step into a larger world.

Think about it: most of the browser development work these days seems to be going into JavaScript performance. Those engines are being overhauled and souped up and tuned and re-tuned to the point that performance is improving by orders of magnitude. Scanning the DOM tree and doing things to it, which used to be slow and difficult, is becoming lightning-fast and easy.

So why not write JS to implement multiple background-image support in all browsers? All that’s needed is to scan the CSS, find instances of multiple-image backgrounds, and then dynamically add divs, one per extra background image, to get the intended effect.

Just like that, you’ve used the browser’s JS to extend its CSS support. This approach advances standards support in browsers from the ground up, instead of waiting for the browser teams to do it for us.

I suspect that not quite everything in CSS3 will be amenable to this approach, but you might be surprised. Seems to me that you could do background sizing with some div-and-positioning tricks, and text-shadow could be supportable using a sIFR-like technique, though line breaks would be a bear to handle. RGBa and HSLa colors could be simulated with creative element reworking and opacity, and HSL itself could be (mostly?) supported in IE with HSL-to-RGB calculations. And so on.

There are two primary benefits here. The first is obvious: we can stop waiting around for browser makers to give us what we want, thanks to their efforts on JS engines, and start using the advanced CSS we’ve been hearing about for years. The second is that the process of finding out which parts of the spec work in the real world, and which fall down, will be greatly accelerated. If it turns out nobody uses (say) background-clip, even given its availability via a CSS/JS library, then that’s worth knowing.

What I wonder is whether the W3C could be convinced that two JavaScript libraries supporting a given CSS module would constitute “interoperable implementations”, and thus allow the specification to move forward on the process track. Or heck, what about considering a single library getting consistent support in two or more browsers as interoperable? There’s a chance here to jump-start the entire process, front to back.

It is true that browsers without JavaScript will not get the advanced CSS effects, but older browsers don’t get our current CSS, and we use it anyway. (Still older browsers don’t understand any CSS at all.) It’s the same problem we’ve always faced, and everyone will face it differently.

We don’t have to restrict this to CSS, either. As I showed with my href-anywhere demo, it’s possible to extend markup using JS. (No, not without breaking validation: you’d need a custom DTD for that. Hmmm.) So it would be possible to use JS to, say, add audio and video support to currently-available browsers, and even older browsers. All you’d have to do is convert the HTML5 element into HTML4 elements, dynamically writing out the needed attributes and so forth. It might not be a perfect 1:1 translation, but it would likely be serviceable—and would tear down some of the highest barriers to adoption.

There’s more to consider, as well: the ability to create our very own “standards”. Maybe you’ve always wanted a text-shake property, which jiggles the letters up and down randomly to look like the element got shaken up a bit. Call it -myCSS-text-shake or something else with a proper “vendor” prefix—we’re all vendors now, baby!—and go to town. Who knows? If a property or markup element or attribute suddenly takes off like wildfire, it might well make it into a specification. After all, the HTML 5 Working Group is now explicitly set up to prefer things which are implemented over things that are not. Perhaps the CSS Working Group would move in a similar direction, given a world where we were all experimenting with our own ideas and seeing the best ideas gain widespread adoption.

In the end, as I said in Chicago last week, the triumph of standards (specifically, the DOM standard) will permit us to push standards support forward now, and save some standards that are currently dying on the vine. All we have to do now is start pushing. Sizzle is a start. Who will take the next step, and the step after that?

• IE Keyword Testing (length)
• IE Keyword Testing (item)
• IE Keyword Testing (namedItem)
• IE Keyword Testing (tags)
• IE Keyword Testing (urns)

These are based on Kevin Hamilton’s observation that it’s highly likely the problems are caused by the tags method in IE/Win’s document.all DOM interface. As he says:

[I]f you have an element with an id=”tags”, then document.all.tags is now a reference to that element, and no longer a method of the document.all object.

Such states would completely shatter any IE DOM scripting that relied on the document.all methods, and at least in the case of tags causes problems like crashing on print (probably because of the aforementioned conflict between the ID value and the DOM method). The other keywords of concern are chronicled in the test pages listed above. I’d test IE/Win myself, except I don’t have a printer handy for IE/Win to use, and besides, bug-hunting is best conducted in large groups.

Basically, load up each test page in IE/Win and do anything you can think to do. Try to print, view source, save a local copy, et cetera, et cetera—the more obscure and offbeat, the better. Let us know via the comments any problems you run into with said pages (trying to print them is a good first step, since that’s what messed up on tags) and I’ll add notes to each page based on what’s found.

In the meantime, I’m personally going to avoid using any of those words as ID values, and heartily recommend the same to you.

Update: I’ve added a test (for length) to the above list, and have another that’s not on the list due to its unfinished nature. It’s a test of id="all"; the problem is, I don’t really know how to test it, or if it’s likely to be a problem at all. Suggestions are welcomed in the comments. I added some JavaScript links to some of the test pages as a secondary test, but I’m not sure how much good they do, to be honest. As with suggestions, your feedback is welcome.

For those in search of more background, or trying to find new ways to test possible conflicts, or whatever, feel free to look over Microsoft’s documentation of the “all Collection”.

Jason did some sleuthing and traced the crash to this line of markup:

<h2 id="tags">Tags and structure</h2>

Honestly, that was it. So Jeffrey renamed the ID to read:

<h2 id="structure">Tags and structure</h2>

So far as we know, no more crashing in Explorer.

Ain’t browsers a slice?

(And yes, we’re aware of the clamor for a print style sheet. More on this later.)

Update: Marten Veldthuis from Strongpsace points out that 37signals ran into a very similar problem in Backpack. Details can be found in Jamis Buck‘s June 3rd post ie-is-teh-3v1l. Spread the word: “tags” is effectively a reserved keyword, even though no such concept exists in (X)HTML. Use it at your (users’) peril.