Re: Pressing Enter in contenteditable: <p> or <br> or <div>?

On Wed, 11 Jan 2012 10:43:24 +0100, Markus Ernst <derernst@gmx.ch> wrote:

>>> p has default margins.
>>
>> This is why we implemented opera-defaultblock. Apps were manually
>> converting our output to use divs because they didn't want margins,
>> which is non-trivial to do and often leaves bugs in edge cases.
>
> Actually, applying p {margin:0} looks quite trivial.

Sure, but some apps like to send their stuff in HTML email to clients that  
don't support styling, or some such.

>> That would rather miss the point of having the spec IMHO. If we all
>> implement a global switch to opt in to a different behavior, let's
>> design a new, sane editing API instead. But I think the editing spec
>> should try to reach interop for the legacy feature first.
>
> IMO the ability to create clean, state-of-the-art HTML code should be  
> one of the main goals of a new spec. That means: Editor implementations  
> should be able to get <p> on Enter, and <br> on Shift-Enter (as people  
> are used to from commonly used word processors) without additional  
> scripting.

That's nice but it's not clear how to go from here to there. There is web  
content that relies on quirks of each browser and might stop working  
completely if we change things. I value interop higher than "clean code",  
so if, for instance, we can converge on <div> but not on <p>, then that's  
what we should spec, IMHO. (However I'm not convinced yet that it's easier  
to converge on <div> rather than <p>, which is why Opera still uses <p> by  
default. We have generally aimed for matching IE for contenteditable.)

> I don't know the use cases Ryosuke mentions, where apps rely on  
> webkit-specific behavior (or other ua-specific behaviors), and I don't  
> know how harmful a change could be for them (paragraph margins appearing  
> in a forum I would not consider very harmful).

It's more that a "subtle" change can break functionality completely in  
some apps. Even if it's "just" margins appearing where they didn't before,  
it might still not be accepted by many users and web developers.

> On the long term, from a developer's and client supporter's POV I'd  
> prefer to have a standard behavior that works the same in all UAs, and  
> all common editor applications, by default.

I agree.

> Offering a default paragraph separator setting means, that editor  
> behaviors will remain different across applications,

It already is different across applications, because they implement the  
default paragraph separator setting themselves.

> which is confusing for many users.
>
> It might be less a hassle to have maintainers of existing applications  
> insert a line of code that triggers legacy behavior, if this is crucial  
> for their application.

-- 
Simon Pieters
Opera Software

Received on Wednesday, 11 January 2012 10:21:13 UTC