Re: Support Existing Content (was: Proposed Design Principles review)

At 03:54 PM 4/29/2007 -0700, Maciej Stachowiak wrote:
>On Apr 29, 2007, at 7:50 AM, Murray Maloney wrote:
>>At 04:09 PM 4/28/2007 -0700, Maciej Stachowiak wrote:
>>>I agree the POV seems off. However, this principle has very important
>>>implications for language design. How about like this:
>>>
>>>Support Existing Content
>>>
>>>SupportExistingContent: HTML5 should be designed so that user agents
>>>conforming to it can still handle existing web content as intended.
>>>In particular HTML5 should make it possible to process web documents
>>>and applications via an HTML5 implementation even if they were
>>>authored against older implementations and do not specifically
>>>request HTML5 processing.
>>>
>>>All changes and additions could cause some content to malfunction at
>>>least in theory, but this will vary in degree. We need to judge
>>>whether the value of the change is worth the cost. Cross-browser
>>>content on the public Web should be given the most weight.
>>
>>I would feel better about this as a design principle if you used
>>the words
>>that I sent you,
>
>More specifically, here are my problems with your suggested wording:
>
>>SupportExistingContent: The HTML WG will document the usage of HTML
>>as it is practiced by popular web browers, and deployed on the web
>>and on
>>intranets throughout the world. Our goal should be to facilitate
>>understanding
>>of extant content, even in the face of unusual and unexpected
>>syntax or position.
>>If any user agent is capable of an understanding an HTML construct,
>>it would
>>be ideal for all user agents to be capable of that understanding.
>
>1) Usage of HTML is not practiced by web browsers. I'm not sure it is
>grammatically correct to say it is practiced by anyone, but surely it
>is content authors who create specific HTML documents.

Actually, languages are practiced. Would you prefer that I reword to:

The HTML WG will document "HTML as she are spoke" in the wild.


>2) "Facilitate understanding of extant content" waters things down
>too much - we need existing content to behave and look basically the
>same in HTML5 UAs.

There are several "we". In the language spec, "we" need to understand each 
construct,
its behaviour and its default appearance in visual, aural and tactile media.

In the browser spec, "we" need to be able to identify and replicate each 
other's
behaviour and appearance.

In other client specs, "we" need to convey whatever meaning is intended for 
that client.


>3) I'm not sure what "unusual and unexpected syntax or position" means.

By that I meant errors. I think that it would be good specification design to
call out error recovery in the face of syntax errors -- missing "" or 
misspelled
attributes -- and irregular element positioning -- <i> ... <b> ... </i> ... 
</b>

>4) Your last sentence is about interoperability, not compatibility; I
>agree with it but it does not belong in this principle.

OK.


>>or you wrote words that related HTML 5 to extant HTML
>>and left the implications as an exercise for the browser designer.
>
>The fact that you did this is what waters down the principle too
>much, I think. The implications for browsers and other UAs are
>exactly what make this principle important, and I don't think it
>helps to leave that vague.

I understand, but then it is not a language principle; it is a browser 
design principle.


>>I think that the meaning of this principle should boil down to "We
>>are not
>>going to change the spelling of "align" or "p" or any other
>>language element
>>that have come to be expected in desktop UAs, the web, or intranets
>>worldwide."
>>
>>Am I missing something?
>
>Yes. Besides spelling, it is important not to incompatibly change
>behavior or appearance. For instance, requiring "p" to have no
>default margins would be unacceptable. Saying <input> with no type
>attribute should render as a button, not a text field, would be
>unacceptable. The principle really is very closely tied to what
>implementations will do with the spec.

Everything in the spec is connected with what the browser will do. But the
browser is not the only UA, and it remains possible to write language design
principles as such and to keep browser design principles separate.


>>P.S. I am totally in support of defining a set of "Browser Design
>>Principles"
>>I think that the world would be a better place if you guys could
>>agree on those.
>>I would prefer that browser and language design principles not
>>become confused.
>
>This one wouldn't even make sense as a browser design principle. If
>HTML5 requires things that are incompatible with existing HTML
>content, how could browsers use their HTML5 implementation to render
>today's content?

Was that a rhetorical question? If not, the answer is: if/then/else

>That being said, the rules for browsers are generally expressed as
>specifications. If the specs are precise enough, there is no need for
>additional guidelines.

That's the thing. HTML is a language spec. I agree that there should be
a browser spec. I would even agree that it should be closely tied
to the language spec -- which is why we have hyperlinks and triples.
I don't think that the language spec and the browser spec should be
written on the same page.

>I feel like there is some reluctance here to acknowledge that
>browsers exist, and to take explicit consideration of them in the
>design of the language. I don't think that makes sense - you can't
>design the web without thinking about the way most users are going to
>experience it.

No reluctance to acknowledge that browsers exist. That would be an absurd
and extreme position. However, I would prefer to maintain a layer of 
abstraction
between the language and the human being. I think that it is possible to 
describe
what you mean with respect to preserving the existing meaning of extant HTML
without resorting to descriptions that are based on browser behaviour and 
performance.

If I am the only person who is uncomfortable with this design principle,
then you can safely ignore me. I still think it's wrong, but I am not going to
stand in front of a moving train.

Received on Monday, 30 April 2007 15:10:09 UTC