[whatwg] Undoscopes inside an editable region should ignored

Aryeh Gregor ayg at aryeh.name
Tue Oct 11 07:26:25 PDT 2011

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.

More information about the whatwg mailing list