Re: Pressing Enter in contenteditable: p or br or div?
On Wed, 11 Jan 2012 18:31:26 +0100, Ryosuke Niwa rn...@webkit.org wrote:
Actually, applying p {margin:0} looks quite trivial.
The problem is that many existing contents don't have that css rule and
we obviously don't want to create markup like p style=margin: 0px;
for it is too verbose.
Probably a stupid question, but one I've always wanted to ask: couldn't we
default to a different, smaller, possibly 0 margin for P when in editable
content?
--
Hallvord R. M. Steen, Core Tester, Opera Software
http://www.opera.com http://my.opera.com/hallvors/
Re: Pressing Enter in contenteditable: p or br or div?
On Wed, 11 Jan 2012 16:39:48 +0100, Aryeh Gregor a...@aryeh.name wrote: On Tue, Jan 10, 2012 at 3:50 PM, Ryosuke Niwa rn...@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 sim...@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 rn...@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
Re: Pressing Enter in contenteditable: p or br or div?
On Thu, Jan 12, 2012 at 1:58 AM, Hallvord R. M. Steen hallv...@opera.comwrote:
On Wed, 11 Jan 2012 18:31:26 +0100, Ryosuke Niwa rn...@webkit.org wrote:
Actually, applying p {margin:0} looks quite trivial.
The problem is that many existing contents don't have that css rule and
we obviously don't want to create markup like p style=margin: 0px; for
it is too verbose.
Probably a stupid question, but one I've always wanted to ask: couldn't we
default to a different, smaller, possibly 0 margin for P when in editable
content?
We could but then existing mail clients, Web UAs, etc... will continue to
have those margins. Given many websites store markups generated by UAs in
contenteditable to be rendered by other UAs, adding such a style doesn't
solve anything in my opinion.
- Ryosuke
Re: Pressing Enter in contenteditable: p or br or div?
On Thu, Jan 12, 2012 at 4:58 AM, Hallvord R. M. Steen hallv...@opera.com wrote: Probably a stupid question, but one I've always wanted to ask: couldn't we default to a different, smaller, possibly 0 margin for P when in editable content? As Markus says: it breaks WYSIWYG. The idea of contenteditable is you can write a blog post or something in a contenteditable area, then post the resulting HTML to your web page in non-editable form and have it look the same. Having contenteditable behave differently means that you write the post, get it looking the way you want it -- and then suddenly when you post it, it looks different for no obvious reason. On Thu, Jan 12, 2012 at 5:50 AM, Simon Pieters sim...@opera.com wrote: 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: . . . As do I -- I suggested new attributes before I saw Ojan's suggestion. Indeed, e.g. shift+enter doesn't break out of lists, so it's not equivalent. Making it equivalent would be adding some complexity. Good point. I didn't think of that. 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. Agreed. That some authors are using it is not a strong enough reason to support it.
Re: Pressing Enter in contenteditable: p or br or div?
On Tue, 10 Jan 2012 21:50:34 +0100, Ryosuke Niwa rn...@webkit.org wrote: On Tue, Jan 10, 2012 at 12:46 PM, Aryeh Gregor a...@aryeh.name wrote: On Tue, Jan 10, 2012 at 3:40 PM, Ryosuke Niwa rn...@webkit.org wrote: Single br tag is shorter than pairs of div tags when serialized. True, but only slightly, and the difference is even smaller if you use p instead of div. This isn't enough of a reason by itself to justify the extra complexity of another mode. Are there other reasons? p has default margins. This is why we implemented opera-defaultblock. Apps were manually converting our output to use divs because they didn't want margins, which is non-trivial to do and often leaves bugs in edge cases. That alone is enough for us not to adopt p as the default paragraph separator. 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. Do you suggest that all browsers adopt div as default separator by default? Or that it will be impossible to reach interop? Or something else? :-) I almost want a global switch to toggle between legacy UA-specific behavior and new spec-compliant behavior. That would rather miss the point of having the spec IMHO. If we all implement a global switch to opt in to a different behavior, let's design a new, sane editing API instead. But I think the editing spec should try to reach interop for the legacy feature first. - Ryosuke -- Simon Pieters Opera Software
Re: Pressing Enter in contenteditable: p or br or div?
On Wed, Jan 11, 2012 at 1:00 AM, Simon Pieters sim...@opera.com wrote: On Tue, 10 Jan 2012 21:50:34 +0100, Ryosuke Niwa rn...@webkit.org wrote: On Tue, Jan 10, 2012 at 12:46 PM, Aryeh Gregor a...@aryeh.name wrote: On Tue, Jan 10, 2012 at 3:40 PM, Ryosuke Niwa rn...@webkit.org wrote: Single br tag is shorter than pairs of div tags when serialized. True, but only slightly, and the difference is even smaller if you use p instead of div. This isn't enough of a reason by itself to justify the extra complexity of another mode. Are there other reasons? p has default margins. This is why we implemented opera-defaultblock. Apps were manually converting our output to use divs because they didn't want margins, which is non-trivial to do and often leaves bugs in edge cases. Right. I think that's a good idea. That alone is enough for us not to adopt p as the default paragraph separator. 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. Do you suggest that all browsers adopt div as default separator by default? Or that it will be impossible to reach interop? Or something else? :-) It might be possible eventually once we introduce commands like defaultblock and everyone starts using that since at that point, the default doesn't really matter. On the other hand, at that point, the default doesn't really matter so not sure if it's really worth converging. I almost want a global switch to toggle between legacy UA-specific behavior and new spec-compliant behavior. That would rather miss the point of having the spec IMHO. If we all implement a global switch to opt in to a different behavior, let's design a new, sane editing API instead. But I think the editing spec should try to reach interop for the legacy feature first. That makes sense but I think we need to make sure we don't break the existing contents during the transition. I really wish we can all converge on one behavior but not at the cost of backward compatibility. - Ryosuke
Re: Pressing Enter in contenteditable: p or br or div?
On Wed, 11 Jan 2012 10:43:24 +0100, Markus Ernst derer...@gmx.ch wrote:
p has default margins.
This is why we implemented opera-defaultblock. Apps were manually
converting our output to use divs because they didn't want margins,
which is non-trivial to do and often leaves bugs in edge cases.
Actually, applying p {margin:0} looks quite trivial.
Sure, but some apps like to send their stuff in HTML email to clients that
don't support styling, or some such.
That would rather miss the point of having the spec IMHO. If we all
implement a global switch to opt in to a different behavior, let's
design a new, sane editing API instead. But I think the editing spec
should try to reach interop for the legacy feature first.
IMO the ability to create clean, state-of-the-art HTML code should be
one of the main goals of a new spec. That means: Editor implementations
should be able to get p on Enter, and br on Shift-Enter (as people
are used to from commonly used word processors) without additional
scripting.
That's nice but it's not clear how to go from here to there. There is web
content that relies on quirks of each browser and might stop working
completely if we change things. I value interop higher than clean code,
so if, for instance, we can converge on div but not on p, then that's
what we should spec, IMHO. (However I'm not convinced yet that it's easier
to converge on div rather than p, which is why Opera still uses p by
default. We have generally aimed for matching IE for contenteditable.)
I don't know the use cases Ryosuke mentions, where apps rely on
webkit-specific behavior (or other ua-specific behaviors), and I don't
know how harmful a change could be for them (paragraph margins appearing
in a forum I would not consider very harmful).
It's more that a subtle change can break functionality completely in
some apps. Even if it's just margins appearing where they didn't before,
it might still not be accepted by many users and web developers.
On the long term, from a developer's and client supporter's POV I'd
prefer to have a standard behavior that works the same in all UAs, and
all common editor applications, by default.
I agree.
Offering a default paragraph separator setting means, that editor
behaviors will remain different across applications,
It already is different across applications, because they implement the
default paragraph separator setting themselves.
which is confusing for many users.
It might be less a hassle to have maintainers of existing applications
insert a line of code that triggers legacy behavior, if this is crucial
for their application.
--
Simon Pieters
Opera Software
Re: Pressing Enter in contenteditable: p or br or div?
On Tue, Jan 10, 2012 at 3:50 PM, Ryosuke Niwa rn...@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 sim...@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 derer...@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.
Re: Pressing Enter in contenteditable: p or br or div?
On Wed, Jan 11, 2012 at 1:43 AM, Markus Ernst derer...@gmx.ch wrote:
Am 11.01.2012 10:00 schrieb Simon Pieters:
On Tue, 10 Jan 2012 21:50:34 +0100, Ryosuke Niwa rn...@webkit.org
wrote:
On Tue, Jan 10, 2012 at 12:46 PM, Aryeh Gregor a...@aryeh.name wrote:
On Tue, Jan 10, 2012 at 3:40 PM, Ryosuke Niwa rn...@webkit.org wrote:
Single br tag is shorter than pairs of div tags when serialized.
True, but only slightly, and the difference is even smaller if you use
p instead of div. This isn't enough of a reason by itself to
justify the extra complexity of another mode. Are there other
reasons?
p has default margins.
This is why we implemented opera-defaultblock. Apps were manually
converting our output to use divs because they didn't want margins,
which is non-trivial to do and often leaves bugs in edge cases.
Actually, applying p {margin:0} looks quite trivial.
The problem is that many existing contents don't have that css rule and we
obviously don't want to create markup like p style=margin: 0px; for it
is too verbose.
On the long term, from a developer's and client supporter's POV I'd prefer
to have a standard behavior that works the same in all UAs, and all common
editor applications, by default. Offering a default paragraph separator
setting means, that editor behaviors will remain different across
applications, which is confusing for many users.
That's just not gonna happen. Each application uses a different paragraph
separator for a reason.
It might be less a hassle to have maintainers of existing applications
insert a line of code that triggers legacy behavior, if this is crucial for
their application.
That doesn't solve any backward compatibility problems.
- Ryosuke
Re: Pressing Enter in contenteditable: p or br or div?
On Wed, Jan 11, 2012 at 12:38 PM, Ryosuke Niwa rn...@webkit.org wrote: That sounds like a great idea. . . . I'm not sure if we should add just editoptions though given we might need to add more elaborative options in the future. It might make more sense to add a new attribute per option as in: div contentEditable paragraphSeparator=p tabIndentation 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? 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. 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.
Re: Pressing Enter in contenteditable: p or br or div?
On Wed, Jan 11, 2012 at 3:15 PM, Ryosuke Niwa rn...@webkit.org wrote: That sounds workable. Presumably it's only available on the editing host (as supposed to any element or any element with contenteditable content attribute). Right.
Re: Pressing Enter in contenteditable: p or br or div?
On Wed, Jan 11, 2012 at 12:09 PM, Aryeh Gregor a...@aryeh.name wrote: On Wed, Jan 11, 2012 at 12:38 PM, Ryosuke Niwa rn...@webkit.org wrote: That sounds like a great idea. . . . I'm not sure if we should add just editoptions though given we might need to add more elaborative options in the future. It might make more sense to add a new attribute per option as in: div contentEditable paragraphSeparator=p tabIndentation 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? That sounds workable. Presumably it's only available on the editing host (as supposed to any element or any element with contenteditable content attribute). 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. 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. - Ryosuke
Re: Pressing Enter in contenteditable: p or br or div?
On Wed, Jan 11, 2012 at 7:39 AM, Aryeh Gregor a...@aryeh.name wrote: 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? That sounds like a great idea. 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? I'm not sure if we should add just editoptions though given we might need to add more elaborative options in the future. It might make more sense to add a new attribute per option as in: div contentEditable paragraphSeparator=p tabIndentation 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. Should enter behave like shift+enter when br is the default paragraph separator? - Ryosuke
Re: Pressing Enter in contenteditable: p or br or div?
On Sun, Jan 8, 2012 at 11:57 PM, Simon Pieters sim...@opera.com wrote: On Sat, 07 Jan 2012 03:57:33 +0100, Ojan Vafai o...@chromium.org wrote: Different apps have different needs and it's crappy for them to have to handle enter themselves just to get a different block type on enter. Something like document.execCommand(**DefaultBlock, false, tagName). What values are valid for tagName are open to discussion. At a minimum, I'd want to see div, p and br. What is the use case for br that div doesn't cover? Single br tag is shorter than pairs of div tags when serialized. I'm tempted to say that any block type should be allowed, I strongly disagree. Supporting any block type opens up for lots of bugs and weird cases. We should only support the types necessary to cover presented use cases. Yeah, supporting arbitrary block element will complicate a lot of things especially because people can add display: inline as a css rule or in inline style declarations. - Ryosuke
Re: Pressing Enter in contenteditable: p or br or div?
On Fri, Jan 6, 2012 at 9:57 PM, Ojan Vafai o...@chromium.org wrote: I'm OK with this conclusion, but I still strongly prefer div to be the default single-line container name. Why? I don't like using div as a line separator at all, because it's also used as a block-level wrapper, while p is specifically meant to wrap lines and br is specifically meant to separate them. I wish that UAs never generated div to wrap lines to start with -- it means that authors can't insert div-wrapped editable content without the risk that it will be interpreted as a line wrapper instead of a block wrapper. Also, I'd really like the default single-line container name to be configurable in some way. Different apps have different needs and it's crappy for them to have to handle enter themselves just to get a different block type on enter. What's a use-case for wanting div or br rather than p? Something like document.execCommand(DefaultBlock, false, tagName). I really don't want more document-global flags. If such a switch is added, it should be per editing host. What values are valid for tagName are open to discussion. At a minimum, I'd want to see div, p and br. As one proof that this is valuable, the Closure editor supports these three with custom code and they are all used in different apps. That's not proof that they're valuable, just that people will use them if given the option. What are examples of apps that use div and br? Do you know why they use them? I'm tempted to say that any block type should be allowed, but I'd be OK with starting with the tree above. For example, I could see a use-case for li if you wanted an editable widget that only contained a single list. As Simon says, making the list element itself contenteditable will work for that use-case. Then hitting Enter will make an li no matter what. On Tue, Jan 10, 2012 at 3:40 PM, Ryosuke Niwa rn...@webkit.org wrote: Single br tag is shorter than pairs of div tags when serialized. True, but only slightly, and the difference is even smaller if you use p instead of div. This isn't enough of a reason by itself to justify the extra complexity of another mode. Are there other reasons?
Re: Pressing Enter in contenteditable: p or br or div?
On Tue, Jan 10, 2012 at 12:46 PM, Aryeh Gregor a...@aryeh.name wrote: On Tue, Jan 10, 2012 at 3:40 PM, Ryosuke Niwa rn...@webkit.org wrote: Single br tag is shorter than pairs of div tags when serialized. True, but only slightly, and the difference is even smaller if you use p instead of div. This isn't enough of a reason by itself to justify the extra complexity of another mode. Are there other reasons? p has default margins. That alone is enough for us not to adopt p as the default paragraph separator. 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. I almost want a global switch to toggle between legacy UA-specific behavior and new spec-compliant behavior. - Ryosuke
Re: Pressing Enter in contenteditable: p or br or div?
On Jan 10, 2012, at 12:50 PM, Ryosuke Niwa rn...@webkit.org wrote: On Tue, Jan 10, 2012 at 12:46 PM, Aryeh Gregor a...@aryeh.name wrote: On Tue, Jan 10, 2012 at 3:40 PM, Ryosuke Niwa rn...@webkit.org wrote: Single br tag is shorter than pairs of div tags when serialized. True, but only slightly, and the difference is even smaller if you use p instead of div. This isn't enough of a reason by itself to justify the extra complexity of another mode. Are there other reasons? p has default margins. That alone is enough for us not to adopt p as the default paragraph separator. 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. I almost want a global switch to toggle between legacy UA-specific behavior and new spec-compliant behavior. - Ryosuke I've got a similar issue with copy/paste of HTML. If a switch were around for contentEditable, I might route through it on copy events in the page to tidy up some of the raw HTML clipboard. -Charles
Re: Pressing Enter in contenteditable: p or br or div?
On Sat, 07 Jan 2012 03:57:33 +0100, Ojan Vafai o...@chromium.org wrote: BCC: whatwg, CC:public-webapps since discussion of the editing spec has moved I'm OK with this conclusion, but I still strongly prefer div to be the default single-line container name. Why? Also, I'd really like the default single-line container name to be configurable in some way. I agree. Different apps have different needs and it's crappy for them to have to handle enter themselves just to get a different block type on enter. Something like document.execCommand(DefaultBlock, false, tagName). What values are valid for tagName are open to discussion. At a minimum, I'd want to see div, p and br. What is the use case for br that div doesn't cover? As one proof that this is valuable, the Closure editor supports these three with custom code and they are all used in different apps. Which apps use br? Could they switch to div without losing some functionality? I'm tempted to say that any block type should be allowed, I strongly disagree. Supporting any block type opens up for lots of bugs and weird cases. We should only support the types necessary to cover presented use cases. but I'd be OK with starting with the tree above. For example, I could see a use-case for li if you wanted an editable widget that only contained a single list. Just use ul contenteditableli|/li/ul. li as defaultblock would result in invalid markup if there's no list (and when breaking out of a list, etc). Ojan On Mon, May 30, 2011 at 1:16 PM, Aryeh Gregor simetrical+...@gmail.comwrote: On Thu, May 12, 2011 at 4:28 PM, Aryeh Gregor simetrical+...@gmail.com wrote: Behavior for Enter in contenteditable in current browsers seems to be as follows: * IE9 wraps all lines in p (including if you start typing in an empty text box). If you hit Enter multiple times, it inserts empty ps. Shift-Enter inserts br. * Firefox 4.0 just uses br _moz_dirty= for Enter and Shift-Enter, always. (What's _moz_dirty for?) * Chrome 12 dev doesn't wrap a line when you start typing, but when you hit Enter it wraps the new line in a div. Hitting Enter multiple times outputs divbr/div, and Shift-Enter always inserts br. * Opera 11.10 wraps in p like IE, but for blank lines it uses pbr/p instead of just p/p (they render the same). What behavior do we want? I ended up going with the general approach of IE/Opera: http://aryeh.name/spec/editcommands/editcommands.html#additional-requirements It turns out WebKit and Opera make the insertParagraph command behave essentially like hitting Enter, so I actually wrote all the requirements there (IE's and Firefox's behavior for insertParagraph was very different and didn't seem useful): http://aryeh.name/spec/editcommands/editcommands.html#the-insertparagraph-command The basic idea is that if the cursor isn't wrapped in a single-line container (address, dd, div, dt, h*, li, p, pre) then the current line gets wrapped in a p. Then the current single-line container is split in two, mostly. Exceptions are roughly: * For pre and address, insert a br instead of splitting the element. (This matches Firefox for pre and address, and Opera for pre but not address. IE/Chrome make multiple pres/addresses.) * For an empty li/dt/dd, destroy it and break out of its container, so hitting Enter twice in a list breaks out of the list. (Everyone does this for li, only Firefox does for dt/dd.) * If the cursor is at the end of an h* element, make the new element a p instead of a header. (Everyone does this.) * If the cursor is at the end of a dd/dt element, it switches to dt/dd respectively. (Only Firefox does this, but it makes sense.) Like the rest of the spec, this is still a rough draft and I haven't tried to pin corner cases down yet, so it's probably not advisable to try implementing it yet as written. As always, you can see how the spec implementation behaves for various input by looking at autoimplementation.html: http://aryeh.name/spec/editcommands/autoimplementation.html#insertparagraph -- Simon Pieters Opera Software
Re: Pressing Enter in contenteditable: p or br or div?
BCC: whatwg, CC:public-webapps since discussion of the editing spec has moved I'm OK with this conclusion, but I still strongly prefer div to be the default single-line container name. Also, I'd really like the default single-line container name to be configurable in some way. Different apps have different needs and it's crappy for them to have to handle enter themselves just to get a different block type on enter. Something like document.execCommand(DefaultBlock, false, tagName). What values are valid for tagName are open to discussion. At a minimum, I'd want to see div, p and br. As one proof that this is valuable, the Closure editor supports these three with custom code and they are all used in different apps. I'm tempted to say that any block type should be allowed, but I'd be OK with starting with the tree above. For example, I could see a use-case for li if you wanted an editable widget that only contained a single list. Ojan On Mon, May 30, 2011 at 1:16 PM, Aryeh Gregor simetrical+...@gmail.comwrote: On Thu, May 12, 2011 at 4:28 PM, Aryeh Gregor simetrical+...@gmail.com wrote: Behavior for Enter in contenteditable in current browsers seems to be as follows: * IE9 wraps all lines in p (including if you start typing in an empty text box). If you hit Enter multiple times, it inserts empty ps. Shift-Enter inserts br. * Firefox 4.0 just uses br _moz_dirty= for Enter and Shift-Enter, always. (What's _moz_dirty for?) * Chrome 12 dev doesn't wrap a line when you start typing, but when you hit Enter it wraps the new line in a div. Hitting Enter multiple times outputs divbr/div, and Shift-Enter always inserts br. * Opera 11.10 wraps in p like IE, but for blank lines it uses pbr/p instead of just p/p (they render the same). What behavior do we want? I ended up going with the general approach of IE/Opera: http://aryeh.name/spec/editcommands/editcommands.html#additional-requirements It turns out WebKit and Opera make the insertParagraph command behave essentially like hitting Enter, so I actually wrote all the requirements there (IE's and Firefox's behavior for insertParagraph was very different and didn't seem useful): http://aryeh.name/spec/editcommands/editcommands.html#the-insertparagraph-command The basic idea is that if the cursor isn't wrapped in a single-line container (address, dd, div, dt, h*, li, p, pre) then the current line gets wrapped in a p. Then the current single-line container is split in two, mostly. Exceptions are roughly: * For pre and address, insert a br instead of splitting the element. (This matches Firefox for pre and address, and Opera for pre but not address. IE/Chrome make multiple pres/addresses.) * For an empty li/dt/dd, destroy it and break out of its container, so hitting Enter twice in a list breaks out of the list. (Everyone does this for li, only Firefox does for dt/dd.) * If the cursor is at the end of an h* element, make the new element a p instead of a header. (Everyone does this.) * If the cursor is at the end of a dd/dt element, it switches to dt/dd respectively. (Only Firefox does this, but it makes sense.) Like the rest of the spec, this is still a rough draft and I haven't tried to pin corner cases down yet, so it's probably not advisable to try implementing it yet as written. As always, you can see how the spec implementation behaves for various input by looking at autoimplementation.html: http://aryeh.name/spec/editcommands/autoimplementation.html#insertparagraph
