Re: HTML5-warnings - request to publish as next heartbeat WD

Maciej Stachowiak wrote:
>> Here is a subset of my standards:
>> For a section to be determined controversial:
>>
>> - It must have been discussed at length (for at least 2 months) without
>>  an agreeable solution being integrated into the specification.
> 
> I'd agree this can be defined as a "controversial" issue.

Good.

>> OR
>> - It must contradict findings or language published by another working
>>  group (either inside or outside the W3C).
> 
> If no representative of that Working Group has raised an objection, then
> I don't see how this automatically makes such an issue "controversial".

The issue becomes controversial by willfully violating another standard.
If we are carefully writing the HTML5 standard so that it provides
browser interoperability and some other working group willfully violates
parts of the HTML5 standard, I would expect that we would take issue
with that. To do otherwise would seem contradictory.

However, perhaps the proper approach is to ask those groups if they
would like to raise an issue with HTML WG or change their specification
to match HTML5.

Minor concern: What happens if the WG that created the spec doesn't
exist in an official capacity anymore?

What I don't want us to do is sit by and let the language blind-side the
other working group or not allow anyone to raise the issue. I believe
that we should be rigorous in seeking feedback and gaining consensus
(both inside and outside the HTML5 community).

>> - It must provide normative functionality that UA manufacturers have
>>  asserted that they will not support as-is.
> 
> As a representative of a UA manufacturer, I would not want my objections
> to implementing something to result in this kind of issue marker
> automatically. Perhaps if the editor refuses to take that feedback into
> account after some time, then there might be a controversy. But in fact,
> "we can't/won't implement this" type feedback is common and seems to be
> resolved in a satisfactory way. Nor have I seen any other UA vendors ask
> for these kinds of markers for their issues. Thus, I don't think issues
> like this that fail to meet condition 1 should be specially marked.

Fair enough, I retract that requirement (more on this below).

> I don't entirely agree, but it's better than nothing. Here's what I
> would propose:
> 
> 1) The issue was raised at least two months ago, by one of email,
> bugzilla or the issue tracker.
>       AND
> 2) There has been no mutually satisfactory satisfactory outcome.
>       AND
> 3) There is an open issue in the issue tracker indicating this.

I've noted that you've compromised to 4 months with Ian. I also note
that we have less than 3 months to LC -- a time when a great number of
people start raising issues and concerns related to the specification.

Since LC is a time for the public to review the spec, your criteria
doesn't allow any new sections of the spec to be marked with warnings.

How are we supposed to convey which sections of the document are most
problematic to the public with the approach you list above?

I think we need another criteria in addition to the list you have above.
The goal of this criteria is to allow rapid detection and public
reporting of a long standing issue that has been ignored/undetected/not
discussed for whatever reason. This is a suggestion and may not be the
most ideal way forward:

OR
4) There are at least 8 people that assert a particular section as
problematic. (8 is arbitrary - whatever number it is, it should be high
enough so that people cannot vote in blocks, but low enough so that it
isn't a herculean effort to place warning text beside a section that
does not enjoy consensus).

Adrian Bateman wrote:
> On Monday, August 10, 2009 5:25 PM, Maciej Stachowiak wrote:
>> Since Ian is incredibly responsive to implementor concerns, even in
>> the
>> face of massive flamewars (see for instance the codec issue), it
>> seems
>> like a waste of time to mark such issues, and gives a misleading
>> impression of their actual degree of controversy.
>
> I agree with Maciej. I don't believe there should be special
> treatment for UA manufacturers and it seems premature to mark
> a section as controversial after two e-mails and little discussion.
> I would very much like to hear feedback on the <bb> element though,
> particularly related to the notion of an on page element compared
> to something more declarative.

Fair enough... it is looking more and more like the <BB> and GC warnings
in the HTML5-warnings draft are going to be removed. Others should note
their support for removal on the poll. I'll be voting for the <BB>
warning language to be removed.

-- manu

-- 
Manu Sporny (skype: msporny, twitter: manusporny)
President/CEO - Digital Bazaar, Inc.
blog: Bitmunk 3.1 Released - Browser-based P2P Commerce
http://blog.digitalbazaar.com/2009/06/29/browser-based-p2p-commerce/

Received on Tuesday, 11 August 2009 04:30:27 UTC