16094 2012-02-23 20:43:03 +0000 Editing commands should do nothing if the selection isn't fully contained in a single editing host 2012-02-24 17:29:29 +0000 1 1 1 Unclassified WebAppsWG HISTORICAL - HTML Editing APIs unspecified All All RESOLVED FIXED P2 normal --- 1 ayg ayg mike public-webapps sideshowbarker+html-editing-api oldest_to_newest 64504 0 ayg 2012-02-23 20:43:03 +0000 (In reply to bug 13118 comment #20) > I think similar problems can arise with selections spanning non-nested editing > hosts, or outside of editing hosts entirely. E.g., per current spec, running > "indent" on > foo<div style=display:inline contenteditable=true>bar</div>[baz] > will actually produce > foo<div style=display:inline > contenteditable=true><blockquote>bar</blockquote></div>[baz] > or something, I think. This is probably just a spec bug, though! Probably > block-extending the selection shouldn't cross editing hosts. > > So we should try to make sure that commands don't affect any editing hosts that > aren't ancestors of some node that's contained or partially contained in the > selection? This should be changed. If the selection doesn't touch an editing host, commands should never affect it. Likewise, if multiple beforeInput events get fired at different editing hosts, canceling some should make the command not affect that editing host. 64505 1 ayg 2012-02-23 20:53:50 +0000 (I'm not prioritizing this, because it only comes up if the page has multiple editing hosts, which isn't so common. And even then only in corner cases.) 64506 2 ayg 2012-02-23 21:11:57 +0000 After some discussion with rniwa in #whatwg: we should probably just say that if the selection is not fully contained in a single editing host, execCommand() does nothing. Probably queryCommandEnabled() should return false in this case. Then all this becomes simple. I'll try doing that now, perhaps. 64557 3 ayg 2012-02-24 17:29:29 +0000 http://dvcs.w3.org/hg/editing/rev/33d0413c3be8