W3C home > Mailing lists > Public > public-html@w3.org > August 2012

Re: img@relaxed CP [was: CfC: Close ISSUE-206: meta-generator by Amicable Resolution]

From: Smylers <Smylers@stripey.com>
Date: Wed, 1 Aug 2012 12:31:32 +0100
To: public-html@w3.org
Message-ID: <20120801113132.GA1625@stripey.com>
Janina Sajka writes:

> Mike ... but you make a statement in the core of your argument I
> simply must challenge you on.
> 
> Mike writes:
> 
> > the need to help developers in those environments "catch markup
> > errors that they can do something about, without bothering them
> > about markup errors they can't do anything about."
> 
> You use the plural "markup errors," but I see only one error as the
> target of this CP

Hi Janina. It looks like the phrase "markup errors" is one of those
English terms that can have two different -- but equally valid --
meanings. Certainly I interpreted it differently from how you did on
originally reading that text.

I'm not claiming my reading of it is the correct one, but it doesn't
create the contradiction that is concerning you with your
interpretation.

Suppose a webpage contains 2 <img> elements that don't have an alt
attribute and also has a <section> tag without a corresponding
</section> tag.

That could count as 3 errors in the page:

* alt missing from the first <img>
* alt missing from the second <img>
* missing </section>

If the page has been created by batch processing, then the developer of
the batch processing system (including associated templates) may
consider the first 2 errors (plural) to be ones that she can't do
anything about.

Obviously if you count the number of different types of error in a page,
(rather than the number of instances of those types) then there are only
2 errors in the above list, and as such just 1 that the developer feels
she can't do anything about.

I happened to interpret the phrase in the first way. Can you see that it
could also have that meaning, and that with that interpretation it
doesn't suffer from the problem you raised?

And if so, that _if_ that is the meaning intended by the writer, then
there's no dishonesty on the writer's part (merely happening to use a
phrase for which you discovered a second meaning he hadn't considered)?

In which case, it seems premature to make accusations of dishonesty
without first clarifying which meaning was intended:

> When there's only one use case and only one error being evaded, it's
> dishonest to claim a generalized approach to multiple "errors." Now,
> I've not found you to be dishonest, <Snip>

Clearly you have a serious concern here, and any ambiguity in the change
proposal needs sorting out. But it might be that no dishonesty was
involved.

The issue of whether to allow empty alt attributes for pages generated
by batch processes, and if so how, is an important one. I haven't yet
made up my own mind on the matter; I'm hoping to do so by considering
the arguments put forth by those advocating various positions -- as, I
would expect, are many others.

For some reason this mailing list can sometimes seem quite a hostile
place, more so than other technical lists I read.

Possibly I'm being over-sensitive, but I find that hostility
off-putting, and it makes me less likely to want to read mails in a
thread, and harder to find the technical merits of proposals when I do.
That means I'm less likely to actually get as far as forming an opinion,
rather than quietly backing away and leaving it to others.

As such, accusations of dishonesty -- particularly in situations where
depending on the interpretation one reads into some words there may not
be any dishonesty involved anyway -- push me away from being involved.

I want to help shape HTML. More specifically, I want to help the group
form the best opinion it can on the issue of what to do about alt
attributes when batch processes create pages containing images. It's
hard to be enthusiastic about doing that in a hostile environment.

Best wishes

Smylers
-- 
http://twitter.com/Smylers2
Received on Wednesday, 1 August 2012 11:32:01 UTC

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