Re: Rethinking HTML 5

Sander Tekelenburg wrote:
> 
> Sorry, but I don't believe for one moment that that will actually work. If we
> want to see more conforming documents out there, the spec will have to be
> made as easy to understand for authors (and authoring tool vendors!) as

For authors, that is never going to be possible for a useful standard. 
Ordinary people don't read raw standards documents in any field of 
endeavour, in the same way as only lawyers read raw legislation.  The 
documents need to be written precisely, but general book trade consumers 
want books which allow them to pretend that they fully understand at 
first sight; they are sold on the instant gratification principle.  They 
also tend to prefer a cook book style, from which canned examples can be 
used without understanding them (in fact, most authors seem to use other 
web pages as their cook books).  Actually, with real cookeru books, it 
is quite difficult to find domestic science text books, rather than 
recipe catalogues.

Unfortunately, with authoring tools, managers only think they need to 
know what the market wants, and coders are employed on their ability to 
meet time and budget (and to trick their development tools into 
following the marketing department's whims).  You can see this for much 
simpler standards, like email, whose original standards where written in 
a rather less formal way.  There are many examples where GUI email 
program's have clearly been written by people who never read the 
standards, but one example might be the excessive use of "'s around the 
human readable parts of addresses.  RFC 822 emails were supposed to be 
as close to being in the form of paper memos as possible.

In fact, with the IETF standards, you can see that the result of 
commercial developers becoming involved has been that the standards now 
have to be written in much more formal language, and therefore much more 
difficult for end user to understand.  That's because the commercial 
developers only implement the letter, not the spirit.

> possible. The past has shown that leaving that up to third-parties is a very,
> very bad idea: authors will not find the 1 decent tutorial inbetween the
> 1000s of nonsensical ones.

I'd agree that much in the book shops is written by people who see a 
market, but do not understand what they are writing about.  I suspect 
many have not read the standards themselves, and most probably don't 
frequent lists, like this.

> I'm not sure yet *how* to best solve this. I think as a WG we should consider
> ourselves obligated to provide a really good tutorial with the spec (to be
> written and published synchronous, not as an afterthought). But given that

Tutorials, written by the specification authors, would probably help 
undermine the me-too "made trivial" (hope that isn't a trademark) book 
industry, but they cannot be written in parallel, because the authors 
will be too close to the changing thoughts on the content of the 
standard.  There is also a risk that the author will have had a 
particular axe to grind.  Where there are only one or two authors, like 
for K & R C or for C++, that may not be so much of a problem.

There is also a very real danger that people will only read the 
tutorial, and therefore fail to grasp the underlying principles.

> the spec itself will be the normative document, it too will have to be as
> understandable as possible for all intended audiences.

The problem is that specifications have to be precise and have to define 
the boundaries of their scope.  That's what really makes them difficult 
to read.  Given a specification that appears to be easy to read, you 
will often find that there are lots of unanswered questions.  Computer 
API documentation is particularly bad in this respect.  If you compare 
vendor man pages with the X/Open documents, you will see the latter has 
to define a lot more to properly characterise the interfaces.

> from the experience of authors finding previous HTML specs way too hard to
> read.

Although it is difficult to track down, the HTML 1.0 specification was 
fairly easy to understand.  The problem was that you couldn't build a 
business based on a text only tool which, as a deliberate choice, didn't 
have any rich presentational characteristics.  In an early paper, TBL 
says that colour has no place in HTML.  Most of the current complexity 
comes from commercialisation and the resulting presentationalisation of 
HTML.

The original HTML concept was that the language would be very simple, 
and consequently the specification could be simple.  (It deliberately 
did not support anything like the GUI capabilities of the day, so those 
people who play the "progress" card for adding those back are actually 
asking for HTML to go backwards, not forwards!)

Incidentally, I think that one of WHATWG's main objections to HTML 4.01 
is that it isn't tightly enough specified, and relies too much on common 
sense and an understanding of the spirit in which HTML was originally 
conceived.  I think they want a much more formally, and therefore 
difficult to read, document.

Received on Sunday, 6 May 2007 09:29:33 UTC