Re: [editing] defaultParagraphSeparator

Sorry for the delayed response -- I've been busy with other things and
didn't have time to check my e-mail.  Thanks a lot for the feedback
and questions!

On Mon, Feb 4, 2013 at 9:59 PM, Alex Mogilevsky <alexmog@microsoft.com> wrote:
> There was a discussion here a while ago on desired default behavior for
> Enter in contenteditable and options for
> execCommand(“defaultParagraphSeparator”):
>
> http://lists.w3.org/Archives/Public/public-whatwg-archive/2011May/thread.html#msg171
>
> Did it ever get to consensus? Or is there new thinking on how that should
> work?

I don't remember if there was consensus.  I wound up speccing
something based on IE/Opera's behavior (<p> by default).
Unfortunately, the complexity of editing and the level of detail I
write the spec in means that everyone other than me seems to have a
hard time understanding most of the spec (and so do I a lot of the
time . . .), but I can answer any questions people have about what I
thought was best and why.

On Tue, Feb 5, 2013 at 2:41 AM, Alex Mogilevsky <alexmog@microsoft.com> wrote:
> * default styles (if 'p' is default, it adds default 1em margin before first line, which most people consider undesirable)

I initially thought this was a significant issue, but then I realized
the same issue exists anyway for lists and indent, and you can't get
around it for them.  You have to have at least some CSS if you want it
to look nice -- particularly for indent, where the top/bottom margin
is rarely desirable (since it hijacks <blockquote> for indentation).
Also, the default margins for <p> match recent versions of Word, IIRC.

Simon Pieters did point out that for e-mail, you can't add styles, so
this is a reason to support <div> as well.  But I do think that <p> is
a better default.  If IE and Opera would be willing to change to <div>
and WebKit is not willing to match IE/Opera, I'd be in favor of
changing the default to <div> for interop's sake.  Otherwise I think
it should stay <p>.

> * when should Enter insert a line break instead of block (e.g. when inside <pre>)?

This is specified in the "insertParagraph" command, which behaves the
same as hitting Enter:

https://dvcs.w3.org/hg/editing/raw-file/tip/editing.html#the-insertparagraph-command

The actual spec text might prove just a tad difficult to read, but the
note at the top explains some of the important parts.  The spec
currently says a <br> should be inserted instead of a new block
element for <address>, <listing>, and <pre>.  My notes ("View
comments" at the side in the normative text) explain the reasoning for
this exact list:

"""
IE9 and Chrome 13 dev just break <pre> up into multiple <pre>s.
Firefox 5.0a2 and Opera 11.10 insert a <br> instead, treating it
differently from <p>. The latter makes more sense. What might make the
most sense is to just insert an actual newline character, though,
since this is a pre after all . . .

IE9 and Chrome 13 dev also break <address> up into multiple
<address>es. Firefox 5.0a2 inserts <br> instead. Opera 11.10 nests
<p>s inside. I don't like Opera's behavior, because it means we nest
formatBlock candidates inside one another, so I'll go with Firefox.

listing and xmp work the same as pre in all browsers. For Firefox and
Opera, this results in trying to put a br inside an xmp, so I go with
IE/Chrome for xmp.

TODO: In cases where hitting enter in a header doesn't break out of
the header, we should probably follow this code path too, instead of
creating an adjoining header. No browser does this, though, so we
don't.
"""

For other elements, of course, you can use Shift-Enter (or platform
equivalent) to produce a <br> instead, e.g., to produce a multi-line
list item.

> * can/should the default block be set per editable area and how?

This is bug 15522:
https://www.w3.org/Bugs/Public/show_bug.cgi?id=15522  I really wanted
this to be per-editing host only, with no document-wide flag, because
in my experience document-wide flags mean authors have to write
wrappers like

  function myCommand(a, b, c) {
    document.execCommand("usecss", false, true);
    document.execCommand(a, b, c);
  }

just in case something else sneakily changed the flag when they
weren't looking.  But I decided not to block one on the other, so
currently the spec has no way to do it per-editing host.

> * why only 'p' and 'div'?

Because no implementation supports any other wrapper for the default
paragraph separator, and there's no obvious reason why it would be
useful.  If people really wanted to allow <blockquote> as a default
line separator, we could add it to the spec easily enough.

(I considered adding <br> as an option, like Firefox now, but it would
require an extra code path, which I don't think is worth it unless we
really have a good reason.)

Received on Wednesday, 20 February 2013 12:37:24 UTC