This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
The editing spec assumes that the caret cannot be independent of the current user selection. However, the selection spec rightly says "On some platforms (such as those using Wordstar editing conventions), the caret position is totally independent of the start and end of the selection, even when the selection is empty". Thus, for instance, if [...] denotes the selection and | denotes the caret, and the current situation is: He|ll[o World] ...then when the user hits "enter", the result will unexpectedly be: Hell | ...rather than, as expected: He ll[o World] ...which is what one would get in an editing environment with WordStar semantics. This isn't a huge problem since browsers pretty much all have a caret that matches the selection, but we shouldn't be making UAs that want to try different interaction models non-conforming. At a minimum, therefore, things in the "Additional Requirements" section should be "SHOULD" not "MUST". Even better would be to handle the case of the caret not matching the selection explicitly. In UAs with WordStar semantics, you never blow away the selection implicitly. So this might be as easy as only doing that in the cases where the selection is treated like a fat caret.
(In reply to comment #0) > The editing spec assumes that the caret cannot be independent of the current > user selection. As far as I know, that is correct in all UAs that are expected to implement it. > This isn't a huge problem since browsers pretty much all have a caret that > matches the selection, but we shouldn't be making UAs that want to try > different interaction models non-conforming. At a minimum, therefore, things in > the "Additional Requirements" section should be "SHOULD" not "MUST". If there are implementers who want to implement the spec and also support these selection semantics, I'll be happy to make this change. But as a rule, if all UAs that implement the spec agree on something and are expected to continue agreeing on it indefinitely, I'll make it a "must". That sends the correct message to readers: if you want to match existing UAs, this is the behavior you need to implement, and anything else is a compat risk. If there are actual UAs who want to deviate, they can ask for the spec to be changed.
Also, I think that supporting such semantics would require bigger changes to the spec than what you mention in comment 0. I agree with Aryeh that unless a UA steps in to actually implement those semantics, it is probably best to leave it out of the spec.