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

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?  And should
it imply contenteditable=true, or should the author have to specify
that separately?

Also: are there any good use-cases for <br>?  Allowing <div> instead
of <p> adds basically no extra complexity, but allowing <br> would
make things significantly more complicated.

> I almost want a global switch to toggle between legacy UA-specific behavior
> and new spec-compliant behavior.

That's something we definitely shouldn't have.  If WebKit wants to go
down the IE route and keep its legacy behavior for WebKit-specific
content, it's welcome to, but web-facing behavior should be entirely
standard.  If we had a nonstandard mode for editing, it would be
quirks mode all over again -- eventually we'd have to standardize that
too so browsers are interoperable on pages that don't opt in to the
standard behavior, and we'd just make everything more painful in the
end.

There's really no way to make this painless.  We just have to be as
careful to make it as painless as possible.

On Wed, Jan 11, 2012 at 4:43 AM, Markus Ernst <derernst@gmx.ch> wrote:
> IMO the ability to create clean, state-of-the-art HTML code should be one of
> the main goals of a new spec.

The overriding goal of the spec is to get interop as quickly and
painlessly as possible.  Everything else is secondary.  Once we have
interop, we can talk about significantly improving the utility of the
features.

Received on Wednesday, 11 January 2012 15:40:43 UTC