[whatwg] Undoscopes inside an editable region should ignored

Ryosuke Niwa rniwa at webkit.org
Thu Oct 13 13:07:18 PDT 2011

On Tue, Oct 11, 2011 at 1:02 PM, Ehsan Akhgari <ehsan at mozilla.com> wrote:
>  > 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.

Suggestions on which exception to throw?

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 didn't know that. Thanks for the clarification.

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

Yes. It's definitely a troublesome feature.

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

What I meant is that we probably don't need this quirk after all. We just
need some custom getter/setter that checks editability before we return

- Ryosuke

More information about the whatwg mailing list