- From: Robert Burns <rob@robburns.com>
- Date: Tue, 14 Aug 2007 01:06:04 -0500
- To: HTMLWG WG <public-html@w3.org>
Split chapter into other UA chapters: part of my review of 9 WYSIWYG editors <http://dev.w3.org/cvsweb/~checkout~/html5/spec/Overview.html? rev=1.78#wysiwyg> Summary ------------------------------------------------ • Another chapter should cover sending and receiving Mail • Another chapter should cover content management solutions (including wikis) • add the @datetime attribute to Q and BLOCKQUOTE elements Introduction ------------------------------------------------ Earlier, in my review of WYSIWYG editors, I suggested re-focussing that chapter on visual editing UAs; non-semantic editing UAs; and converting UAs that convert from non-semantic formats. I included those topics, because I sensed that was the spirit that the chapter was addressing (even if it was off the mark a bit). In that earlier segment of this review, I accidentally included the two summary items for this portion of the review. I turn to those topics now. HTML in email ------------------------------------------------ Since HTML has become the de facto standard for rich text email, I think it is important for our recommendations to address the topic. Email has many issues that are beyond my own immediate knowledge. It has to include HTML and all the associated resources in the same message. Many ad hoc conventions have developed surrounding email. Some clients may be capable of consuming a wide-variety of HTML-like content, while producing a very narrow form of HTML-like content. I think it would be a good idea for the WG to bring its collective knowledge together to address these issues. Here's some very basic statements regarding what I think such a chapter should say. Receiving and displaying HTML5 email ------------------------------- HTML5 email conforming UAs must be capable of processing and displaying all HTML5 content. When displaying HTML5 email, UAs should present nested quotations in different colors or with different voices in a manner similar to RFC 2646[1]. UAs should extract the contents of the @cite attribute on Q and BLOCKQUOTE elements and present those before the quotation with either the raw URI or a suitable transliteration from the a address book or directory service. If a Q or BLOCKQUOTE includes a @datetime attribute UAs may also display this data prior to the quotation. UAs may allow user style sheets or other preference items to override this default presentation. Composing and sending mail ------------------------------- HTML5 email conforming UAs must be capable of accepting and preserving pastes of any HTML5 content and displaying all HTML5 content. Ideally, an HTML5 conforming email UA should provide a mechanism for authors to compose semantic email (exposing EM and STRONG as well as tables and lists). When an email author quotes another message in a newly composed message the UA must include the quoted material in a BLOCKQUOTE element with one or more nested P elements. The UA must tag the quote with a mailto: or other suitable URI for the @cite attribute and should set the @datetime attribute with the date and time of the original message in UTC with an offset of 0. Processing of mail ------------------------------- A web-based email archive should preserve either the text/html or application/xhtml+xml portions of any email message. A web-based archive may also store the text version of the message, or could deploy a special TTY media style sheet for delivery to suitable client UAs. There may be other processing applications we want to address. Preserving text/html and applicaiton/xhtml+xml and application/xml content (or at least one of the three) would be crucial. The idea here is to push applications to aspire to be HTML5 conforming applications: even those not traditionally understood as HTML applications or browsers. Content management systems (including wikis) ------------------------------------------------ I think we should also address the content management systems out there. Sometimes even stating the obvious can improve the situation dramatically. Content management systems should allow all HTML5 elements and attributes unless a particular element or attribute raises a security concern. There's probably a lot more we can say about content management systems (I would include wikis under this), but I'd rather get the whole WG thinking about these issues. Some of what has already been said about visual and non-semantic editing UAs and non-semantic conversion UAs could also be said about content management systems that convert or allow non-semantic or visual authoring. A section on content management systems could refer to those sections. Alternatively, the content management systems could simply receive some mention in the other chapter. [1]: <http://www.ietf.org/rfc/rfc2646>
Received on Tuesday, 14 August 2007 06:14:36 UTC