[whatwg] HTML5-warnings - request to publish as next heartbeat WD

[Tab Atkins Jr.]

On Sun, Aug 9, 2009 at 8:32 AM, Manu Sporny<msporny at digitalbazaar.com> wrote:
> I took some time this weekend to go through the HTML5 specification and
> write warning language for features that are currently either
> controversial or have long-standing bugs logged against them. It is
> important that we draw attention to the least stable sections of the
> HTML5 draft in order to align public expectation as we move towards Last
> Call.
>
> The only difference between this draft and Ian's latest draft are the
> warnings - there are no new technical additions or deletions. Since
> there are no new technical changes, there is no need to trigger a FPWD.
>
> I am requesting three things of the HTML WG:
>
> 1. That this version is published as the next heartbeat
>   Working Draft. Specifically, this is not a FPWD since there are no
>   technical changes and thus there are no additional patent concerns.
>
> 2. Two other independent voices to support the publishing of this draft.
>   Without those voices, this proposal cannot be considered for
>   publishing.
>
> 3. A poll is created with two options:
>   [ ] Publish Ian's latest draft to address the heartbeat requirement.
>   [ ] Publish Ian's latest draft with Manu's warning language to
>       address the heartbeat requirement.
>
>   Whichever option that receives more than 50% of the vote will be
>   published. A tie will result in Ian's latest draft being published.
>
> Here is the complete diff-marked version:
> http://html5.digitalbazaar.com/specs/html5-warnings-diff.html
>
> Here is a link to every warning that was added to the HTML5
> specification (this is the easiest way to review the changes):
>
> http://html5.digitalbazaar.com/specs/html5-warnings-diff.html#editor-s-draft-date-08-August-2009
> http://html5.digitalbazaar.com/specs/html5-warnings-diff.html#urls
> http://html5.digitalbazaar.com/specs/html5-warnings-diff.html#fetch
> http://html5.digitalbazaar.com/specs/html5-warnings-diff.html#misinterpreted-for-compatibility
> http://html5.digitalbazaar.com/specs/html5-warnings-diff.html#implied-strong-reference
> http://html5.digitalbazaar.com/specs/html5-warnings-diff.html#other-metadata-names
> http://html5.digitalbazaar.com/specs/html5-warnings-diff.html#microdata
> http://html5.digitalbazaar.com/specs/html5-warnings-diff.html#predefined-type
> http://html5.digitalbazaar.com/specs/html5-warnings-diff.html#obsolete
> http://html5.digitalbazaar.com/specs/html5-warnings-diff.html#the-source-element
> http://html5.digitalbazaar.com/specs/html5-warnings-diff.html#alt
> http://html5.digitalbazaar.com/specs/html5-warnings-diff.html#the-head-element
> http://html5.digitalbazaar.com/specs/html5-warnings-diff.html#navigating-across-documents
> http://html5.digitalbazaar.com/specs/html5-warnings-diff.html#the-bb-element
>
> If Ian updates his spec, I can regenerate and republish an
> updated version of this document within an hour or two. The
> non-diff-marked specification can be found here:
>
> http://html5.digitalbazaar.com/specs/html5-warnings.html
>
> This version of the specification will be checked into W3C CVS when
> Mike(tm) clears its addition to the repository.

I think it appropriate to note that the #urls section willfully
violates existing specs for legacy web compat reasons, as you have
done with #misinterpreted-for-compatibility.

I don't recall any controversy being generated around
#implied-strong-reference.  Was it only on the HTMLWG list, or perhaps
far enough in the past that it predated my following the WHATWG list?

The warning text for #alt is incorrect - the concerns that have been
raised are about @alt being *omitted*, not left blank.  Blank @alt is
perfectly fine and the only correct value for the attribute in many
cases.

In many of the code examples strewn throughout the diff-marked
document, the text will suddenly change to one word per line, which
makes it very difficult to follow (I noted it especially in the #alt
section, as it has tons of examples).  There doesn't seem to be any
rhyme or reason to this, as it can happen in the middle of an example
and then switch back to normal behavior before the block is closed.
This problem is not present in the non-diff-marked version.

~TJ