Re: HTML is a declarative mark-up language

On Jan 29, 2009, at 11:46, Leif Halvard Silli wrote:

> Henri Sivonen 2009-01-29 09.05:
>> On Jan 29, 2009, at 03:47, Roy T. Fielding wrote:
>>> On Jan 28, 2009, at 2:11 PM, Ian Hickson wrote:
>>>> On Wed, 28 Jan 2009, Roy T. Fielding wrote:
>      [...]
>>>>> There is considerable  value in defining what is valid HTML
>>>>> for both what-goes-over-the-wire and what gets rendered on a  
>>>>> browser.
>>>>
>>>> You've said this before, but you never replied to the last e-mail  
>>>> I sent
>>>> on the thread trying to work out what made you believe this:
>>>>
>>>>  http://lists.w3.org/Archives/Public/public-html/2008Nov/0420.html
>
> Yeah, what is it that make some "*believe*" that there would be  
> considerable value in defining what is a valid HTML ...?
>
>>> I didn't reply to it because there seemed no point.  You say that it
>>> doesn't require DOM, CSS, or scripting, yet the entire spec is
>>> defined in terms of the effect on DOM, the impact of CSS, and the
>>> behavior of scripting.  If you try to read the spec from the  
>>> perspective
>>> of someone whose implementation does not have a DOM, for whom CSS
>>> is an entirely orthogonal concept because there is no rendering or
>>> presentation being implemented, and for which scripting is  
>>> irrelevant,
>>> then I think you will discover that HTML5 as currently drafted  
>>> doesn't
>>> even define the base mark-up.  That is not an unusual perspective.
>> I have tried this, and what I discovered was different from what  
>> you say you think one would discover.
>
> So, in your view it does "define the base mark-up"?

In my view, "HTML 5" defines HTML5 markup. I'm assuming "base markup"  
is a subset of all of HTML5 markup, so yes.

> 30 minutes after this letter you wrote about the draft that "(It  
> isn't optimized for developing a validator, either, but it seems  
> pretty obvious that optimizing it for validator developers wouldn't  
> be a good use of the WG's resources.)"

Right. I think "HTML 5" with its (currently implied) normative  
references defines the things about HTML5 that a validator developer  
needs to know, but the spec is not optimized for this purpose and  
doesn't need to be.

> And may be the spec doesn't need to be optimised for HTML guide  
> authors either.

I think "HTML 5" doesn't need to be optimized for guide authors,  
either. I think it is suitable for reading by HTML guide authors as it  
is.

> The amusing thing is that in all its "we built HTML 5 from scratch",  
> because of all the things it doesn't define, it is very dependent on  
> the past.

What kind of things do you mean?

>> I develop an HTML5 consumer that doesn't have a DOM (or any other  
>> tree data structure for representing the document tree), doesn't  
>> have a style system (CSS or other) and doesn't run scripts. The  
>> consumer I develop is an HTML5 validator and, as such, has  
>> everything to do with "base markup". Yet, I'm quite able to extract  
>> the information I need from the HTML 5 spec.
>
> So you are not under the "belief" that there is "considerable value  
> in defining what is a valid HTML".

I believe there is value in defining what is valid HTML5, and I think  
"HTML 5" defines what is valid HTML5.

I think the valuable aspects of defining what is valid HTML5 are:

  1) Invalid syntactic constructs are reserved for future development  
of the language, i.e. what's now invalid can be given a meaning in a  
future level of HTML. (For the purpose of this email, I take it as a  
given that reserving the ability to produce "HTML 6" in the future is  
valuable.)

  2) It allows users of validator-style quality assurance tools that  
catch typos, etc., to substitute products without the switching cost  
of reworking existing content to adhere to the rules of the new tool  
(compared to a situation where validators had a product-specific  
notion of what's a reportable error).

  3) It helps HTML consumer developers and QA prioritize their  
polishing work to valid cases first even though eventually they need  
to support arbitrary inputs.

  4) It lowers the user support costs of validator developers as some  
design choices can be blamed on the WG and users can be referred to  
documentation written for the central notion of validity instead of a  
product-specific notion.

-- 
Henri Sivonen
hsivonen@iki.fi
http://hsivonen.iki.fi/

Received on Thursday, 29 January 2009 12:44:52 UTC