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

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:

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

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

> 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:

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

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

Received on Wednesday, 12 August 2009 17:06:09 UTC