- From: Sam Ruby <rubys@intertwingly.net>
- Date: Fri, 26 Mar 2010 09:27:25 -0400
- 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