Posts from March 2012

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.

• Touchy About Faucets was published on Friday, March 30th, 2012.
• It was assigned to the General and Guide categories.
• There have been fifteen replies.

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 :

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.

• Customizing Your Markup was published on Wednesday, March 28th, 2012.
• It was assigned to the (X)HTML, Commentary, HTML5, Microformats, semantic web, and Standards categories.
• There have been sixteen replies.

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.

• Invented Elements was published on Friday, March 23rd, 2012.
• It was assigned to the (X)HTML, Browsers, DOM, HTML5, Standards, and Web categories.
• There have been fourteen replies.

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.)

• Negative Proximity was published on Wednesday, March 7th, 2012.
• It was assigned to the CSS category.
• There have been nine replies.

Last Thursday, I had the rare honor and privilege of chatting with Jen Simmons as a guest on The Web Ahead .  (I’ve also chatted with Jen in real life.  That’s even awesomer!)  As is my wont, I completely abused that privilege by chatting for two hours — making it the second-longest episode of The Web Ahead to date — about the history of the web and CSS, what’s coming up that jazzes me the most, and all kinds of stuff.  I even revealed, toward the end of the conversation, the big-picture projects I dearly wish I had time to work on.

The finished product was published last Friday morning.  I know it’s a bit of a lengthy beast, but if you’re at all interested about how we got to where we are with CSS, you might want to give this a listen:  The Web Ahead, Episode #18.  Available for all your finer digital audio players via embedded Flash player, iTunes, RSS, and MP3 download.

My deepest thanks to Jen for inviting me to be part of the show!

• The Web Ahead, Episode #18: Me! was published on Monday, March 5th, 2012.
• It was assigned to the CSS and Interviews categories.
• There have been three replies.

Thanks to last summer’s home renovation project, the new kitchen is lit by six interior flood bulbs.  We were using the diffuse incandescent bulbs our contractors put in, which were nice and warm and soft.  And also, being essentially freebies, not long for this world.  We recently had three burn out within two weeks.

We decided to take the opportunity to switch from incandescents to something far more energy-efficient.  Having used a number of CFLs around the house, I knew I wanted no part of that scene.  The subtle flicker they generate isn’t subtle enough for me, and I hate the wan quality of the light.  I’m not really thrilled with the warm-up time, either.

So we went with LEDs.  This wasn’t as straightforward as I might have liked, but we’ve now switched and are really happy to have done so.  I’d like to share the most important thing we learned in hopes of helping others through the transition.

It’s this:  if you’re going from “warm” incandescents straight to LED, find bulbs that have a color temperature of 2700K.  The first test bulb we bought was 3000K, and the difference was enormous.  By comparison to the incandescents, it was a harsh white.  In a Modernist design setting, like say at the Guggenheim, 3000K is probably a good choice.  In our wood-and-grain center-hall Colonial home, it was all wrong.

So I ran up to Home Depot and picked up a couple of EcoSmart BR30 diffuse floodlight bulbs, which are 2700K.  I put in one as a test, and when we flipped on the lights, I couldn’t see a difference in the light given off by the LED and incandescent bulbs.  The LED gave off a little bit more light than the incandescents around it (more on that in a minute) but the quality of light was essentially the same.  I put in the other test bulb with the same results.  Now we have all six cans fitted with the EcoSmarts, and the kitchen is just as warm as it was before.

One slightly noticeable difference is that there are more lumens bouncing around the kitchen than before, because we had 65W incandescents and the LEDs are equivalent to 75W (they actually consume 14W).  There weren’t any 65W equivalents in the floods, at least when I went looking, so I picked the 75W equivalents.  The new bulbs put out 800 lumens each, whereas the old ones likely shed 650-700 lumens each.  I do notice the difference, but it’s not so extra-bright that it’s bothersome.  That said, if I track down some bright white 2700Ks in the 650-700 lumen range, I may swap out half the kitchen bulbs in a staggered pattern to see how it feels.  Whichever ones I don’t use in the kitchen, I can always reuse in the cans in our basement.

The really noticeable difference is that when you flip the wall switch, it takes half a second for the bulbs to actually light up.  It’s a bit unusual when you switch straight from incandescent, but it’s no worse than the “on time” for most CFLs, and there’s no slow warm-up time for LEDs like you get with CFLs.  Once they’re on, they’re on.  And they don’t hum or flicker they way CFLs are prone to doing.

In closing, I just want to reiterate that color temperature is absolutely crucial, and if you’re coming over from incandescents, you want to be at 2700K.  Beyond that, match up the wattage as best you can, grit your teeth through the purchase price, and bask in the knowledge that your electricity bills will be lower, plus you shouldn’t have to replace the bulb any time in the next decade or even two.  That last part alone nearly makes LEDs worth the up-front cost.

If you have experiences or tips to share with regards to LED bulbs, by all means leave a comment!

• From Filaments to Semiconductors was published on Friday, March 2nd, 2012.
• It was assigned to the General and Guide categories.
• There have been nine replies.

A little while back, I was reading some text when I realized the hyphens didn’t look quite right.  A little too wide, I thought.  Not em-dash wide, but still…wide.  Wide-ish?  But when I copied some of the text into a BBEdit window, they looked just like the hyphens I typed into the document.

Of course, I know Unicode is filled with all manner of symbols and that the appearance of those symbols can vary from one font face to another.  So I changed the font face, made the size really huge, and behold: they were indeed different characters.  At this point, I was really curious about what I’d found.  What exactly was it?  How would I find out?

For the record, here’s the character in question:

−

Googling “−” and “− Unicode” got me nothing useful.  I knew I could try the Character Viewer in OS X, and eventually I did, but I was wondering if there was a better (read: lazier) solution.  I asked the Twittersphere for advice, and while I don’t know if these solutions are any lazier, here are the best of the suggestions I received.

• Unicode Lookup, a site that lets you input or paste in any character and get a report on what it is and how one might call it in various encodings.
• Richard Ishida’s UniView Lite, which does much the same as Unicode Lookup with the caveat that once you’ve input your character, you have to hit the “Chars” button, not the “Search” button.  The latter is apparently how you search Unicode character names for a word or other string, like “dash” or “quot”.
• UnicodeChecker (OS X), a nice utility that includes a character list pane as well as the ability to type or paste a character into an input and instantly get its gritty details.

Any of those will tell you that the − in question is MINUS SIGN, codepoint 8722 (decimal) / 2212 (UTF-16 hex) / U+2212 (Unicode hex) / et cetera, et cetera.  Did you know it was designated in Unicode 1.1?  Now you do, thanks to UnicodeChecker and this post.  You’re welcome.

Update 2 Mar 12:  Philippe Wittenberg points out in the comments that you can add a UnicodeChecker service.  With that enabled, all you have to do is highlight a character, summon the contextual menu (right-click, for most of us), and have it shown in UnicodeChecker.  Now that’s the kind of laziness I was trying to attain!

• Finding Unicode was published on Thursday, March 1st, 2012.
• It was assigned to the Tools category.
• There have been twenty-eight replies.