Re: minor copy edits needed in HTML 5 draft

I'm surprised that after all the work put into other aspects of HTML 5, 
someone who claims to appreciate clear, concise, formal technical 
specifications would ask why the draft's cavalier attitude of "sometimes when 
we say X we mean Y, except when we mean Z" matters.

As an implementer, application developer, data architect, and writer, it has 
been my experience that carelessness with terminology in a spec such as this 
often leads to varying interpretations & expectations and disparate 
implementations. I've pored over dozens of specs in excruciating detail [1]
to implement and/or document them, and have encountered numerous instances of 
"close enough" terminology having irritating, progress-impeding consequences. 
Little details someone thought inconsequential if left open to interpretation 
in 1993 became entrenched, irreversible idiosynchrasies of the technology by 
1998. XPath, XSLT, and DOM edge-case references I thought were mere nuance in 
2000 became critical to how I went about coding an implementation in 2004. 
Sure, maybe the examples I gave for the HTML 5 draft will indeed prove to be 
inconsequential, but I thought you'd appreciate the attention to detail, even 
if you don't agree about the potential for confusion.

I've found that even the hobby of curating a Wikipedia article like the one on 
HTML (the history section of which I've just expanded again) has been arduous 
because of ambiguities in the status of the specs -- the "HTML is dead, long 
live XHTML: the latest HTML version" evangelists had to be beaten down with 
copious citations pointing out that HTML 3.2, 4.0, and 4.01 are all still in 
force and retaining much traction. I'm definitely not looking forward to the 
fight over the possible interpretations and ramifications of the HTML 5 
draft's intent to "replace" / be "the latest version of" HTML 4.x, XHTML 1.x, 
and DOM Level 2 HTML, all of which have a far greater scope than the HTML 5 
draft, not to mention can't really be superseded in quite the sweeping way 
that's implied.

Besides, the comments from a "fresh pair of eyes" looking at your spec for the 
first time should be welcomed. Concerns, even trivial ones, should be 
addressed in the spirit of "the fact that someone barely got into reading the 
spec and got hung up on that issue indicates the topic may need to be better 
explained, even if the suggested fix wasn't much of an improvement." As more 
people learn about, review, and send their feedback about the draft to the 
working group, you are going to have to deal with this kind of thing more and 
more often.

Mike


[1] ...though not ECMAScript, hence my assumption that "[[Get]]" was an
    accidental artifact of editing.

Received on Monday, 18 June 2007 04:19:08 UTC