- From: Ian Hickson <ian@hixie.ch>
- Date: Mon, 15 Jun 2009 18:03:25 +0000 (UTC)
- To: Henri Sivonen <hsivonen@iki.fi>, Sam Ruby <rubys@intertwingly.net>
- Cc: HTMLWG WG <public-html@w3.org>
On Mon, 15 Jun 2009, Henri Sivonen wrote: > On Jun 13, 2009, at 01:22, Ian Hickson wrote: > > On Tue, 2 Jun 2009, John Foliot wrote: > > > What, in practical terms, will it achieve - how will it modify > > > author behavior? > > > > It's not intended to modify author behaviour, it's intended to help > > authors stay within safe boundaries. > > How is making @summary or <font color=blue> non-conforming not intended > to modify author behavior? If authors otherwise wouldn't stay within > boundaries that you consider 'safe', isn't making/helping them stay > within those boundaries modifying their behavior? Is selling a map or a compass to a camper or explorer "intended to modify explorer behaviour" or is it "intended to help explorers stay within safe boundaries"? I think this is more or less the same thing. > > * More likely to have their content be accessible. For example, authors > > will get notified when they use features like <font color=""> instead > > of features like <h1>. > > If the alternative is <h1>. If Sam's XSLT turns <font> into style='', I > don't believe accessibility got helped at all. I agree. I'd rather drop style="" altogether; it's one of the things in HTML5 that I don't agree with. On Mon, 15 Jun 2009, Sam Ruby wrote: > > I operate a validator for another (and related) specification, so I > definitely know where you are coming from, but taking a look at this: > > http://html5.validator.nu/?doc=http%3A%2F%2Fwww.google.com%2F > > Noting that the last six errors relate to the font element, let me ask: > how does this help "you find mistakes that would otherwise be slower > (i.e. more expensive) to spot"? Speaking as the representative of the company that authors that page, we find that pointing out places where we've used <font> to be useful. Many of our legacy pages have a poor HTML conformance story, but we use the errors pointed out by the validator to fix problems during development. In particular, we have found that using CSS instead of <font> is desireable both because of accessibility issues and performance issues. (We even have an internally-hosted instance of Henri's HTML5 validator.) For various reasons, fixing existing pages is a low priority for us, but since conformance checking has zero cost for us for legacy pages (since we just don't check them), we would rather have conformance represent the best known practices than make it a watered down kind of checking on top of which we'd have to add more checking. If there's one feature request that we might ask for, it would be the ability to give the validator a copy of an old version of a page, tell it to use that as a baseline, and then give it a new copy of that page (or a diff to that page) and have it tell us whether we introduced any _new_ errors. That would allow us to continue to use the conformance checker even when updating legacy pages. This isn't a high priority though. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Monday, 15 June 2009 18:04:25 UTC