W3C home > Mailing lists > Public > whatwg@whatwg.org > October 2011

[whatwg] Undoscopes inside an editable region should ignored

From: Ryosuke Niwa <rniwa@webkit.org>
Date: Thu, 13 Oct 2011 13:07:18 -0700
Message-ID: <CABNRm63yuOYtFdHLe2MWAVj1GUti1DKAk-kL_96GoVcHc2SQ0Q@mail.gmail.com>
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
Received on Thursday, 13 October 2011 13:07:18 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:37 UTC