Matthew Raymond wrote:
Ian Hickson wrote:
On Fri, 26 Aug 2005, Matthew Raymond wrote:
So, effectively, what you're saying about <textarea accept="text/html">
is the following:
1) The HTML in a <textarea> is unstyled (at least unstyled by the parent
document) unless styles or stylesheets are specified within the
<textarea> contents.
There is no defined rendering for <textarea>. The UA would be perfectly
within its rights to interpret the contents of such an element and style
it using the styles of the containing document.
The trouble is that if you don't have a DOM, CSS really doesn't make
a lot of sense. For instance, "textarea p" is illogical because the <p>
element isn't actually a child of the <textarea> because the control can
only have a text node as its child.
Right but there's nothing to stop a UA creating a DOM from the text in
the textarea and making this avaliable in some implementation-dependent
way. I can certianly imagine a Firefox extension designed to replace a
<textarea accept="text/html"> with an <iframe contentEditable> to allow
WYSIWYG HTML editing. I can equally imagine a situationwhere WYSIWYG
isn't required and instead the textarea is presented as an ordinary
control but with UA-provided syntax highlighting (this should be easy to
implementgt where browsers use native widgets that already support
highlighting) or a situation where the user is given an "edit..." button
on the textarea that opens the contents in an emacs (or other external
editor) buffer and allows changes to be made. Clearly these last two
willalso work if the accept value is application/javascript or
whatever,as well as HTML.
Not having a required WYSIWYG rendering for <textarea
accept="text/html"> may be a strength rather than a weakness.
--
"As soon as people come up with a measurable substitute for whatever
it is they care about they start treating it as more important than the
real thing"
-Boris Zbarsky
