On semantic HTML

Reposted from a discussion on pdxruby.

On Jun 14, 2008, at 3:02 AM, Bill Burcham wrote:

How does one resolve the Absolute Good of semantic HTML against the need for a CSS layout framework?

But I must ask: Semantic to whom? The framework? The browser? The web developer? The user? The user who peers into the HTML page to see how well/poorly it’s constructed?

Semantic HTML has always seemed like a misguided idea. I have no problem with the idea of expressing content semantically, but I’m not sure HTML is the right place to take the fullest advantage of semantic markup. It’s language is too limited, too concrete, and was designed with the analog of printed, mostly textual publications.

And CSS doesn’t help: its generally a one-to-one styling mechanism. It can bridge generic presentation with specific presentation (‘make this header Helvetica’), but it can’t provide more abstract functions: eg, creating a navigation system. This abstraction, I think, is what’s missing in the HTML/CSS universe.

At HTML’s inception, there were two worlds: one of pixel-level object interaction (CD-ROM/multimedia) and one of hypertext (SGML/running text). Tim Berners-Lee chose the latter. Interestingly, early HTML was all semantic: you marked up headings, paragraphs, citations, lists, etc. Here is the original ‘spec’ for HTML.

Most of those elements still function in modern HTML. And in fact this is the only way I’ve been able to keep myself sane and still do web development: use old-style HTML elements (h[1-6], p, em, ul/li, dd/dl/dt) for marking up the text structure, use logical elements (div, span) for defining areas that need special treatment, and very occasionally change the style of elements directly (eg, <p class=”foo”>). I will even check sites using the lynx/links text-mode browsers just to make sure I haven’t made a mess of it all.

The most pure method seemed to be pushing XML down to the browser, and using something like XSLT to convert truly semantic markup into presentation markup. I think it was an idea ahead of its time, though; we were still knee-deep in the browser wars, decent web frameworks were rare, and most users/developers were still getting their heads around CSS. I suppose nowadays the answer is XMLHttpRequest, JSON responses, and buckets of DOM-modifying Javascript code.

Of course, technology has moved on and we’ve solved this in a few ways:

  • Domain/content-type/browser detection: Instead of trying to make one perfect HTML/CSS page that properly renders on all browsers, give it up and create pages that are more specific for the user’s purpose. Just go full throttle and be unsemantic and concrete.
  • High-level widgets: Express the content semantically on the back-end, and implement either server-side widgets that build HTML that is then sent down the pipe, or client-side Javascript widgets that are rendered by the browser.
  • Hold your nose and use a framework: I know this has been my attitude in my recent usage of YUI. Yeah, it looks sucky and is unintuitive, but it works and I know I will never again vent my frustration for ‘hacks modes.’ Of course, I still need a site-specific CSS file, but I find that its content is far simpler and less browser-dependent.

Bill Burcham continued:

Compare doing layout in semantic HTML and CSS to doing layout in Adobe InDesign for instance. I assert that the requirements addressed by the two approaches are roughly equivalent and yet you hardly have to be a high priest to do layouts in InDesign. You just lay things out. Sheesh.

But this is apples and oranges: you’re comparing semantic HTML/CSS with (presumably) non-semantic page layout.

Doing semantic layout in InDesign is actually a total pain. I do a lot of InDesign layouts (these days, probably more than websites), and am often irritated that I have to use “hacks” to, for example, get the first paragraph in a chapter flush left but remaining paragraphs indented. There’s no apparent way to do it other than a special substyle of a the paragraph with no indenting, and manually setting the first paragraph to that substyle. Worse, there’s no way to have the chapter title appear a few picas down on a page without either moving the text box handles, or adding a dummy pre-title line that has the appropriate amount of leading.

InDesign layout seems easier because the end result is just ink on paper; its semantic meaning is implicit in the relationships of the page elements. Your choice of paper size, spacing, line measures, type size, font, etc., all create a meaning (if the design is successful) that the reader understands. The effect is the same regardless of whether you (the designer) create the elements by directly specifying text blocks, fonts, etc., or whether you use InDesign’s XML markup, stylesheets, anchors, etc.

And this gets back to my original point: who is the semantics intended for? All that really matters, in the end, is that the user/reader sees the printed/web page and understands its meaning.

Published in: on 14 June 2008 at 12:44 am  Leave a Comment  

The URI to TrackBack this entry is: https://johnlabovitz.wordpress.com/2008/06/14/on-semantic-html/trackback/

RSS feed for comments on this post.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: