Re: [editing] defaultParagraphSeparator
On Tue, 05 Feb 2013 01:41:14 +0100, Alex Mogilevsky alex...@microsoft.com wrote: ± From: Pablo Flouret [mailto:pab...@motorola.com] ± Sent: Monday, February 4, 2013 12:47 PM ± ± On Mon, 04 Feb 2013 11:59:46 -0800, Alex Mogilevsky alex...@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/thre ± ad.html#msg171 ± ± Did it ever get to consensus? Or is there new thinking on how that ± should work? ± ± I implemented this in Opera and WebKit[1], can't really tell from the ± bugzilla bug if it's in firefox too[2], but i think they were on board as ± well. ± ± [1] https://bugs.webkit.org/show_bug.cgi?id=59961 ± [2] https://bugzilla.mozilla.org/show_bug.cgi?id=748303 The Editing API document flags defaultParagraphSeparator as having issues, some are mentioned in the document and more raised in the discussion. Such as * default value (currently 'p', but not consistent in implementations) Opera used p for compat with IE, though I don't have a strong opinion about what the default should be, so long as we all do the same thing. * default styles (if 'p' is default, it adds default 1em margin before first line, which most people consider undesirable) The undesirable style is basically the reason we implemented this in Opera. We didn't want to just use div by default because it was considered risky compat-wise. * when should Enter insert a line break instead of block (e.g. when inside pre)? Isn't this defined in the spec? https://dvcs.w3.org/hg/editing/raw-file/tip/editing.html#the-insertparagraph-command * can/should the default block be set per editable area and how? This is not specific to defaultparagraphseparator but applies to many commands, and there has been a proposal to expose execCommand on elements. * why only 'p' and 'div'? Only p and div addresses the use case of p having undesirable style. If there is a chance to settle on what's right for any of these, it would be awesome. Alex [1] https://dvcs.w3.org/hg/editing/raw-file/tip/editing.html#the-defaultparagraphseparator-command -- Simon Pieters Opera Software
Re: [editing] defaultParagraphSeparator
On Sat, 09 Feb 2013 02:11:41 +0100, Alex Mogilevsky alex...@microsoft.com wrote: ± From: Pablo Flouret [mailto:pab...@motorola.com] ± Sent: Monday, February 4, 2013 12:47 PM ± ± On Mon, 04 Feb 2013 11:59:46 -0800, Alex Mogilevsky alex...@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/thre ± ad.html#msg171 ± ± Did it ever get to consensus? Or is there new thinking on how that ± should work? ± ± I implemented this in Opera and WebKit[1], can't really tell from the ± bugzilla bug if it's in firefox too[2], but i think they were on board as ± well. ± ± [1] https://bugs.webkit.org/show_bug.cgi?id=59961 ± [2] https://bugzilla.mozilla.org/show_bug.cgi?id=748303 I can't find any documentation for any of the implementations, perhaps you could answer if the following is true: * The command name is defaultParagraphSeparator, unprefixed In Presto, it's opera-defaultblock (we implemented it before it was in the spec). * Argument is case insensitive * The only available options are P and DIV * Default is P In Presto, yes. Is that correct? Thanks Alex -- Simon Pieters Opera Software
Re: [editing] defaultParagraphSeparator
On Fri, Feb 22, 2013 at 2:42 AM, Alex Mogilevsky alex...@microsoft.com 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: http://lists.w3.org/Archives/Public/public-webapps/2012JanMar/0045.html 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.
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 alex...@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 alex...@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 pres.
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
addresses. Firefox 5.0a2 inserts br instead. Opera 11.10 nests
ps 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.)
[editing] defaultParagraphSeparator
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? Thanks Alex
Re: [editing] defaultParagraphSeparator
On Mon, 04 Feb 2013 11:59:46 -0800, Alex Mogilevsky alex...@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 implemented this in Opera and WebKit[1], can't really tell from the bugzilla bug if it's in firefox too[2], but i think they were on board as well. [1] https://bugs.webkit.org/show_bug.cgi?id=59961 [2] https://bugzilla.mozilla.org/show_bug.cgi?id=748303 -- pablo flouret motorola | webkit / browser team
RE: [editing] defaultParagraphSeparator
± From: Pablo Flouret [mailto:pab...@motorola.com] ± Sent: Monday, February 4, 2013 12:47 PM ± ± On Mon, 04 Feb 2013 11:59:46 -0800, Alex Mogilevsky alex...@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/thre ± ad.html#msg171 ± ± Did it ever get to consensus? Or is there new thinking on how that ± should work? ± ± I implemented this in Opera and WebKit[1], can't really tell from the ± bugzilla bug if it's in firefox too[2], but i think they were on board as ± well. ± ± [1] https://bugs.webkit.org/show_bug.cgi?id=59961 ± [2] https://bugzilla.mozilla.org/show_bug.cgi?id=748303 The Editing API document flags defaultParagraphSeparator as having issues, some are mentioned in the document and more raised in the discussion. Such as * default value (currently 'p', but not consistent in implementations) * default styles (if 'p' is default, it adds default 1em margin before first line, which most people consider undesirable) * when should Enter insert a line break instead of block (e.g. when inside pre)? * can/should the default block be set per editable area and how? * why only 'p' and 'div'? If there is a chance to settle on what's right for any of these, it would be awesome. Alex [1] https://dvcs.w3.org/hg/editing/raw-file/tip/editing.html#the-defaultparagraphseparator-command
