W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2012

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

From: Simon Pieters <simonp@opera.com>
Date: Thu, 12 Jan 2012 11:50:53 +0100
To: "Ryosuke Niwa" <rniwa@webkit.org>, "Markus Ernst" <derernst@gmx.ch>, "Aryeh Gregor" <ayg@aryeh.name>
Cc: "Ojan Vafai" <ojan@chromium.org>, "Ehsan Akhgari" <ehsan@mozilla.com>, "WebApps WG" <public-webapps@w3.org>
Message-ID: <op.v7ywe3vtidj3kv@simon-pieterss-macbook.local>
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  

Simon Pieters
Opera Software
Received on Thursday, 12 January 2012 10:51:39 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:38 UTC