Re: Simple template-based editing

----- Original Message ----- 
From: "Matthew Raymond" <mattraymond@earthlink.net>
To: "Andrew Fedoniouk" <news@terrainformatica.com>
Cc: <www-style@w3.org>
Sent: Friday, September 30, 2005 2:06 PM
Subject: Re: Simple template-based editing


> Andrew Fedoniouk wrote:
>> 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
>
>   /me scratches his head.
>
>   Wasn't that already possible? What prevents us from using the DOM to
> change/add/delete <option> elements now?

Yes, it is.
But in our case you may use following:
<select>
  <option><img src=.../> text </option>
</select>
--another example--
<select>
  <table>....
  <td><option> text </option></td>
  <td><option> text </option></td>
  </table>
</select>

I mean that <select> as also for example <button>
can contain any markup inside not only #PCDATA.

Another example - labeled check box:
<input type="checkbox">label text</input>

CSS:
input[type="checkbox"]
{
   display: inline-block;
   background-image: url(stock:checkbox);
   background-repeat: no-repeat;
   background-position: 0 50%;
   padding-left: 16px;
   behavior: checkbox;
   role: form-field;
   ... etc.
}
input[type="checkbox"]:hover
{
   background-image: url(stock:checkbox-hover);
}
.. etc.

>
>> 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 }
>
>   The problem here is that the contents of <textarea> are not in the
> DOM. It's the default value of <textarea> that's in the DOM, and
> <textarea> can only contain text. The instant you allow actual elements
> in the markup, you break backwards-compatibility with XHTML. So you can
> never have the contents of <textarea> be markup and you can never put
> the current contents in <textarea>, because they would overwrite the
> existing contents and prevent the default from being restored when
> pressing a reset button.

Yes, it is.

Conceptually textarea could be represented as
<textarea style="display:inline-block; white-space: pre">
    some text
</textarea>

Again conceptually nothing stops you from interpreting it this way.

Restoring (resetting) is a different story and part of undo/redo 
functionality of
tes-editor behavior.

>
>> To be short: In our case all "controls" and their content are
>> "DOM citizens" with "behaviors" applied, again, through
>> CSS.
>
>   For backwards-compatibility, <textarea> can't contain elements, only
> text, so there's nothing to style. You could in theory apply styles as
> if the WYSIWYG content of the control was in the DOM, though, and that's
> worth considering. You won't be able to see the styling in a legacy
> browser, though.
>

"so there's nothing to style"
I guess it is a wrong assumption.
E.g. "code syntax coloriser" may apply different styles to textarea content.

Plain text representation of textarea is what to be sent to the server as a 
value of the form field.
And this is part of behavior to determine what exactly is it.


Andrew Fedoniouk.
http://terrainformatica.com

Received on Friday, 30 September 2005 22:16:19 UTC