W3C home > Mailing lists > Public > www-style@w3.org > September 2005

Re: Simple template-based editing

From: Andrew Fedoniouk <news@terrainformatica.com>
Date: Fri, 30 Sep 2005 10:40:21 -0700
Message-ID: <00a101c5c5e6$07f25880$3201a8c0@Terra>
Cc: "Bert Bos" <bert@w3.org>, <www-style@w3.org>

Hi, Lachlan,

----- Original Message ----- 
From: "Lachlan Hunt" <lachlan.hunt@lachy.id.au>
> Andrew Fedoniouk wrote:
>> Instead of having contentEditable attribute in our rendering engine we've 
>> introduced new input element <htmlarea> analogous to <textarea>.
> We had a similar discussion recently on the WHATWG list [1] about 
> contentEditable vs. htmlarea vs. textarea.  The general feeling, AIUI, was 
> that <textarea accept="text/html"> and a hypothetical <htmlarea> element 
> would be semantically equivalent, and that contentEditable is also needed 
> for different use cases, mostly because, unlike textarea, (1) its content 
> can be styled with CSS and (2) its content can be accessed/manipulated 
> through the DOM interface.

In our experimental engine all input elements
and their components are part of the dom.
So e.g. <select> and their <option>s are accessible
from the DOM and more over can have arbitrary
See illustration: http://terrainformatica.com/hsmile/images/sctls.png

The same apply to the content of <textarea> and <htmlarea>.
<textarea> - is the same wysiwyg editor - container of paragraphs
textarea { white-space: pre  }
textarea p { margin:0 }

To be short: In our case all "controls" and their content are
"DOM citizens" with "behaviors" applied, again, through

> For textarea, it's up to the UA to provide the editing environment, 
> whether it be a WYSIWYG type of editor, a textarea with syntax hilighting, 
> or whatever else.  Plus the textarea at least falls back to a textarea for 
> UAs that don't provide such editing abilities and is more flexible in that 
> it can accept any type of text input, such as text/*, */*+xml, etc, 
> whereas htmlarea is limited to HTML only.
>> allow - string, comma delimited list of tag names of allowed
>>        elements in the content.
>> reject -  string, comma delimited list of tag names of forbidden
>>        elements in the content.
> The expressiveness of such attributes is limited at best, and such 
> complicated validation is best handled on the server side.

Agree. But it is better than nothing and easy to implement and compact.
We are limitied in 812kb of binary size.

> [1] 
> http://listserver.dreamhost.com/pipermail/whatwg-whatwg.org/2005-August/thread.html#4526
Oh, thanks for that.

Andrew Fedoniouk.
Received on Friday, 30 September 2005 17:40:36 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:27:20 UTC