W3C home > Mailing lists > Public > public-html@w3.org > March 2010

Re: Bug 7034

From: Sam Ruby <rubys@intertwingly.net>
Date: Fri, 26 Mar 2010 09:27:25 -0400
Message-ID: <4BACB63D.8030405@intertwingly.net>
To: Henri Sivonen <hsivonen@iki.fi>
CC: HTMLwg WG <public-html@w3.org>, James Graham <jgraham@opera.com>
On 03/26/2010 06:56 AM, Henri Sivonen wrote:
> "Henri Sivonen"<hsivonen@iki.fi>  wrote:
>
>> Personally, I'd be more inclined to allow more
>> interoperably-implemented presentational pre-existing markup
>> features as valid to allow authors to use an HTML5 validator as a
>> development aid when adding HTML5 features to pre-existing content
>> that has interoperably supported legacy cruft in it.

Ditto.

> Based on IRC discussion, I feel I should clarify: I'm not suggesting
> that all interoperably-implemented presentational pre-existing
> features should be valid as a blanket policy. However, I think it
> would be worthwhile to allow things that are used so much that not
> allowing them makes validators too noisy for use with legacy
> markup--but only when the harm arising from the use of legacy markup
> features is directed mostly to the maintainer of the markup and not
> to the users.
>
> Examples: Tweaking table borders in CSS vs. tweaking them in
> presentational attributes is probably an issue where the harm is
> directed at the page author. Using<font size>  most likely means
> that<h1>,<h2>, etc. aren't being used, which is a case where the harm
> is directed at users of non-conventional browsing software.

Apparently, you got some blowback from the CSS-orthodoxy.  We also have 
an accessibility-orthodoxy, an XML-orthodoxy and possibly quite a few 
additional orthodoxies to deal with, each of which require that we 
worship in their various churches.

This has resulted in a number of open issues to resolve.  Included in 
this is a MIME type registry to pursue.

I'd like to see us follow a path along the lines you describe at the top 
of this email.  And then additionally either produce ourselves or 
encourage others to produce additional sets of guidelines over this bare 
minimum and strongly encourage authors to adopt as many of these 
guidelines as they see fit.

Think about it: wouldn't it be a wonderful thing if the WAI PF WG could 
produce their own set of guidelines?

I'd also prefer that there be some mechanism in the document itself to 
indicate which sets of a given document conforms to.  I believe that 
would be helpful to editing tools and validators alike.

I'd love to unleash the creativity of the working group and solicit 
change proposals (complete with rationale) to address this.

I'm frustrated that bugs 7034 and bugs 7468 have been in process and 
without a either resolution or even a rationale provided since June and 
August (and, yes, I know technically they were only recently reopened, 
and I'm equally frustrated that the clock can be reset so simply).

It is my request that any and all bugs that block us from proceeding to 
the state in the Decision Process that enables the co-chairs to put out 
a call for proposals be treated as a priority at this time.

- Sam Ruby
Received on Friday, 26 March 2010 13:28:15 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:16:00 UTC