Jon Barnett wrote:
> On 11/3/07, Andrew Fedoniouk <news@terrainformatica.com> wrote:
>
>> <textarea> is declared currently as
>>
>> <!ELEMENT TEXTAREA - - (#PCDATA)
>>
>> So this:
>>
>> <textarea>
>> <p>Hello World</p>
>> </textarea>
>>
>> works in all modern UA without any escapement.
>> Thus it is possible to reuse <textarea> with additional attributes as
>> a <richtext>:
>>
>
> I think browsers will still treat that as a single <textarea> element
> with text content, not a textarea element with a p element child. See
> [3].
This is exactly what is needed for <richtext> as I posted initially.
But you said that this is not good... I suspect that I lost something
between lines.
>
> And that's basically what I'm getting at - have a textarea element
> whose value is a string of HTML code, but is presented to the user as
> a rich text editor - again, basically what I do now with a set of
> complex javascript and iframes.
Try to imagine that <textarea> will get attribute @type="wysiwyg" or so.
That will be exactly proposed <richtext>.
The only difference between <richtext> and <textarea type="wysiwyg">
is that first one is a block element and second is inline[-block] element.
Thus
<richtext>
<b>Bold</b>
</richtext>
will show editor with additional UI (optional) with content:
Bold
that is rendered by bold font.
At the same time markup:
<textarea>
<b>Bold</b>
</textarea>
will present multiline plain text editor with content:
<b>Bold</b>
so "as is".
>
>> >
>> > The only difference between the plain textarea and the one replaced
>> > with RTE is the way line breaks are handled. When the form is
>> > submitted, a flag needs to be passed to let the server know if line
>> > breaks shoiuld be preserved (by converting them to <br> tags or
>> > heuristically placing <p> tags)
>> >
>>
>> I do not understand why do you need this. richtext aware application
>> will get the value as a markup - pretty much in the same way as if you
>> will submit html file by <input type="file">.
>>
>
> I didn't get very specific there. Basically, a lot of forums such as
> phpBB [1] or web sites that accept comments like Techdirt [2] allow
> you to type plain text into a text area. Paragraphs are separated by
> line breaks, etc., but they also allow a set of HTML tags, like <a>,
> <b>, etc. Line breaks in your comment/post show up as line breaks on
> the page. ([2], for better or worse, replaces line breaks with <br>
> tags).
>
> If the user was presented with a Rich Text Editor, it's not safe to
> assume line breaks in the HTML code are intended to be paragraph
> breaks. When the form is submitted, the server needs to know if the
> submitted text is raw HTML because the user's browser supported
> <textarea type="wysiwyg">, and that it shouldn't do anything heuristic
> with line breaks. (Again, [2], for better or worse has a radio button
> to choose between "plain text" and "html" to handle this)
markup produced by wysiwyg html editor will not have "free text" on
output. Any text is wrapped in proper text container <p>, <li>, etc. :
<p>wysiwyg html editor has no need to produce empty lines</p>
Thus I do not think that you will have problem here.
If you would have dangling text at input on the server then and only
then you need to do that BB-markup -> html processing.
--
Andrew Fedoniouk.
http://terrainformatica.com
>
> [1] http://www.phpbb.com/
> [2] http://techdirt.com/articles/20071102/025323.shtml (sample site
> that accepts comments, not an interesting article)
> [3] http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Ctextarea%3E%3Cp%3Etest%3C%2Fp%3E%3C%2Ftextarea%3E