- From: Maciej Stachowiak <mjs@apple.com>
- Date: Mon, 10 Aug 2009 17:24:37 -0700
- To: Manu Sporny <msporny@digitalbazaar.com>
- Cc: HTMLWG WG <public-html@w3.org>
On Aug 10, 2009, at 10:21 AM, Manu Sporny wrote: > 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. > 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". If they have, then the first condition would apply. Furthermore, it seems like this is a state that, as defined, could not be removed by a decision of the Working Group. > OR > - 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. > > While that doesn't constitute the entire line of reasoning that went > into the HTML5-warnings draft, it does provide a broad summary of how > the sections came to be marked as controversial. 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 originally said 6 months, but 2 months seems like a reasonable timeline.) > >>> I marked <bb> because both Microsoft and Mozilla have raised fairly >>> strong concerns about implementing it in its current form and >>> because >>> Ian has stated that he won't place anything in the final spec that >>> doesn't enjoy a 100% conformance rate among UA implementations. >> >> <bb> does not look even remotely likely to cause a perma-thread. In >> fact, your text above explains why. > > That's because the perma-thread criteria wasn't applied to the <BB> > element, this one was: > > - It must provide normative functionality that UA manufacturers have > asserted that they will not support as-is. 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. Regards, Maciej
Received on Tuesday, 11 August 2009 00:25:18 UTC