- From: Aryeh Gregor <ayg@aryeh.name>
- Date: Tue, 11 Oct 2011 10:26:25 -0400
On Mon, Oct 10, 2011 at 9:32 PM, Ryosuke Niwa <rniwa at webkit.org> wrote: > Allowing authors to define an undoscope inside an editing host appears to be > troublesome because user editing actions can modify the subtree of the host > in very complex ways, and it's hard to understand which node may be mutated > as a result of some editing actions or execCommand. > Given that, I propose to ignore undoscope content attributes or assignments > to undoScope IDL attribute if the content attribute is added to or the IDL > attribute is set to true for an editable element. This sounds reasonable. The content attribute should be made non-conforming in that case. Perhaps the IDL attribute should throw on setting? Maybe better to just do nothing, but that doesn't give the author any idea of what's wrong. > Furthermore, I propose to continue to ignore undoscope content attribute and > keep undoScope IDL attribute false when?the element becomes non-editable in > the future (e.g. by removing contenteditable content attribute of its > ancestor). ?Such a quirk is needed to?avoid creating > and?destroying?undoManager as a result of style recalculation in Mozilla and > WebKit because both engines support -webkit-user-modify and -moz-user-modify > to toggle editability. That sounds bad. To an author, it means that some element won't be an undoscope for no discernible reason. I guess you just mean that existing undoscope content attributes will be ignored, but if the author sets the IDL or content attribute after the element is editable, it will still work? It seems confusing. What do you intend to do if an element with the undoscope attribute becomes editable? This could also happen due to style recalculation, right? Are you not going to check in that case either, so it's possible to get editable undoscopes after all? Why do Gecko/WebKit support a CSS property for this anyway? It also means you can't support :read-write for contenteditable, because that would make selectors depend on style resolution. Is it just a convenience measure so that you don't have to implement efficient property inheritance a second time? Could you make the property ignored in user stylesheets, at least, so that the only way authors can make things editable is contenteditable/designMode? I really don't think we want to standardize this -- it's not something authors should be using CSS for.
Received on Tuesday, 11 October 2011 07:26:25 UTC