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

Ian Hickson wrote:
> On Tue, 11 Aug 2009, Manu Sporny wrote:
>> 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.
> 
> If some other working group contradicts parts of HTML5 because HTML5 is 
> wrong, then I wouldn't take issue, I'd fix HTML5. Unfortunately other 
> groups haven't always had quite the same commitment to documenting what 
> implementations do.

I agree, in principle, with the statement you've made above. I
understand that some other groups have not been as vigilant as WHAT WG
in documenting what implementations actually do - and I think that
should be a strong consideration when determining if a specification is
actually working out in the field.

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.

Here's what I'm asserting should have 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. Repeat steps 1 and 2 until WAI/PFWG responds satisfactorily, OR
4. Propose alternatives that could replace @summary that meet WAI/PFWG's
   requirements. Author preliminary language into the HTML5
   specification and note that the solution does not enjoy consensus
   and is controversial.

While you may assert that the second set of steps is actually what
happened, WAI/PFWG is asserting that what happened is closer to the
first set of steps... which we all observed, ended in Disaster.

> 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."

> You didn't put warnings for each one; how did you pick which
> ones to add the additional warning to?

If I didn't put warnings at the top of each section that willfully
violates another specification, then that was my mistake. I'm attempting
to be consistent and lack of consistency should be remedied.

My intention was to mark every section that violates another
specification with a warning noting that the section is undergoing
discussion.

>> 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.
> 
> There's a reason the timetable expects us to be in LC until 2012. :-)

What do you mean by "expects us to be in LC"? My understanding of the LC
process is that we can't enter LC until most of these larger issues are
addressed... which may take much more than 3 months.

> Personally I have to say that I don't see much point in adding warnings to 
> the spec. I support your right to have the working group publish your 
> edits, but I don't think it's an especially good idea. I don't really see 
> what the point is. 

I explained this in more detail when responding to Maciej:

http://lists.w3.org/Archives/Public/public-html/2009Aug/0550.html

> We already work in public, our lists of open issues are 
> all very open and accessible to all. If they're not open enough, then we 
> should work on that, we shouldn't add yet another issue list (this would 
> be what, the fifth?), asthat will just confuse people.

I agree, we shouldn't have another issue list, that would be counter
productive.

The problem is not one of openness, it is one of communication.

We are not effectively communicating the larger issues with HTML5 to the
public. Many, many people (including myself), don't have the time to
track every e-mail and every issue that is flying through these mailing
lists. Having the ability to look at 500 issues doesn't solve the
communication issue, it just succeeds at providing too much information
to the readers -- information overload.

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?

Not having any warnings noting that a section is undergoing active
discussion is not helpful either. So we have this spectrum:

           |--------------------|
      No warnings       Every issue ever

I'd like us to communicate something in the middle to public readers,
reviewers, and those that may end up writing blog posts about the
changes to HTML5 that are not intimately familiar with HTML5. I think
Maciej and I have come to an understanding of how we could do that. Do
you agree with the set of objective criteria to determine which sections
to visibly mark as controversial in the W3C published HTML5 WD?

If nothing else, marking the sections that should be documented with
warnings re-assures those outside of WHAT WG that their concerns are
recognized.

-- 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 18:02:29 UTC