WYSIWYG signature/UNREADY signature

Semantic mark-up requires two things - from any author: forethought and 
afterthought.

Thus, Section 9, which permits <FONT> for WYSIWYG tools (via the WYSIWYG 
signature), really only says that such authors are permitted to skip 
preplanning and post-editing. As if only WYSIWYG users have problems 
with those parts of the authoring process:

* <FONT>, in order: “to allow a way for WYSIWYG editors, which don't 
have enough information to use the "real" "semantic" elements,” [1]

However, the draft in fact “knows” that even non-WYSIWYG authors have 
similar problems, since it suggests that one should “strongly 
discourage” and “not letting it be ok” for hand-coding authors to use 
the @style attribute (which hand-coders will often use as an ad-hoc 
solution). Despite this knowledge about the similarities, the draft ends 
up expecting different things from each author group:

* “... got to find a solution to this [the <font> issue], while not 
letting it be ok for hand-coding authors to abuse the style="" 
attribute.” [2]
* “ ... we really should find a way to strongly discourage its use [the 
style attribute] [...] for non-WYSIWYG authors.” [3]

The current aproach
1) fails to set one standard for all documents
2) fails to identify the similarities between WYSIWYG non-WYSIWYG 
authoring (even non-WYSIWYG authors have a need for a "forgiving" mode - 
where they can "misuse" the style attribute, in order to see "fast 
results")
3) creates problems in mixed mileu situations (as soon as the author 
opens the WYSIWYG made document in a non-WYSIWYG tool, then other rules 
suddenly apply).

Instead, I propose this approach:

1) One goal for all documents, regardless of authoring tool.
2) An 'UNREADY signature' instead of a 'WYSIWYG signature'. When used, 
one can expect to find certain features that are typical for a document 
that is still being edited: misuse of style attributes,(perhaps) <font> 
elements, lack of @ALT attributes etc. Both hand-coding authors and 
WYSIWYG author can use it, if they need.
3) A spesification of the authoring process, which should be outlined as 
a multistep process. The final touches - the 'semantification' of the 
document, doesn't happen 'naturally' - it needs preplanning or 
postprocessing. HTML authoring is never a one step thing. (Unless the 
authoring tools offer lots of useful, premade - or interactive - 
templates which gives the author the /impression/ that is only one step.)

Post processing: Roughly something like this: When written, then 
identify elements of the document/HTML fragment with identical styling, 
classify them - and place them in style sheets. Etc. (Adding @alt texts 
could belong here.)

Afterthought, WYSIWYG: We should realise how important the after process 
often is, compared with preplanning. (At least until one has created 
some templates that can be reused.) And thus, WYSIWYG tools have no 
excuse: They too can be made to do postprocessing. I imagine that 
WYSIWYG tools could have buttons that take care of the post processing. 
And also it would be natural to have "generate class based upon the 
styling of this element" buttons. (I think there are several word 
processors that have similar features - I have at least tried one.) Such 
buttons could be used for making the document ready for public consumtion.

Aferthought, non-WYSIWYG: While separate style sheets is a brilliant 
idea, it is always a tempation to fix things "right there" instead of 
inside the separate style sheet. Therefore, hand-coding authors too need 
tools that can extract classes and stylesheets from their code.

Validation: While @STYLE and <FONT> can be useful during authoring, in 
demonstration pages and in test case pages etc, they should not be 
permitted in "for consumtion" pages. And thus should _not_ be allowed to 
be stamped with the W3 Validation stamp. Merely the use of the "UNREADY 
signature" should prevent it from validation. Since such documents are 
UNREADY, they need not validate.

The point of these proposals is to make us have more realistic approach 
to the creation of authoring tools. Realising the multistep nature of 
HTML authoring is crucial, I think. If we say that authoring is a 
mulistep process, then we should try to identify the steps and spec them.

[1], [2], [3]: see the section about the “the font element” in the draft.
-- 
leif halvard silli

Received on Monday, 10 March 2008 20:16:03 UTC