Oh, this is such a good analogy from Mandy! Choosing the right HTML element is like choosing the right data type in a strongly typed programming language.
Get to know the HTML elements available to you, and use the appropriate one for your content. Make the most it, like you would any language you choose to code with.
I encourage you to think about and make sure you are using the right elements at the right time. Sometimes I overthink this, but that’s because it’s that important to me - I want to make sure that the markup I use helps people understand the content, and doesn’t hinder them.
If you don’t fancy watching this video, Eric Runyon has written down the salient points about what it means for developers now that websites can be viewed on the Apple Watch. Basically, as long as you’re writing good, meaningful markup and you’ve got a sensible font stack, you’re all set.
Or, as Tim puts it:
When we build our sites in a way that allows people using less-capable devices, slower networks and other less than ideal circumstances, we end up better prepared for whatever crazy device or technology comes along next.
I really like this month’s CodePen challenge, all about HTML elements that go well together. First up: del and ins.
Lesson learned: the discoverable and understandable web is still do-able — it’s there waiting to be discovered. It just needs some commitment from the people who make websites.
What it says on the tin—a few suggestions to ensure the accessibility of your site.
Everything you ever wanted to know about the title attribute in HTML.
What’s hot: using title on inputs, abbrs, and iframes.
What’s not: using title on anything else.
I like this distinction between coders and developers.
The Coder is characterized by his proficiency in a narrow range of chosen skills.
By contrast the Developer’s single greatest skill is in being an applied learner.
I’m definitely not a coder. Alas, by this criterion, I’m also not a developer (because I do not pick things up fast):
Quite simply the Developer has a knack for grokking new [languages|frameworks|platforms] and becoming proficient very quickly.
I prefer Charlie’s framing. It’s not about speed, it’s about priorities:
I’m not a “developer” in that I’m obsessed with code and frameworks. I’m a “developer” as in I develop the users experience for the better.
James has been tweaking the accessibility of his site navigation. I’m looking forward to the sequel.
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.
A great one-page intro to microformats (h-card in particular), complete with a parser that exports JSON. Bookmark this for future reference.
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?”
(I added a small historical note in the comments pointing to the first occurrence of this proposal way back in 1991.)
Readability is back, but now it’s called Mercury.
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.
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.
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.
Most importantly, make the naming process a collaborative exercise, as outlined by Alla and Charlotte.
The best ARIA role is the one you don’t need to use.
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…”
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.
A superb piece by Ross Penman on the importance of being true to the spirit of the web.