Re: HTML5: The Markup Language - section 5 suggestions

Hello,

this looks like another promising attempt with some more structure:
http://dev.w3.org/html5/html-author/
But I don't know, if this is continued.

However, I think for the majority of authors it will be
confusing to have three or more notes/recommendations/drafts
intended for authors about the same issue, how to write
HTML5 documents - could be useful to join together these
efforts to only document, the vast majority of authors can
simply follow, as available for HTML4 (I always missed this
for XHTML, maybe many other authors too, could be one
reason for some problems of this variant).

Such a single W3C document with a clear structure, that explains, 
how to write a HTML5 document and which elements to use
for which purpose in a proper way could be pretty useful for many
authors. More than one document for authors for the variant HTML5
might be confusing, because it is not simple for authors to identify,
which of them is relevant for them (as the complete draft is confusing,
because it contains so many things completely irrelevant for authors
of proper documents).

An alphabetical order of element names is mainly useful for
those authors, who are already familiar with the language or
the language version to find some details, but not a big help 
for those, who are trying to markup a specific structure and
looking for proper elements for it. 
Therefore if http://dev.w3.org/html5/spec-author-view/
is intended for authors and 
http://dev.w3.org/html5/html-author/ with a similar
structure, what is the purpose of http://dev.w3.org/html5/markup/ ?
Mainly only a look-up table?
But how does this fit to the abstract:
'
This document describes the HTML markup language and provides details 
necessary for producers of HTML content to create documents that conform to 
the language. By design, it does not define related APIs nor attempt to 
specify how consumers of HTML content are meant to process documents.
'
?
For a look-up table the abstract should indicate, that it is mainly such 
a look-up table for authors, who already know how to create documents
in this HTML variant and are searching just for details, but not for a
general idea.

Because in the current drafts there is no version indication, I still do 
not know with all these drafts, how to write a HTML5 document at all - 
one, that indicates, that is is HTML5, not just one, that may be 
interpreted as HTML5 or any other dialect, because it does not indicate, 
what it is ;o)
After the version indication question is solved, this will be a pretty
important task for such a document relevant for authors as well.

About:
>> I think, this needs some more
>> careful exploration, what is new and what is changed
>> compared to what (recommendation HTML4.01? XHTML1.0? 
>> XHTML1.1? XHTML+RDFa?)

>I have so far not attempted to have the H:TML document
>exhaustively list all the changes since the previous major update
>of the HTML language. For one thing, we do already have a document
>that does a very good job of that -- the "HTML5 differences from
>HTML4" document:

The idea was only to indicate in one sentence, what the keywords
'NEW' or 'CHANGED' mean in the context of the list. Obviously
they have a meaning, one can guess approximately (and even 
better after the addition of the missing keywords). But something
like 'The keywords "new" or "changed" indicate major changes compared to 
HTML4.01 (?) as detailled in http://dev.w3.org/html5/html4-differences/  '
would be already a big help for readers of the document and authors.
If such keywords have no meaning, that is worth to be noted in the
document, they can be removed completely. There will be always
automatically the question: new or changed compared to what?
Just because the meaning of those keywords implicate that the noted
issues have some relation to something, that can be called 'old'. 

Usability is often not subjective, it is often mainly a question to provide
information at all and at the right place or to reference to other documents
with more details. Of course, usability depends on the use case too, but this
is indicated already in the abstract or the title of the document ;o)

Olaf

Received on Tuesday, 2 March 2010 11:30:52 UTC