Category Archives: HTML5

Communities

Leave a reply

This year’s Balisage conference is over and I miss it. I miss the people and I miss the talks, but above all, I miss the sense of community.

See, this year’s Balisage was all about communities and the softer values of markup. Don’t get me wrong; there were some great talks on markup theory (overlap, anyone?) and how to make JavaScript into something tolerable in a markup context. But above all, there were numerous talks on communities and on what we do and on how we regard our profession.

Steven Pemberton (who held the mic on no less than four occasions) delivered a brilliant talk on the virtues of declarative markup while killing off HTML5, once and for all.

Mary Holstege discussed the metaphors we code by, and how it’s easy to take those metaphors too far. I chose my words very carefully for the rest of the conference.

Bethan Tovey and Norman Walsh invited us all to rediscover our passion for declarative markup with Markup Declaration, a call for arms to unite the community and to find XML and its kin a new home.

Allen Renear discussed the ethics of XML (really!), and I am unable to do that talk justice here. You should have been there.

Abel Braaksma gave us a tour of the declarative (and functional) programming paradigm, and my only complaint is that he should have been allowed at least twice the time to do the topic justice.

And there was yours truly who discussed the virtues of style guides, that perfect complement to schemas and validation.

The list goes on. I can’t possibly mention everyone here, but I could have mentioned at least as many more talks, every one of them every bit as good as those mentioned above.

Balisage, more than anything else, was about the community we inhabit and participate in, and how we all stand a better chance united. It’s not about just SGML or XML, even though both are important; it’s about declarative markup and our chosen field. It’s about all those standards starting with X but also quite a few that do not, and the power offered to us by semantics, and it’s about us all acknowledging each other’s work. And yes, it’s also about JSON and Markdown, and a whole bunch of other things that we may or may not approve of.

So, from one addict to a bunch of other addicts: I miss you.

P.S. You should all look up Developing SGML DTDs. Yes, there was also a book discussion.

On Reflection

Leave a reply

Having reread my recent post on HTML5, I suppose I’d better stress the fact that it was never meant to be a commentary on HTML5 itself. It was a rant, something that happened because of the attitudes I think have increased in tandem with HTML5’s growing popularity. I really don’t know enough HTML5 to have an informed opinion beyond what I see suggested and discussed about it that is related to markup in general. My comments should be read in that light.

Take the addition of document semantics in HTML5 as a case in point. For example, the article and section tags are welcomed additions, as are, in my humble opinion, the fairly minor redefinitions of the em and strong semantics. And there’s some important work being done in the area of extensible semantics for the web (see, for example, Robin Berjon’s XML Prague paper, Distributed Extensibility: Finally Done Right? and the Web Components web page on best practices), which turned out to be a heated topic at Balisage this year because quite a few of its participants are, like me, grumpy old men defending their own turf.

These are steps in the right direction, because they move away from the presentational horror that is the “old” HTML and to a more semantic web. Semantics is about meaning, and meaning is now being added to the web rather than simply empty but oh-so-cool visuals. I should add that some very cool visuals are being added, too, but in, and please pardon the joke, a meaningful way.

But, and maybe this is just me, it’s when those steps are being heralded as original and unique, never thought of before or at least never done right, when history and past (and working) solutions are ignored or misinterpreted because they are part of a standard (XML or even SGML) that is regarded as failed, when I react. Google’s Dominic Denicola provided a case in point when he held a controversial presentation on the subject called Non-Extensible Markup Language at Balisage; unfortunately, only the abstract seems to be available at their website.

That grumpy old men thing, above, is meant as a joke, of course, but I imagine there to be some truth in it. Part of the HTML5 crowd will certainly see it that way because they are trying to solve a very practical problem using a very pragmatic standard. HTML5 is, in part, about keeping old things working while adding new features, and it seems to do the job well. Having to listen to some older markup geeks argue about what XML was actually designed to do must seem to be as being utterly beside the point.

So, what to do? Well, I think it’s largely about education, both for the newer guys to read up on the historical stuff, and the older guys to try to understand why HTML5 is happening the way it is, and then attempting to meet halfway because I’m pretty sure it will benefit both.

Me, I’m in the midst of the reading up phase, and HTML5 – The Missing Manual is an important part of that.

Reading Up On HTML5 – A Rant

Leave a reply

I’ve been reading up on HTML5 lately, feeling that I should brush up my web development skills before I attempt an upgrade of a personal web page. Every other web page these days seems to be taking its design cues from some for me yet unknown source and I figured HTML5 is probably the place to look.

I’ve come across it before, of course, both in my day-to-day work and at markup conferences. We’ve been doing various web solutions and mobile apps involving HTML5 for some time now, and this year’s Balisage, to pick the most recent markup conference I’ve attended, started with a one-day symposium on HTML5 which was both interesting and illuminating. There’s a lot of it going on, right now.

And the other day, I came across HTML5 – The Missing Manual and have been reading it on and off since. It seems to be quite comprehensive and more or less what I need right now, but it is not a book primarily written for markup geeks. Don’t get me wrong; it is well written, as are all of the Missing Manuals I’ve read, and it seems to do a reasonably good job explaining its subject.

But–and there’s always a but, isn’t there?–there’s stuff in that book that makes me cringe. Or rather, it’s not the book itself but what the book represents. See, the book seems to define that moment in time when I am no longer able to selectively ignore the HTML5 crowd.

There are a couple of terminology issues, of which the most annoying to me right now is that empty elements are apparently called void elements these days. This is not the author doing a reinterpretation of anything, this is the W3C working group talking–I just checked–but it is a symptom of what I am talking about here.

Another symptom, and one known to everyone who’s done any web-related markup since the inception of the web, is how markup errors are frequently shrugged at. Nesting errors are the most glaring, of course, and the way they are ignored is to say that everybody does them but the browsers can all handle them, so while you may decide to be anal and actually validate your HTML, the message between the lines is that it’s OK and you shouldn’t worry about it since the browsers can handle it.

Coupled with this lax attitude towards draconian error handling (actually any error handling that is not related to browser-based limitations) in the book is the not-so-subtle hint that this is all the fault of the oh-so-obviously failed XHTML attempt from a few years back, when W3C tried to introduce XML syntax rather than fix HTML.

And there are the usual mentions of missing end tags (but no recognition of the fact that this was actually an SGML feature, once upon a time) and how that’s really not such a bad thing after all because modern browsers can handle it, and the closely related ignorance towards empty (sorry, void) element syntax. It’s OK, no need to be anal about it, because modern browsers can handle it. It’s a question of style.

The HTML DOCTYPE declaration is explained, of course, and its lack of any kind of versioning indicators, SYSTEM or PUBLIC identifiers, etc, declared to be a good thing. Again, the motivations are browser-based and basically about doing it in this way because the browsers can handle it. The DOCTYPE declaration’s existence is only important because of legacy reasons.

And the whole concept of well-formedness is explained as a matter of good style but really not much more than that (since yes, the browsers can handle it), and the benefit mainly the ability to include a couple of attributes in the root element.

And on and on it goes.

I don’t mean to say that HTML5 is a bad set of standards–I know far too little about it to have an informed opinion–but much of the attitude I’m seeing in the wonderful world of HTML5, both now in this book and earlier in the various presentations and discussions I’ve witnessed or been a part of, seems both frivolous and dangerous. It seems to me to be a combination of reinventing the wheel and ignoring the lessons learned by others, and I can’t help wondering what damage it will do to other markup technologies.

The Balisage symposium from earlier this year did give me hope–the people present were both smart and reasonable, more than willing to listen and learn from each other, and the discussion that ensued was informative and balanced–but most people do not go to Balisage, or any other markup conference, for that matter. They learn by doing, and some by reading, and quite a few sources now are like HTML5 – The Missing Manual, well written, comprehensive–and potentially dangerous to anyone with no experience of markup technologies outside their immediate needs, because they reinvent, reinterpret and redefine what they need and ignore everything else.

The result, I fear, is a more complex situation than ever in the world of markup, a situation where different sets of standards apply depending on the context and where XML, while sorely needed by some parts of the community, is ignored by others.

End of rant. Thanks for reading.