Re: Design Principles, Section 1.6.1 relationship to HTML 4.01

On May 30, 2009, at 11:39 AM, Larry Masinter wrote:

>
>
> 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.

Can you be specific about which statements you believe are untrue?  
Just a succinct list of specific untrue statements with an explanation  
of why you think they are untrue. I'd want to fix anything that is  
factually inaccurate. Note that publication as a Note is not imminent;  
at least one more Working Draft is planned.

I couldn't readily find any reports of false statements in your linked  
email below.

>
> 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 23:35:25 UTC