html musings

Sometimes it helps to ponder a little about html specifics. While semantics and structure may appear to be clear cut guidelines, die-hard htmlers know that there's a lot of fuzzy territory when dealing with our beloved tags. This feature will help me to share some of that fuzziness, hopefully coming to some meaningful insights in the process.

scrset arrives in webkit / hardware-dependent html

date
August 22, 2013
permalink

Last year I already wrote at length about the proposition to include a standardized (or was it bastardized) solution for responsive images in html. Well, earlier this week webkit incorporated the srcset attribute, which hopes to fix the retina/HD part of the equation. It hard not to feel disappointed.

One of the toughest things about defining web standards is that we have to be backwards compatible. Most people assume this just means that new changes shouldn't break older code, but it's actually a little trickier than that. Being backwards compatible also means that any new additions will determine what we can (and can't) do with future code. If we add a half-arsed solution now (and it is adopted widely), we're probably stuck with it for the next 10 years (if not longer). So it's of utmost importance to think twice before adding something to the spec.

In short, the problem of burdening html with responsive content images is that the solution simply doesn't belong there. Because different available options need to be hard-coded in the html for each image separately this means a major set of html changes whenever a new form factor or resolution needs to be added. Every single image (including all content images uploaded in CMSes) needs to be updated to reflect this change, which just plain sucks. There's never been a link between html and hardware before and it would be best to keep it that way, as it opens a door that's best kept shut.

Even worse, the srcset attribute only takes care of resolution and screen size, and not the actual available size for the image, meaning we still haven't learned a thing from the media queries mistake we made before. The days that phone/tablet screen sizes matched the available space are already behind us, so I don't really get why we're still stuck with that paradigm.

Everything points at the fact that srcset is a quick fix for a tough problem we can't solve right away. The problem with quick fixes is that they tend to linger and that five or ten years down the line we'll find ourselves cursing at the people who thought it wise to include them. It's happened before and it'll happen again, it's just a shame when you see it happening and you can do very little about it. Let's hope other rendering engine developers will act wiser, but I doubt it.

components and states / responsive changes

date
July 24, 2013
permalink

Responsive web design taught us a thing or two about component-based front-end development. Before we were talking rwd, front-end components were pretty straight-forward. They presented a singular solution to a problem and that was that. Each component matched a more or less fixed html structure that could be brought to life using css and javascript. But since responsive design took over by necessity, varying layouts and devices started to affect the once so robust patterns we devised for ourselves.

Still, html-wise very little has changed. In the end html just describes what a piece of content is, rather than describing its appearance or functional behavior. On the css side of things we were helped by media queries. A far from perfect solution but we can make do for the time being. But what about functional changes (ie javascript is involved) ?

A lot of functional components we used to define (carousel, accordion, tabpane, swipe list) are more or less interchangeable depending on the context. What is a carousel on non-touch desktop can become a swipe list on tablets and could even be turned into a plain old list on mobile. The actual component here is a mere container of data clusters, which can then be given a different functional behavior depending on its context.

The dilemma here is whether to hardcode this information into the html, or to leave it up to javascript to implement the correct behavior for each instance of the base component. Hardcoding it into the html means that you lose some flexibility in your css and javascript when something needs to be changed. Finding a syntax for hardcoding isn't that easy either. You have to list the condition (which could be a breakpoint, touch context, OS context, ...), a value for that condition and the corresponding state while making sure you don't create conflicts. Relying entirely on hooks on the other hands means that you could end up a few hooks short to properly implement everything.

It's an interesting exercise that will require some balancing between defining components and states. Trial and error is probably the key here, but it will definitely change the way we look at components in the future.

html is structure / think group layers

date
June 20, 2013
permalink

Explaining html to other people can be a daunting exercise, even when those people are actively working in the web development business. It's true that html is the core frame upon which an entire site is built (and people do realize this), but all too often they cast aside html as a mere excuse for applying css or javascript. Much in the same way many people consider pasta a good excuse to gobble down sauce.

Us html people got lucky when html semantics were able to hitch a ride on SEO's back. Suddenly we had a firm and convincing business model for writing class A html code. People learned about semantics and accepted it as valuable, which was definitely a good thing. But html provides more than just semantic information, it also provides structures. This is a much more abstract aspect of the language and it is a lot harder to communicate. Hence this little analogy:

Structure is about grouping things together (or separating them, depending on your point of view), pretty much like you do when working with a design program (PhotoShop, Flash, ...). Those graphical programs all have a "group elements" functionality which allows you to bundle separate building blocks into a bigger one. The cool thing about this is that you can manipulate the entire group as a single entity, while still being able to tweak the smaller ones. So if for example you're designing a website and the distance between the site content and the site header needs to be bigger, you don't have to drag down every single content element while worrying about its respective layout. You can put all elements in a group and just reposition that group.

That's exactly what html does. Every html element on a page that has children is a group. You can manipulate this group as a whole, or you can manipulate its children separately (with css, javascript or whatever language you have running over the html code). Of course you don't have to group certain elements, but you lose the flexibility to manipulate them as such, often resulting is crappy, unstable css solutions.

Structure is important because it determines what you can do with the elements on a page and it determines the speed at which things can be moved around or changed. As long as a html element has structural meaning, I don't mind leaving it in (for the record, I don't mean pure wrapper elements as they have only one direct descendant by default), if only to allow for future adaptability. I know there are still some people who consider it overkill, but that opinion is often reflected in the quality of their css code.

classes and ids / no css exclusives

date
May 30, 2013
permalink

When reading about classes and ids these days, you'd start believing that they were invented exclusively for css and js targeting. To the point where css and js are actually dictating the rules for using classes and ids. While it's true that css and js are the primary languages that make use of them, they are not the ones laying down the rules. Classes and ids are part of the html and are the htmler's responsibility.

Concessions can be made of course, after all we're talking web design here, but coming up with class/id-related best practices based on the needs of css or js is just plain wrong. The needs of different languages should definitely be considered, but in the end it's the responsibility of the csser or javascripter to adapt to the html, not the other way around.

The true function of classes and ids is to open up the html to a variety of interested parties. Classes and ids are hooks that other languages use to find what they need. Classes and ids may not need semantic, but thinking of them as semantic abstractions makes it a lot easier for a htmler to identify what classes and ids are needed to make the code accessible to all. A class like .fancyHeading is not a valid class under normal circumstances. It's a css-specific class that no other interested party would benefit from and only solves a problem that could've been better solved using css preprocessors.

The problem is that lack of html consistency is preventing other languages from actively querying our html code, so the dominance of css and js remains. Forgoing the wealth of opportunities here and focusing on css and js just further diminishes the power of classes and ids. So let's stop messing up our html with language-specific classnames and ids, instead focusing on drawing up html components and leaving the responsibility to deal with them in each respective language.

the breadcrumb / where does it belong

date
May 14, 2013
permalink

Once a novel concept, the breadcrumb has become one of the strongholds of just about every content-heavy website's interface out there. When you consider its place in the html though, it's a somewhat unusual component. It falls right in between the site frame and the actual content of a page, not really belonging to either. Most of the time I let the design decide where to add the breadcrumb, but here are a couple of things to consider:

The breadcrumb is clearly part of the meta data of a page (as it indicates the page's position within the entire website) and it varies with each different page. From that point of view, the breadcrumb probably belongs in the header of the page section. It does offer navigational means to get higher sections within the site though, so coming from that angle the site header doesn't sound like such a bad place for a breadcrumb. If you have a breadcrumb that separates the navigation part from the active page part (usually incorporating the h1 of a page) it makes even more sense to put it into the site header, leaving the h1 in the page header and faking the connection using css. But there's also an option to place it inside the introduction section (together with the site label and skip links) if you consider the breadcrumb a vital tool for your user to orient himself.

<body> <div id="introduction"> ... <nav class="breadcrumb">...</nav> </div> <div id="page"> <header> <div class="breadcrumb">...</div> ... </header> ... </div> <div id="site"> <header> ... <div class="breadcrumb">...</div> </header> ... </div> </body>

Personally I'd say the breadcrumb belongs in the #page > header as that's where I usually put my meta data when dealing with regular content types. The design may decide differently and in certain cases (where a lot of emphasis is placed onto the breadcrumb) the #introduction section may be better suited to house it. I wouldn't completely rule out the #site > header either, but only when dealing with a split breadcrumb that doesn't encompass the page's main heading. As for the nav/div discussion, I think breadcrumbs are usually secondary navigation means, so a div should suffice. But when placed into the #introduction section I think a nav element is probably the right choice.

Such a simple and well-known component, so many things to worry about.

intro text / part of the header or body?

date
April 26, 2013
permalink

Intro text is hardly a new concept. Newspapers have had them for years, so have magazines. On the web they are a little rarer, but sites like Smashing Magazine have made good use of them. Typically intro text is a visualized a little bigger than the body copy, sometimes set in italic or rendered in a different font. The purpose of the introductory text is to tease the content of the article (not summarize it) and to provide a slick transition between the tease and the first paragraph of your body copy. The question is: where does introduction text belong, structurally speaking?

Or to put it differently: is intro text part of the header or does it belong in the main section of your article? Most sites seem to just include it together with the body text, providing an extra class for the alternate styling. Then again, the introductory text should not contain additional information that isn't part of the core article itself, meaning it could be left out without hurting the core content of the article. Not only that, the name "intro" seems to suggest all by itself that the header is actually a better location for this type of content.

<article class="article"> <header> ... <div class="intro">...</div> </header> <div class="main"> <div class="intro">...</div> ... </div> </article>

So either we add the intro text as the last element in the header (since it transitions right into the text), or we put it as the first element in the body, right before the actual body copy. I prefer the first option, since it is little more than a standalone piece of text that functions as an introduction to the actual content (like all other elements inside the header) and it should not be considered an integral part of the article's core content, though reality (and designs) often learn us that this puts some serious strain on the css. Purely seen from an html point of view though, the header seems definitely like the right place for intro text.