RE: WYSIWYG editing: execCommand & co

Andrew -

That covers my thoughts as well. The <richtext> tag could certainly be
helpful to creators of tools like FCKEditor, particularly as a "preview"
window. It could also be used in conjunction with XSLT to provide
translation for those people working with non-HTML markup. But at the end of
the day, the fact that it doesn't cover every imaginable usage of a rich
text edit is not really the point; the point is, is that it would (finally)
bring a way to usefully have an input field that allowed something other
than plain text. Indeed, it would be only a smidgen of effort with this
control to write an online editor of many varieties, as opposed to a ton of
work like it is now.

J.Ja

-----Original Message-----
From: Andrew Fedoniouk [mailto:news@terrainformatica.com] 
Sent: Friday, May 16, 2008 3:12 PM
To: Frederico Caldeira Knabben
Cc: 'Justin James'; 'Sam Kuper'; 'HTMLWG'
Subject: Re: WYSIWYG editing: execCommand & co

Frederico Caldeira Knabben wrote:
> 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.
>   
Intention of the <richtext> is not to replace application-components 
like FCKeditor.
To be precise FCKeditor is not only <richtext> per se. It is also an 
editing environment:
e.g. toolbars and actions associated with them. Use cases of components 
like FCKeditor
assume that target of edited content is known to the Web Application.

<richtext> (in my interpretation) is an input element that is aimed to 
be used primarily
as just a simple input element.
  <form action=...>
      <richtext name="..."></richtext>
     <button type=submit>Send your comment</button>   
  </form>
User shall be able to press, say, Ctrl+B to apply <strong>|<b>. Handling 
of simple lists (and image insertions
if they are allowed) is also highly desirable without any UI. That is 
the idea.

Output of the <richtext> shall be style neutral as destination (edited 
fragment insertion/storage points) of the emitted
content is unknown to the element. <richtext> is an HTML fragment 
editor.  And that is it.
Set of elements/attributes emitted has to be limited and well known to 
support simple/effective filtering on the server side.
Markup emitted by the <richtext> has to be perfectly valid XHTML without 
any exceptions.  There are only two
elements that  has to be converted into pure HTML if needed: <img /> and 
<br /> (but all UAs accept these elements
in closed form in HTML without any additional efforts).  In my 
implementation emitted content is a subset of HTML
that is common to all HTML version starting from HTML 2.0 so it can be 
used in HTML5/HTML4/XHTML - version
simply does not matter.

[Optional] support of toolbar.
Toolbar here is a set of UI elements (buttons and selectors) that are 
(elements) bound with current state of
the <richtext>. Each such UI element has predefined class name so 
binding happens by pure declaration without
any scripting:
  <div id="rt-toolbar">
     <button class="richtext-strong" type="checkbox" >Strong</button>
     <button class="richtext-em" type="checkbox" >Emphasis</button>
  </div>
  <richtext tools="rt-toolbar"></richtext>

If @tools is not defined that UA is free to provide it own context menu, 
popup toolbar, etc.

As I said above <richtext> is not a replacement of widgets like 
FCKeditor. There are
requirements where you need to support full and true WYSIWYG editor. But 
there are
too many cases where such simple thing as <richtext> is perfectly enough.
Blog articles and comments,  on-line e-mail systems, forums, etc.
Use of things like BBcodes on forums for example is a modern form of
"humiliation of mankind" ((C) my wife). That is why <richtext>.

One more: I believe that <richtext> as a required feature of HTML5, alone,
will do more for adopting it than any other things there.

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



> 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 Saturday, 17 May 2008 04:41:16 UTC