- From: Ryosuke Niwa <rniwa@webkit.org>
- Date: Thu, 13 Oct 2011 13:07:18 -0700
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 undoManager. - Ryosuke
Received on Thursday, 13 October 2011 13:07:18 UTC