Re: 9. WYSIWYG editor (enforcing the signature)

On Aug 3, 2007, at 7:13 PM, Sander Tekelenburg wrote:

>
> At 20:56 +0000 UTC, on 2007-08-03, Ian Hickson wrote:
>
>> On Fri, 3 Aug 2007, Mihai Sucan wrote:
>>>
>>> I have read the HTML 5 spec section on WYSIWYG editors [1] and  
>>> I'd like
>>> to express my concern on requiring the inclusion of "(WYSIWYG  
>>> editor)"
>>> in the META NAME="generator" CONTENT attribute value.
>>
>> I agree; in fact at this point I don't think anyone thinks it's a  
>> good
>> idea. We still need a better solution for handling the two tiers of
>> document quality
>
> Maybe it should be obvious, but it's not to me: why exactly is this  
> needed?
> UAs already need to deal with pre-HTML5 documents, and for  
> 'claiming to be
> HTML5' documents the spec defines how they must handle authoring  
> errors.

I would also add that I do not understand what WYSIWYG editors has to  
do with a poorer document conformance criteria. The very premise of  
this section seems to conflate many concepts: WYSIWYG, GUI, Visual  
(as in direct graphical manipulation of HTML objects), Visual (in any  
other sense)., etc. None of these have any inherent disadvantage when  
asked to produce / create stellar HTML5 content. (however we end up  
defining that).

On the other hand there may  be editors that do not edit HTML at all,  
but instead edit RTF or TeX or some other non-semantic format (like  
word processors or word processor emulating HTML editors). Those too  
may be WYSIWYG, GUI, Visual, etc. However, the direct manipulation of  
objects has no easy mapping to HTML. This is a chapter I think we  
should definitely write and include in the HTML5 recommendation.  
However, I do not see any reason that needs to involve FONT or any  
content models we deem invalid.

This class of editors should:
  • map bold to B and italics to I or SPAN with CSS styles defined  
for bold an italics
  • should produce valid content (including DIV content models models  
and avoiding invalid HTML5 elements like FONT) in all cases
• should make use of DIV and SPAN (with valid content) and CSS  
(however that can be validly applied) when no clear semantics can be  
gleaned

There may be other issues we should discuss explicitly in such a  
chapter that I'm not thinking of right now. However, I do not see why  
we need to make a differently conforming document for these editors.

Take care,
Rob

Received on Saturday, 4 August 2007 00:36:46 UTC