Re: HTML extensibility framework

On Wed, 18 Mar 2009 02:02:19 +0100, Larry Masinter <masinter@adobe.com>  
wrote:
> I’m trying to list the ways in which new features
> are added to languages; in HTML this has happened
> usually by adding new elements, or adding comments,
> or adding <Script> elements with new script types
> or Javascript calls to new APIs. Perhaps there are
> more ways in which HTML is or can be extended.

Ah, I see. It wasn't quite clear to me what you meant with "new element".  
A new attribute would be another obvious one. In case of e.g <input type>  
new attribute values is another one. As done in HTML5 the parser can be  
changed so that e.g. MathML suddenly becomes useable.


>>  (I tend to think that languages that are incrementally improved upon by
>> multiple parties and are widely deployed are much better off without
>> versioning. Then again, everyone has different ideas as to what  
>> versioning
>> means. Some feel it's just a hint for the validator. Some think user
>> agents need different processing models. Etc.)
>
> Clearly when you have a single speaker and multiple
> recipients, and a single speech act, then the single
> speaker needs to indicate the language more clearly
> than in cases where the speaker adapts the content
> of the message to the listener.

I'm not sure I follow this. If this is meant to be some sort of anology  
though I do not think it applies to the Web. The Web has a lot of speakers  
that each do their own illogical thing and a slightly smaller set of  
recipients that try to make sense of it.


> I'd like to see if we could move the conversation from
> "I thend to think X" vs "I tend to think Y" to
>
>  Here are 5 choices: (A) (B) (C) (D) (E)
>  Here are 7 use cases: (1) (2) (3) (4) (5) (6) (7)
>
> and evaluating the choices against the use cases in
> a consistent way.
>
> Then, we can make a more informed decision of which
> choice we're making by evaluating how important the
> use cases are and what the impact is.

To be frank, I think the versioning story for HTML is pretty much settled.  
It has already been heavily discussed at the start of the HTML WG and I'm  
not that interested in doing it again.

   http://lists.w3.org/Archives/Public/public-html/2007Apr/thread.html#msg1053
   http://lists.w3.org/Archives/Public/public-html/2007Apr/thread.html#msg858


> "everyone has different ideas as to what versioning means"
>
> I've found discussions about "meaning" to be frustrating
> when carried out without reference to the context of
> use. That's why I try to distinguish between the indicator
> (element, attribute, version designation, etc.) as
> uttered by a speaker, vs the behavior of a recipient
> when reading and trying to process the content that
> contains this sign.

Agreed. The problem I had was that if someone says that "HTML should have  
a version attribute" it is completely unclear what the person  
means/implies by that. Should browsers not render the page? (Not going to  
happen.) Should browsers indicate they might not be able to render the  
page properly? (Not going to happen.) Should browsers ignore it? (Already  
happens, but what's the use then?) Should browsers render elements  
differently depending on the <html version> value? (Not going to happen.  
Also doesn't work for compound documents.)


-- 
Anne van Kesteren
http://annevankesteren.nl/

Received on Wednesday, 18 March 2009 10:31:12 UTC