- From: Robert Burns <rob@robburns.com>
- Date: Sat, 4 Aug 2007 15:17:16 -0500
- To: Mihai Sucan <mihai.sucan@gmail.com>
- Cc: Ian Hickson <ian@hixie.ch>, public-html <public-html@w3.org>
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