FWD: Web standards for the ordinary person

From the list mom, a very well spoken man.

———- Forwarded message ———-
From: [wd] List Mom
Date: Wed, Aug 6, 2008 at 12:40

on Wed, Aug 06, 2008 at 03:28:36PM +0100, Peter Bowyer wrote:
> At 14:56 06/08/2008, Bob Meetin wrote:
> >Ultimately as already noted your client is your master.  You can educate but you can’t make them care.
>
> Doesn’t this make a mockery of standards? In my book a standard is like a physical law: applied globally without exception. Maybe talk
> of standards is misleading and guidelines would be more accurate. TCP/IP is a protocol standard, because things break if it’s not
> followed. HTML isn’t.

    “Ah, but a man’s reach should exceed his grasp, or what’s a heaven for?” — Robert Browning

There are standards, and there are standards. While it’s wonderful to think of things in terms of their exact mathematical or formal descriptions, the relative importance of their various boundaries and limits varies widely. Paper is a good example – whether US Letter or A4, paper is used in many contexts where precision is expected, such as printers, and in some where it’s more a guideline, like file folders, and in some where it’s not, like the shopping list in your pocket.

Software is expected to have a high degree of conformance to syntactical correctness, enforced by the compiler, because randomness makes software really weird and unpredictable, but you can compile code that has bugs and that fails to implement the features you want.

Various organizations exist that codify the standards by which their industries (and, by extension, anyone peripherally involved) conform to expectations of similarity. Whether it’s the diameter, sheathing, and quality of household wiring, or the size and shape and quality of the nuts and bolts in your engine, or the protocols by which your mail and Web surfing are managed, these standards can be exacting or vague. There is a reason why the people who built the Internet commonly refer to
Postel’s Law (or, as I prefer to call it, Robustness Principle):
    “Be liberal in what you accept, and conservative in what you send”

It’s a way of recognizing and allowing for differences in interpretation, implementation, and errors introduced in transit.

While I do believe that Web standards are important – as anyone who’s watched me over the past dozen or so years will attest – and I happen to personally believe that validation of markup and styles is pretty much THE most important first step in troubleshooting a Web page, I can also see that the Web, historically, has been a pretty slack place.

I remember in 1995 when Netscape fixed their parsing engine in Navigator so that attributes lacking a close quote were suddenly treated as broken:
    <a href=”http://slack.no.longer.works.here.net>click ME!</a>

I laughed at how many sites had gotten away with such sloppy markup. I’d spent the previous few months trying desperately to train my team to be meticulous and consistent, because I knew syntax mattered, and because I knew the HTML editors of the day basically sucked. So we did hand coding for years, until the editors finally caught up.

But on the other hand, that the link above doesn’t work (and in that version of NN, excluded all content until the next double quote) is very, very wrong. If a parser can read broken HTML and recognize such brokenness, it should fix it on the fly. And that’s what most HTML parsers and rendering engines do, and it’s what they’ve always done. It’s what the Church of the SubGenius says we all want: “slack”.

I came of age in the SGML era, using tools that were much less forgiving, to tag and edit documents that I assumed had much greater importance than your average Web page – parts lists and maintenance manuals for airplanes and nuclear submarines and the like. Our editor, SoftQuad’s Author/Editor, simply failed to open in “pretty” mode (where the tags were all delimited with chewy GUI goodness) if the document it was opening failed to validate against the DTD.

You can see the “pretty” mode here, in a descendant of A/E called XMetal:
 

If we failed to produce valid markup, all we’d see was something like a stream of raw markup. So, that did a lot to enforce the sense that syntax mattered, and I carried that through to working with HTML – even though Web browsers have never (with a few exceptions, like maybe Opera and the old Arena browser) had anything remotely resembling that sort of enforced strictness.

It’s worth remembering, too, that early HTML, while it certainly laid a sly finger aside its nose and winked at SGML, didn’t even have a DTD until several years in, thanks to Dave Raggett. And that DTD was so loose as to be almost no DTD at all. We had HTML 3, which literally *nobody* adopted, and then later we had three flavors of HTML4, one even named “loose”, we’ve seen editions of XHTML that are little more than Murray Altheim playing around with different ways to structure DTDs.

Standards – the name being a misnomer for Web stuff, anyway, which the W3C prefers we think of as “Recommendations” – are only as effective as their adoption and observance. And to confuse them with physical laws is to mistake the map for the territory.

So, we’re in the unfortunate situation of having standards that are not properly so-called (though there is an early version of HTML that was an IETF standard), that are processed by software that comes from a rich tradition of helpfully ignoring syntactical correctness, and an even richer tradition of really bad markup practices. On the bright side, some folks figured out early on that CSS was a better way to style their documents, and that good CSS and bad markup was a recipe for a life spent troubleshooting. Once the browsers had caught up, we spent years waiting for the editors.

So, think of “Web standards” as a mindset, as a goal, as a guide.
> I started on this list in 2001. We talk about standards less these days and more web designers use CSS layouts, but overall have we made
> any progress? I don’t believe so. Standards were nothing more than a distraction – the majority of companies that got on and created
> successful sites were pragmatic about their use.

We’ve made substantial progress since the old days. Don’t forget the Browser Wars. Incompatible DOMs, in many cases incompatible embedding markup, differing rendering cross-browser, and so forth. But I think perhaps the most important thing we’ve realized is that there’s no such thing as a perfect reference rendering – we’re all hermeneuts here, dealing with layers and layers of interpretation.

Some people aren’t really cut out for markup. That’s why we have editors. Some people can’t get past the idea that if they can write it up in Word and print it, it looks “the same” (itself a relatively recent expectation), so why can’t the Web? They’re the hardest to deal with, because they’re not dealing in reality, they’re dealing in expectations – unreasonable and pointless, but stubborn.

Like Don Draper from Mad Men says, “Listen, I’m not here to tell you about Jesus. You already know about Jesus. Either he lives in your heart or he doesn’t.” It’s the same way with people for whom the Web and HTML is just a vehicle, a tool, and for whom the arcana of their own jobs is far more interesting and important. You’re not going to be able to convince them that the Caio Hack is something they should care about at all. Ever.

You may be able to give them a basic training in markup, if they have budget and/or patience. You’ll probably be able to show them that when they screw up the syntax, they screw up the presentation – in fact, this is probably a powerful way to get the message across. B
ut you’re not going to be able to convince them that “tables for layout are bad”, or any of the other issues that drive more towards observance of the “mindset” than of the core formalisms of HTML.

Why not? Because they don’t have the negative experiences with tables that you probably do. They don’t know the pain of manually debugging a three column layout. They don’t know anything about how many levels of nested tables it takes to give Navigator 4 an aneurism. They have never had to go in after someone less skilled and figure out which of the nested tables is missing a </table>. And that’s okay.

Kids these days. 🙂


hesketh.com/inc. v: +1(919)834-2552 f: +1(919)747-9073 w: http://hesketh.com/
antispam news, solutions for sendmail, exim, postfix: http://enemieslist.com/
+———————————————————————-+
 more info about webdesign-l: http://webdesign-L.com/

– Randall Noval
Advertisements

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 )

Twitter picture

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

Facebook photo

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

Google+ photo

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

Connecting to %s