WYSIWYG, GUI, visual and non-semantic editors: final part of my review of 9 WYSIWYG editors

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