[whatwg] Undoscopes inside an editable region should ignored

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

FWIW, I think we should throw in this case.

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

I'm not sure if I understand the need for this quirk.

Firstly, FWIW, Gecko's implementation of -moz-user-modify does not allow content to use that attribute to make something contentEditable.  However, setting something to be editable changes the computed value for -moz-user-modify to read-write.  I don't really think that we would ever want to do the reverse, because of the problem that Aryeh mentions.  WebKit, however, seems to fully support -webkit-user-modify:read-write making something contentEditable.

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

I'm not sure I follow.

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

Can you mention some examples?  These are applications which use -webkit-user-modify to make something editable.  However, they _should_ be using the contentEditable attribute in order for their to work on any other UA, right?

Cheers,
--
Ehsan Akhgari
ehsan at mozilla.com
http://ehsanakhgari.org/

Received on Tuesday, 11 October 2011 13:02:38 UTC