- From: Matthew Raymond <mattraymond@earthlink.net>
- Date: Fri, 30 Sep 2005 17:06:15 -0400
- To: Andrew Fedoniouk <news@terrainformatica.com>
- CC: www-style@w3.org
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?
> 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.
> 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.
Received on Friday, 30 September 2005 21:06:27 UTC