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: Janina Sajka <janina@rednote.net>
Date: Tue, 31 Jul 2012 22:01:57 -0400
To: Steve Faulkner <faulkner.steve@gmail.com>
Cc: "Michael[tm] Smith" <mike@w3.org>, public-html@w3.org, "Edward O'Connor" <eoconnor@apple.com>
Message-ID: <20120801020156.GE12889@concerto.rednote.net>

Your suggestion to generalize this tag makes more sense to me than Ted's
CP, but only a little. In the first instance, we should have some
legitimate use cases for it. But, more importantly, we should consider
whether providing an auto opt-out tag is what we really want to supply.
Do we really believe site developers know more about what is legitimate
to exempt from checking than the standards development body that has
painstakingly developed their standards? Why would we believe they'd
make intelligent decisions about privacy, security, i18n, or a11y? Isn't
that simply ceding the most important reasons for user-centered
standards? If we're going to give that power away, why bother developing
the specs in the first place? Because, by so doing, we reduce them to
suggestions of convenience.

I, for one,  don't trust my accessibility to some developer's


Steven Faulkner writes:
> Hi Mike,
> you wrote:
> "When users attempt to validate documents and end up getting a large amount
> of error messages about potential problems which they have no means to
> correct directly themselves, we risk having them just give up and quit
> using the validator altogether."
> i would think this is a concern for more than alt errors, there are many
> potential errors emitted that may or may not be under the authors control,
> such as the use of custom attributes on any element, would it not makes
> sense in this case to allow the relaxed attribute to be a global attribute
> on usable on any element?
> regards
> SteveF
> On 1 August 2012 01:58, Michael[tm] Smith <mike@w3.org> wrote:
> > Edward O'Connor <eoconnor@apple.com>, 2012-07-31 15:13 -0700:
> >
> > >          http://www.w3.org/html/wg/wiki/User:Eoconnor/ISSUE-206
> > >
> > > While this Change Proposal is both concrete and complete, I intend to
> > > solicit comments from conformance checker developers which may result in
> > > testimonials I would like to cite in the Rationale section.
> >
> > Speaking personally and only with my conformance-checker-developer hat on,
> > I strongly support this change proposal. I've not talked with Henri about
> > it yet, but if he were also supportive of it, then it's something we would
> > implement support for in the validator.nu sources (on which both the
> > validator.nu service and W3C Nu Markup Validation Service are based).
> >
> > Some specific parts of the CP that lead me to express support for it:
> >
> > 1. I agree with the statement in the CP which asserts that the general use
> > case this CP is attempting to address is an important use case to address.
> > The use case is valid, and I think we should all work together to try to
> > find out a way to address it that we can all agree on. This CP seems to me
> > to be the most viable CP for this issue so far that we actually have a
> > chance of getting agreement on.
> >
> > 2. The observations in this CP about the need for "granular relaxation" for
> > this use case are particularly important and need to be considered; I
> > believe in particular the following statement makes an important point:
> >
> >   "The markup of large Web applications is typically partly generated from
> >   code and partly sourced from hand-authored HTML templates. With an
> >   all-or-nothing mechanism, there's no way to relax the conformance
> >   criteria for only the portions of the document corresponding to
> >   user-generated content, while retaining strict requirements on the
> >   portions of markup from the hand-authored HTML templates.
> >
> > This CP addresses that particular use case. The meta@name=generator
> > exception currently in the spec does not.
> >
> > 3. Related to #2, I agree with the following assertion about the positive
> > effects of this proposed change:
> >
> >   "We enable engineers of large Web applications to catch markup errors
> > that
> >   they can do something about, without bothering them about markup errors
> >   they can't do anything about."
> >
> > That's something which is of real-world concern to validator developers.
> > When users attempt to validate documents and end up getting a large amount
> > of error messages about potential problems which they have no means to
> > correct directly themselves, we risk having them just give up and quit
> > using the validator altogether. This is of very practical concern for
> > anybody maintaining a validator: You want users to keep using your
> > validator
> > and to have the validator match their real-world needs as much as possible.
> >
> > Anyway, in summary and as I mentioned in #1, I think this CP provides a
> > resolution that we have a good chance of getting agreement on among the
> > people in the group who so far have been unable to reach agreement on it.
> > So I hope everybody involved can consider it very carefully, with an open
> > mind.  It's not a perfect solution for the problem. We're not going to find
> > a perfect solution. But this is the best solution I've seen so far.
> >
> >   --Mike
> >
> > --
> > Michael[tm] Smith http://people.w3.org/mike
> >
> >
> -- 
> with regards
> Steve Faulkner
> Technical Director - TPG
> www.paciellogroup.com | www.HTML5accessibility.com |
> www.twitter.com/stevefaulkner
> HTML5: Techniques for providing useful text alternatives -
> dev.w3.org/html5/alt-techniques/
> Web Accessibility Toolbar - www.paciellogroup.com/resources/wat-ie-about.html


Janina Sajka,	Phone:	+1.443.300.2200
		Email:	janina@rednote.net

The Linux Foundation
Chair, Open Accessibility:	http://a11y.org

The World Wide Web Consortium (W3C), Web Accessibility Initiative (WAI)
Chair,	Protocols & Formats	http://www.w3.org/wai/pf
	Indie UI			http://www.w3.org/WAI/IndieUI/
Received on Wednesday, 1 August 2012 02:02:23 UTC

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