W3C home > Mailing lists > Public > whatwg@whatwg.org > August 2012

Re: [whatwg] alt="" and the <meta name=generator> exception

From: Michael[tm] Smith <mike@w3.org>
Date: Wed, 8 Aug 2012 01:43:23 +0900
To: Henri Sivonen <hsivonen@iki.fi>
Message-ID: <20120807164322.GC68105@sideshowbarker>
Cc: WHATWG <whatwg@whatwg.org>
Henri Sivonen <hsivonen@iki.fi>, 2012-08-05 16:01 +0300:

> On Sat, Aug 4, 2012 at 9:08 AM, Michael[tm] Smith <mike@w3.org> wrote:
> > Agreed. I support making having some kind of "trial period" like what you
> > describe, or a year or two or 18 months. If we do that I would prefer that
> > the spec include some kind of note/warning making it clear that the
> > attribute is experimental and may be dropped or changed significantly
> > within the next two years based on analysis we get back during that time.
> 
> There's a non-trivial set of validator users who get very upset if the
> validator says that the document that previously produced no
> validation errors now produces validation errors--even if the new
> errors result from a bug fix.

So are you saying that we should never remove anything once it's been added
to the spec? Or that we should never add anything to the spec without being
certain that it's the right solution and we're going to keep it?

There's clearly also a non-trivial set of users who get very upset when
features are removed from the spec. Witness the <time> debacle.

I don't think we have sufficient evidence to suggest that adding this
attribute is absolutely the right way to solve the problem you've outlined.
As Chaals has noted elsewhere, the problem you've described is a
social-engineering problem, and I'm not sure a markup-based solution is
actually going to fix that problem. But I think it's worth trying at least
-- as long as we retain the option to drop it if we don't end up with data
to show that it's actually ended up having the effect we hoped for.

> In my experience, handing out badges makes people more upset if the
> criteria behind the badge changes, but even without badges, it seems to
> me that the sentiment is there.
> 
> Therefore, if you tell people that if they use a particular syntax
> their document might become invalid in the future, chances are that
> they will steer clear of the syntax when an easier alternative is
> available--just writing alt="".

So to avoid that, the alternative is to not state clearly and honestly up
front that we're adding it experimentally? And instead a year or two from
now when we look back at this and maybe find out the experiment has not
worked out the way we hoped, we drop the attribute anyway -- without ever
having been clear about that fact that is was experimental to begin with?

> So adding a warning that the syntax is experimental is an almost certain
> way to affect the outcome of the experiment.

Yeah, sure. But I don't see much way around that, if it is actually an
experiment.

> On the other hand, not warning people and then changing what's valid is
> likely to make people unhappy.
> 
> It seems to me that running an experiment like this will either result
> in a failed experiment, unhappy people or both.

So what alternative do you suggest? We add the attribute with the agreement
that we're never going to drop it, no matter what? Even if we later learn
that it's not having the effect that we hoped for?

> If an experiment on this topic was to be run, what would you measure
> how would you interpret the measurements?

First off, very simply: Are any generator tools actually generating this
attribute at all? If a year or two from now, no generators are actually
generating it, then there would be no point in keeping it in the spec.

Beyond that, we can measure if it's actually being used in a way that
conforms to the spec, instead of being abused. For example, we might find
that there are tools that are generating the attribute but that shouldn't
be. Or we might find that users are manually adding it do their images just
to shut up the validator.

  --Mike

-- 
Michael[tm] Smith http://people.w3.org/mike
Received on Tuesday, 7 August 2012 16:43:55 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:44 UTC