Posts in the Standards Category

Customizing Your Markup

Published 8 years, 4 months past

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.


Invented Elements

Published 8 years, 4 months past

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.


“The Vendor Prefix Predicament” at ALA

Published 8 years, 5 months past

Published this morning in A List Apart #344: an interview I conducted with Tantek Çelik, web standards lead at Mozilla, on the subject of Mozilla’s plan to honor -webkit- prefixes on some properties in their mobile browser.  Even better: Lea Verou’s Every Time You Call a Proprietary Feature ‘CSS3,’ a Kitten Dies.  Please—think of the kittens!

My hope is that the interview brings clarity to a situation that has suffered from a number of misconceptions.  I do not necessarily hope that you agree with Tantek, nor for that matter do I hope you disagree.  While I did press him on certain points, my goal for the interview was to provide him a chance to supply information, and insight into his position.  If that job was done, then the reader can fairly evaluate the claims and plans presented.  What conclusion they reach is, as ever, up to them.

We’ve learned a lot over the past 15-20 years, but I’m not convinced the lessons have settled in deeply enough.  At any rate, there are interesting times ahead.  If you care at all about the course we chart through them, be involved now.  Discuss.  Deliberate.  Make your own case, or support someone else’s case if they’ve captured your thoughts.  Debate with someone who has a different case to make.  Don’t just sit back and assume everything will work out—for while things usually do work out, they don’t always work out for the best.  Push for the best.

And fix your browser-specific sites already!


Unfixed

Published 8 years, 6 months past

Right in the middle of AEA Atlanta—which was awesome, I really must say—there were two announcements that stand to invalidate (or at least greatly alter) portions of the talk I delivered.  One, which I believe came out as I was on stage, was the publication of the latest draft of the CSS3 Positioned Layout Module.  We’ll see if it triggers change or not; I haven’t read it yet.

The other was the publication of the minutes of the CSS Working Group meeting in Paris, where it was revealed that several vendors are about to support the -webkit- vendor prefix in their own very non-WebKit browsers.  Thus, to pick but a single random example, Firefox would throw a drop shadow on a heading whose entire author CSS is h1 {-webkit-box-shadow: 2px 5px 3px gray;}.

As an author, it sounds good as long as you haven’t really thought about it very hard, or if perhaps you have a very weak sense of the history of web standards and browser development.  It fits right in with the recurring question, “Why are we screwing around with prefixes when vendors should just implement properties completely correctly, or not at all?”  Those idealized end-states always sound great, but years of evidence (and reams upon reams of bug-charting material) indicate it’s an unrealistic approach.

As a vendor, it may be the least bad choice available in an ever-competitive marketplace.  After all, if there were a few million sites that you could render as intended if only the authors used your prefix instead of just one, which would you rather: embark on a protracted, massive awareness campaign that would probably be contradicted to death by people with their own axes to grind; or just support the damn prefix and move on with life?

The practical upshot is that browsers “supporting alien CSS vendor prefixes”, as Craig Grannell put it, seriously cripples the whole concept of vendor prefixes.  It may well reduce them to outright pointlessness.  I am on record as being a fan of vendor prefixes, and furthermore as someone who advocated for the formalization of prefixing as a part of the specification-approval process.  Of course I still think I had good ideas, but those ideas are currently being sliced to death on the shoals of reality.  Fingers can point all they like, but in the end what matters is what happened, not what should have happened if only we’d been a little smarter, a little more angelic, whatever.

I’ve seen a proposal that vendors agree to only support other prefixes in cases where they are un-prefixing their own support.  To continue the previous example, that would mean that when Firefox starts supporting the bare box-shadow, they will also support -webkit-box-shadow (and, one presumes, -ms-box-shadow and -o-box-shadow and so on).  That would mitigate the worst of the damage, and it’s probably worth trying.  It could well buy us a few years.

Developers are also trying to help repair the damage before it’s too late.  Christian Heilmann has launched an effort to get GitHub-based projects updated to stop being WebKit-only, and Aarron Gustafson has published a UNIX command to find all your CSS files containing webkit along with a call to update anything that’s not cross-browser friendly.  Others are making similar calls and recommendations.  You could use PrefixFree as a quick stopgap while going through the effort of doing manual updates.  You could make sure your CSS pre-processor, if that’s how you swing, is set up to do auto-prefixing.

Non-WebKit vendors are in a corner, and we helped put them there.  If the proposed prefix change is going to be forestalled, we have to get them out.  Doing that will take a lot of time and effort and awareness and, above all, widespread interest in doing the right thing.

Thus my fairly deep pessimism.  I’d love to be proven wrong, but I have to assume the vendors will push ahead with this regardless.  It’s what we did at Netscape ten years ago, and almost certainly would have done despite any outcry.  I don’t mean to denigrate or undermine any of the efforts I mentioned before—they’re absolutely worth doing even if every non-WebKit browser starts supporting -webkit- properties next week.  If nothing else, it will serve as evidence of your commitment to professional craftsmanship.  The real question is: how many of your fellow developers come close to that level of commitment?

And I identify that as the real question because it’s the question vendors are asking—must ask—themselves, and the answer serves as the compass for their course.


CSS Editors Leaderboard

Published 9 years, 6 months past

I recently decided to create a CSS Editors Leaderboard, which is my attempt to rank the various editors of CSS modules based on the current process status of their modules, how current the modules are, and so on.  It’s kind of a turn of the wheel for me, given that I started out my CSS career with browser support leaderboards.  Now you can see who’s amassed the most spec points, and who’s made the most effective use of their time and energy.  Who knows?  Maybe some editors will try to game the system by pushing their specs along the process track.  That’d be just awful.

One thing of note: I decided to write the leaderboard script so that it directly parses an HTML file to figure out the rankings.  You can see the file yourself, if you like.  At the moment it’s just a bunch of dls, but at some point I suspect I’ll convert it to a table.  The advantage is that it’s easier for other people to fact-check the source data this way: just load it up in a browser.

I thought about just parsing specs directly but it seemed like overkill to load the entirety of the CSS2.1 module just to figure out the process status, publication date, and editor list.  And then do that same thing for every one of the 38 tracked modules.  This way I have the leaderboard and a central summary of the modules’ status, and hopefully the latter will be even more human-readable in the future.

Anyway, it was a fun little project and now it’s loose in the world.  Enjoy.


Vendor Prefix Lists

Published 9 years, 10 months past

At the prompting of an inquiry from a respected software vendor, I asked The Twitters for pointers to “canonical” lists of vendor-prefixed properties, values, and selectors.  Here’s what the crowd sourced at me:

Lists more than just prefixed properties, values, and so on.

While there’s no guarantee of completeness or accuracy, these are at least what the vendors themselves provide and so we can cling to some hope of both.  I was also pointed to the following third-party lists:

If you know of great vendor-prefix lists that aren’t listed here, particularly anything from the vendors themselves, please let us know in the comments!

Somewhat if not obviously related: does anyone know of a way to add full Textile support to BBEdit 9.x?  Having it be a Unix filter is fine.  I know BBEdit already supports Markdown, but since Basecamp uses Textile and lots of people I work with use Basecamp, I’d like stick to one syntax rather than confuse myself trying to switch between two similar syntaxes.


In Defense of Vendor Prefixes

Published 10 years, 1 month past

…that having been the original working title for “Prefix or Posthack“, my latest article for A List Apart.  (Sort of like Return of the Jedi had a working title of Blue Harvest.)  In a fairly quick read, I make the case that vendor prefixes are not only good, they have the potential to be great and to deliver greater interoperability and advancement of CSS.

So far the reaction has been overwhelmingly positive, which frankly came as a bit of a surprise.  The annoyance factor of prefixes is undeniable, and it’s been my experience that annoyance dramatically hardens opposition regardless of whether or not there are good reasons to oppose.  I could flatter myself that the agreement is due to the Obvious Rightness of my argument, but I suspect it’s actually that I merely articulated what most people had already instinctively decided for themselves.  Which isn’t a bad place to be.

Anyway, if you haven’t already, feel free to decide for yourself by reading the article—which, I feel like mentioning for no clear reason, is only the fourth piece I’ve ever written for ALA.


The Web Stack

Published 10 years, 2 months past

Following on my “HTML5 vs. Flash” talk of a couple of weeks ago, I’m hoping to do a bit of blogging about HTML5, Flash, mobile apps, and more.  But first I need to get some terminology straight.

As I did in my talk, I’m going to refer to the collection of front-end web-standards technologies—(X)HTML (of any flavor), CSS, and JavaScript—as “the web stack”.  I’ve seen the term used here and there and it makes the most sense to me as a condensed verbal shorthand.  It beats writing out the specific technologies every time or trying to use similarly clumsy constructions like “front-end tech”.  If you like, think of “web stack” as a rough equivalent to “Ajax”—a term that was invented because continually saying “asynchronous JavaScript + CSS + DOM + XMLHttpRequest” was unworkable.

The web stack sort of includes downloadable fonts, but only in the same sense that images or any other external resource is part of the stack.  SImilarly, it encompasses frameworks like jQuery in the sense that they’re built out of the components of the web stack.

When I use the term “web stack”, though, I’m not referring to back-end technologies.  Those things are important, certainly, but not from the front-end point of view.  A browser doesn’t care if your page was generated by PHP, Django, Rails, Perl, or what have you.  It doesn’t even care if the server runs on Apache or something else.

Furthermore, it doesn’t refer to plugins.  Yes, that means Flash, but it also means QuickTime, Real, ActiveX, and so forth.  What I need to make clear is that I’m not doing this in an attempt to imply that plugins don’t belong on the web at all.  They’re just not part of that core web stack any more than the web stack is part of them.  That doesn’t stop them working together, obviously.

Okay, so that’s out of the way, and I hope my meaning is sufficiently clear to everyone.  Please do leave a comment if it isn’t.  Onward!


Browse the Archive

Earlier Entries

Later Entries