- From: Manu Sporny <msporny@digitalbazaar.com>
- Date: Wed, 12 Aug 2009 13:05:31 -0400
- To: HTMLWG WG <public-html@w3.org>
Ian Hickson wrote: > On Tue, 11 Aug 2009, Manu Sporny wrote: >> We cannot, however, willfully break other specifications without there >> being blowback. For example, here's what I'm asserting happened with >> @summary: >> >> 1. Gather some data and report the @summary issue to WAI/PFWG. >> 2. WAI/PFWG does not respond satisfactorily, for whatever reason. >> 3. Break the WAI/PFWG guidance by authoring normative language into the >> HTML5 spec. >> 4. Disaster. > > We didn't break the WAI/PFWG guidance at all. There are no normative WAI > documents that refer to summary="", and the only note that refers to > summary explicitly states that only HTML4 and XHTML1 are in scope. Clearly /something/ caused the WAI/PFWG to object, en masse, to the way things were being handled re: @summary in HTML5: http://lists.w3.org/Archives/Public/public-html/2009Jul/0556.html Rather than taking the time to convince them that they have no reason to raise an issue, why not take the time to work toward a solution with them? >>> Having said that, are there are any violations in the HTML5 spec that >>> aren't already called out in the spec? I thought I had put text about >>> each occurance. >> The way they are called out in the current spec is the problem. I'm >> asserting that what the current language says is: >> >> "We have chosen to willfully violate another specification." >> >> What I am asserting is that the language should be changed to express >> the following notion: >> >> "We have chosen to willfully violate another specification, and thus >> this section is unstable because a clean solution to the issue has yet >> to be found." > > These sections aren't unstable unless you think that there is any chance > that HTML5 is going to specify something that implementations won't > implement. I know you think that the sections are stable, but there are others that do not. I know that you think that many of the issues that are being raised in the HTML WG are issues that you "resolved" many years ago, but others in the WG do not share the same opinion (and it's not just wild opinion, it is opinion based on implementation experience in their respective fields). Your definition of "resolved" is clearly different than what others define "resolved" as being. The HTML spec, in these specific sections, is being willfully inconsistent with the rest of the standards community. I would hope that we'd be unrelenting in engaging these other specification writers to correct their specifications, if there is in fact, something wrong with them. >> My intention was to mark every section that violates another >> specification with a warning noting that the section is undergoing >> discussion. > > Then those warnings are going to be wrong. There's no way you're ever > going to convince a major Web browser vendor to treat ISO-8859-1 as > anything but Windows-1252, for example. What does a warning about a section undergoing discussion have anything to do with what the browsers are implementing? I'll re-iterate the goal (by reformulating the steps to get to that goal): 1. Willfully violate another specification and add a warning stating that the section is under discussion. 2. Discuss the necessary change by providing data to the external spec writer. Repeat until an acceptable solution is realized. 3. Update the willful violation such that it is no longer a willful violation and remove the warning. > I expect we'll be at zero technical issues by October, at which point the > announcement of last call will result in a ton of more feedback which will > likely take until 2012 to handle. > > The issues you have listed, and the issues on the HTML issue tracker, are, > with few exceptions, not technical issues. It's possible that as Maciej > said, the HTMLWG will be quagmired in discussing non-issues for many > months, delaying the W3C's publication of an LC draft. It's not the *HTML WG* that will be quagmired -- it's the *HTML5 spec* that will be quagmired, mostly because of content in the document that /you/ authored and have decided not to change. This isn't just HTML WG's problem - its the entire HTML5 community's problem. Those who see this as purely an HTML WG issue must stop seeing it as such - all issues, across all trackers, must be resolved before we can publish this document as a REC. Pointing out the potential quagmire that is coming does nothing to move us forward. >> http://lists.w3.org/Archives/Public/public-html/2009Aug/0550.html > > I still don't see what the point is. It just looks like you're trying to > stir up controvery so that you can gain support for dropping the microdata > section and replacing it with RDFa. The point is to more effectively communicate the sections of the document that are under active discussion to the public. We don't have a warning on the <p> element because most of us agree on the purpose and stability of that element. We should have a warning on the @summary and @alt attributes because there is clearly conflict surrounding the current spec language for elements that use those attributes. I think that is very clearly stated in the '0550.html e-mail... I don't think you mean to say you don't see the point... you just don't think it's necessary to inform the public about the parts of the spec that are under active discussion. This isn't just about Microdata, as I explained here: http://lists.w3.org/Archives/Public/public-html/2009Aug/0462.html This is about conveying the current status of the HTML5 specification to the public. >> We are not effectively communicating the larger issues with HTML5 to the >> public. > > I really don't think that the issues you are trying to communicate will do > anything to aid the public, and I think it will do everything to slow down > our progress even further, by bringing people who are naturally > argumentative into discussions that are already high on rhetoric and low > on data. It will just discredit the HTMLWG even further. How is pointing out the issues on a specification that /you/ have written going to discredit the HTML WG? Pointing out issues are going to slow us down - but we need to agree that there are issues, convey those issues to the public in an easily digestible form, and resolve those issues. Finding and handling all of the issues before the HTML5 spec becomes a REC is our job at the HTML WG. The HTML 5 spec doesn't get a free ride just because some of the charter members of the WHAT WG assert that it enjoys consensus. >> Even reviewers that read the HTML5 specification are going to find it >> difficult to understand the high-level issues with the specification. >> What's stable, what's unstable? > > We have had stability markers for exactly that purpose for years. The stability markers are only part of the solution. One has to be familiar with what each marker/graphic means before they start to make sense. The learning curve, of "how to read the HTML5 spec" is too steep currently. Even the HTML5 document is a bear to load and manage in a web browser. The current issues, at the very least, in the HTML WG issue tracker, is the other bit of data that should be integrated into the published specs. You have demonstrated an unwillingness to recognize and address the issue, so that will be the next thing that I work on. -- 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 Wednesday, 12 August 2009 17:06:09 UTC