Even though a lot has changed (both good and bad) since I started working as a front-end developer, there have been a few constants in my line of work that have persisted no matter how much I wrote or talked about them. I'm not a quitter though, so I've prepared yet another article in an attempt to try and bare the core of what makes an html developer tick. What exactly is it that makes us choose one particular html structure over another.
visual order vs logical order
At first glance there might be a strong bond between visual and logical order, but upon closer inspection you'll find that our eyes behave very differently from our brains. Our eyes don't always follow a logical path (top left to bottom right for us Westerners) when scanning for information and they often manage to skip ahead based on what attracts them or what they have learned from previous experiences.
For example, when browsing through a site our eyes will start to skip the site header after a while because they know from previous pages that they're not going to find anything of interest there, instead the eyes skip immediately to the content section of a new page. Then there are also color and alignment impulses that help our eyes to focus, whereas a logical order might dictate a different structure.
These alignment impulses is what I'm going to talk about here, as they perfectly illustrate the way we deal with checkboxes (or radio buttons if you want) on our websites. It's a perfect example of how the mind of someone who writes html works (or should work).
Checkboxes don't pose a big challenge these days, not for developers nor for designers. Just line up the checkboxes to the left, then add the labels to the right and when a label spans multiple lines make sure it doesn't wrap around the checkbox. It's easy as can be.
At least, that's how our eyes interpret it. By lining up the checkbox elements to the left they are a lot easier to spot (useful for quickly checking which ones are active). If we'd put the checkbox elements behind the labels they would be a lot harder to find, so to the left they go. But from a logical perspective, putting the checkbox first makes no sense at all.
Instead of thinking like a blind user (who probably has a screenreader that couples the label to the input element for him), just imagine going through the html code from top to bottom. If you'd match the html to the visual structure, you'd be putting the checkbox first in the html structure. So basically, you'd get a checkbox without the slightest idea of what its label is going to be. There is no context at all that tells you what this checkbox is about. Only when continuing you'd get to read the label. Should you then want to activate the checkbox, you'd be required to hop back before you could check the checkbox. It's like asking someone to reply "yes" or "no" without posing the question first. Silly, no?
So from a logical point of view, the label comes first, followed by the checkbox. And in short, that's what I try to take into account when I write html code. It's css that's supposed to bridge the gap between logical and visual structures, where html makes sure everything is presented in a logical order. As for the practical side, a position absolute and some padding will do the trick, or you can be all modern and flexbox both elements in the right visual order, but that's a css thing, not a html thing.
Don't get me wrong, I fully understand that this is quite the purist example. If you put the label after the checkbox, nobody will die and your site won't be much harder to use by the people visiting it, but to me this example perfectly illustrates the difference between what you see in a design and what you code in html. Other popular examples include "see all" links laid out next to the heading of a list or "back to top" links laid out in the same spot. Share buttons above an article or images that appear above headings are other popular examples.
Sticking to logical html structures can put some extra stress on the css and unless you're confident enough I wouldn't recommend going all the way, all the time, but it's good to keep things like this in mind whenever you're writing html code. Just read it from top to bottom and consider whether it makes sense without a visual design, because that's what html is all about.