- From: Koji Ishii <notifications@github.com>
- Date: Tue, 18 Aug 2015 06:26:57 -0700
- To: w3c/editing <editing@noreply.github.com>
- Message-ID: <w3c/editing/issues/68/132204456@github.com>
The canonicalization, in Blink/WebKit terminology, is a concept to try to move carets to a *sane* place. For instance, when user/JS pressed "right", and there's a `<div style="display:none"></div>` next to the caret, it makes sense to skip it. There are several such rules to make it saner and better, built in years. However, since those rules were defined in an ad-hoc manner and were never spec'ed, when all rules were combined against a specific DOM tree, rules conflict to each other and the logic is lost to where it should move carets to. That is what you're seeing when JS cannot selections to. I'm not familiar with cases where the caret does not blink, but I guess the same cause. That is why we're hesitant to fix specific bugs today. By adding another ad-hoc rule, we'll make the rules more complicated, and probably introduce yet another case where we cannot set selections to. Take an example of [crbug.com/456917](http://crbug.com/456917). Our first idea to fix it was to synthesize the height for the empty `<p>`, but then figured out that such behavior is not interoperable with Gecko/Trident. Our next idea was to allow setting selections to height=0 just like Gecko/Trident does in this case, but we're not sure if that's really what Gecko/Trident does, and since the rule was baked in Blink/WebKit for a long period, we're not sure how much it can break. I think we share a goal that, clearly defined, simple, and non-contradicting rules in the spec are desired. With that, we can really fix bugs. Ideally I'd like Gecko and Trident to join the discussions too (maybe it's time to ping Trident folks again?), but at least when a stable spec approaches to CR or such milestones, we can expect them to review the spec and object if any. When you file bugs against browsers, if the bug has a link to a stable spec, it's obvious that the bug is not talking about only one specific case and is not likely to introduce other edge cases. Browser developers should be easier to take the fix. Does this make sense, how the specing would help fixing bugs you want browser developers to fix, possibly including Gecko/Trident? --- Reply to this email directly or view it on GitHub: https://github.com/w3c/editing/issues/68#issuecomment-132204456
Received on Tuesday, 18 August 2015 13:27:27 UTC