Re: @contenteditable versus <richtext>

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

Received on Sunday, 4 November 2007 05:54:15 UTC