W3C home > Mailing lists > Public > public-html@w3.org > May 2009

Re: Design Principles

From: Leif Halvard Silli <lhs@malform.no>
Date: Fri, 29 May 2009 03:35:35 +0200
Message-ID: <4A1F3BE7.2030903@malform.no>
To: Ian Hickson <ian@hixie.ch>
CC: HTML WG <public-html@w3.org>
Ian Hickson On 09-05-27 04.12:
> On Wed, 27 May 2009, Leif Halvard Silli wrote:

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

> (Indeed, refering

Are you using HTTP spelling? ;-)

  to "HTML4" in this way is exactly what I did in the
> interview, using the version number of the spec to indicate the general 
> era and area of technology to which I was referring.)

Well, then perhaps we understand each others at this point.

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

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

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

> 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 

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

> It is quite possible to have deployed technology without a specification. 
> It is a sad state of affairs, though, and one which, for HTML and related 
> APIs, I have spent many years attempting to redress with HTML5 and its 
> related specifications.

And it has been inspiring and interesting to learn about many of 
the absurdities that you, Anne and others have blogged about ...

But I suppose that (some of) those group members that have been 
hinting that the title of the spec should have a (sub)title that 
said something like "for Web browsers" are also hinting which side 
of the development they have most satisfied with. (And most 
difficult to understand.) Or you could say they are telling what 
side they are most interested in having a say over.

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.
leif halvard silli
Received on Friday, 29 May 2009 01:36:14 UTC

This archive was generated by hypermail 2.4.0 : Saturday, 9 October 2021 18:44:47 UTC