Re: 9. WYSIWYG editor (enforcing the signature)

On Aug 4, 2007, at 12:16 PM, Mihai Sucan wrote:

>
> Le Sat, 04 Aug 2007 16:37:27 +0300, Robert Burns <rob@robburns.com>  
> a écrit:
>
>>
>> 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.

Earlier I said [1]:
"I do not understand what WYSIWYG editors have to do with 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)."

> 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.

You cannot do it by labeling them as WYSIWYG produced. There's  
nothing in the difference between WYSIWYG  produced and non-WYSIWYG  
produced that can tell you about the quality. The actual distinction  
I would make (if we're going to make a distinction) would be between  
semantic editors and non-semantic editors. Perhaps many (or all)  
current WYSIWYG editors are also non-semantic editors, but there's  
nothing that requires that link. By labeling WYSIWYG as the problem,  
there's nothing the editors can do to fix themselves. If we label non- 
semantic as the problem then there's an improvement the editors can  
make if they don't want to be labeled poor quality. It also raises  
awareness among hand  editors who will look into what this  
distinction means. Just to clarify with an example, a semantic editor  
would expose both "emphasis" and "italics" as menu items and map them  
to EM and I respectively in the produced source. A non-semantic  
editor, on the other hand, would only provide an italics menu item  
and would map this to the I element in all cases. It would never make  
use of the EM element (to do so would be a very serious conformance  
violation; not just non-semantic low-quality code).

>> 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.

No, it certainly does make documents more semantic and accessible.  
DIV and SPAN are generic. The reason editors should use a DIV or SPAN  
in a high-quality document is to apply one of the global attributes  
to a block of text or run of text respectively. A DIV or SPAN without  
a global attribute basically says the author has a reason for  
distinguishing this text from all the rest, but leaves the reason for  
doing so completely out of the picture. Requiring authors to ad @id,  
@irrelevant, @title, @class, @role, or @xml:lang at least improves  
the situation. Adding any of those adds meaning to the otherwise  
generic element. I would also add that we should encourage the use of  
semantically centered thinking with the application of @class  
attribute values rather than @presentational-centered thinking. For  
example authors wanting to make all blocks of side notes into "green"  
text should use a @class name like "side-note" rather than "green".  
Either could be used to accomplish the same styling. But the former  
is a more semantic, more accessible, and more maintainable approach.

> 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.

Providing guidance to authors (changing the spec in some way) can  
help reduce the abuse of DIV and SPAn by providing authors with  
further guidance on how they should be used properly.

On the remainder of your reply, I'm fine with the proposal for edit- 
modes proposal. It does provide metadata of interest. I think we  
don't want to log every change in edit mode because that would grow  
very long and encourage authors to toss-out the whole thing to save  
band-width.

However, I don't think WYSIWYG has anything inherently to do with  
poor quality documents. All of these tools should meet the needs of  
human authors. So we're always talking about human's editing document  
whether WYSIWYG or not, whether GUI or not, whether visual or not. I  
know some of our WG members live in California, but we don't really  
have to worry about some Terminator-like future where the California  
governor starts editing all of our HTML in some uncontrollable  
way. :-). Even the machine editing is human-driven (so far :-) ).

Take care,
Rob

[1]: <http://lists.w3.org/Archives/Public/public-html/2007Aug/0195.html>

Received on Saturday, 4 August 2007 20:18:02 UTC