RE: WYSIWYG editing: execCommand & co

Justin, Andrew and Sam,

Let me add an important thing to this, which partially breaks your
proposals: RTEs are not used to edit HTML5 content only. Content produced
with them can be used inside web pages, but can also be injected in other
places and used in other ways. Let me illustrate some:

	- HTML5 content to be injected in a page (like news in a home page).

	- Full page HTML5 content that represents an entire page, from
<html> to </html>.

	- The same for XHTML 1.0 / 1.1, meanwhile.

	- HTML 4 content to be sent in e-mails (someone said <font> here?)

	- Contents to be used inside Flash (well... now I've really heard
<font>!)

	- Non HTML content, like BBCode or Wiki Syntax. Internally the
editor works with HTML, but its input and output is in different formats.

The above are just some few examples to show that the HTML5 specs *must not*
specify how the input or output must be, not even how to apply
formatting/semantic elements. This decision must be left to the tools
(FCKeditor), while the UA must provide features to make all that doable, and
simple. Even CSS is totally optional here.

I hope all this makes sense.

Fred

PS: Sam, it's nice to hear you again ;)

Frederico Caldeira Knabben
Project Manager, FCKeditor
----
http://www.fckeditor.net

 
> -----Original Message-----
> From: Justin James [mailto:j_james@mindspring.com]
> Sent: 15 May 2008 06:24
> To: 'Andrew Fedoniouk'
> Cc: 'Sam Kuper'; 'Frederico Caldeira Knabben'; 'HTMLWG'
> Subject: RE: WYSIWYG editing: execCommand & co
> 
> Andrew -
> 
> What you have done here is quite similar to what I think should go into
> the spec on this topic. Anyone else have ideas on this?
> 
> J.Ja
> 
> -----Original Message-----
> From: Andrew Fedoniouk [mailto:news@terrainformatica.com]
> Sent: Wednesday, May 14, 2008 2:20 PM
> To: Justin James
> Cc: 'Sam Kuper'; 'Frederico Caldeira Knabben'; 'HTMLWG'
> Subject: 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 Friday, 16 May 2008 08:22:06 UTC