Re: [editing] selection across editing host boundaries
On Jun 24, 2014, at 6:39 AM, Piotr Koszuliński
wrote:
>
> On Tue, Jun 24, 2014 at 12:34 PM, Robin Berjon wrote:
> On 23/06/2014 20:33 , Johannes Wilm wrote:
> I filed bugs on this on both Firefox and Chrome in spring 2013. It was
> briefly fixed in Chrome, but the fix was then retracted and we never
> heard any more of it. It was also reported in Firefox by someone else in
> 2011. [1]
>
> I also had some contact with Webkit people working in this area who
> unfortunately didn't find the behavior to be problematic.
>
> This is probably the main reason why at least I am wondering if editing
> maybe just is an area that won't be of enough interest to browser makers
> to ever fix and that it may therefore just make more sense to just ask
> them to remove it and do everything in Javascript. But now it seeems
> this is about to change, which would be really really good.
>
> >From discussions I've had in the past on this topic, it's not so much that
> >browser-folks don't want to fix this. The problem is more that 1) this is
> >hard, so fixing can often only happen if someone really owns the problem
> >rather than contributing the odd fix, and such a person isn't always
> >available; 2) the current state of contentEditable is such a mess, notably
> >with libraries doing per-UA workarounds, that fixes that make the behaviour
> >globally saner actually break deployed code.
>
> This has conspired to make the situation rot. Hopefully we can fix this with
> the new tack taken here, notably by using contentEditable=cursor as a "sanity
> hook" which doesn't have to be backwards compatible with the existing madness.
>
> I am happy to see more cases that force us to propose something new, instead
> of patching rotting contentEditable=true :D.
>
>
> That's all nice and well, but what should the range be in the following cases:
>
> A:
> blah foo| blah
>
> B:
> blah [foo] blah
>
> C:
> bl[ah foo bl]ah
>
> D:
> blah f[oo bl]ah
>
> E:
> blah |foo blah
>
> Or in this:
>
> F:
>
> blah
> |blah
>
>
> F2:
>
> blah
> |
>
>
> or just for kicks, one could make the argument that this is different:
>
> G:
>
> blah
> |blah
>
>
> ?
>
> I think that we can start to solve this in the following manner:
>
> • When a deletion event would produce a range crossing an odd number of
> editing boundaries (either because there's a selection doing so in the sum of
> its ranges or for instance given backspace in case A above) then its range is
> empty and corresponds to a collapsed range a the cursor position (this is
> defined even for selections).
>
> • Conversely, when it would cross an even number of editing boundaries,
> then the range covers them.
>
> • Deletion events capture information expressing the direction of the
> deletion ("previous", "next", or possibly "both" in the delete-line case).
> This makes it possible for script to know how to hand the empty-range case.
>
> • Additionally, the deletion event can expose convenient information about
> the editing boundaries being crossed, their number, their hosts.
Could you list use cases that support the above behaviors? I agree all these
recent discussions about editing is great but I've got a feeling that we've
been spending too much time talking about solutions without really
understanding use cases and the full scope of the problem we're trying to solve.
> This means that, assuming backspace, the cases above can be handled as
> follows:
>
> A: empty range, the script can decide whether to select or delete the
> non-editable content (direction "previous").
> B: a range containing non-editable. Presumably deleted.
> C: same as B with some extra content on both sides. Presumably deleted.
> D: empty range, the script can decide what makes most sense. (Stabbing the
> user in the face sounds good.)
> E: empty range, the script decides which is best.
>
> For F, F2, G, and an awful lot of other cases (dt/dd, td, etc.) I think we
> should take the minimalist approach: just produce a deletion event indicating
> its direction but with an empty range. Scripts can decide if they wish to
> merge elements, delete empty ones, outdent, etc.
>
>
> This is getting complicated enough (and I haven't mentioned other cases such
> as br, script, hr, td, img, video...) that I wonder if the Deletion event
> shouldn't have its own spec.
>
> I agree about A, B and C. Selection in D in my opinion should not be possible
> (I'll comment on that later [1]). Selection in E also should not be possible
> because empty selection can't be made in non-editable element.
It does seem that disallowing selections that cross odd numbers of editing
boundaries would simplify the issue. Perhaps UA could auto-correct such
selections before presenting it to the user so that the user would not get
confused by editing actions not being applied to the entirely of such selection.
I do see one
Re: [editing] selection across editing host boundaries
On Tue, Jun 24, 2014 at 12:34 PM, Robin Berjon wrote:
> On 23/06/2014 20:33 , Johannes Wilm wrote:
>
>> I filed bugs on this on both Firefox and Chrome in spring 2013. It was
>> briefly fixed in Chrome, but the fix was then retracted and we never
>> heard any more of it. It was also reported in Firefox by someone else in
>> 2011. [1]
>>
>> I also had some contact with Webkit people working in this area who
>> unfortunately didn't find the behavior to be problematic.
>>
>> This is probably the main reason why at least I am wondering if editing
>> maybe just is an area that won't be of enough interest to browser makers
>> to ever fix and that it may therefore just make more sense to just ask
>> them to remove it and do everything in Javascript. But now it seeems
>> this is about to change, which would be really really good.
>>
>
> From discussions I've had in the past on this topic, it's not so much that
> browser-folks don't want to fix this. The problem is more that 1) this is
> hard, so fixing can often only happen if someone really owns the problem
> rather than contributing the odd fix, and such a person isn't always
> available; 2) the current state of contentEditable is such a mess, notably
> with libraries doing per-UA workarounds, that fixes that make the behaviour
> globally saner actually break deployed code.
>
> This has conspired to make the situation rot. Hopefully we can fix this
> with the new tack taken here, notably by using contentEditable=cursor as a
> "sanity hook" which doesn't have to be backwards compatible with the
> existing madness.
>
I am happy to see more cases that force us to propose something new,
instead of patching rotting contentEditable=true :D.
>
> That's all nice and well, but what should the range be in the following
> cases:
>
> A:
> blah foo| blah
>
> B:
> blah [foo] blah
>
> C:
> bl[ah foo bl]ah
>
> D:
> blah f[oo bl]ah
>
> E:
> blah |foo blah
>
> Or in this:
>
> F:
>
> blah
> |blah
>
>
> F2:
>
> blah
> |
>
>
> or just for kicks, one could make the argument that this is different:
>
> G:
>
> blah
> |blah
>
>
> ?
>
> I think that we can start to solve this in the following manner:
>
> • When a deletion event would produce a range crossing an odd number of
> editing boundaries (either because there's a selection doing so in the sum
> of its ranges or for instance given backspace in case A above) then its
> range is empty and corresponds to a collapsed range a the cursor position
> (this is defined even for selections).
>
> • Conversely, when it would cross an even number of editing boundaries,
> then the range covers them.
>
> • Deletion events capture information expressing the direction of the
> deletion ("previous", "next", or possibly "both" in the delete-line case).
> This makes it possible for script to know how to hand the empty-range case.
>
> • Additionally, the deletion event can expose convenient information
> about the editing boundaries being crossed, their number, their hosts.
>
> This means that, assuming backspace, the cases above can be handled as
> follows:
>
> A: empty range, the script can decide whether to select or delete the
> non-editable content (direction "previous").
> B: a range containing non-editable. Presumably deleted.
> C: same as B with some extra content on both sides. Presumably deleted.
> D: empty range, the script can decide what makes most sense. (Stabbing the
> user in the face sounds good.)
> E: empty range, the script decides which is best.
>
> For F, F2, G, and an awful lot of other cases (dt/dd, td, etc.) I think we
> should take the minimalist approach: just produce a deletion event
> indicating its direction but with an empty range. Scripts can decide if
> they wish to merge elements, delete empty ones, outdent, etc.
>
>
> This is getting complicated enough (and I haven't mentioned other cases
> such as br, script, hr, td, img, video...) that I wonder if the Deletion
> event shouldn't have its own spec.
>
I agree about A, B and C. Selection in D in my opinion should not be
possible (I'll comment on that later [1]). Selection in E also should not
be possible because empty selection can't be made in non-editable element.
As for the complexity, I feel that there's an indefinite number of cases
(e.g. we can start including styling - hidden elements, block/inline etc.).
Since the information about proposed result range is just an information -
can't we provide it only in some cases. For example, considering
CTRL+backspace in this scenarios:
1. foo bar| => [bar], direction:previous
2. foo|bar => direction:previous
In the second case editor may choose between multiple possible results
(select non-editable block, delete it, merge paragraphs, move caret and
don't merge, delete "foo" or not), so proposing anything only complicates
spec and may not be really valuable.
I think that browser could propose range if it does not:
* cross any block/hidden
Re: [editing] selection across editing host boundaries
On Tue, Jun 24, 2014 at 12:34 PM, Robin Berjon wrote: > > From discussions I've had in the past on this topic, it's not so much that > browser-folks don't want to fix this. The problem is more that 1) this is > hard, so fixing can often only happen if someone really owns the problem > rather than contributing the odd fix, and such a person isn't always > available; 2) the current state of contentEditable is such a mess, notably > with libraries doing per-UA workarounds, that fixes that make the behaviour > globally saner actually break deployed code. > Don't worry. I don't think browser people are evil. :) It may just be that this isn't a priority for browser makers, as it's not that widely used, and CkEditor/TinyMCE are doing a good job most places. > > This has conspired to make the situation rot. Hopefully we can fix this > with the new tack taken here, notably by using contentEditable=cursor as a > "sanity hook" which doesn't have to be backwards compatible with the > existing madness. > > You point to several bugs, but I think the one most worth reading is: > > https://code.google.com/p/chromium/issues/detail?id=238000 > > This has a wealth of issues and information, as well as a number of good > ideas. Piotr's point about the behaviour of deletion when a selection > crosses an even number of editing boundaries is particularly useful. > Deletion is indeed a difficult thing and I would estimate that maybe half of our code that deals with contenteditable deals with backspace, del, and the error keys in some way or another. > The way we've been thinking about this so far is that with cE=cursor, the > browser would perform no DOM modification on your behalf but rather you'd > have to handle events in order to carry out the modifications yourself. > This increases the amount of work that script has to do but in this case it > would likely enable you to produce the precise handling you require. > Having said that, considering this specific problem makes me realise that > the deletion event model that I had in mind does not work. > Thoughts? Yes, exactly. All your proposals sound fine concerning this. Yet even if it's up to the javascript library to decide what should happen, it would still be nice to have some kind of standard behavior defined so that web users get used to one way. For example, it was mentioned several times in various discussions that del/backspace in the case of "complex elements" that are being treated as a single character when it comes to cursor movement, should be selected rather than deleted if the range is empty. A second press on backspace or delete will then delete them and collapse the selection range. This was what the previous draft on cursor movement in contenteditable said about tables. It doesn't need to specifically be that way, but it could. Wikimedia have implemented this in their latest attempt at a WYSIWYG editor: https://en.wikipedia.org/w/index.php?title=Repulsion_theory&veaction=edit (try deleting the "[2]" with the cursor either in front or behind it). I would think that elements involving several editing boundaries should in just about all cases be classified as "complex elements". > > > > Use cases for this: >> >> 1. We use it for footnotes which we float of to the right of the text in >> a > contenteditable="true">[FOOTNOTE TEXT]. If one has >> access to CSS regions, one can even float them to be under the text on >> each page. The other is used to draw the >> footnote number in the main text. If one hits backspace behind it, the >> entire footnote should disappear. as it is now, instead the "back wall" >> of the footnote is removed which means that the rest of the paragraph >> is being added to the footnote. >> > > A question for you: how would you like selection to work in this case, > notably for copy/pasting? As a user, I would tend to expect that if I > select from before the 1 to after it and copy, I would get a > buffer containing the 1 but *not* the footnote content > (otherwise you get the famed "PDF effect" with lots of junk in your > buffer). It also looks visually weird if you have the footnote to the side > of the page being selected. But with the logical document order you use, it > would get selected. Do you make use of selection-preventing tricks? > Actually in our case, we would expect for the footnote and its contents to also be selected and copied along with the main text that surrounds it. But our use case may be very specific and different from how others use footnotes: In our case the student/academic decides that two paragraphs from the beginning of chapter 2 should be moved to the end of chapter 4 instead. The footnotes should move along with the main text, and should therefor be part of the selection-copy-paste process. *Placing footnotes to the right/left of the main text was a solution we found when it became clear that CSS Regions would be removed from Chrome. Previously we "flowed" them to below the text
Re: [editing] selection across editing host boundaries
On 23/06/2014 20:33 , Johannes Wilm wrote:
I filed bugs on this on both Firefox and Chrome in spring 2013. It was
briefly fixed in Chrome, but the fix was then retracted and we never
heard any more of it. It was also reported in Firefox by someone else in
2011. [1]
I also had some contact with Webkit people working in this area who
unfortunately didn't find the behavior to be problematic.
This is probably the main reason why at least I am wondering if editing
maybe just is an area that won't be of enough interest to browser makers
to ever fix and that it may therefore just make more sense to just ask
them to remove it and do everything in Javascript. But now it seeems
this is about to change, which would be really really good.
From discussions I've had in the past on this topic, it's not so much
that browser-folks don't want to fix this. The problem is more that 1)
this is hard, so fixing can often only happen if someone really owns the
problem rather than contributing the odd fix, and such a person isn't
always available; 2) the current state of contentEditable is such a
mess, notably with libraries doing per-UA workarounds, that fixes that
make the behaviour globally saner actually break deployed code.
This has conspired to make the situation rot. Hopefully we can fix this
with the new tack taken here, notably by using contentEditable=cursor as
a "sanity hook" which doesn't have to be backwards compatible with the
existing madness.
You point to several bugs, but I think the one most worth reading is:
https://code.google.com/p/chromium/issues/detail?id=238000
This has a wealth of issues and information, as well as a number of good
ideas. Piotr's point about the behaviour of deletion when a selection
crosses an even number of editing boundaries is particularly useful.
The way we've been thinking about this so far is that with cE=cursor,
the browser would perform no DOM modification on your behalf but rather
you'd have to handle events in order to carry out the modifications
yourself. This increases the amount of work that script has to do but in
this case it would likely enable you to produce the precise handling you
require.
Having said that, considering this specific problem makes me realise
that the deletion event model that I had in mind does not work. The way
I'd initially considered it was that you'd receive a Deletion event that
would abstract away from the deleting backwards/forwards differences
across platforms as well as reach of the deletion (character, word,
line, etc.). This works well for the following examples (in all of which
| represents a cursor and [] a selection):
If a clock gets hungry|, it goes back four seconds.
Here (at least on my computer) the following key combinations would
yield deletion events with the indicated ranges:
backspace "y"
delete","
alt-backspace "hungry"
ctrl-K"If a clock gets hungry, it goes back four seconds."
So far so good, and this extends well to the selection case:
If a clock gets [hungry], it goes back four seconds.
backspace "hungry"
delete"hungry"
alt-backspace "hungry"
ctrl-K"If a clock gets hungry, it goes back four seconds."
That's all nice and well, but what should the range be in the following
cases:
A:
blah foo| blah
B:
blah [foo] blah
C:
bl[ah foo bl]ah
D:
blah f[oo bl]ah
E:
blah |foo blah
Or in this:
F:
blah
|blah
F2:
blah
|
or just for kicks, one could make the argument that this is different:
G:
blah
|blah
?
I think that we can start to solve this in the following manner:
• When a deletion event would produce a range crossing an odd number
of editing boundaries (either because there's a selection doing so in
the sum of its ranges or for instance given backspace in case A above)
then its range is empty and corresponds to a collapsed range a the
cursor position (this is defined even for selections).
• Conversely, when it would cross an even number of editing
boundaries, then the range covers them.
• Deletion events capture information expressing the direction of the
deletion ("previous", "next", or possibly "both" in the delete-line
case). This makes it possible for script to know how to hand the
empty-range case.
• Additionally, the deletion event can expose convenient information
about the editing boundaries being crossed, their number, their hosts.
This means that, assuming backspace, the cases above can be handled as
follows:
A: empty range, the script can decide whether to select or delete the
non-editable content (direction "previous").
B: a range containing non-editable. Presumably deleted.
C: same as B with some extra content on both sides. Presumably deleted.
D: empty range, the script can decide what makes most sense. (Stabbing
the user in the face sounds good.)
E: empty range, the script decides which is best.
For F, F2, G, and an a
Re: [editing] selection across editing host boundaries
I filed bugs on this on both Firefox and Chrome in spring 2013. It was briefly fixed in Chrome, but the fix was then retracted and we never heard any more of it. It was also reported in Firefox by someone else in 2011. [1] I also had some contact with Webkit people working in this area who unfortunately didn't find the behavior to be problematic. This is probably the main reason why at least I am wondering if editing maybe just is an area that won't be of enough interest to browser makers to ever fix and that it may therefore just make more sense to just ask them to remove it and do everything in Javascript. But now it seeems this is about to change, which would be really really good. Use cases for this: 1. We use it for footnotes which we float of to the right of the text in a [FOOTNOTE TEXT]. If one has access to CSS regions, one can even float them to be under the text on each page. The other is used to draw the footnote number in the main text. If one hits backspace behind it, the entire footnote should disappear. as it is now, instead the "back wall" of the footnote is removed which means that the rest of the paragraph is being added to the footnote. 2. Figures with captions: blablablabla blablablabla 1) See https://code.google.com/p/chromium/issues/detail?id=242110 https://code.google.com/p/chromium/issues/detail?id=238000 https://bugzilla.mozilla.org/show_bug.cgi?id=873883 On Mon, Jun 23, 2014 at 6:03 PM, Robin Berjon wrote: > On 07/06/2014 15:15 , Xavier Morel wrote: > >> I've been working with @contenteditable and I've hit a case where >> one browser family (Webkit) seems to behave very differently than the >> others (tested: Firefox and MSIE). The situation is nested editing >> hosts: when starting a selection from the inner editing host, the >> selection stops at the host boundary in all cases. However when starting >> the selection from the outer editing host and entering the inner one, >> >> * MSIE and Gecko treat the inner editing host as an opaque item (a >>character, or a non-editable element embedded in the editable one), >>either none of the inner host is selected or all of it is part of >>the overall selection >> >> * Webkit-ish browsers (Safari and Chrome) on the other hand extend the >>selection within the inner editing host (so the selection can be half >> in >>and half out) >> >> The issue is, in the case of webkit browsers, when an edition is then >> performed they start moving stuff across the editing host boundary, and >> text goes in or out of the inner host (depending on the direction of the >> selection), generally ending up in an unrecoverable mess and panicking >> the end user. >> > > Urgh, that's horrible. Indeed, it needs to be fixed. > > > Now the use-case for the situation is the edition of a document (or >> document section) in which sub-sections with differing edition >> constraints are embedded e.g. content sections which may not be >> formatted (even though the top-level may), sections which may only be >> edited via a specific interface (e.g. embedded video + controls, >> embedded slides or graph) or section with other edition restrictions >> (e.g. only an enumerated set of values allowed), or even edition of more >> "template"-oriented systems with restricted blocks (providing >> template logic) containing free-form document sections[cke]. >> >> From my testing and use cases so far, I would say that the MSIE/Gecko >> behaviour is sensible and has the advantage of being uniform, whether >> a non-editable section contains editable descendants or not, it is >> also significantly less likely to destroy user content. But I would >> like to know what other people think of it, and whether an issue >> should be opened on the webkit and chromium trackers. >> > > I think that there are several distinct things that should help here. > > First, I believe that we should clearly define that when you have a > selection that goes outside of a given editing host then the editing > commands don't reach it. Put differently, you can only receive those events > if you have focus, and you can only be focused if the current selection is > *entirely* contained inside of you. A larger container might get keyboard > events, but that's it. > > Second, I think that it would be helpful to put the selectability of some > elements under user controls. (With which mechanism is another question. IE > does it with an attribute, others through CSS. I don't think it's a styling > decision.) > > As part of that it might be useful for non-editable islands/nested hosts > to state how they should react to ensconcing selections. For instance, if I > have a paragraph and a figure inside a section, I might refuse to carry out > any editing action when I have a selection that goes from half of one to > half of the other; but if both are fully selected as part of the section I > might wish to delete them. > > I wonder if we could list a set
Re: [editing] selection across editing host boundaries
On 07/06/2014 15:15 , Xavier Morel wrote: I’ve been working with @contenteditable and I’ve hit a case where one browser family (Webkit) seems to behave very differently than the others (tested: Firefox and MSIE). The situation is nested editing hosts: when starting a selection from the inner editing host, the selection stops at the host boundary in all cases. However when starting the selection from the outer editing host and entering the inner one, * MSIE and Gecko treat the inner editing host as an opaque item (a character, or a non-editable element embedded in the editable one), either none of the inner host is selected or all of it is part of the overall selection * Webkit-ish browsers (Safari and Chrome) on the other hand extend the selection within the inner editing host (so the selection can be half in and half out) The issue is, in the case of webkit browsers, when an edition is then performed they start moving stuff across the editing host boundary, and text goes in or out of the inner host (depending on the direction of the selection), generally ending up in an unrecoverable mess and panicking the end user. Urgh, that's horrible. Indeed, it needs to be fixed. Now the use-case for the situation is the edition of a document (or document section) in which sub-sections with differing edition constraints are embedded e.g. content sections which may not be formatted (even though the top-level may), sections which may only be edited via a specific interface (e.g. embedded video + controls, embedded slides or graph) or section with other edition restrictions (e.g. only an enumerated set of values allowed), or even edition of more “template”-oriented systems with restricted blocks (providing template logic) containing free-form document sections[cke]. From my testing and use cases so far, I would say that the MSIE/Gecko behaviour is sensible and has the advantage of being uniform, whether a non-editable section contains editable descendants or not, it is also significantly less likely to destroy user content. But I would like to know what other people think of it, and whether an issue should be opened on the webkit and chromium trackers. I think that there are several distinct things that should help here. First, I believe that we should clearly define that when you have a selection that goes outside of a given editing host then the editing commands don't reach it. Put differently, you can only receive those events if you have focus, and you can only be focused if the current selection is *entirely* contained inside of you. A larger container might get keyboard events, but that's it. Second, I think that it would be helpful to put the selectability of some elements under user controls. (With which mechanism is another question. IE does it with an attribute, others through CSS. I don't think it's a styling decision.) As part of that it might be useful for non-editable islands/nested hosts to state how they should react to ensconcing selections. For instance, if I have a paragraph and a figure inside a section, I might refuse to carry out any editing action when I have a selection that goes from half of one to half of the other; but if both are fully selected as part of the section I might wish to delete them. I wonder if we could list a set of use cases for this sort of interaction and figure out how best to handle them. It is related to something I've often wanted to do with editing. Assume you have two content items inside a section, and since they have different constraints they are editable separately (horrible markup just for example purposes): A thing of beauty is a joy forever. Time will say nothing But I told you so At this point, if I have my cursor right after the "y" of "say" in the first poem line and arrow up, I would like the cursor to go, roughly, after the "e" in "beauty". In existing systems it is far more likely to wind up right before "Time". Maybe that could be differentiated thusly: A thing of beauty is a joy forever. Time will say nothing But I told you so In other words, the presence of a containing host would influence the behaviour of cursors at (inner) editing boundaries. And as indicated above, my script could refuse to do anything for a selection from "joy" to "nothing" (since the operation might be meaningless across the nested contexts) but it might respond to deletion if both the p and div.poem are fully selected. PS: I am not subscribed to the list, if anybody is interested and wants to reply or has further questions, I'd be grateful if you could CC me. Maybe you'll be interested in signing up to the new public-editing-tf list which has much lower traffic. -- Robin Berjon - http://berjon.com/ - @robinberjon
[editing] selection across editing host boundaries
I’ve been working with @contenteditable and I’ve hit a case where one browser family (Webkit) seems to behave very differently than the others (tested: Firefox and MSIE). The situation is nested editing hosts: when starting a selection from the inner editing host, the selection stops at the host boundary in all cases. However when starting the selection from the outer editing host and entering the inner one, * MSIE and Gecko treat the inner editing host as an opaque item (a character, or a non-editable element embedded in the editable one), either none of the inner host is selected or all of it is part of the overall selection * Webkit-ish browsers (Safari and Chrome) on the other hand extend the selection within the inner editing host (so the selection can be half in and half out) The issue is, in the case of webkit browsers, when an edition is then performed they start moving stuff across the editing host boundary, and text goes in or out of the inner host (depending on the direction of the selection), generally ending up in an unrecoverable mess and panicking the end user. See http://jsfiddle.net/3LzKU/ for test cases, the editing host is composed of an outer element with contenteditable=false and an inner one with contenteditable=true (see note for reasons). Case 0 is non-editable content embedded in an editing host (to see browser behaviour in the base case), case 1 is as described above, cases 2 and 3 add whitespace (through padding and margin) to see if behaviour differs from case 1 (it does not) and case 4 adds read-only textual content (provides additional insight regarding DOM shifting during edition across the boundary) Now the use-case for the situation is the edition of a document (or document section) in which sub-sections with differing edition constraints are embedded e.g. content sections which may not be formatted (even though the top-level may), sections which may only be edited via a specific interface (e.g. embedded video + controls, embedded slides or graph) or section with other edition restrictions (e.g. only an enumerated set of values allowed), or even edition of more “template”-oriented systems with restricted blocks (providing template logic) containing free-form document sections[cke]. From my testing and use cases so far, I would say that the MSIE/Gecko behaviour is sensible and has the advantage of being uniform, whether a non-editable section contains editable descendants or not, it is also significantly less likely to destroy user content. But I would like to know what other people think of it, and whether an issue should be opened on the webkit and chromium trackers. Note: [editing] and browsers seem to disagree on what an editing host is: unless I’m misreading the spec, a direct child of an editing host with @contenteditable=true should be an editing host itself. Thus would be 2 editing hosts, one within the other. No browser seems to treat the inner node as an editing host as boundary behaviours don’t appear. [editing] https://dvcs.w3.org/hg/editing/raw-file/tip/editing.html [cke] I believe the latest “ckeditor” release provides a system of “widgets” working along the lines outlined there. PS: I am not subscribed to the list, if anybody is interested and wants to reply or has further questions, I'd be grateful if you could CC me.
