Re: [editing] defaultParagraphSeparator

On Fri, Feb 22, 2013 at 2:42 AM, Alex Mogilevsky <> wrote:
> Thanks for background, it helps a lot. I don't see a need to comment it by point so let me just reference it [1] and try to summarize.
> 1. There is no consensus on what the default should be. There are
>    implementations favoring each of <br>, <p> and <div>.
> 2. It would be good to set it per contenteditable, but we are not sure
>    how to express that.
> 3. There are no options other than <p> and <div> because there is no obvious
>    reason why it would be useful. (my interpretation: if it is something that
>    can't be done with a <div>, it probably wouldn't work as a default block
>    element anyway).
> 4. Sometimes Enter inserts <br> or EOL character instead of a new element. That
>    behavior is independent of the choice between <p> and <div> (but deserves
>    a good definition too).
> Is that a fair summary?

Yep, that's about right.

> I think that main reason it's hard to get a consensus is that it is not clear what problem the feature is trying to solve...

In an ideal world, I would prefer that <p> be the only option, as IE
does it.  This is in fact what the spec originally required.  But
there are two reasons for the switch, which I added to the spec by
request of people from WebKit and Opera:

Opera already implemented the command by the name of
"opera-defaultblock", because it outputs <p> but they found some apps
were changing it to <div> to avoid the margins:

So that's evidence of a real-world use-case for switching for <p> to
<div> -- although you'll have to ask Opera for details of what sites
these are.  Presumably they'd have the same problem with IE.

The use-case for switching from <div> to <p> is as a transition
feature for WebKit, which defaults to <div>.  Now authors can at least
opt into <p> for IE/WebKit/Opera, and deal with only two distinct
browser behaviors instead of three.  WebKit is not willing to change
their default away from <div> because of the risk of breaking
WebKit-specific content.

> If the only problem is the uncollapsed top border that annoyingly appears on first Enter - then it is an overkill to globally change what HTML element should represent a paragraph of text (if you saw it on paper, you would call it a paragraph, right?), just because it has a different default style.

At least someone thinks otherwise, according to Opera.  Notably, a
major use-case for contenteditable is richtext e-mail.  E-mail clients
don't reliably support CSS at all, and I don't know if any of them
support non-inline CSS, so you don't have any nice way to get rid of
<p>'s margins when sending.

Received on Tuesday, 26 February 2013 13:08:40 UTC