Re: WYSIWYG editing: execCommand & co

Justin James wrote:
> Sam –
>
> I think that your suggestion is the better way to do it as well. Simply put, <font> was deprecated for a good reason, namely that one of the major intentions of HTML 4 seems to have been to remove style-specific tags in favor of  CSS; thus, <i>, <b>, <font>, and so on were all made obsolete; for users wanting to apply semantically meaningless style (such as a ship name needing to be italicized), there is <span> and <div>, and for cases where you need something to stand out, there is <strong> and <em>, and it *just so happens* that every major browser’s default, built-in style sheet makes <strong> synonymous with <span style=”font-weight: bold;”> and <em> the italic version. This is why, when authoring HTML, I *always* define <strong> and <em> to be precisely what I want them to be, and do not use them merely for stylistic reasons. But I am also in the small minority of HTML authors who have read the spec and try to follow it.
>
> It is unfortunate that tool authors are forced to make a choice between doing things in a simple, straightforward manner, and doing this in a way that generates correct output. I think, given the widespread usage of widgets like FCK Editor, that it may be time for us to consider a form widget to assist with this. For example:
>
> <input name="htmleditor" ID="htmleditor" type="richtext" doctype="HTML5" bodytext="<p>Hello world! It is <em>really</em> good to be here tonight!</p>" />
>
> The spec would then instruct the user agent that it should render the contents of @bodytext over the area of the input element on the screen as if it were HTML unto itself. Upon form submission, @bodytext would be sent as the value. This is an EXTREMELY rough outline of what I am envisioning, but I think that if we start with this as the kernel for the idea, and shape it to meet the rest of the spec in intent and usage, etc., that we would have a big win for usability, accessibility, tool authors, browser authors, and users over all. It would unlock huge swaths of possible functionality, make it easier for application writers who might need something like this without a full HTML editor, and so on.
>
>   
I've implemented this as [1]:

<richtext content-style="richtext.css" tools="toolbar-selector">
    Hello <em>World</em>
</richtext>

The <richtext> has CDATA inside parsing model, thus its content is not a 
part of the page but
rather bodytext of yours.
The richtext accepts subset of HTML -  only those features that can be 
WYSIWYGed in
non-contradictory manner.

@content-style points on style sheet that uses a subset of CSS for the 
same reason as above.
That style sheet is allowed to define only simple selectors like: tag 
{}  and tag.class {}
Internal implementation parses this CSS and builds UI (@tools) for the 
user.  For example set of rules:
em {...}
em.cool {...}
em.nice {...}
will make a dropdown list for the user under the button "em" with 
options {default} | "cool" | "nice" .

And no other styling is allowed to be edited from user side. In 
principle. I suspect that having such input element is the only way
to provide acceptable WYSIWYG that will produce semantically meaningful 
markup.

--
Andrew Fedoniouk.
http://terrainformatica.com

[1] 
http://www.terrainformatica.com/wiki/doku.php?id=h-smile:built-in-behaviors:richtext

> J.Ja
>
> From: public-html-request@w3.org [mailto:public-html-request@w3.org] On Behalf Of Sam Kuper
> Sent: Wednesday, May 14, 2008 11:52 AM
> To: Frederico Caldeira Knabben; HTMLWG
> Subject: Re: WYSIWYG editing: execCommand & co
>
> 2008/5/14 Frederico Caldeira Knabben <fredck@fckeditor.net>:
>   
>> FWIW, I don't think that generating <span style="font-size:small"> is any
>> better than generating <font size="2">.
>>     
> I completely agree with you Anne.
>
> Dear Fred,
>
> Might it not be an idea to have FCKeditor generate <span class="foo"> (where foo is some class picked from a list of presets or created by the user) and also generate a .css file with .foo {font-size: small} ?
>
> [For what follows, I'm still thinking in HTML 4.01 - I've not yet considered the future of the LINK element in HTML5]
> Of course, if FCKeditor doesn't have access to the <head> of the HTML document in order to add a <link> to the CSS file, this could be a problem. Perhaps it could be solved by allowing the <link> element to be used in the <body> of an HTML document (although maybe this would create other problems - I don't know).
> [End HTML 4.01]
>
> All best,
>
> Sam (PS. I'm sorry I haven't been in touch since Wikimania'06 - it was good to meet you!)
> --
> Mr Sam Pablo Kuper BSc MRI
> Research Assistant
> Darwin Correspondence Project
> Cambridge University Library
> West Road
> Cambridge CB3 9DR
> spk30@cam.ac.uk
> Office: +44 (0)1223 333008
> Mobile: +44 (0) 7971858176
> www.darwinproject.ac.uk 
>
>

Received on Wednesday, 14 May 2008 18:21:01 UTC