- 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>
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. 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 attributes?). 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. -- http://www.robodesign.ro
Received on Saturday, 4 August 2007 17:16:23 UTC