This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Currently I do lots of DOM operations where I first check whether the nodes are editable/editing hosts/etc. This should be moved to some kind of wrapper, so that all DOM mutations in the spec are invoking some subroutine that does the checks. I'll still need to do editability checks elsewhere, but this will make them more idiot-proof.
Also, as part of the editability checks, we should make sure that the node to be tested falls into the active editing host.
Should we? What does "active" mean? If you have two editing hosts and the user selects across both of them and hits delete, shouldn't it delete from both of them?
(In reply to comment #2) > Should we? What does "active" mean? The editing host in which the selection focus node falls into (at least, this is what Gecko has started to use). > If you have two editing hosts and the > user selects across both of them and hits delete, shouldn't it delete from both > of them? That is a tough question to answer, but my intuitive answer would be "no". It really depends on what those two editing hosts are trying to implement, but I think that web authors would be surprised if multiple editing hosts accept commands across each other.
Currently I don't have any concept of active editing hosts in the spec. I'm not sure what the advantage is. It seems like added complexity, compared to just treating all editable elements the same, so I'm reluctant to introduce the concept at all without specific use-cases that make it clear we need it.
OK, imagine Google Spreadsheets as an example. Let's say there is a huge table element and each cell contains a contentEditable div. Do we really want selections across table cells to behave in the way you describe in comment 2?
I'd think so, yes. If the user selects a bunch of text and hits delete, they'd expect it to all get deleted. Anything else would be confusing. Of course, the UA might prevent them from creating such selections in the first place, as a UI issue. But if such a selection is created somehow, I don't see why it should behave other than I describe. I'm not sure why you'd want to make each cell a separate editing host in your use-case, though. Why not just make the whole table one big editing host? (Other than the fact that there aren't any table editing features yet.)