Design Principles, Section 1.6.1 relationship to HTML 4.01

(May not be able to reply to responses in June unless urgent)

I do not doubt that the working group started "from scratch", and I do
not propose starting over "from HTML4". At least within this working group,
there is a clear desire to finish the current document and publish it
quickly, and I (HONESTLY) am *not* trying to interfere with that.

On the other hand, I think the document produced should honestly 
and openly say what actually happened, who was represented, the
scope of applicability, in the abstract and intro front matter, in the
"Design Principles" published, etc.

Since the actions are not hidden and the origin of decisions are
actually clear and public, some attention to resolving incongruities
between these statements should not be so difficult.

Yes, the charter says the goal was to "evolve" the document from
HTML4. I think it is the obligation of the working group, in the
documents it publishes, to say that (and why) this path wasn't
actually followed, and give at least some summary of the reasons
and the actual path taken.

Right now, "1.6.1 Relationship to HTML 4.01 and DOM2 HTML"

> This specification represents a new version of HTML4, along with a
> new version of the associated DOM2 HTML API. Migration from HTML4
> to the format and APIs described in this specification should 
> in most cases be straightforward, as care has been taken to ensure
> that backwards-compatibility is retained. [HTML4]

While you might want to argue under some legalism that a document
constructed "from scratch" was  "a new version of HTML4", I don't
see how that statement ever got into the document in the first
place, and would formally object to publication of documents that
continue this misrepresentation.

"This section is non-normative" is not a cover for "This section
can also be misleading or untrue". Just tell the truth -- everyone
here knows it, people not in the working group who read the document
should too.

Similarly, the current Design Principles document, as written,
makes statements that I believe are untrue. I would formally
object to publishing a Working Group Note which contained statements
I think are untrue.

I have suggested two possible directions, one of which is
quite easy:

* Change the abstract on the current document
  in a way that the description of the historical application 
  of the design principles isn't misleading:
   http://lists.w3.org/Archives/Public/public-html/2009May/0303.html

and another which is more difficult and not (in my opinion)
an effective use of working group time and attention:

* Fix the Design Principles to be more useful and come to
  consensus on them:

  http://lists.w3.org/Archives/Public/public-html/2009May/0359.html

Regards,

Larry
--
http://larry.masinter.net


-----Original Message-----
From: public-html-request@w3.org [mailto:public-html-request@w3.org] On Behalf Of Ian Hickson
Sent: Saturday, May 30, 2009 2:34 AM
To: Leif Halvard Silli
Cc: HTML WG
Subject: Re: Design Principles

On Fri, 29 May 2009, Leif Halvard Silli wrote:
> Ian Hickson On 09-05-27 04.12:
> > 
> > The HTML4 spec, however, only bears a vague resemblence to the syntax, 
> > elements, attributes, DOM APIs, and other aspects of what is generally 
> > known as HTML as implemented today and contemporary to Acid2 and 
> > Acid3, even though the HTML4 specification presumes to define what 
> > that is.
> 
> Vague resemblance when it comes to syntax, elements, attributes?

When it comes to pretty much everything, yes.


> > > If HTML 4 is silent about something, then there is no reality to 
> > > differ from.
> > 
> > HTML4 is silent about much, but it isn't silent about everything. What 
> > it is not silent about is usually wrong (e.g. saying browsers must not 
> > have a default encoding, whatever that means, or saying that all 
> > browsers, even speech synthesisers, must render quote marks around <q> 
> > elements, or saying that the default media="" is "screen", or saying 
> > that parsing should be done using SGML, or...).
> 
> But this is pretty low fruit. Obvious bugs.

I don't disagree that many of these problems are pathetically simple to 
fix, yes. I don't really see that that makes much difference, though.

When one wants to make a big thick blanket with yellow dots, if one has a 
white handkerchief, one could start with the handkerchief, and add cloth 
around it, and sew dots onto it, and so on, or, one could start with a 
large piece of whole cloth and just not worry about trying to adapt the 
handkerchief into the big blanket.

It's far easier in such a case to start with whole cloth.

But again, if anyone wants to try starting with HTML4, I encourage them to 
do so. There is no need to take my word for it. I'm just describing what I 
(and others at the time, and maybe still now) felt was the best course of 
action. I certainly don't intend to start over now myself.


> > > > > The high deployment of HTML that you talk about includes a lot 
> > > > > of XHTML.
> > > 
> > > Those 15% can at least not be counted as "HTML 4 as she are spoke". 
> > > Perhaps we could call it "XHTML treated as HTML 4 are spoke".
> > 
> > I don't understand the relevance of this line of argumentation.
> > 
> > In practice it doesn't matter what the DOCTYPE is; it has little 
> > bearing on which specification the rest of the document more closely 
> > follows, and it has no bearing (beyond quirks mode detection) on what 
> > the browsers do with the content.
> 
> As you know, many have been switching to XHTML - consciously, albeit 
> perhaps in incomplete ways.  It is true that many mix the syntaxes - 
> _both directions_.  I agree that the "HTML 4" parsing of XHTML is 
> "winning". But I don't find it fair to count XHTML in text/html as HTML 
> 4 no matter how much you try to diminish it.

I don't really understand the relevance of this, so I don't have any 
reason to argue this particular point further.


> > > Or do you mean that deployed HTML 4 contradicts the specified HTML 
> > > 4?
> > 
> > Yes, this certainly happens a lot.
> 
> Examples that are not obvious bugs?

Section 16.2, third paragraph, the blanket statement is incorrect for 
<script> elements; doing so will not cause the frameset to be ignored.


> > It's not anywhere near as big a problem as the near-complete lack of 
> > conformance criteria in HTML4, though, or the extreme vagueness of the 
> > semantics defined in HTML4.
> 
> (Not so important, but examples of "extreme vagueness of the 
> semantics"?)

HTML4 doesn't define what a section is, so it isn't clear which headings 
apply to which elements, e.g. in the following example:

   ...
   <body>
    <p>A</p>
    <h1>B</h1>
    <p>C</p>
    <div>
     <h2>D</h2>
     <p>E</p>
    </div>
    <p>F</p>
    <h1>G</h1>
    <p>H</p>
   </body>

...what is the heading that applies to each of A through H? What is the 
resulting document outline?

(I am pretty sure I can literally pick _any_ section in the HTML4 spec and 
find examples of errors or vagueness.)


> > > I cannot see how one can talk about deployment without reference to 
> > > specification.
> > 
> > The Win32 API has huge deployment numbers, but no formal 
> > specification.
> > 
> > On the Web, the XMLHttpRequest object was deployed and widely used 
> > long before it had a specification of any kind.
> 
> (OK. But since HTML 4 has a spec, it was more valid.)

I have no idea what that means.


> I understand that you also wanted to have a say on the semantics and 
> over all structure/vocabulary, though. But in an ideal process, the UA 
> side and the vocabulary side should have had two different editors that 
> were trumping each others. ;-) The "browser editor" could tell the 
> "vocabulary editor" about "the costs" of having one feature too much. 
> But at least it would be up to the "vocabulary editor" to make the right 
> choices within the frame that he "browser editor" gave.

I don't know if I agree that that would be a productive way of developing 
a spec, but I can certainly agree that in an ideal world there would be 
many more specification editors. I've been looking for more editors for 
literally years with minimal success (less than half a dozen people have 
started working on specifications related to HTML5 since we started 
working on HTML5, and none of them are working on this full-time).

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Saturday, 30 May 2009 18:40:05 UTC