This picture completely cracks me up every time I look at it:
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.)
A couple of weeks back I wrote about customizing your markup, but I got an important bit wrong and while I’ve corrected the post, I wanted to clear up the error in detail.
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.
I’ve been messing around with native calculated values in CSS, and there’s something a bit surprising buried in the value format. To quote the CSS3 Values and Units specification:
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.
I have this very odd problem that seems to be some combination of PDF, Acrobat, Outlook, Thunderbird, and maybe even IMAP and GMail. I know, right?
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:
mail.server.default.fetch_by_chunks to false.mail.imap.mime_parts_on_demand to false.mail.server.default.mime_parts_on_demand to false.Here’s what I know about the various systems in play here:
So. Any ideas?
As part of last year’s renovation, we redid our kitchen, which means a new sink and faucet. We traded up from an overmount single-bowl sink to an undermount double-bowl sink, both aspects of which we’d long wanted.
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.
So HTML5 allows you (at the moment) to create your own custom elements. Only, not really.
(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 :
element element. That’s not a typo.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.name attribute that names your custom “element” name, like x-kern.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.
This morning I caught a pointer to TypeButter, which is a jQuery library that does “optical kerning” in an attempt to improve the appearance of type. I’m not going to get into its design utility because I’m not qualified; I only notice kerning either when it’s set insanely wide or when it crosses over into keming. I suppose I’ve been looking at web type for so many years, it looks normal to me now. (Well, almost normal, but I’m not going to get into my personal typographic idiosyncrasies now.)
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.
There’s a subtle aspect of CSS descendant selectors that most people won’t have noticed because it rarely comes up: selectors have no notion of element proximity. Here’s the classic demonstration of this principle:
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.)