RE: comments on 'private use' section of proposal - Sanity check

-----Original Message-----
From: public-html-request@w3.org [mailto:public-html-request@w3.org] On Behalf Of Steve Axthelm
On 2010-07-19 Charles McCathieNevile <chaals@opera.com> wrote:

>>But hand-authoring HTML email? I have never heard of someone doing
>>that. I presume it is possible, but I don't know of any software that
>>supports it and I don't know of anyone who uses /usr/ucb/mail and
>>sends HTML mail, or writes their email in HTML by hand and uses a
>>custom tool to push it to an SMTP server. I seriously doubt that such
>>people exist in triple-digit numbers, to be honest.

> Email "blasts" to marketing lists are often authored by hand (or 
> use templates that were originally authored by hand.) You're 
> talking a _lot_ more than triple digits there.

I think this is getting us further away from the issue here, which is that HTML-based email is only a distant relative to HTML:

1) Much of the functionality of HTML in email is stripped away for reasons of security (including forms and access to CSS, script or plugin content);
2) The UAs are either browsers (most likely in quirks mode due to the contortions this garbage puts them through) or MUAs with some limited HTML functionality tacked on--functionality which, over the last decade, has only seen the addition of support for rudimentary inline CSS;
3) Layout is done using tables; and
4) Text is laid out almost exclusively using <font>.

Support for "HTML" in email is limited to the LCD of a handful of ancient renderers. Those who build HTML-based emails are dealing with de facto limitations of the MUAs, and a smattering of best-practice guides. The link to any documented specification for HTML at this point is almost vestigial. 

Which is what makes all this maneuvering over "private" use so quixotic. Nobody in the HTML-as-email ecosystem, be they UA vendors or content providers, has any real use for HTML5, and if they ever do, they're not going to need special dispensation from the spec to do what they want with it. They're going to see an element they want to use, and then they're going to print out the spec, cut it up and make their own version of it out of papier-mâché. Making an exception for this specific case has no purpose, because these authors couldn't care less about conforming content. They care about faithful reproduction against a set of stable (if moribund) UAs and MUAs.

I think we all get that there will be cases where an img element will be transmitted without an associated src attribute from one user to another, over this or that protocol. In the case of HTML as email, however, the specification as it stands is overspecifying this case, for whatever reason, while being completely silent on the numerous other gaps between HTML5 and the use cases for HTML within an email.

I see two ways to solve this:
1) Declare HTML-in-email as a use case for which HTML5 intends to be comprehensive. Then spend as much time as is necessary to create authoritative guidance for implementers in that world to support HTML5 given their architectural constraints; or
2) Accept that there are use cases for the transmission of rich text that have used or will use some version of HTML as a baseline, and don't try to boil the ocean solving them all in the name of a singular definition of conformance.

If 2 above is the sense of the WG, then the "private use" exception should be removed.

-
m

Received on Monday, 19 July 2010 19:55:45 UTC