W3C home > Mailing lists > Public > public-html@w3.org > August 2007

Re: 9. WYSIWYG editor (enforcing the signature)

From: Mihai Sucan <mihai.sucan@gmail.com>
Date: Sat, 04 Aug 2007 20:16:14 +0300
To: "Robert Burns" <rob@robburns.com>
Cc: "Ian Hickson" <ian@hixie.ch>, public-html <public-html@w3.org>
Message-ID: <op.twjoxcpfmcpsjgr0b0dp@localhost.localdomain>

Le Sat, 04 Aug 2007 16:37:27 +0300, Robert Burns <rob@robburns.com> a  

> On Aug 4, 2007, at 4:10 AM, Mihai Sucan wrote:
>> Others suggested the use of the Strict/Transitional terminology. I  
>> don't agree with it, because it's not appropriate in this context.
> Well, I think whether strict/transitional is an appropriate distinction  
> probably depends on what problem we're trying to solve here. We have no  
> clear agreement on what constructs we're even talking about here.  
> Suggestions related to WYSIWYG  editors include:
>   • Use of FONT
>   • Use of @style
>   • Use of DIV with an inline content model
>   • Use of B and I elements
> Except for FONT [1], none of these strike me as representing anything  
> like low-quality markup (I'm thinking here mostly about semantics). I  
> would expect to see DIV (even with inline content model), SPAN, possibly  
> B and I and even @style in well done semantic pages.

Quoting Ian Hickson:

"We still need a better solution for handling the two tiers of
document quality, one targetting humans (who can know what they mean) and
one targetting today's computers (who rarely know what humans mean), but
I'm not sure what it is. One possibility I've considered is to just have
two conformance levels, "conforming html5 document" and "conforming
low-quality html5 document", with <font>, style="", and
<div>s-containing-inlines kicking documents into the second category."

Documents are written in two main ways: by humans, or by applications. The  
quality of the code written by humans is generally much better. Yes, many  
learners do make mistakes, but they don't go too far - not beyond the  
sites they make. Code generated by a WYSIWYG editor goes very far,  
thousands of users, thousands of sites, etc. The code quality can't be  
superior, nor can it match human code quality.

This is the problem: how do you tell in the code that the document code is  
of high/low quality? Such that editors and automated tools can insert the  
signature, and/or use it for some purpose. A purpose that has yet to be  
defined by the one who initially proposed making the difference between  
high and low quality documents.

> Earlier, I had also said we might want to require DIV and SPAN elements  
> to have at least one of the global attributes. That's something that I  
> think helps ensure documents are authored in a semantic and accessible  
> way.

Requiring at least one of the global attributes for the DIV and SPAN  
elements does not help making documents more semantic, nor accessible.

Currently, CSS lacks lots of features needed by Web authors, and as is  
known, they sometimes (often) abuse DIV and SPAN. I'd say: don't change  
the spec in any way which makes it even worse for Web authors.

>> It's non-trivial (if not impossible) for a machine to make the  
>> difference between high/low quality code. The style attribute should be  
>> allowed in "high quality" documents too, same goes for DIVs and SPANs.  
>> The one left is the FONT tag.
> I think FONT is the one we can safely deprecate. However, this is true  
> whether the editor is WYSIWYG or otherwise. So its not really needed in  
> the strict/transitional (or strict/loose or whatever) distinction we're  
> trying to make.

As I said in my previous email: I am not "fond" of the FONT element. It  
may be removed. No problem.

>> [...]
>> <meta name="edit-modes" content="human, tool, WYSIWYG, CMS">
>> [...]
>> This would provide an improved indication of code quality. .
> There may be reasons to provide this metadata (I think I would want the  
> modes to only show once for each mode with the latest editing mode  
> appearing last in the list) However, I do not think it provides any  
> indication of quality. All of these modes should take care to ensure it  
> doesn't create low quality markup. If these various tools take those  
> steps then I see no reason to rank one above the other in terms of  
> quality..

In my proposal, the order in which the edit-modes are listed does not  
matter, unless the "logging" method is used.

Actually, it provides a quite good indication of quality, especially the  
"logging" method.

The Edit-modes proposal includes the WYSIWYG editor signature which even  
made it (for now) in the spec. A signature which was highly contested and  
now will be removed from the spec in due course.

You also have signatures for unlimited "circumstances" that change the  
document, either tools, CMSs, humans, and ... actually, edit-modes could  
allow any arbitrary set of tokens to be specified - while defining several  
general tokens (like CMS, WYSIWYG, human, tool, etc).

Like I previosuly said, you cannot have a "thumbs up" nor a "thumbs down"  
meta-tag, which hints at the code quality being high or low. It's  
impossible, because code is not a matter of black and white. My proposal  
for edit-modes provides a middle ground. The edit-modes meta-tag gets  
uglier by time, just like the code gets.

Edit-modes allows for UAs (e.g. parsers, or bots for special purposes) to  
define the quality of the code on arbitrary algorithms, taking into  
consideration how many variations are in the edit-modes meta-tag, how bad  
the code is actually (any DIVs? any SPANs? any FONTs? any STYLE  

If people want, the edit-modes can be used just like a "thumbs up/down"  
meta-tag. You can check if edit-modes=human or if it contains WYSIWYG.  
It's trivial.

Given you are able to see how many variations, how many types of edits the  
document went through its life time ... we can estimate how bad the code  
is. The fact all edit-modes are recorded just helps estimating the code  
quality. We assume WYSIWYG editors generate a lower quality code than  
humans write (in general, in most cases). It's also fair to assume that  
additional tools and WYSIWYG editors make the code even worse.

>> Now, the spec could hint at which edit-modes indicate high/low quality  
>> documents. However, the spec must not set in stone what's defined  
>> high/low quality.
> This seems completely opposite. If we provide no criteria for what is  
> low and what is high quality, then how can we expect anyone, operating  
> in any edit mode to achieve high or low quality markup.

I didn't say to not define any criterias *at all*. It's just you cannot  
expect the criterias you write *now* in the spec will still be valid  
tomorrow (or in a few years). They should not be set in stone, because  
"quality" is subjective.

>> The edit-modes suggestion could have a wider range of applications,  
>> than simply having a meta-tag "thumbs up" (high quality) or "thumbs  
>> down" (low quality).
>> One of the advantages of edit-modes is, you get to see the "quality" in  
>> a single tag, without checking the document. This is *without* directly  
>> telling the quality.
> Again, this may be interesting metadata, but no one should draw any  
> conclusions about the quality of a document from it (that's something we  
> should say in the recommendation if we include this metadata).

I think you can draw much better conclusions about the quality of a  
document from edit-modes, compared to the WYSIWYG editor signature, or to  
any "thumbs up/down" meta-tag. It's also better (and faster) than checking  
the document if it makes use of the STYLE attribute, or of the  
SPAN/DIV/FONT elements.

Received on Saturday, 4 August 2007 17:16:23 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:15:25 UTC