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

Ian Hickson On 09-08-09 22.18:

> (Please don't cross-post messages to the WHATWG list and another list.)
> 
> On Sun, 9 Aug 2009, Julian Reschke wrote:
>>> 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
>>> ...
>> I agree with those.
>>
>> Optimally, the "hyperlink auditing" (a/@ping) section should be 
>> mentioned as well.
> 
> If the idea is to mark up all the issues where someone disagrees, then 
> there are a number of other sections we should mark, in addition to all 
> those that have XXX markers in the source already, those that have bugs 
> filed, and those for which outstanding e-mail feedback is pending:


  [ snipped list of candidate warnings ]

Like Ian, I support publishing both drafts. And like Ian, I would 
like to have a say regarding both of them. ;-)

Regarding Manu's draft, I think it would be better if the
warning messages appeared in context. For instance, now there is a
warning for the head element, whereas the real issue is one of its
attributes  - profile. The same can be said about the source
element - the issue is with codecs. Confusing readers to think the 
issue is with <source> as such would not be good. A warning that 
appears in context is also more likely to be accurate (example the 
'blank @alt' warning is currently incorrect/unclear). Also, for 
the summary warning -  there is a separate issue regarding 
"deprecation" vs "obsolete but  conforming" - it doesn't feel 
right to have "summary" as the  "subheader" of the "obsolete 
features" section. And if the summary warning text also speaks 
about the summary issue as such [and so it seems], then it belongs 
just as much under the Table element ...

I would therefore suggest changing the current warnings to some
kind of standard text - like:

    This section has a the following warnings about lack of consensus:
      <a href="#X">attribute X</a> (Serious)<br>
      <a href="#Y">codec Y</a> (Minor)<br>
      <a href="#Z">feature Z</a> (Normal).

And then each link could lead to an explanation in context. Such
a solution could also scale better, if one were to add more
warnings ... Could possibly integrate better with the current XXX 
markers system, as well, and so on.

Effectively it would also be a in-document consensus tracker.
-- 
leif h silli

Received on Sunday, 9 August 2009 21:36:30 UTC