Re: comments on 'private use' section of proposal for ISSUE-31 AND ISSUE-80

hi benjamin,

>It have to confess it does seem unlikely to me that popular email clients
will block the sending of an email because it is missing a >human-authored
text alternative for an image, regardless of what the spec says. Does it
seem likely to anyone?

I don't support the idea or promote the idea that any authoring tool should
block the publication of a document unless it is conforming. Who does? is
publication blocked when an image with incorrect source is included in a
html5 document?

The email I am writing  and sending now will be non conforming I don't want
the fact that it is to stop me from sending it.

>If we had a means to flag machine-generated alternatives with an attribute,
it's possible email clients could generate such >alternatives better than
user agents and insert them if asked to send otherwise non-conforming HTML.

don't know about this.

>2. Make conformance rules that are likely to be implemented by all classes
of authoring tools, with exceptions for particular >classes of authoring
tools.

It is perfectly reasonable and possible for ALL classes of authoring tool to
provide the option for users to provide a text alternative, whether it by by
using the alt or using figure/figcaption. Can you provide an example where
it would not be, but at the same time possible to respect all other
conformance requirements?

>"Authoring tools and markup generators must generate conforming documents."

how is this to be enforced? what happens if they don't? the world stops
turning?

this should be changed to

"Authoring tools and markup generators SHOULD generate conforming
documents."

as it better reflects reality.

>It seems to me this would be a logical consequence of Laura's and Al
Gilman's argument that whether tools generate conforming >documents is a
"business-policy or personal" issue

the conformance error results in my previous email are i believe, the result
of a business decision, just as the use of the HTML5 doctype was on the
email code was a business decision, even though the code itself doesn't
resemble conforming HTML5.

>I'd recommend raising any conformance changes you clearly identify as
necessary for email clients as a class as bugs.

I prefer to remove the exception for allowing images without a text
alternative, keep it simple...

>Leaving aside "alt" missing on "img", would not the following code
alterations address the conformance errors raised *without* >most users
noticing any difference?

sure, what's your point? the google engineers have chosen at this time not
to do the things you list, to output a conforming HTML5 document, they could
have but didn't so the email client is non conforming authoring tool.

regards
Stevef


On 18 July 2010 13:00, Benjamin Hawkes-Lewis <bhawkeslewis@googlemail.com>wrote:

> I think email clients should provide an interface for suggesting,
> supplying, exposing, and highlighting the absence of text alternatives, same
> as other authoring tools.
>
> It have to confess it does seem unlikely to me that popular email clients
> will block the sending of an email because it is missing a human-authored
> text alternative for an image, regardless of what the spec says. Does it
> seem likely to anyone?
>
> If we had a means to flag machine-generated alternatives with an attribute,
> it's possible email clients could generate such alternatives better than
> user agents and insert them if asked to send otherwise non-conforming HTML.
>
> On 18 Jul 2010, at 10:30, Steven Faulkner wrote:
> > If we are basing conformance rules solely on what a particular email
> client or authoring tool is likely support,
>
> Don't you mean "what a whole class of authoring tools is likely to
> support", given Maciej's point was it's *not* just one particular email
> client?
>
> We have three options:
>
>   1. Make only conformance rules that are likely to be implemented by all
> classes of authoring tools.
>
>   2. Make conformance rules that are likely to be implemented by all
> classes of authoring tools, with exceptions for particular classes of
> authoring tools.
>
>   3. Ignore likelihood of implementation by authoring tools.
>
> If we followed (3), would we not be ignoring this charter requirement:
> "Availability of multiple, independent, interoperable implementations of
> each deliverable with conformance criteria;, as demonstrated by an
> implementation report (summarizing implementation status against the
> relevant test suite) for *each testable class of product*" (emphasis mine)?
>
> This could block the progress of HTML5 to a standard, unless we dropped
> this requirement: "Authoring tools and markup generators must generate
> conforming documents."
>
> http://dev.w3.org/html5/spec/Overview.html#conformance-requirements
>
> It seems to me this would be a logical consequence of Laura's and Al
> Gilman's argument that whether tools generate conforming documents is a
> "business-policy or personal" issue:
>
>
> http://www.w3.org/html/wg/wiki/ChangeProposals/ImgElement20100707#HTML5_Should_Not_Facilitate_the_Creation_of_Inaccessible_Content
>
> http://lists.w3.org/Archives/Public/public-html/2008Apr/0326.html
>
> The reason for favouring (2) over (1), as I understand it, is that it
> requires all authoring tools to create interoperable documents conforming in
> other respects, while still requiring as many tools as possible to follow a
> conformance rule judged important for users.
>
> Would you prefer (1) or (3) as a general approach, and if so, why?
>
> > then there are a lot of other exceptions we should make for email clients
> and authoring tools.
>
> This seems entirely plausible.
>
> I'd recommend raising any conformance changes you clearly identify as
> necessary for email clients as a class as bugs.
>
> However, simply pasting conformance checker output without any assessment
> of why the errors exist, whether HTML5 includes conforming features to match
> the error, and what the cost of switching to those features would be, does
> not demonstrate that the need exists in reality.
>
> Precisely what conformance exceptions do you believe are required by the
> conformance checker output you pasted, and why?
>
> Leaving aside "alt" missing on "img", would not the following code
> alterations address the conformance errors raised *without* most users
> noticing any difference?
>
>  1. Add a "title" element with the subject of the email.
>
>  2. Replace custom attributes like "idlink", "jid", "email", and "alt" (on
> "span") with data-* attributes (or microdata or RDFa).
>
>  3. Omit units on "width" and "height" attributes on "img".
>
>  4. Replace "table", "cellpadding", and "font" with equivalent CSS.
>
>  5. Replace "u" with "button".
>
> --
> Benjamin Hawkes-Lewis




-- 
with regards

Steve Faulkner
Technical Director - TPG Europe
Director - Web Accessibility Tools Consortium

www.paciellogroup.com | www.wat-c.org
Web Accessibility Toolbar -
http://www.paciellogroup.com/resources/wat-ie-about.html