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

On Wed, 11 Jan 2012 16:39:48 +0100, Aryeh Gregor <ayg@aryeh.name> wrote:

> On Tue, Jan 10, 2012 at 3:50 PM, Ryosuke Niwa <rniwa@webkit.org> wrote:
>> p has default margins. That alone is enough for us not to adopt p as
>> the default paragraph separator.
>
> On Wed, Jan 11, 2012 at 5:15 AM, Simon Pieters <simonp@opera.com> wrote:
>> Sure, but some apps like to send their stuff in HTML email to clients  
>> that
>> don't support styling, or some such.
>
> I used to think that this was a strong argument, but then I realized
> <blockquote> and <ol> and <ul> have default margins too.  So if you
> want it to look right, you'll have to use a stylesheet.  Also, it's
> worth pointing out that recent versions of Word have margins by
> default when you hit Enter.
>
> But Simon makes a good point: for the e-mail use-case, styling might
> not be available.  So this is a decent reason to support <div>.
>
>> Also, unfortunately, there are many legacy
>> contents that rely on the fact webkit uses div as the paragraph  
>> separator so
>> we need a global or per editing-host switch regardless.
>
> This is also a good reason -- it lets preexisting apps that expect
> <div> opt into that behavior in new browsers, instead of being
> rewritten to support <p>.
>
> Okay, so what API should we use?  I'd really prefer this be
> per-editing host.  In which case, how about we make it a content
> attribute on the editing host?  It can be a DOMSettableTokenList.
> Maybe something like
>
>   <div editoptions="tab-indent">
>
> where the attribute is a whitespace-separated list of tokens.  To
> start with, we can maybe have tab-indent (hitting Tab indents) and
> div-separator (hitting Enter produces div).  Does this sound like a
> good approach?  If so, what should we call the attribute?

Currently the editing options available, other than enabling and disabling  
contenteditable, use the execCommand API. I don't see why we should switch  
to attributes for new editing options. To make editing options per editing  
host, I prefer this proposal:

[[
>> Ojan suggested in the other thread that we instead allow calling
>> execCommand() on Element, and have the result restricted to that
>> Element.  That solves the global-flags problem too, and doesn't
>> require new attributes.  So you'd do
>>
>>  div.execCommand("tabindent", false, "true");
>>
>> or whatever.  Someone could still call
>> document.execCommand("tabindent", false, "false"), but that would be
>> overridden if it was called on the editing host.  I filed a bug on it:
>>
>> https://www.w3.org/Bugs/Public/show_bug.cgi?id=15522
>>
>> Does that sound good too?
]]

>  And should
> it imply contenteditable=true, or should the author have to specify
> that separately?

The latter IMHO.

> Also: are there any good use-cases for <br>?

I still haven't seen any.

> Allowing <div> instead
> of <p> adds basically no extra complexity, but allowing <br> would
> make things significantly more complicated.


On Wed, 11 Jan 2012 21:15:18 +0100, Ryosuke Niwa <rniwa@webkit.org> wrote:

>> > Should enter behave like shift+enter when br is the default
>> > paragraph separator?
>>
>> Default paragraph separators are used in a couple of other places too,
>> so it would be a little more work than that.

Indeed, e.g. shift+enter doesn't break out of lists, so it's not  
equivalent. Making it equivalent would be adding some complexity.

>> But I just looked, and
>> it wouldn't be as bad as I thought.  So this is doable if people have
>> any good use-cases.
>>
>
> Great.

So what's the use case? :-) If none are presented, I object to adding it  
based on the Avoid Needless Complexity and Solve Real Problems design  
principles.

-- 
Simon Pieters
Opera Software

Received on Thursday, 12 January 2012 10:51:39 UTC