Re: On validation

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