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

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

Received on Sunday, 18 July 2010 12:00:49 UTC