James has been tweaking the accessibility of his site navigation. I’m looking forward to the sequel.
Thursday, October 5th, 2017
Tuesday, July 4th, 2017
Here’s an interesting proposal to slightly amend the semantics of the
small element so it could apply to the use-case that
hgroup was trying to cover.
Sunday, June 18th, 2017
A great one-page intro to microformats (h-card in particular), complete with a parser that exports JSON. Bookmark this for future reference.
Monday, February 20th, 2017
Jake is absolutely spot-on here. There’s been a lot of excited talk about adding an
h element to HTML but it all seems to miss the question of why the currently-specced outline algorithm hasn’t been implemented.
This is a common mistake in standards discussion — a mistake I’ve made many times before. You cannot compare the current state of things, beholden to reality, with a utopian implementation of some currently non-existent thing.
If you’re proposing something almost identical to something that failed, you better know why your proposal will succeed where the other didn’t.
Jake rightly points out that the first step isn’t to propose a whole new element; it’s to ask “Why haven’t browsers implemented the outline for sectioned headings?”
Monday, January 2nd, 2017
Sunday, September 25th, 2016
Heydon asked screen readers some questions about their everyday interactions with websites. The answers quite revealing: if you’re using headings and forms correctly, you’re already making life a lot easier for them.
Thursday, May 26th, 2016
Snook has been on a roll lately, sharing lots of great insights into front-end development. This is a particularly astute post about that perennial issue of naming things.
Sunday, April 24th, 2016
Psst… Jeremy! Right now you’re getting notified every time something is posted to Slack. That’s great at first, but now that activity is increasing you’ll probably prefer dialing that down.
Why does everyone always look at me? I know I’m a chalkboard and that’s my job, I just wish people would ask before staring at me. Sometimes I don’t have anything to say.
I’m Little MOO - the bit of software that will be managing your order with us. It will shortly be sent to Big MOO, our print machine who will print it for you in the next few days. I’ll let you know when it’s done and on it’s way to you.
It looks like you’re writing a letter.
Your quest is to find the Warlock’s treasure, hidden deep within a dungeon populated with a multitude of terrifying monsters. You will need courage, determination and a fair amount of luck if you are to survive all the traps and battles, and reach your goal — the innermost chambers of the Warlock’s domain.
Welcome to Adventure!! Would you like instructions?
I am a lead pencil—the ordinary wooden pencil familiar to all boys and girls and adults who can read and write.
ÆLFRED MECH HET GEWYRCAN
Ælfred ordered me to be made
I have marked up the protagonist of each conversation using the
cite element. There is a long-running dispute over the use of this element. In HTML 4.01 it was perfectly fine to use
cite to mark up a person being quoted. In the HTML Living Standard, usage has been narrowed:
citeelement represents the title of a work (e.g. a book, a paper, an essay, a poem, a score, a song, a script, a film, a TV show, a game, a sculpture, a painting, a theatre production, a play, an opera, a musical, an exhibition, a legal case report, a computer program, etc). This can be a work that is being quoted or referenced in detail (i.e. a citation), or it can just be a work that is mentioned in passing.
A person’s name is not the title of a work — even if people call that person a piece of work — and the element must therefore not be used to mark up people’s names.
In the examples above, it’s pretty clear that I, Pencil and Warlock Of Firetop Mountain are valid use cases for the
cite element according to the HTML5 definition; they are titles of works. But what about Clippy or Little Moo or Slackbot? They’re not people …but they’re not exactly titles of works either.
If I were to mark up a dialogue between Eliza and a human being, should I only mark up Eliza’s remarks with
cite? In text transcripts of conversations with Alexa, Siri, or Cortana, should only their side of the conversation get attributed as a source? Or should they also be written without the
cite element because it must not be used to mark up people’s names …even though they are not people, according to conventional definition.
It’s downright botist.
Wednesday, March 2nd, 2016
There is one truism that has been constant throughout my career on the web, and it’s this: naming things is hard.
Trent talks about the strategies out there for naming things. He makes specific mention of Atomic Design, which as Brad is always at pains to point out, is just one way of naming things: atoms, molecules, organisms, etc.
In some situations, having that pre-made vocabulary is perfect. In other situations, I’ve seen it cause all sorts of problems. It all depends on the project and the people.
Personally, I like the vocabulary to emerge from the domain knowledge of the people on the project. Building a newspaper website? Use journalism-related terms. Making a website about bicycles? Use bike-related terms.
Wednesday, December 9th, 2015
The best ARIA role is the one you don’t need to use.
Saturday, November 7th, 2015
This is such an incredibly useful resource by Steve and Léonie: documenting how multiple screen readers handle each and every element in HTML.
It’s a work in progress, but it’s definitely one to remember the next time you’re thinking “I wonder how screen readers treat this markup…”
Wednesday, September 9th, 2015
Here’s a classic. David Siegel—of Creating Killer Websites fame—outlines exactly why he turned his back on that 1×1 spacer .gif trick he invented.
Tuesday, March 31st, 2015
A superb piece by Ross Penman on the importance of being true to the spirit of the web.
Tuesday, December 9th, 2014
With all my talk about extending existing elements instead of making new ones, I was reminded of one of my favourite examples of custom elements in action: Github’s extensions of the
Saturday, November 22nd, 2014
A great presentation on web components by Marcy, with an emphasis on keeping them accessible.
Wednesday, October 22nd, 2014
A question of markup
I’m really sorry it’s taken me so long to write back to you (over a month!)—I’m really crap at email.
I’m writing to you hoping you can help me make my colleagues take html5 “seriously”. They have read your book, they know it’s the “right” thing to do, but still they write !doctype HTML and then div, div, div, div, div…
Now, if you could provide me with some answers to their “why bother?- questions” would be really appreciated.
I have to be honest, I don’t think it’s worth spending lots of time agonising over what’s the right element to use for marking up a particular piece of content.
That said, I also think it’s lazy to just use divs and spans for everything, if a more appropriate element is available.
Paragraphs, lists, figures …these are all pretty straightforward and require almost no thought.
Deciding whether something is a section or an article, though …that’s another story. It’s not so clear. And I’m not sure it’s worth the effort. Frankly, a div might be just fine in most cases.
For example, can one assume that in the future we will be pulling content directly from websites and therefore it would be smart to tell this technology which content is the article, what are the navigation and so on?
There are some third-party tools (like Readability) that pay attention to the semantics of the elements you use, but the most important use-case is assistive technology. For tools such as screen readers, there’s a massive benefit to marking up headings, lists, and other straightforward elements, as well as some of the newer additions like nav and main.
But for many situations, a div is just fine. If you’re just grouping some stuff together that doesn’t have a thematic relation (for instance, you might be grouping them together to apply a particular style), then div works perfectly well. And if you’re marking up a piece of inline text and you’re not emphasising it, or otherwise differentiating it semantically, then a span is the right element to use.
So for most situations, I don’t think it’s worth overthinking the choice of HTML elements. A moment or two should be enough to decide which element is right. Any longer than that, and you might as well just use a div or span, and move on to other decisions.
But there’s one area where I think it’s worth spending a bit longer to decide on the right element, and that’s with forms.
When you’re marking up forms, it’s really worth making sure that you’re using the right element. Never use a span or a div if you’re just going to add style and behaviour to make it look and act like a button: use an actual button instead (not only is it the correct element to use, it’s going to save you a lot of work).
Likewise, if a piece of text is labelling a form control, don’t just use a span; use the label element. Again, this is not only the most meaningful element, but it will provide plenty of practical benefit, not only to screen readers, but to all browsers.
So when it comes to forms, it’s worth sweating the details of the markup. I think it’s also worth making sure that the major chunks of your pages are correctly marked up: navigation, headings. But beyond that, don’t spend too much brain energy deciding questions like “Is this a definition list? Or a regular list?” or perhaps “Is this an aside? Or is it a footer?” Choose something that works well enough (even if that’s a div) and move on.
There’s a bit of a contradiction to what I’m saying here.
On the one hand, I’m saying you should usually choose the most appropriate element available because it will save you work. In other words, it’s the lazy option. Be lazy!
On the other hand, I’m saying that it’s worth taking a little time to choose the most appropriate element instead of always using a div or a span. Don’t be lazy!
I guess what I’m saying is: find a good balance. Don’t agonise over choosing appropriate HTML elements, but don’t just use divs and spans either.
Hope that helps.
Hmmm… you know, I think I might publish this response on my blog.
Friday, August 15th, 2014
Remember when I was talking about refactoring the markup for Code for America? Well, it turns out that Heydon Pickering is way ahead of me.
He talks about the viewpoint of a writer (named Victoria) who wants to be able to write in Markdown, or HTML, or a textarea, without having to add classes to everything. That’s going to mean more complex CSS, but it turns out that you can do a lot of complex things in CSS without using class selectors.
There are slides.
Tuesday, June 3rd, 2014
I really hope that this is the kind of usage we’ll see for web components: enhancements for the browsers that support them without a good ol’ fashioned fallback for older browsers.
Friday, March 28th, 2014
Funny because it’s true:
The thing I regret the most is how my class addiction affected my relationship with HTML.
Friday, January 31st, 2014
The complexity of HTML
Now we’re back to seeing almost the same level of complexity and messiness in most web pages as we saw in the worst days of table-hacking. The semantic elements from HTML5 are largely unused.
The reason for this, as outlined in an old email by Matthew Thomas, is down to the lack of any visible benefit from browsers:
unless there is an immediate visual or behavioural benefit to using an element, most people will ignore it.
That’s a fair point, but I think it works in the opposite direction too. I’ve seen plenty of designers and developers who are reluctant to use HTML elements because of the default browser styling. The
legend element is one example. A more recent one is
input type=”date”—until there’s a way for authors to have more say about the generated interface, there’s going to be resistance to its usage.
Anyway, Baldur’s complaint is that HTML is increasing in complexity by adding new elements—
article, etc.—that provide theoretical semantic value, without providing immediate visible benefits. It’s much the same argument that informed Cory Doctorow’s Metacrap essay over a decade ago. It’s a strong argument.
There’s always a bit of a chicken-and-egg situation with any kind of language extension designed to provide data structure: why should authors use the new extensions if there’s no benefit? …and why should parsers (like search engines or browsers) bother doing anything with the new extensions if nobody’s using them?
Whether it’s microformats or new HTML structural elements, the vicious circle remains the same. The solution is to try to make the barrier to entry as low as possible for authors—the parsers/spiders/browsers will follow.
I have to say, I share some of Baldur’s concern. I’ve talked before about the confusion between
article. Providing two new elements might seem better than providing just one, but in fact it just muddies the waters and confuses authors (in my experience).
But I realise that in the grand scheme of things, I’m nitpicking. I think HTML is in pretty good shape. Baldur said “simply put, HTML is a mess,” and he’s not wrong …but HTML has always been a mess. It’s the worst mess except for all the others that have been tried. When it comes to markup, I think that “perfect” is very much the enemy of “good” (just look at XHTML2).
I actually found quite a few use cases for
hgroup in my own work …but I could certainly see why it was a dodgy solution. The way that a wrapping
hgroup could change the semantic value of an
h3, or whatever …that’s pretty weird, right?
And then Tantek pointed out that there are a number of HTML elements that depend on their wrapper for meaning …and that’s a level of complexity that doesn’t sit well with HTML.
For example, a
p is always a paragraph, and
em is always emphasis …but
li is only a list item if it’s wrapped in
tr is only a table row if it’s wrapped in a
(Interestingly, these are the very same elements that browsers will automatically adjust the DOM for—generating
table if the author doesn’t include it. It’s like the complexity is damage that the browsers have to route around.)
I had never thought of that before, but the idea has really stuck with me. Now it smells bad to me that it isn’t valid to have a
figcaption unless it’s within a
These context-dependent elements increase the learning curve of HTML, and that, in my own opinion, is not a good thing. I like to think that HTML should be easy to learn—and that the web would not have been a success if its lingua franca hadn’t been grokabble by mere mortals.
Tantek half-joked about writing HTML: The Good Parts. The more I think about it, the more I think it’s a pretty good idea. If nothing else, it could make us more sensitive to any proposed extensions to HTML that would increase its complexity without a corresponding increase in value.