There seems to be some interest in making all concrete interfaces in the
DOM constructible (there also seems to be some interest in making
abstract interfaces constructible, but that seems insane to me and I
will speak no further of it).
This presents some special difficulties for HTML
(sorry for the long delay in responding, life is sometimes flaky for
me right now)
On Fri, Oct 28, 2011 at 3:54 PM, Ryosuke Niwa rn...@webkit.org wrote:
But that manual transaction may be mutating DOM outside of the editable
region. i.e. in the slide app case, you may have plane that's showing
On Mon, Nov 7, 2011 at 8:15 AM, Aryeh Gregor a...@aryeh.name wrote:
What you're saying is that maybe there will be parts of the DOM that
the author doesn't want the UA to touch? In that case, how about we
let the author specify that UA undo/redo shouldn't affect certain
subtrees? E.g., have
Okay, I created a wiki page with use-cases and requirements for them:
http://wiki.whatwg.org/wiki/UndoManager_Problem_Descriptions
I based it off http://rniwa.com/editing/undomanager-usecases.html,
plus posts in this thread. I think that the current spec does not
fulfill the following
On Mon, 07 Nov 2011 09:00:14 -0500, James Graham jgra...@opera.com wrote:
There seems to be some interest in making all concrete interfaces in the
DOM constructible (there also seems to be some interest in making
abstract interfaces constructible, but that seems insane to me and I
will
On Mon, 7 Nov 2011, Michael A. Puls II wrote:
On Mon, 07 Nov 2011 09:00:14 -0500, James Graham jgra...@opera.com wrote:
There seems to be some interest in making all concrete interfaces in the
DOM constructible (there also seems to be some interest in making abstract
interfaces
On Mon, 07 Nov 2011 16:15:17 -0500, James Graham jgra...@opera.com wrote:
On Mon, 7 Nov 2011, Michael A. Puls II wrote:
On Mon, 07 Nov 2011 09:00:14 -0500, James Graham jgra...@opera.com
wrote:
There seems to be some interest in making all concrete interfaces in
the DOM constructible
Hi,
while implementing the IFRAME sandbox attribute, a couple of questions have
come up :
- although the HTML5 spec deprecates the frame tag, there's been a couple of
people
asking if frame will support @sandbox - thoughts and opinions here welcome,
although
this may be 'off topic' if the
On Mon, Nov 7, 2011 at 2:45 PM, Ian Melven imel...@mozilla.com wrote:
while implementing the IFRAME sandbox attribute, a couple of questions have
come up :
- although the HTML5 spec deprecates the frame tag, there's been a couple
of people
asking if frame will support @sandbox - thoughts
On Mon, Nov 7, 2011 at 12:26 PM, Aryeh Gregor a...@aryeh.name wrote:
I based it off http://rniwa.com/editing/undomanager-usecases.html,
plus posts in this thread.
Thanks!
* The author must not be forced to deal with manually handling DOM
state just because they want to handle non-DOM state.
On Mon, Nov 7, 2011 at 2:49 PM, Adam Barth w...@adambarth.com wrote:
- there's also a similar question about whether the object tag will
(should) support
@sandbox when using the form object type=text/html data=something.html
(which
is in the HTML5 spec) - thoughts and opinions also welcome
On Mon, Nov 7, 2011 at 5:03 PM, Ryosuke Niwa rn...@webkit.org wrote:
Okay, thanks. This is the key point I was missing. Just so I
understand, what's supposed to happen here:
1. Some changes get made in an automatic transaction.
2. Some changes get made in no transaction at all, just a
On Wed, Mar 23, 2011 at 5:37 PM, Ian Hickson i...@hixie.ch wrote:
I'm studying some of the feedback raised over the past few months
regarding history.pushState() and related APIs, in particular in the
context of applying these changes to the spec:
On Mon, Nov 7, 2011 at 8:27 PM, Jonas Sicking jo...@sicking.cc wrote:
What we should do is to define exactly how the tracking works, and
what exact operations the browser does to revert a automatic
transaction.
Yeah, it'll be ideal if we could specify that.
For example, if we say that for
Hi,
It appears that automatic transaction should treat changing the value of
input and textarea as a DOM change because I can definitely see use cases
for scripts to modify the values of input/textarea in automatic
transactions and expect it be restored upon unapply/reapply.
Unfortunately, the
On Mon, Nov 7, 2011 at 7:13 PM, Jonas Sicking jo...@sicking.cc wrote:
On Mon, Nov 7, 2011 at 2:49 PM, Adam Barth w...@adambarth.com wrote:
- there's also a similar question about whether the object tag will
(should) support
@sandbox when using the form object type=text/html
16 matches
Mail list logo
