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

[Cameron Heavon-Jones]

might it be possible for a default contenteditable algorithm to operate in a most-intuitive-possible mode but for all editor commands to pass through as keyboard events for customizations?

this makes a perfect solution redundant over an optimal solution which can be specified.

i would think when i press enter, i'm going to get a <p>, shift-enter would seem to makes sense to be included so as to have a <br> possible by default. these are the semantics of html and for the default editor in html to not produce semantic html would seem to be a misnomer. 

the goal of wysiwig is to hide the user from the complexity of the implementation, current user-interface design should not influence the semantics of the implementation - who knows what new wysiwig interface someone might come up with? do we change html every time this happens?

customizations for presentational reasons would seem to require explicit editable authoring in tandem with their explicit presentation authoring.

cameron jones

On 19/05/2011, at 1:38 PM, Cameron Heavon-Jones wrote:

> might it be possible for a default contenteditable algorithm to operate in a most-intuitive-possible mode but for all editor commands to pass through as keyboard events for customizations?
> 
> this makes a perfect solution redundant over an optimal solution which can be specified.
> 
> i would think when i press enter, i'm going to get a <p>, shift-enter would seem to makes sense to be included so as to have a <br> possible by default. these are the semantics of html and for the default editor in html to not produce semantic html would seem to be a misnomer. 
> 
> the goal of wysiwig is to hide the user from the complexity of the implementation, current user-interface design should not influence the semantics of the implementation - who knows what new wysiwig interface someone might come up with? do we change html every time this happens?
> 
> customizations for presentational reasons would seem to require explicit editable authoring in tandem with their explicit presentation authoring.
> 
> cameron jones
> 
> 
> On 19/05/2011, at 1:11 PM, Henri Sivonen wrote:
> 
>>> On Mon, May 16, 2011 at 12:20 PM, Aryeh Gregor
>>> <Simetrical+w3c at gmail.com>wrote:
>>>> 
>>>>> This is very presentational thinking.
>>>> 
>>>> Correct. This API was designed and is used presentationally, not
>>>> semantically. Both authors and users want presentational formatting
>>>> here. That's why it's called "What You *See* Is What You Get".
>>>> 
>>> 
>>> 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.
>>> 
>>> And when I press enter, I want a paragraph separator NOT a line break.
>> 
>> I agree.
>> 
>> Furthermore, I think it makes no sense for the spec to pretend to have a hard line against presentationalism (to the point of trying to define <i> and <b> to mean something other than italic and bold) while supplying a built-in mechanism for creating totally presentational markup. I'd want contenteditable to supply an editor that's suitable for producing content that's correct for the purposes of the rest of the spec. That is, I think pressing return should create a paragraph break. On the other hand, I think the commands for italicizing and bolding text should generate <i> and <b> and those should be defined to mean italics and bold.
>> 
>> In other words, I think the old IE behavior makes sense and I think the Gecko and WebKit behaviors of creating a soup of <br> and style="..." are unfortunate. That libraries feel the need to fix e.g. Gecko output in JS to get more IE-ish behavior is indication that the Gecko/WebKit approach isn't good. 
>> 
>> -- 
>> Henri Sivonen
>> hsivonen at iki.fi
>> http://hsivonen.iki.fi/
>