[whatwg] Undoscopes inside an editable region should ignored

[Ryosuke Niwa]

On Tue, Oct 11, 2011 at 7:26 AM, Aryeh Gregor <ayg at aryeh.name> wrote:

> 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.
>

Right.

> 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?
>

On my second thought, we probably don't need to do this. Since the creation
of UndoManager or undoscope isn't visible until the author obtains the value
of undoscope content attribute or undoScope IDL attribute, we can
probably destroy undoManager lazily.

Ehsan & Jonas, any opinions on this from Mozilla side?

Why do Gecko/WebKit support a CSS property for this anyway?


http://www.w3.org/TR/1999/WD-css3-userint-19990916#user-modify


> 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 wanted to get rid of it but couldn't due to compat. issue. There are too
many applications that depend on -webkit-user-modify at the moment.

I really don't think we want to standardize this -- it's not something
> authors
> should be using CSS for.
>

Right. I don't think we should but that doesn't mean we can drop the
support.

- Ryosuke