W3C home > Mailing lists > Public > public-html@w3.org > August 2009

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

From: James Graham <jgraham@opera.com>
Date: Tue, 11 Aug 2009 20:29:29 +0000
Message-ID: <20090811202929.cp79lgxdvk040kww@staff.opera.com>
To: Manu Sporny <msporny@digitalbazaar.com>
Cc: HTMLWG WG <public-html@w3.org>
Manu Sporny wrote:
> The public is currently under the impression that HTML5 is right around
> the corner because of the success of <video> and <canvas> - we need to
> align the public's expectations with the current state of development.
> That is the purpose of HTML5-warnings.

If that is the purpose of HTML5-warnings I think it is inadequate to  
achieve its goal and the discussion about it thus far has not been  
along lines that will bring it closer to meeting this goal.

The discussion around HTML 5 warnings has focused on "warning" users  
that text in specific areas known to be controversial within the HTML  
Working Group suffer from controversy. Warnings selected using  
criteria based on controversy are insufficient to communicate accurate  
information about stability because controversial sections are only a  
tiny subset of those that are likely to change between now and Rec.  
For example it is rather probable that the text discussing the  
seamless attribute on the iframe element will be substantially revised  
because, as far as I am aware, no user agent has yet attempted to  
implement that section of the spec and, assuming such implementations  
occur, the experience they bring will likely cause the spec text to be  
revised. Alternatively, if no implementation occurs then the section  
may be removed entirely. However authors who rely on the warnings  
language for stability information will not discover this unless it  
happens to be raised in the HTMLWG tracker.

Conversely many parts of the <video> specification are now deployed in  
multiple UAs and can be expected to remain rather stable going  
forward. This is also information that authors may need to set their  
expectations appropriately since the spec currently has a blanket  
warning of instability at the top. The current "warnings" draft also  
fails to communicate the existence of these unusually stable sections  
to users.

I believe this demonstrates that warnings as discussed thus far are an  
insufficient means to achieve the goal that you have set out. I  
further believe that the approach of using warnings is actually  
harmful to progress. Phrasing stability information as a "warning" is  
unnecessarily pejorative and only serves to focus yet more attention  
on the few sections that have already undergone a great deal of  
discussion. Whilst this extra attention is welcome if it can resolve  
the issue, in many cases the "warning"s apply to text in which there  
are philosophical differences between different groups and where what  
is needed is consensus building rather than yet more emphasis of  
differences. At the same time more attention on sections where  
well-understood issues exist likely comes at the expense of feedback  
on sections which have been comparatively little reviewed. For example  
the great majority of the feedback from the accessibility community  
had focused on differences between HTML 5 and HTML 4; at this point it  
would likely be more useful to get feedback on how new features match  
up with accessibility needs than to have yet another round of debate  
about the exact wording surrounding the summary attribute. I believe  
the focus on known controversy in the warning draft discourages that  
type of progress.

To meet the goal of informing readers of the spec about the likely  
stability of different sections, we are much better off adding  
informative annotations to each section that describe the stability of  
that section using criteria such as whether the feature is supported  
in released user agents. Such annotations would be both positive  
"Ships in multiple UAs; likely to be stable" and negative  
"Unimplemented, likely subject to change or removal". It is notable  
that the WHATWG draft already has a system for doing this based on  
user-supplied information. It would not (I expect) be a technical  
challenge to statically add those annotations to the W3C version of  
the spec. Of course other approaches are possible. However I would  
discourage anything that will take up a great deal of the group's  
bandwidth; it is simply untrue that solving issues is independent of  
deciding on which issues are controversial when the latter takes up  
time that could be dedicated to the former. I can't speak for anyone  
else but reading email about this warnings draft has already sucked up  
a huge amount of my time that I think I could otherwise have used more  
Received on Tuesday, 11 August 2009 20:30:27 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:15:49 UTC