So I created my own table, which you can now find in the CSS area of meyerweb. Most of it is dynamically generated, taking a list of keywords and RGB decimal equivalents and then calculating the rest of the values from there. The presentation is still a work in progress, and may change a little or a lot. In particular, if I can’t find a better algorithm for determining which rows should have white text instead of black, I’ll probably shift away from the full-row background colors to some other presentation. (Update: it’s been greatly improved, so I’m sticking with the full-row backgrounds. For now, anyway.)

My thanks to Tab Atkins for his donation of the RGB-to-HSL routine I adapted as well as help improving the pick-light-or-dark-text algorithm; and to the people who responded positively on Twitter when I mused about the idea there.

Update 25 May 12: the table now allows sorting (both directions) on the Keyword, RGB Decimal, and HSL columns. The sorting and styling code uses methods like el.classList.remove() so it may not function well, or at all, in older versions of Internet Explorer. The numeric sorts also appear to be borked in Opera and Chrome for no reason I can discern, and it’s not like I did anything fancy in the JavaScript—exactly the opposite, I’d wager. (Speaking of which, I’m sure my JavaScript is an non-stop amateur-hour horrorshow. I’m okay with that. If you aren’t, you might want to avert your gaze.) If there’s a simple fix that doesn’t screw up other browsers, like Safari and Firefox, I’m interested. If not, then we’ll all just have to live with it.

As always: share and enjoy!

h1 {color: red;}
h1 {color: green;}

…results in green h1 text, but this:

h1 {background:
	url(red-wave.gif) repeat,
	url(green-wave.gif) repeat;}

…results in a red wavy h1 background does my head in every single time. And it’s the same with text and box shadows, too! In cases where backgrounds or shadows overlap, the first one you write “wins”, by virtue of being “in front of” the background images that are listed after it.

I know that font stacks are also done in order of most-to-least preferred, but I don’t see them as being equivalent. The reason is that a font stack is a list of fallbacks—use this face unless it can’t render the glyph or doesn’t exist, in which case try the next one in the list, etc., etc. Multiple background images and multiple shadows, on the other hand, are not a series of fallbacks. I expect to see them all, unless I made a mistake of some kind; and I do, constantly, because of this disconnect. Sure, one could use the multiple background image syntax to create a series of fallbacks—first an SVG file, second a PNG, third a GIF—but that’s not its primary purpose, and I certainly wouldn’t teach multiple background images that way. That’s not what they’re designed to do.

Maybe writing the problem down here will purge this daemon, but in all honesty, my hopes are not terribly high.

ch unit

Equal to the advance measure of the “0″ (ZERO, U+0030) glyph found in the font used to render it.

…and that’s it. I had never heard the term “advance measure” before, and a bit of Googling for font "advance measure" only led me to copies of the CSS Values and Units module and some configuration files for the Panda 3D game engine. So I asked the editor and it turns out that “advance measure” is a CSS-ism that corresponds to the term “advance width”, which I had also never heard before but which yielded way more Google results. Wikipedia’s entry for “Font” has this definition:

Glyph-level metrics include … the advance width (the proper distance between the glyph’s initial pen position and the next glyph’s initial pen position)…

My question for the font geeks in the room is this: is that the generally accepted definition for “advance width”? If not, is there a better definition out there; and if so, where? I’d like to be able to recommend the best known definition for inclusion in the specification; or, if there’s no agreement as to the best, then at least a good one. The Wikipedia definition certainly sounds good, assuming it’s accurate. Is it?

In CSS terms, if I’ve understood things correctly, 1ch is equal to the width of the character box for the glyph for “0”. In other words, if I were to create a floated element with just a “0” and no whitespace between it and the element’s open and close tags, then the float’s width would be precisely 1ch. But that’s if I’ve understood things correctly. If I haven’t, I hope I’ll be corrected soon!

For example, you might write:

border-radius: 1em !webkit-draft !moz-draft !o-draft;

That’s it. The prefixed alternative, of course, runs to multiple lines and has spawned a whole subindustry of framework plugins and mixins and what-all just to take the repetitive authoring burden off our shoulders.

I’ve been contemplating this proposal all morning, and perhaps not too surprisingly I’ve come down in favor of the idea. I’m on record as being a fan of vendor prefixes, but what I was truly a fan of was the capabilities they offer. The syntax was never a core interest for me, and the ugliness was pretty apparent. Vendor tokens are less tortuous, and even make it much simpler to build in versioning, like so:

border-radius: 1em !webkit-draft-2 !moz-draft !o-draft;

Not that I’m saying this proposal will or even should get to that point, but the ability is there and it feels cleaner than trying to do the same thing with prefixes. I feel they ought to drop the -draft part of the tokens; just saying !webkit !moz !o or possibly !x-webkit !x-moz !x-o should be sufficient. I’m also not a fan of the bang, but then I never have been, and I figure any token marker would suffice. As before, it’s not the syntax I care about so much as the capabilities.

There is a discussion ongoing at www-style, if you’re interested in adding your perspective or even just following along as various stakeholders thrash at the idea. I’m cautiously optimistic. It’s kind of a nice feeling!

“Earplugs.”

Seriously. Get some earplugs. They don’t have to be fancy; the squishy yellow foam plugs you can get in a cardboard holder for a dollar work just fine. If you already have some fancier in-ear jobs for rock concerts or woodworking or whatever, those are good too.

Because as much as you love your new baby, and as much as you will work to keep them calm and happy, there will almost certainly be times when they are hurting or uncomfortable or just generally upset and unable to be soothed. No matter how much you cuddle and sing and swaddle, they will scream and cry. Some kids will do this rarely. Others will do it all the time. (A friend of ours tells how her eldest child screamed more or less non-stop from the day she was born until the day she walked.) I don’t honestly know which is harder to handle, but I do know that the screaming worked its way through my eardrums and into my brain to induce a panicked pseudo-flight-or-flight response. It was cumulatively, enormously stressful.

Earplugs do not shut out the cries completely. You will not be denying your baby’s distress or placing unwarranted distance between you and your child. Earplugs simply take the raw, serrated edge off their cry, giving you some mental space to cope with it and be a calmer and therefore better parent. It lets you hang in there longer, putting off the point where you have to put the baby in the crib and walk away for a few minutes. (And that’s okay too; the baby won’t die if you take five to regroup.) That means more direct contact with your baby, and possibly a shorter time to a calm baby due to longer, more continuous periods of parental contact.

So: earplugs. Probably the highest-ROI parental purchase I ever made.

Let me note right up front that some of what I’m talking about here isn’t widely deployed yet, nor for that matter even truly set in stone. Close, maybe, but there could still be changes. Even if nothing actually does change, this isn’t a “news you can use RIGHT NOW” article. Like so much of what I produce, it’s more of a stroll through a small corner of CSS, just to see what we might see.

For all their apparent complexity, linear gradients are pretty simple. You define a direction along which the gradient progresses, and then list as many color stops as you like. In doing so, you describe an image with text, sort of like SVG does. That’s an important point to keep in mind: a linear (or radial) gradient is an image, just as much as any GIF or PNG. That means, among other things, that you can mix raster images and gradient images in the background of an element using the multiple background syntax.

But back to gradients. Here’s a very simple gradient image:

linear-gradient(45deg, red, blue)

The 45deg defines the gradient line, which is the line that defines how the gradient progresses. The gradient line always passes through the center of the background area, and its specific direction is declared by you, the author. In this case, it’s been declared to point toward the 45-degree angle. red and blue are the color stops. Since the colors don’t have stop distances defined, the distances are assumed to be 0% and 100%, respectively, which means you get a gradient blend from red to blue that progresses along the gradient line.

You can create hard stops, too:

linear-gradient(45deg, green 50%, lightblue 50%)

That gets you the result shown in Figure 1, to which I’ve added (in Photoshop) an arrow showing the direction of the gradient line, as well as the centerpoint of the background area. Each individual “stripe” in the gradient is perpendicular to the gradient line; that’s why the boundary between the two colors at the 50% point is perpendicular to the gradient line. This perpendicularness is always the case.

Now, degrees are cool and all (and they’ll be changing from math angles to compass angles in order to harmonize with animations, but that’s a subject for another time), but you can also use directional keywords. Two different kinds, as it happens.

The first way to use keywords is to just declare a direction, mixing and matching from the terms top, bottom, right, and left. The funky part is that in this case, you’re declaring the direction the gradient line comes from, not that toward which it’s going; that is, you specify its origin instead of its destination. So if you want your gradient to progress from the bottom left corner to the top right corner, you actually say bottom left:

linear-gradient(bottom left, green 50%, lightblue 50%)

But bottom left does not equal 45deg, unless the background area is exactly square. If the area is not square, then the gradient line goes from one corner to another, with the boundary lines perpendicular to that, as shown in Figure 2. Again, I added a gradient line and centerpoint in Photoshop for clarity.

Of course, this means that if the background area resizes in either direction, then the angle of the gradient line will also change. Make the element taller or more narrow, and the line will rotate counter-clockwise (UK: anti-clockwise); go shorter or wider and it will rotate clockwise (UK: clockwise). This might well be exactly what you want. It’s certainly different than an degree angle value, which will never rotate due to changes in the background’s size.

The second way to use keywords looks similar, but has quite different results. You use the same top/bottom/left/right terms, but in addition you prepend the to keyword, like so:

linear-gradient(to top right, green 50%, lightblue 50%)

In this case, it’s clear that you’re declaring the gradient line’s destination and not its origin; after all, you’re saying to top right. However, when you do it this way, you are not specifying the top right corner of the background area. You’re specifying a general topward-and-rightward direction. You can see the result of the previous sample in Figure 3; once more, Photoshop was used to add the gradient line.

Notice the hard-stop boundary line. It’s actually stretching from top left to bottom right (neither of which is top right). That’s because with the to keyword in front, you’re triggering what’s been referred to as “magic corners” behavior. When you do this, no matter how the background area is (re)sized, that boundary line will always stretch from top left to bottom right. Those are the magic corners. The gradient line thus doesn’t point into the top right corner, unless the background area is perfectly square—it points into the top right quadrant (quarter) of the background area. Apparently the term “magic quadrants” was not considered better than “magic corners”.

The effect of changing the background area’s size is the same as before; decreasing the height or increasing the width of the background area will deflect the gradient line clockwise, and the opposite change to either axis will produce the opposite deflection. The only difference is the starting condition.

Beyond all this, if you want to use keywords that always point toward a corner, as in Figure 2 except specifying the destination instead of the origin, that doesn’t appear to be an option. Similarly, neither can you declare an origin quadrant. Having the gradient line always traverse from corner to corner means declaring the origin of the gradient line (Figure 2). If you want the “magic corners” effect where the 50% color-stop line points from corner to corner, with the gradient line’s destination flexible, then you declare a destination quadrant (Figure 3).

As for actual support: as of this writing, only Firefox and Opera support “magic corners”. All current browsers—in Explorer’s case, that means IE10—support angles and non-magic keywords, which means Opera and Firefox support both keyword behaviors. Nobody has yet switched from math angles to compass angles. (I used 45deg very intentionally, as it’s the same direction in either system.)

That’s the state of things with linear gradients right now. I’m interested to know what you think of the various keyword patterns and behaviors—I know I had some initial trouble grasping them, and having rather different effects for the two patterns seems like it will be confusing. What say you?

The basic problem is, every newfangled “try code out for yourself” site I hit is just failing in Firefox 11 and 12. Dabblet, for example, just returns a big blank page with the toolbar across the top, and none of the top-right buttons work except for the Help (“?”) button. And I write all that in the present tense because the problem still exists as I write this.

What’s happening is that any attempt to access localStorage, whether writing or reading, returns a security error. Here’s an anonymized example from Firefox’s error console:

Error: uncaught exception: [Exception... "Security error" code: "1000" nsresult: "0x805303e8 (NS_ERROR_DOM_SECURITY_ERR)" location: "http://example.com/code.js Line: 666"]

When you go to line 666, you discover it refers to localStorage. Usually it’s a write attempt, but reading gets you the same error.

But here’s the thing: it only does this if your browser preferences are set so that, when it comes to accepting cookies, the “Keep until:” option is set to “ask me every time”. If you change that to either of the other two options, then localStorage can be written and read without incident. No security errors. Switch it back to “ask me every time”, and the security errors come back.

Just to cover all the bases regarding my configuration:

1. Firefox is not in Private Browsing mode.
2. dom.storage.default_quota is 5120.
3. dom.storage.enabled is true.

Also: yes, I have my cookie policy set that way on purpose. It might not work for you, but it definitely works for me. “Just change your cookie policy” is the new “use a different browser” (which is the new “get a better OS”) and it ain’t gonna fly here.

To my way of thinking, this behavior doesn’t conform to step one of 4.3 The localStorage attribute, which states:

The user agent may throw a SecurityError exception instead of returning a Storage object if the request violates a policy decision (e.g. if the user agent is configured to not allow the page to persist data).

I haven’t configured anything to not persist data—quite the opposite—and my policy decision is not to refuse cookies, it’s to ask me about expiration times so I can decide how I want a given cookie handled. It seems to me that, given my current preferences, Firefox ought to ask me if I want to accept local storage of data whenever a script tries to write to localStorage. If that’s somehow impossible, then there should at least be a global preference for how I want to handle localStorage actions.

Of course, that’s all true only if localStorage data has expiration times. If it doesn’t, then I’ve already said I’ll accept cookies, even from third-party sites. I just want a say on their expiration times (or, if I choose, to deny the cookie through the dialog box; it’s an option). I’m not entirely clear on this, so if someone can point to hard information on whether localStorage does or doesn’t time out, that would be fantastic. I did see:

User agents should expire data from the local storage areas only for security reasons or when requested to do so by the user.

…from the same section, which to me sounds like localStorage doesn’t have expiration times, but maybe there’s another bit I haven’t seen that casts a new light on things. As always, tender application of the Clue-by-Four of Enlightenment is welcome.

Okay, so the point of all this: if you’re getting localStorage failures in Firefox, check your cookies expiration policy. If that’s the problem, then at least you know how to fix it—or, as in my case, why you’ll continue to have localStorage problems for the next little while. Furthermore, if you’re writing JS that interacts with localStorage or a similar local-data technology, please make sure you’re looking for security exceptions and other errors, and planning appropriate fallbacks.

So guess what? It’s caption contest time! Give us your best caption(s) in the comments, and see if you have what it takes to boost the inherent hilarity. Knock us out!

(Photo credit: Drew Angerer/The New York Times.)

I said that you wrap portions of your document (or the whole thing) in an element element and use the customized element inside. This is incorrect, and actually a very bad idea. In fact, you define your customized elements using an element element and then use the customized elements later in the document. Something like this:

<element extends="h1" name="x-superh1">
</element>

<h1 is="superh1">UltraMegaPower!!!</h1>
<h1>Regular Old Power</h1>

The line break inside the element element isn’t required—I just threw it in for clarity.

The element element can optionally contain template markup, but I honestly don’t understand that part of it yet. I get the general idea, but I haven’t crawled through the specifics long enough to have really internalized all the fiddly bits. And as we all know by know, the fiddly bits are where understanding lives and dies. (Also where the Devil hangs out, or so I’ve been told.)

I still firmly believe that all this papers over a much bigger problem, which is the arbitrary barrier to devising and using actual custom elements (as opposed to customized existing elements). HTML5 already allows you to make up your own bits of language: you can make up any attribute you want as long as your preface the name with data-. Okay, so that’s a little bit clumsy naming-wise, but the capability is there. You don’t have to register your attributes, or declare them in a list, or any of that other stuff. You just make up data-timing or data-proglang or data-sttngcharacter on the spot and off you go.

This is not possible for elements. You can’t even make up a prefixed element name, whether it’s data-kern or x-kern or even xkern (to avoid the limitation that hyphens aren’t allowed in element names). You just can’t devise your own elements. The best you can do is use the element element to sprinkle some semantic dust bunnies on top of elements that already exist.

Of course, all this “you can’t” and “not possible” applies to the specification. Browsers will let you feed them any old element name and style it, script it, whatever. Some say that’s more than enough. If the browser lets you do it, why let the specification hold you back? And of course, that’s how most people will approach the situation.

To someone like me, though, who spent years (literal years) explaining to web folk the world over that just because Internet Explorer for Windows let you write width: 12 px, actually writing it was still a bad idea—well, those habits die hard. Just doing stuff because the browser let you do it is not always a good idea. In fact, more often than not it’s a bad idea.

None of that really matters, as I say, because people are going to inject their own elements into their markup. They’ll do it because it’s easier than thinking about the proper element to use, or they’ll do it because no appropriate element yet exists, or for some other reason. That’s why the HTML5 specification ought to include the ability to do it, so that we have a paved path and defined best practices. The capability is useful, as the data- attribute feature demonstrates. If there’s a good, solid technical reason why extending that customization from attributes to elements is not desirable, I’d really like to know what it is.

Note that the grammar requires spaces around binary ‘+’ and ‘-’ operators. The ‘*’ and ‘/’ operators do not require spaces.

In other words, two out of four calculation operators require whitespace around them, and for the other two it doesn’t matter. Nothing like consistency, eh?

This is why you see examples like this:

width: calc(100%/3 - 2*1em - 2*1px);

That’s actually the minimum number of characters you need to write that particular expression, so far as I can tell. Given the grammar requirements, you could legitimately rewrite that example like so:

width: calc(100% / 3 - 2 * 1em - 2 * 1px);

…but not like so:

width: calc(100%/3-2*1em-2*1px);

The removal of the spaces around the ‘-’ operators means the whole value is invalid, and will be discarded outright by browsers.

We can of course say that this last example is kind of unreadable and so it’s better to have the spaces in there, but the part that trips me up is the general inconsistency in whitespace requirements. There are apparently very good reasons, or at least very historical reasons, why the spaces around ‘+’ and ‘-’ are necessary. In which case, I personally would have required spaces around all the operators, just to keep things consistent. But maybe that’s just me.

Regardless, this is something to keep in mind as we move forward into an era of wider browser support for calc().

Oh, and by the way, the specification also says:

The ‘calc()’ expression represents the result of the mathematical calculation it contains, using standard operator precedence rules.

Unfortunately, the specification doesn’t seem to actually define these “standard operator precedence rules”. This makes for some interesting ambiguities because, as with most standards, there are so many to choose from. For example, 3em / 2 * 3 could be “three em divided by two, with the result multiplied by three” (thus 4.5em) or “three em divided by six” (thus 0.5em), depending on whether you privilege multipliers over dividers or vice versa.

I’ve looked around the Values and Units specification but haven’t found any text defining the actual rules of precedence, so I’m going to assume US rules (which would yield 4.5em) unless proven otherwise. Initial testing seems to bear this out, but not every browser line supports these sorts of expressions yet, so there’s still plenty of time for them to introduce inconsistencies. If you want to be clear about how you want your operators to be resolved, use parentheses: they trump all. If you want to be sure 3em / 2 * 3 resolves to 4.5em, then write it (3em / 2) * 3, or (3em/2)*3 if you care to use inconsistent whitespacing.

The problem is that certain PDFs sent to me by a single individual won’t open at first. I’ll get one as an email attachment. I drag the attachment to a folder in my (Snow Leopard) Finder and double-click it to open. The error dialog I immediately get from Acrobat Professional is:

There was an error opening this document. The file is damaged and could not be repaired.

Preview, on the other hand, tells me:

The file “[redacted]” could not be opened. It may be damaged or use a file format that Preview doesn’t recognize.

When this happens, I tell the person who sent me the file that The Problem has happened again. She sends me the exact same file as an attachment. Literally, she just takes the same file she sent before and drags it onto the new message to send to me again.

And this re-sent file opens without incident. Every time. Furthermore, extra re-sends open without incident. I recently had her send me the same initially damaged file five times, some attached to replies and others to brand-new messages. All of them opened flawlessly. The initially damaged file remained damaged.

Furthermore, if I go through the GMail web interface, I can view the initial attached PDF (the one my OS X applications say is damaged) through the GMail UI without trouble. If I download that attachment to my hard drive, it similarly opens in Acrobat (and Preview) without trouble.

A major indication of damage: that first download is a different size than all the others. In the most recent instance, the damaged file is 680,302 bytes. The undamaged files are all 689,188 bytes. If only I knew why it’s damaged the first time, and not all the others!

So far, I’ve yet to see this happen with PDFs from anyone else, but then I receive very few attached PDFs from people other than this one (our events manager at An Event Apart, who sends and receives PDFs and Office documents like they’re conversational speech—an occupational hazard of her line of work), and it only seems to happen with PDFs of image scans that she’s created. Other types of PDFs, whether she generated them or not, seem to come through fine; ditto for other file types, like Word documents. I’d be tempted to blame the scanning software, but again: the exact same file is damaged the first time, and fine on every subsequent re-attachment.

I’ve done some Googling, and found scattered advice on ways clear up corrupted-PDF-attachment problems in Thunderbird. I’ve followed these pieces of advice, and nothing has helped. In summary, I have so far:

1. Set mail.server.default.fetch_by_chunks to false.
2. Set mail.imap.mime_parts_on_demand to false.
3. Set mail.server.default.mime_parts_on_demand to false.
4. Tried the Thunderbird extension OPENATTACHMENTBYEXTENSION. That failed, and so I immediately uninstalled it because handling files by extension alone is just asking to be pwned, regardless of your operating system or personal level of datanoia. (I wouldn’t have left it installed had it worked; I just wanted to see if it did work as a data point.)

Here’s what I know about the various systems in play here:

• I’m using Thunderbird 11.0.1 on OS X 10.6.8.
• The attachments are always sent via Outlook 2010 on Windows 7.
• The software used for the scanning is the HP scanning software that was installed with the scanner. Scans are saved to the hard drive, renamed, and then manually attached to the email. On resend, the same file is manually attached to the email.
• My email account is a GMail IMAP account.

So. Any ideas?

There was one thing we had to fight a bit to get, though, which was a garbage disposal for each sink bowl. The plumber didn’t want to do it on ground of it adding weight to the sink. Our response was, in effect: “We’ll have the sink remounted in ten years if necessary, but put in two disposals.” So he did, and we’re really glad.

The replacement faucet, however, does not make us nearly as glad. We decided to get a touch-activated faucet, settling on a Delta Addison single-handle faucet. The touch activation was because many are the times we want to wash off hands that have just handled raw meat, and being able to touch-on the faucet with a forearm seemed like a great idea—and it is! The problem is that nearly the entire faucet body, including the temperature/flow adjustment handle, is touch-sensitive. The exception is the pull-out head, which is inert.

Thus, if you reach past the faucet and brush it by mistake, the water starts flowing. This is true even if you bump the base of the faucet, which is annoying when you’re trying to wipe down the countertop around the faucet. Even worse, changing the temperature or flow rate means using the touch-sensitive handle. There’s evidently logic built into the faucet that’s meant to prevent the water from cutting off if you adjust the handle, but it only works about half the time. So sometimes you make an adjustment and the flow cuts off, and sometimes it doesn’t.

Frankly, the inconsistency is more maddening than the unwanted cutoffs. For example, I’ve developed an expectation that the flow will cut off after I use the handle. So I’ll adjust and then immediately tap the faucet again so it cuts off and then comes back on tap. Except if it didn’t cut off, then my tap cuts it off before I can stop the impulse and then I have to tap again.

Of course, any touch-sensitive faucet is a total luxury, and fortunately it’s easy to disable the touch feature—all we have to do is pull the batteries from the battery pack and it becomes a regular faucet. The drawback there is that there are definitely times when you want to be able to turn on the water flow without smearing whatever’s all over your hands on the faucet. (And with three kids, one of which is an infant, there are some things you definitely want to avoid smearing.)

The really incredible part is that these problems would be completely solved if only the neck of the faucet were touch-sensitive. If the base, which is a separate part from the neck, and the adjustment handle were inert, easily 90% of our frustration would just vanish. We could start the water flow by touching the neck and not worry about weirdness with the adjustment handle or when brushing the base.

If you’re thinking of installing a touch-sensitive faucet, I can’t recommend this one, unless of course a future version of it fixes the problems plaguing this one. And I have no idea if there’s a better touch faucet on the market; for all I know, they’re all like this. Definitely do your homework, and if at all possible play with a functioning model before taking the plunge. The touch feature doesn’t add a ton to the price of the base faucet, but it’s enough to be annoying when you’re seriously considering disabling it.

(Ed. note: this post has been corrected since its publication, and a followup clarification has been posted.)

Suppose you’re creating a super-sweet JavaScript library to improve text presentation—like, say, TypeButter—and you need to insert a bunch of elements that won’t accidentally pick up pre-existing CSS. That rules span right out the door, and anything else would be either a bad semantic match, likely to pick up CSS by mistake, or both.

Assuming you don’t want to spend the hours and lines of code necessary to push ahead with span and a whole lot of dynamic CSS rewriting, the obvious solution is to invent a new element and drop that into place. If you’re doing kerning, then a kern element makes a lot of sense, right? Right. And you can certainly do that in browsers today, as well as years back. Stuff in a new element, hit it up with some CSS, and you’re done.

Now, how does this fit with the HTML5 specification? Not at all well. HTML5 does not allow you to invent new elements and stuff them into your document willy-nilly. You can’t even do it with a prefix like x-kern, because hyphens aren’t valid characters for element names (unless I read the rules incorrectly, which is always possible).

No, here’s what you do instead (corrected 10 Apr 12):

1. Wrap your document, or at least the portion of it where you plan to use your custom markup,Define the element customization you want with an element element. That’s not a typo.
2. To your element element, add an extends attribute whose value is the HTML5 element you plan to extend. We’ll use span, but you can extend any element.
3. Now add a name attribute that names your custom “element” name, like x-kern.
4. Okay, you’re ready! Now anywhere you want to add a customized element, drop in the elements named by extends and then supply the name via an is attribute.

Did you follow all that? No? Okay, maybe this will make it a bit less unclear. (Note: the following code block was corrected 10 Apr 12.)

<element extends="span" name="x-kern"></element>
<h1>
<span is="x-kern" style="…">A</span>
<span is="x-kern" style="…">u</span>
<span is="x-kern" style="…">t</span>
<span is="x-kern" style="…">u</span>
mn
</h1>
<p>...</p>
<p>...</p>
<p>...</p>

(Based on markup taken from the TypeButter demo page. I simplified the inline style attributes that TypeButter generates for purposes of clarity.)

So that’s how you create “custom elements” in HTML5 as of now. Which is to say, you don’t. All you’re doing is attaching a label to an existing element; you’re sort of customizing an existing element, not creating a customized element. That’s not going to help prevent CSS from being mistakenly applied to those elements.

Personally, I find this a really, really, really clumsy approach—so clumsy that I don’t think I could recommend its use. Given that browsers will accept, render, and style arbitrary elements, I’d pretty much say to just go ahead and do it. Do try to name your elements so they won’t run into problems later, such as prefixing them with an “x” or your username or something, but since browsers support it, may as well capitalize on their capabilities.

I’m not in the habit of saying that sort of thing lightly, either. While I’m not the wild-eyed standards-or-be-damned radical some people think I am, I have always striven to play within the rules when possible. Yes, there are always situations where you work counter to general best practices or even the rules, but I rarely do so lightly. As an example, my co-founders and I went to some effort to play nice when we created the principles for Microformats, segregating our semantics into attribute values—but only because Tantek, Matt, and I cared a lot about long-term stability and validation. We went as far as necessary to play nice, and not one millimeter further, and all the while we wished mightily for the ability to create custom attributes and elements.

Most people aren’t going to exert that much effort: they’re going to see that something works and never stop to question if what they’re doing is valid or has long-term stability. “If the browser let me do it, it must be okay” is the background assumption that runs through our profession, and why wouldn’t it? It’s an entirely understandable assumption to make.

We need something better. My personal preference would be to expand the “foreign elements” definition to encompass any unrecognized element, and let the parser deal with any structural problems like lack of well-formedness. Perhaps also expand the rules about element names to permit hyphens, so that we could do things like x-kern or emeyer-disambiguate or whatever. I could even see my way clear to defining an way to let an author list their customized elements. Say, something like <meta name="custom-elements" content="kern lead follow embiggen shrink"/>. I just made that up off the top of my head, so feel free to ignore the syntax if it’s too limiting. The general concept is what’s important.

The creation of customized elements isn’t a common use case, but it’s an incredibly valuable ability, and people are going to do it. They’re already doing it, in fact. It’s important to figure out how to make the process of doing so simpler and more elegant.

My reason to bring this up is that I’m very interested by how TypeButter accomplishes its kerning: it inserts kern elements with inline style attributes that bear letter-spacing values. Not span elements, kern elements. No, you didn’t miss an HTML5 news bite; there is no kern element, nor am I aware of a plan for one. TypeButter basically invents a specific-purpose element.

I believe I understand the reasoning. Had they used span, they would’ve likely tripped over existing author styles that apply to span. Browsers these days don’t really have a problem accepting and styling arbitrary elements, and any that do would simply render type their usual way. Because the markup is script-generated, markup validation services don’t throw conniption fits. There might well be browser performance problems, particularly if you optically kern all the things, but used in moderation (say, on headings) I wouldn’t expect too much of a hit.

The one potential drawback I can see, as articulated by Jake Archibald, is the possibility of a future kern element that might have different effects, or at least be styled by future author CSS and thus get picked up by TypeButter’s kerns. The currently accepted way to avoid that sort of problem is to prefix with x-, as in x-kern. Personally, I find it deeply unlikely that there will ever be an official kern element; it’s too presentationally focused. But, of course, one never knows.

If TypeButter shifted to generating x-kern before reaching v1.0 final, I doubt it would degrade the TypeButter experience at all, and it would indeed be more future-proof. It’s likely worth doing, if only to set a good example for libraries to follow, unless of course there’s downside I haven’t thought of yet. It’s definitely worth discussing, because as more browser enhancements are written, this sort of issue will come up more and more. Settling on some community best practices could save us some trouble down the road.

Update 23 Mar 12: it turns out custom elements are not as simple as we might prefer; see the comment below for details. That throws a fairly large wrench into the gears, and requires further contemplation.

body h1 {color: red;}
html h1 {color: green;}

Given those styles, all h1 elements will be green, not red. That’s because the selectors have equal specificity, so the last one wins. The fact that the body element is “closer to” the h1 than the html element in the document tree is irrelevant. CSS has no mechanism for measuring proximity within the tree, and if I had to place a bet on the topic I’d bet that it never will.

I bring this up because it can get you into trouble when you’re using the negation pseudo-class. Consider:

div:not(.one) p {font-weight: bold;}
div.one p {font-weight: normal;}

<div class="one">
  <div class="two">
    <p>Hi there!</p>
  </div>
</div>

Given these styles, the paragraph will not be boldfaced. That’s because both rules match, so the last one wins. The paragraph will be normal-weight.

“AHA!” you cry. “But the first rule has a higher specificity, so it wins regardless of the order they’re written in!” You’d think so, wouldn’t you? But it turns out that the negation pseudo-class isn’t counted as a pseudo-class. It, like the univseral selector, doesn’t contribute to specificity at all:

Selectors inside the negation pseudo-class are counted like any other, but the negation itself does not count as a pseudo-class.

—Selectors Level 3, section 9: Calculating a selector’s specificity

If you swapped the order of the rules, you’d get a boldfaced paragraph thanks to the “all-other-things-being-equal-the-last-rule-wins” step in the cascade. However, that wouldn’t keep you from getting a red-on-red paragraph in this case:

div:not(.one) p {color: red;}
div.one p {background: red;}

<div class="one">
  <div class="two">
    <p>Hi there!</p>
  </div>
</div>

The paragraph is a child of a div that doesn’t have a class of one, but it’s also descended from a div that has a class of one. Both rules apply.

(Thanks to Stephanie Hobson for first bringing this to my attention.)