I am available for freelance work - HIRE ME

Considering an (x)HTML5 Methodology

posted by Matt Ward on Aug 29, 2010.

In this article, I will be offering my own perspective on HTML5, my concerns about its openness in terms for formatting, and the benefits of XML syntax. All of this will bring us to the simple formulation of an (x)HTML5 methodology for readable, well written code as we move forward.

On Friday, I opened up my mailbox and was pretty stoked to find that my copy of HTML5 for Web Designers by Jeremy Keith had finally arrived, just over two weeks after having ordered it (pretty good coming from the U.S. to Canada). I immediately sat down and started reading it, and finished it up yesterday. There’s a lot of really great material packed into those few short pages and I’m not going to try to dissect it all here.

Instead, I want to consider just one important aspect of this new HTML5 technology: the form of the code.

Prior to HTML5, the evolution of markup for the web had started taking its lead from XML (extensible markup language), which, though it is infinitely extensible through user defined tags, is also extremely and rigidly structured. So, after HTML 4.01, we had XHTML 1.0 which was identical to HTML 4.01 in terms of the tags that it supported, but which instituted an XML syntax, attempting to remove some of the looseness that tended to permeate different documents across the web.

Now, for XHTML to be considered valid, the tags all had to be in lower case, all tags had to be closed (according to the order in which they were opened) and all attributes value had to be contained in proper quotation marks. From my perspective, the benefits of this were several:

  1. Better readability – When I first started to learn HTML, writing it all in uppercase was a popular coding trend—to the point where I actually thought that that was the way it had to be done. Once I learned the error of that assumption and started coding my HTML in lowercase, everything became so much easier to read.
  2. Better structure – A stricter XML structure infuses a certain, inherent logic into the document, especially when it comes to block level elements. Though it would likely never have been considered a good practice to close tags in anything other than the relative order in which they were opened, an XML structure makes this intrinsically necessary (at least in order to be considered valid).
  3. Better consistency – Before XHTML 1.0, tag attributes did not need to be contained in quotation marks. That is, of course, unless there were spaces in the attribute value itself, in which case, quotation marks were necessary for the sake of the interpreter. This meant that some attributes would be quoted while others wouldn’t. With XML syntax, however, attributes need to be quoted, which leads to a greater all around consistency, not only within a single document, but also between different documents. It also helps with readability, making the attribute and its value easily recognizable with a single glance.

From my perspective, these are the three main benefits that caused me to embrace the XHTML and its stricter syntax with open arms. It’s made our code cleaner, better structured and more consistent, and for me that’s definitely a good thing.

A Step Backward or An Open Road?

So, when I first started reading about HTML5 (before ever purchasing Keith’s excellent primer), I have to admit that I viewed it with some apprehension. The simple reason for this is best encapsulated in Keith’s own words:

With HTML5, anything goes. Uppercase, lowercase, quoted, unquoted, self-closing or not; it’s entirely up to you (16).

For someone like me, who embraced the XML-ness of XHTML, the very thought of opening everything back up at first seemed like a mammoth step backward. I mean, it was like undoing the very thing that I loved so much about XHTML 1.0 and that definitely rubbed me the wrong way.

However, since HTML5 seemed like such a big deal and so many people who are a lot smarter than I am were actually looking forward to it, I decided to withhold any final judgment until I had the chance to read more about it. I also decided that HTML5 for Web Designers would be the best place to start, so I held off as much as possible until I actually had that volume in my hands.

And now that I’ve read it? I still feel pretty much the same way, actually.

Because the HTML5 specification was created not just for web designers and developers, but also for the people actually making the browsers, I understand the reasoning a bit better now. The idea was not to create a new language based on theory, but to extend the current language based on the content already exists. It’s the concept of paving the cowpaths (Keith, 10), which essentially means: take what’s already there an make it better.

So, because there are still thousands of sites out there that still used non-XML formed HTML, the decision to make HTML5 so open ended makes sense in the light of backward compatibility. It’s what the browser makers are doing anyhow. All that “bad” coding out there still renders, and has been doing so long before the introduction of HTML5—which isn’t even fully supported yet anyhow.

And therein we begin to see the sometimes murky waters between the realms of pure theory and practical reality—but that’s a different discussion altogether.

Suffice it to say, however, that I’ve come to accept that HTML5 doesn’t so much take a giant step backward as it operates on an open road, allowing us to move forward without cutting off those who might still be lagging behind.

It’s Up to Me

Of course, I do realize that, when it comes to my own work, the openness of HTML5 doesn’t really matter. I believe in the benefits of XML syntax, and there is really nothing stopping me from continuing to use it (mostly) for any HTML5 coding that I do in the future. I can still write in lowercase, still produce well formed markup, and still quote all my attribute values.

Thus, I can still derive both the key benefits that I did from the syntax of XHTML 1.0 and all the new functionality of HTML5 (as it is supported, of course). I would encourage anyone else to do the same.

That’s why I am going to undertake an (x)HTML5 methodology for coding my own work. I’m certainly not arrogant enough to propose any sort of major revision to the HTML5 specification itself—I’m sure the people who devised it are a lot brighter than me, and I’m going to assume that they know what they’re doing. Instead, I think of this (x)HTML5 concept more as a methodology that can basically be boiled down to the decision to continue (or begin) using well formed XML syntax to deploy HTML5 documents.

If we embrace this concept, share it, teach it, evangelize it and otherwise support it, then doesn’t all the concern about the openness of the HTML5 syntax become something of a moot point? We won’t have lost any ground at all. As already noted, the browsers are already rendering non-XML HTML documents anyhow, so if people start writing non-XML HTML5, it’s not as though all that much will have really changed.

Methodology vs Technology, or Why Parentheses?

As already noted, I’m not looking to institute a new technology or specification, and there does already seem to be some work being done on the concept of a full XHTML5, which differs from my concept of (x)HTML5, in that the former is intended to actually be xml, while the later simply seeks to apply some of the syntactical benefits of XML to HTML5.

The WHATWG Wiki at least begins to explain the difference between HTML and XHTML (at least from their perspective), and notes that

There is a community who find it valuable to be able to serve HTML5 documents which are also valid XML documents. They may, for example, use XML tools to generate the document, and they and others may process the document using XML tools. These documents are served as text/html.

This could probably be useful to many people, but starts to get a bit beyond me in terms of relevance. The wiki article lists all kinds of differences between HTML5 and XHTML5 which seem to stretch beyond what is really relevant to my day to day work. I rarely work with actual XML tools, and am far more interested in the technology for the way in which it improves the structure and readability of my code.

That’s why I add the parentheses to my concept of (x)HTML5, since the idea is not necessarily to create pure XML documents (something that is probably not strictly necessary when working on the font-end code of a website). It is simply a matter of choosing to implement and enjoy the benefits of certain XML syntactical forms onto the open openness of HTML5.

Conclusion

To be quite honest, digging some of the more technical and schematic stuff too far starts to give me a headache sometimes, and I’m not sure that I would ever really find a concrete answer. That’s part of the reason I wanted HTML5 for Web Designers instead of digging into the actual HTML5 specification itself. Many of you out there probably know a whole lot more about the relationship between HTML5 and XHTML5 that I do, and I’m okay with that.

In this article, I have simply tried to encapsulate my own thoughts about HTML5, along with some of my initial concerns (and reasoning). I then tried to present the concept of an (x)HTML5 methodology as a means of deflecting my concerns in a positive fashion and continuing to derive what I perceive to be the primary benefits of the XML syntax in an HTML context.

I hope you found it interesting, and that it at least raised some interesting thoughts or questions.

Anyhow, now that I’m done throwing around acronym after acronym, it’s time to hear from you. What do you think about HTML5? Will you will still be using the XML syntax? Let’s hear your thoughts.

Post A Comment

Also from Echo Enduring Media:

An Unfolding Tale

About the Author

Matt Ward is a digital artist who lances freely under the moniker of Echo Enduring Media, and specializes in graphics design, illustration and writing. He is also the Creative Director for Highland Marketing, a creative direct marketing company based out of Waterloo, Ontario. You can follow Matt on Twitter

Like this post? Help Promote it!

Comments

Aug 29, 2010

nilopc says:

I feel 100% the same as you. As for me, I’ll be sticking with XHTML syntax when coding HTML5.

It’s just a matter of making sense semanthically.

After all, if someone else is to mantain your code in the future (maybe that could end up being yourself!) it doesn’t feel right making someone go crazy trying to figure out crappy markup.

Besides, bad HTML5 could make it hard to style with CSS or abusing from the class and id attributes. :(

Aug 29, 2010

Chip says:

I completely agree.

It’s hard for me to go back to the HTML loose syntax. I prefer working with tight code and strict rules.

I just released a WordPress theme and it crossed my mind I could make it HTML5 compatible. Half way into the coding I decided to make it XHTML 1.0 Strict.

Not sure ’bout this trend yet.

Aug 29, 2010

Jens Scherbl says:

You’ve written down exactly what I’ve been thinking since I started learning about and using HTML5.

To give an example of what I’ve been through – Facebook’s Open Graph and social widgets are based on XML namespaces, so it’s nearly impossible to use it while still trying to maintain valid HTML5 markup.

Same for other techniques relying on XML namespaces.

Using XHTML5 (properly served with content-type text/xml) is also not an option as long as some widely used wannabe-browsers can’t handle it.

Aug 30, 2010

Len says:

Yep, that all sounds sensible to me.

The other benefit to writing (x)HTML is you will look more professional to your colleagues, even if your a relative n00b like me.

Aug 30, 2010

Kenny says:

Hi

I certainly will be using the XML syntax because I like clean code over messy code. Not saying that I’ll never make a mistake, but I want to make the effort.

I do find it a bit regrettable that HTML5 allows you to write “dirty” code. I know people already do it and that it will be rendered, but I think that the strictness of XHTML convinces some of the doubters to write clean code.

So I’d prefer a stricter form of HTML, reducing the amount of dirty coded documents, even though eliminating all dirty code is impossible.

Aug 30, 2010

Exionyte says:

Hi,

HTML 5 is the way forward there might be a couple of cons but you will have to accept it.
Although I won’t let XHTML strict go very easily!

Aug 31, 2010

Dayle Rees says:

I feel exactly the same way, since XHTML, mark up has started to look beautiful again, easier to read, and tends to validate a lot more, due to the strictness.

HTML5′s “whatever goes” approach seems a little like a step back to me too, I am glad I’m not alone here.

Sep 1, 2010

Sunny Singh says:

I had the same thought process as you about HTML5 when I first heard about its openness. I was always the XHTML FTW type guy that just loved the clean markup it produces, but didn’t realize that perhaps HTML5 is that way to be inclusive, rather than exclusive. I’m totally with you about (x)HTML5 and will continue writing code as I always have yet embracing the new features.

Some things are starting to get a bit fuzzy though. For form attributes like “disabled”, it seems odd to have to declare it twice.

For example:
<input disabled=”disabled” />

HTML5 lets you simply leave it as just the attribute, which actually does look cleaner to me, yet invalid. I wish we could change the value to “true” and have it still work. I think this is one major mistake in HTML in general.

Sep 1, 2010

Benjamin Charity says:

I couldn’t agree more. XHTML is beautiful compared to non-XHTML (in my opinion). You couldn’t pay me to go back.

Sep 6, 2010

Sam says:

Everyone snubbed their nose up before XHTML came out. We have to run with HTML5 and embrace all the great features it has

Leave a Comment

Links

  1. CSS Brigit | Considering an (x)HTML5 Methodology

Top Commenters

Thanks so much to these awesome people for joining in on the discussion!

Copyright © Echo Enduring Media 2009-2014