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

Leif Halvard Silli wrote:
> Regarding Manu's draft, I think it would be better if the
> warning messages appeared in context. 

I attempted to place the warning messages in the proper context.

If they are not in the proper context, they can be moved. Some are going
to disagree with what constitutes the "proper context". Could you
clarify and note which warnings are not in the proper context?

> For instance, now there is a
> warning for the head element, whereas the real issue is one of its
> attributes  - profile. 

Where do you think the warning about this attribute should go?

> The same can be said about the source
> element - the issue is with codecs. 

Codecs seem to be discussed heavily in <source>, which is why I placed
the warning there. In general, I attempted to place warnings for
features before the feature is discussed. Where would you place the
codec warning?

> A warning that appears in
> context is also more likely to be accurate (example the 'blank @alt'
> warning is currently incorrect/unclear).

I believe that you're the second person to point this out so I'll
re-examine the wording/clarity issue. Could you please provide the exact
language that would be acceptable to you?

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

How would you re-word the warning and where would you place this
re-worded warning?

> 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).
> 
> Effectively it would also be a in-document consensus tracker.

Leif, I really like the idea of an in-document consensus tracker... it's
a tool we're going to need going forward. I'm afraid that drafting new
polls for every controversial feature of HTML5 is going to be incredibly
time consuming, which is an issue I think your idea could address (aside
from being a helpful documentation tool).

-- 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 Monday, 10 August 2009 05:04:07 UTC