Re: 9. WYSIWYG editor (enforcing the signature) detailed review of

Le Fri, 03 Aug 2007 21:19:37 +0300, Sander Tekelenburg <st@isoc.nl> a  
écrit:

> At 12:46 +0300 UTC, on 2007-08-03, Mihai Sucan wrote:
>
> [...]
>
>> I don't "like" the above scenario. Having the document as valid, is ...
>> practically... at the "mercy" of the generator meta-tag. I do not  
>> consider
>> this anywhere close to "appropriate".
>
> Fully agreed.
>
> Some other problems are
>
> - The lack of definition of "WYSIWYG editor". (Even a Word imitator like
> FCKEditor may present content as it would be rendered, or only partially  
> so,
> or as uninterpreted markup, depending on (level of) javascript support,  
> and
> settings of both the authoring system and the client. In which cases  
> would
> the "WYSIWYG editor" signature be required/not allowed?)

That's another good point. I "touched" this issue marginally by mentioning  
that, yes, editors like Dreamweaver should include the "WYSIWYG editor"  
signature, but not embedded editors, used together with an entire CMS.

In the current situation CMS authors would be required to include the  
signature in all pages generated, because they can't trivially ensure that  
FONT is not used on some page - if they want to have valid code. I'm  
stressing the point about content management systems, because they play a  
major role in the ever-growing tag soup available on the Internet.

If this signature is to be required, then a clear definition what is a  
"WYSIWYG editor" must be made. Yet, one cannot expect a general  
definition, since there are at least two major types of editors:

- Web authoring tools: NVU, Dreamweaver, etc. which generate the entire  
code, including the document HEAD.
- Embedded editors: editors like FCKEditor, HTMLArea, Awebitor, and many  
others. These are used for editing document fragments, which are included  
the page output (blog articles, news articles, page content, etc).

There are, of course, Web-based HTML document authoring applications,  
which try their best to allow complete control over a HTML document. These  
Web applications should be included in the same category as Dreamweaver  
and friends.

As Jason White pointed out, it's inaccurate to define file converters as  
"WYSIWYG editors" - yet, semantically they can generate code of about the  
same quality as any WYSIWYG editor.

You could also call "file converter" a HTML document cleaner. Should this  
be required to also include the signature? I believe not, since the  
purpose of the cleaner tool is to produce code as "human-like" as possible  
(e.g. semantical) - eliminating any of the "cruft" from WYSIWYG editors.  
However, it's obvious that no tool can guarantee accurate semantical code  
(beyond a marketing campaign).


> - The fact that that "WYSIWYG editor" is usually an embedded app within a
> larger app, not writing at all to <head>. So it is the host app that  
> needs to
> 'know' whether content was provided through an editor that is to be
> considered "WYSIWYG". My impresson of authoring systems is that they try  
> to
> avoid such complicated interweaving. For instance because one one the  
> same
> system is designed to allow embedding different editors (be they  
> "WYSIWYG" or
> not). Is there a strong enough need to impose such implementation  
> challenges
> to authoring tools?
>
> - How should the host app deal with situations in which content is  
> entered
> through a "WYSIWYG editor", than edited through a non-"WYSIWYG editor",  
> or
> vice versa?

On this matter, I'd say the host app does not need to deal differently  
with code written manually or with a WYSIWYG editor.

I can speak only based on my experience: my CMS does not make such  
distinction. The editor generates the code, as is, with no changes for  
cleanup, absolutely nothing. The output, obviously varies across UAs. For  
that, I only integrated a document cleaner tool - which can focus only on  
cleanup, doing a much better job than a JS-based approach can. Thus, in  
the big picture: the host app, the editor, and the cleaner are all  
independent, each can be replaced by something else which fills the same  
role.


> Note that this issue was raised a while ago on the whatwg mailing list.  
> The
> question why an authoring tool in specific would need to be allowed to  
> insert
> <font> was not really answered IIRC. If I'm not mistaken, the one or two
> authors of "WYSIWYG editors" that participated didn't appear to see a  
> real
> need to be allowed to output <font>.

Hmm... yes, that's interesting. The "new FONT tag" is the SPAN now, with a  
style attribute. Every use of the FONT tag can be substituted with a SPAN  
and a style.

I would agree dropping the FONT element and the "WYSIWYG editor"  
signature, both in a row. This would be better than the current situation.



-- 
http://www.robodesign.ro

Received on Friday, 3 August 2007 19:54:12 UTC