Re: Simple template-based editing

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
content.
See illustration: http://terrainformatica.com/hsmile/images/sctls.png
http://www.terrainformatica.com/news/0002.whtm

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
CSS.

>
> 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.
http://terrainformatica.com

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