[whatwg] Undoscopes inside an editable region should ignored
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
More information about the whatwg