[whatwg] Editor types [Was: Pressing Enter in contenteditable: <p> or <br> or <div>?]

[Markus Ernst]

Am 17.05.2011 22:28 schrieb Ryosuke Niwa:
> On Tue, May 17, 2011 at 12:50 PM, Aryeh Gregor<Simetrical+w3c at gmail.com>wrote:
>>
>>   On Tue, May 17, 2011 at 3:19 AM, Ryosuke Niwa<rniwa at webkit.org>  wrote:
>>> I completely disagree. As a user, I want semantics when I write my blog
>>> entry on WordPress so that I can tweak presentation afterwards.  e.g. I
>> have
>>> frequently used em {font-style: normal; font-weight:bold;} strong
>>> {text-decoration:underline; font-weight: normal;} in the past.
>>
>> Then the commands will completely break no matter what you do, because
>> they're tied to the CSS, not the HTML element.  For instance, in this
>> test case:
>>
>
> No, I apply those CSS styles only on readonly published pages so my editor
> isn't affected by those rules.

Re-reading the discussions I get the impression that we have actually 
two different basic concepts of online rich-text editors:

1. A WYSIWYG editor. It offers all kinds of formatting options, allowing 
users to apply their preferred fonts, colors, sizes, table column widths 
and whatever. In this case I want to generate a code that preserves the 
visuals in all kinds of situations. In this case, it may be a good idea 
to generate style attributes whereever possible. It might even be a good 
idea to use <div>s for paragraph separation, I don't know.

2. An HTML editor. Authors possibly want to restrict the formatting 
options. The code generated should be as basic HTML as possible, so the 
output adapts to the styles of the target page - even if they are 
changed due to a redesign. In this case I want to avoid style attributes 
whereever possible, and I definitely want to generate <p>s and <br>s. I 
might even want to make a distinction between <i> and <em>. I assume 
this is what Ryosuke (and myself) talk about.

With this distinction in mind, I think some of Aryeh's questions on what 
markup we want to generate have two different answers by nature. I read 
about the styleWithCSS option erlier in this list. Maybe it would be 
helpful to have a more generic option to set the editor into a WYSIWYG 
or HTML state. This would of course cause more speccing and 
implementation work, but could allow to define two different and 
consistent sets of standard behaviors.