Four things I learned by validating my HTML
Prompted by Jens’ posts on quality HTML, I validated my HTML for the first time in, well, years.
Publically validating your HTML was a big thing around the time we were debating whether to go down the strict XHTML route. Sites often proudly displayed an XHTML valid image in their footer.
I suspect fewer developers go through the validation process now. I appreciate that’s a very fuzzy statement, and it’s quite possible we simply don’t display badges proclaiming what has become a mundane part of the development process.
Anyway, here are a few things I learned from validating my (invalid) website.
The time element requires a datetime attribute
I knew this, so only sloppiness on my part can explain why I hadn’t added
datetime attributes to the
times on my archive pages. This makes sense as how we express time varies, even in a single language. For example, today could be 4/12/12, 12/4/12, 4th December, 4 Dec, December 4th, Dec 4 etc. etc.
datetime provides a means of objectively experessing the date and time.
This also prompted me to consider whether it was right to use
time at all. I can envisage Safari’s reader mode or Pocket parsing
datetime from a single article, but I’m not sure it’s worth marking up over 200 summaries on a single page in this way. And if adding an element doesn’t aid meaning, should we do so just because we can, or because it’s valid? It’s a reminder that marking up documents often requires some form of judgement beyond sticking to the specification.
for attributes link to input ids, not names
Take this markup from this website:
<div hidden> <label for="bot-field">Complete if you’re a robot</label> <input name="bot-field"> </div>
It’s invalid. More sloppiness on my part, unfortunately. I have no idea how I forgot that a
for attribute should match its associated
id, rather than its
name. Maybe the fact that it’s wrapped in a
div made me think it doesn’t matter as much?
I guess this makes sense because not every
input will require a name, while the
id’s function is to assign it a unique handle within the HTML.
Again, validation is making me think through how I’m using my HTML to aid accessibiity and meaning.
The autocorrect attribute is invalid
Here’s some markup from my comment form (I’ve removed the
<input autocorrect="off" required type="text" name="name" id="name">
This too is invalid because I’ve used the
autocorrect attribute. However, I decided not to remove it because I feel autocorrecting this field makes for a poor user experience – it’s also plain rude suggesting a name is somehow wrong because it’s not in the device’s dictionary.
Have I made the right decision? Will this cause a problem on some device and browser combinations? I don’t know, but the fact it’s not valid HTML at least makes me consider these possibilities.
Inline svgs shouldn’t have an alt attribute
I have a logo. It’s a transmission tower. It’s an inline
Here’s the valid HTML (
class attribute removed):
<svg role="img" id="TransmissionTower" aria-labelledby="TransmissionTowerTitle" viewBox="0 0 24 24"> <title id="TransmissionTowerTitle">Home</title> <path fill="currentColor" d="M8.28,5.45L6.5,4.55L7.76,2H16.23L17.5,4.55L15.72,5.44L15,4H9L8.28,5.45M18.62,8H14.09L13.3,5H10.7L9.91,8H5.38L4.1,10.55L5.89,11.44L6.62,10H17.38L18.1,11.45L19.89,10.56L18.62,8M17.77,22H15.7L15.46,21.1L12,15.9L8.53,21.1L8.3,22H6.23L9.12,11H11.19L10.83,12.35L12,14.1L13.16,12.35L12.81,11H14.88L17.77,22M11.4,15L10.5,13.65L9.32,18.13L11.4,15M14.68,18.12L13.5,13.64L12.6,15L14.68,18.12Z" /> </svg>
And here’s what I used before validation:
<svg alt="" viewBox="0 0 24 24">
alt attribute is invalid here. That makes sense as I’m not using an image file which may or may not load and therefore require alternative descriptive text (or an empty
alt attribute then raised the question of how to make my logo accessible. I’ve opted to use a
aria-labelledby combination that I think works. Regardless, the validation process got me researching
aria and accessible icons and images.
This is, of course, the wrong question. Why not validate? Jens is right – it’s a basic part of being a professional frontend developer (which by the way I’m not).
What I’ve also found is that validation gets you thinking more deeply about your HTML, asking questions like is this the right element to use?, how do I make this markup accessible? and could this markup cause me a future problem? HTML isn’t difficult per se by design, but requires a thoughtful approach if you want to produce work that’s robust and accessible, especially in complex interfaces and applications.
Experimenting with short lines of text: the ideal width for whom? Previous post
Next post Imagining WordPress without themes