Re: ISSUE-41/ACTION-97 decentralized-extensibility

Henri Sivonen wrote:
> On Oct 5, 2009, at 14:25, Maciej Stachowiak wrote:
> 
>> On Oct 5, 2009, at 12:03 AM, Sam Ruby wrote:
>>
>>> Henri Sivonen wrote:
>>>> I think you are jumping ahead of things. We don't yet have consensus 
>>>> on what problems to solve. We don't have consensus on whether 
>>>> "decentralized extensibility" is the right way to solve those 
>>>> problems. And we don't have consensus on whether Microsoft's 
>>>> proposal (even on the high level) is the right kind of 
>>>> "decentralized extensibility" for solving the problems.
>>>> I think it would make the situation clearer if you could state what 
>>>> problems you want solved, why you believe the HTML WG should solve 
>>>> those problems, what "decentralized extensibility" is (so the WG can 
>>>> recognize whether alternative proposals constitute "decentralized 
>>>> extensibility"), why you believe "decentralized extensibility" is 
>>>> the right way to solve the problems and why you believe Microsoft's 
>>>> proposal is the right kind of "decentralized extensibility".
>>>
>>> Consensus on what the values of localName, prefix, namespaceURI (and 
>>> possibly tagUrn) should return -- that's what I would like to see 
>>> resolved.
>>
>> If you really want to nail this down to concrete technical questions, 
>> then it's really a question of parsing, not API behavior. All of 
>> HTML5's current behavior flows directly from the element's or 
>> attribute's {namespace, prefix, localName} tuple. That tuple is either 
>> set by the parser, or as a result of creating elements or attributes 
>> directly with DOM calls.(*)
>>
>> As I understand it, Microsoft's proposal does not change any behavior 
>> for elements or attributes created with DOM APIs. All it does is 
>> change the initial {namespace, prefix, localName} tuple for elements 
>> and attributes created by the parser, and this is observable through 
>> the API behavior. I don't believe Microsoft's proposal can be 
>> explained solely in terms of API changes, without having the parser do 
>> something different (at the very least record some additional 
>> information). But it can be explained solely in terms of parser changes.
> 
> I agree with this assessment. However, I further think it doesn't make 
> sense to nail down technical questions without knowing the purpose of 
> the nailing. Without knowing the purpose, one can't perform informed 
> nailing. I'm interested in a *good* outcome--not just *any* outcome that 
> enjoys consensus potentially because people participating in the 
> consensus lacked information.

Let's stop with the strawmen.

I want to discuss technical ramifications alongside of the reasons.

You said "you are jumping ahead of things".  I interpret that as not 
wanting to talk about technical ramifications just yet.  If so, here we 
disagree.  And even if so, that's fine.  We can have multiple 
discussions, and each of us can participate in the ones we wish to. 
Abstract discussions with no clear and tangible ramifications simply do 
not interest me.  YMMV.

But to position this as me not wanting to know the purpose... that's 
simply a strawman.  Please stop.

>> Stating my personal views once again:
>> - I can live with what HTML5's current parsing algorithm does to 
>> elements and attributes with colons in the name.
> 
> In my view, the current parser spec addresses the problems it sets out 
> to address in a satisfactory way (except likely for the way HTML 
> <script> elements are closed).
> 
> I think the set of changes flowing from an empty set of additional 
> problems to solve should be the empty set of changes. That is, I think 
> it wouldn't be rational for me personally to be part of a consensus 
> endorsing changes compared to the current spec without problems to solve 
> to motivate the set of changes.
> 
> Sam, did you mean for the WG to endorse the current parsing spec text by 
> consensus?

I interpret Microsoft's post as a something to seed discussion, and not 
(yet) as a proposal.  If they meant something more than that, I hope 
that they clarify.

For anybody to say that they can't live with something that has yet to 
be proposed is a bit premature, in my opinion.

If no alternate proposals are made, then I am prepared to endorse the 
current parsing spec text as having consensus.  Like Maciej, I have yet 
to hear anybody (including Microsoft) indicate that they can't live with 
the current spec text.

All of the above is independent of whether or not any given individual 
considers the current spec text to have sufficient "distributed 
extensibility".

I'll try to make a separate statement later today on my personal (i.e., 
not as chair) opinions are on the subject.  A quick overview: I believe 
that it is true that Microsoft could implement the current HTML5 spec in 
IE9 in a way that would effectively break the web AND I believe that it 
is true that if other browsers were to adopt what MS put out for 
discussion, that too would break the web.

At the present time, we have a horrible mix of sites that test for user 
agents and infer capabilities, and sites that test for capabilities and 
infer behaviors unrelated to those capabilities.  One solution to that 
(a solution that I gather that both you and I, Henri, want to avoid as 
much as possible) is to version the web.  The other is to decide what is 
the appropriate level of breakage is possible, and even desirable.

- Sam Ruby

Received on Monday, 5 October 2009 16:01:33 UTC