[whatwg] Constructors for HTML Elements
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 Elements as there is not generally one interface per tag (e.g. HTMLHeadingElement is used for h1-h6) and making all zero-argument constructors work seems like a more natural API than sometimes having to say 'new HTMLDivElement()' and sometimes having to say 'new HTMLHeadingElement(h1)'. So the question is whether we can change this without breaking compat. The only problem I foresee is that adding new interfaces would change stringification. But I think it is possible to override that where needed.
Re: [whatwg] Feedback on UndoManager spec
(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 a list of slides. Since that's a part of the UI provided by the app, the DOM state of that UI may change over time without necessarily undoing or redoing insertions and removals of slides. So when you undo/redo an insertion of a slide, the exact change you make to the DOM may not be a mere restoration. Yet, the app still may want undo/redo in text fields to be implemented by UAs. 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 the plane that shows a list of slides in div noundo or something like that. Then just like the UA doesn't undo/redo DOM changes outside the undo scope, it shouldn't undo/redo changes in a noundo region (or whatever you want the attribute to be called). This way, again, the UA will never be faced with the problem of undoing/redoing changes in a part of the DOM that the author may have tampered with. This is critical for making the APIs work reliably -- if automatic undo/redo can fail because of authoring bugs, authors won't want to use it. It also simplifies the API by getting rid of the distinction between automatic and manual transactions. Are you (or anyone) making a list of use-cases somewhere? If not, I guess I will, because it's really essential to designing a good API.
Re: [whatwg] Feedback on UndoManager spec
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 the plane that shows a list of slides in div noundo or something like that. Then just like the UA doesn't undo/redo DOM changes outside the undo scope, it shouldn't undo/redo changes in a noundo region (or whatever you want the attribute to be called). I don't understand what problem(s) you're trying to solve here. Even if we introduced noundo content attribute, there's nothing that prevents authors from not using that content attribute and modifying DOM directly. Also, this noundo content attribute will be problematic inside contenteditable region because random elements that need to removed/moved may have this attribute. This way, again, the UA will never be faced with the problem of undoing/redoing changes in a part of the DOM that the author may have tampered with. This is critical for making the APIs work reliably -- if automatic undo/redo can fail because of authoring bugs, authors won't want to use it. It also simplifies the API by getting rid of the distinction between automatic and manual transactions. Adding noundo content attribute doesn't solve this problem because authors can still temper with the parts of DOM managed by the UA, and some UAs will still manage to undo managed transactions. Are you (or anyone) making a list of use-cases somewhere? If not, I guess I will, because it's really essential to designing a good API. There's out-dated list at http://rniwa.com/editing/undomanager-usecases.html - Ryosuke
Re: [whatwg] Feedback on UndoManager spec
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 requirements that I suggest on that page: * The author must not be forced to deal with manually handling DOM state just because they want to handle non-DOM state. Currently, if I want the UA to automatically handle DOM state, I cannot provide unapply or reapply methods. This means that if I need to handle non-DOM state, like for a canvas editor, then I have to keep track of all my DOM changes too. I should be able to write a canvas editor and still let the UA handle all DOM state. This would mean allowing unapply/reapply methods to be provided for automatic transactions, with the UA undoing any DOM changes they cause. * If browsers try to merge changes themselves, the algorithm should be well-defined if possible. Otherwise it will just confuse authors and not be useful, because it will succeed in some browsers and fail in others, or have unpredictable results. The current spec doesn't solve this requirement, but it might not be solvable. I discuss that further below. Does anyone disagree with any of the requirements on that page, or think that there are any more requirements that need to be added? I think all that should happen at this point is allowing unapply/reapply to be supplied for automatic transactions, but make sure that any DOM changes they make are undone immediately so that the DOM doesn't fall out of sync. That solves one of the two requirements that (IMO) the current spec doesn't meet. On Mon, Nov 7, 2011 at 11:55 AM, Ryosuke Niwa rn...@webkit.org wrote: I don't understand what problem(s) you're trying to solve here. Even if we introduced noundo content attribute, there's nothing that prevents authors from not using that content attribute and modifying DOM directly. Okay, thanks. This is the key point I was missing. Just so I understand, what's supposed to happen here: * Some changes get made in an automatic transaction. * Some changes get made in no transaction at all, just a script calling DOM methods. * execCommand(undo) Is the resulting DOM just undefined? Why isn't it defined to be whatever the state was before the automatic transaction, so any intervening changes just get undone too? This seems to be what Gecko does. E.g.: data:text/html,!doctype html div contenteditableFoo/div script var div = document.querySelector(div); getSelection().selectAllChildren(div); document.execCommand(bold); div.innerHTML = bar; document.execCommand(undo); /script Firefox 9.0a2 produces the results I expected, i.e., Foo selected and not bolded. Chrome 16 dev re-adds the removed Foo, then unbolds and selects it, so you get bar[Foo]. Opera Next 11.50 just ignores the undo. Now consider this: data:text/html,!doctype html div contenteditableFoo/div script var div = document.querySelector(div); getSelection().selectAllChildren(div); document.execCommand(bold); document.body.appendChild(document.createTextNode(bar)); document.execCommand(undo); /script Opera seems to just ignore the undo. Chrome tries to cleverly merge it, and in this case succeeds, unbolding Foo without removing the bar. Firefox removes bar and also unbolds Foo, so again, it just restores the whole page's DOM state to what it was before the transaction it undoes. It looks like what Gecko does is include *any* DOM changes anywhere in the page automatically in the previous transaction. This makes sense to me, and it guarantees that changes can always be undone reliably. Is Gecko's behavior here bad? What disadvantages does it have? Can we work around those disadvantages while still meeting all use-cases, and keeping behavior performant *and* well-defined? Also, this noundo content attribute will be problematic inside contenteditable region because random elements that need to removed/moved may have this attribute. Yes, we'd have to be careful about what happens if the attribute is added/removed. However, it should be possible to do that, and then behavior will be well-defined, which is a big plus. Obviously, as you point out, this attribute is only really useful if the UA tracks *all* DOM changes as part of the last transaction, as Gecko seems to do. Otherwise it doesn't simplify anything. There's out-dated list at http://rniwa.com/editing/undomanager-usecases.html Thanks.
Re: [whatwg] Constructors for HTML Elements
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 speak no further of it). This presents some special difficulties for HTML Elements as there is not generally one interface per tag (e.g. HTMLHeadingElement is used for h1-h6) and making all zero-argument constructors work seems like a more natural API than sometimes having to say 'new HTMLDivElement()' and sometimes having to say 'new HTMLHeadingElement(h1)'. So the question is whether we can change this without breaking compat. The only problem I foresee is that adding new interfaces would change stringification. But I think it is possible to override that where needed. You'd have to do HTMLUnkownElement(name) anyway, so new HTMLHeadingElement(name) wouldn't be bad. But, what is the ownerDocument? Will it always be window.document I assume? Anyway, I think it'd be great to have this. It wouldn't really solve a problem except for making code a tiny bit shorter. But, it's kind of something that seems like it should work (as in, makes sense, intuitive etc.) Side Note: Opera and Safari don't seem to have HTMLSpanElement and a span element stringifies to HTMLElement instead of HTMLSpanElement. Safari seems to be missing HTMLUnkownElement. -- Michael
Re: [whatwg] Constructors for HTML Elements
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 constructible, but that seems insane to me and I will speak no further of it). This presents some special difficulties for HTML Elements as there is not generally one interface per tag (e.g. HTMLHeadingElement is used for h1-h6) and making all zero-argument constructors work seems like a more natural API than sometimes having to say 'new HTMLDivElement()' and sometimes having to say 'new HTMLHeadingElement(h1)'. So the question is whether we can change this without breaking compat. The only problem I foresee is that adding new interfaces would change stringification. But I think it is possible to override that where needed. You'd have to do HTMLUnkownElement(name) anyway, so new HTMLHeadingElement(name) wouldn't be bad. I think it is quite acceptable to break HTMLUnknownElement. But, what is the ownerDocument? Will it always be window.document I assume? It would work like new Image; i.e. The element's document must be the active document of the browsing context of the Window object on which the interface object of the invoked constructor is found.. Anyway, I think it'd be great to have this. It wouldn't really solve a problem except for making code a tiny bit shorter. But, it's kind of something that seems like it should work (as in, makes sense, intuitive etc.) FWIW the two cited reasons for wanting it to work are it makes the DOM feel more like other javascript and it helps us use element subclassing as part of the component model.
Re: [whatwg] Constructors for HTML Elements
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 (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 Elements as there is not generally one interface per tag (e.g. HTMLHeadingElement is used for h1-h6) and making all zero-argument constructors work seems like a more natural API than sometimes having to say 'new HTMLDivElement()' and sometimes having to say 'new HTMLHeadingElement(h1)'. So the question is whether we can change this without breaking compat. The only problem I foresee is that adding new interfaces would change stringification. But I think it is possible to override that where needed. You'd have to do HTMLUnkownElement(name) anyway, so new HTMLHeadingElement(name) wouldn't be bad. I think it is quite acceptable to break HTMLUnknownElement. O.K. No strong feeling either way. But, what is the ownerDocument? Will it always be window.document I assume? It would work like new Image; i.e. The element's document must be the active document of the browsing context of the Window object on which the interface object of the invoked constructor is found.. O.K. Anyway, I think it'd be great to have this. It wouldn't really solve a problem except for making code a tiny bit shorter. But, it's kind of something that seems like it should work (as in, makes sense, intuitive etc.) FWIW the two cited reasons for wanting it to work are it makes the DOM feel more like other javascript and it helps us use element subclassing as part of the component model. O.K. -- Michael
[whatwg] iframe sandbox, object tag
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 list is purely concerned with the HTML5 spec, please just let me know if so. - 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 here. thanks ! ian
Re: [whatwg] iframe sandbox, object tag
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 and opinions here welcome, although this may be 'off topic' if the list is purely concerned with the HTML5 spec, please just let me know if so. That seems like a win. There's very little implementation effort needed to support that. - 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 here. That's probably a win too. Adam
Re: [whatwg] Feedback on UndoManager spec
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. I disagree with this requirement. This should be an opt-in feature, not something forced upon authors. Currently, if I want the UA to automatically handle DOM state, I cannot provide unapply or reapply methods. This means that if I need to handle non-DOM state, like for a canvas editor, then I have to keep track of all my DOM changes too. I should be able to write a canvas editor and still let the UA handle all DOM state. This would mean allowing unapply/reapply methods to be provided for automatic transactions, with the UA undoing any DOM changes they cause. Calling unapply/reapply methods for automatic transaction seem like a good non-controvertial change. Will make the change in the next iteration. * If browsers try to merge changes themselves, the algorithm should be well-defined if possible. Otherwise it will just confuse authors and not be useful, because it will succeed in some browsers and fail in others, or have unpredictable results. I don't think this is possible for various implementation-specific reasons. 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 script calling DOM methods. 3. execCommand(undo) It depends. If the DOM changes made in step 2 does not mutates the highest node affecting the automatic transaction in step 1, then step 3 succeeds and UA undoes every DOM change made in step 1. If the DOM changes made in step 2 mutates the highest node affecting the automatic transaction in step 1, then UAs still does its best to unapply the transaction but doesn't need to guarantee the states are restored completely. Is the resulting DOM just undefined? Why isn't it defined to be whatever the state was before the automatic transaction, so any intervening changes just get undone too? As far as I understand, implementing such a behavior will be extremely expensive in WebKit and I don't want to do that. Is Gecko's behavior here bad? What disadvantages does it have? Can we work around those disadvantages while still meeting all use-cases, and keeping behavior performant *and* well-defined? We can't. That's why I have spec'ed the way it is. Keeping the entire DOM state is extremely expensive. Yes, we'd have to be careful about what happens if the attribute is added/removed. However, it should be possible to do that, and then behavior will be well-defined, which is a big plus. Yeah, it'll be nice if we could define the behavior precisely but then again, there's nothing that prevents authors from modifying DOM in any arbitrary way. Obviously, as you point out, this attribute is only really useful if the UA tracks *all* DOM changes as part of the last transaction, as Gecko seems to do. This is very expensive to implement, and I'll be opposed to implementing such a behavior at least in WebKit. - Ryosuke
Re: [whatwg] iframe sandbox, object tag
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 here. That's probably a win too. Do people actually do this enough that it's worth spending time on? My concern here is that it might be confusing that @sandbox works for object when it contains a HTML page, but not when it contains a plugin. / Jonas
Re: [whatwg] Feedback on UndoManager spec
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 script calling DOM methods. 3. execCommand(undo) It depends. If the DOM changes made in step 2 does not mutates the highest node affecting the automatic transaction in step 1, then step 3 succeeds and UA undoes every DOM change made in step 1. If the DOM changes made in step 2 mutates the highest node affecting the automatic transaction in step 1, then UAs still does its best to unapply the transaction but doesn't need to guarantee the states are restored completely. Is the resulting DOM just undefined? Why isn't it defined to be whatever the state was before the automatic transaction, so any intervening changes just get undone too? As far as I understand, implementing such a behavior will be extremely expensive in WebKit and I don't want to do that. Yes, we don't want to track all changes ever made, that is indeed expensive. What we should do is to define exactly how the tracking works, and what exact operations the browser does to revert a automatic transaction. That way it doesn't matter (from a consistency point of view) what changes the page does outside of transactions. All browsers will react the same to the unknown state of the DOM. For example, if we say that for each node removed when a automatic transaction is created, the browser records that nodes old parent and previous sibling. Then we can say that when the automatic transaction is undone, the browser checks that the old previous sibling is still a child of the parent (unless the previous sibling was null), if the test passes, the browser inserts the removed node after the previous sibling in the parent. We could also remember both the following and previous sibling in order to be more resilient against unrecorded mutations. There's lots of options here. The point is we should define the exact algorithm that the browser should use. / Jonas / Jonas
Re: [whatwg] history.popstate in Firefox4
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: http://hacks.mozilla.org/2011/03/history-api-changes-in-firefox-4/ One of the differences between the spec and the API as implemented in Firefox that is not mentioned in the post above seems to be that the firing of 'popstate' events during history.back() is synchronous in Firefox, but asynchronous in the spec. (Chrome implements it in an asynchronous manner as per the spec. I couldn't test Safari.) Test: http://damowmow.com/playground/tests/history/001.html It was made asynchronous here: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-January/024871.html ...specifically, to make it possible to implement history traversal in a multiproces UA without requiring a blocking call across the process boundary (assuming each top-level Document in a tab's history is in a different process, and that they are coordinated by yet another process). Making it async with the proposed changes leaves a race condition between the user hitting the back button and a pushState() around the same time, but in practice that seems somewhat unlikely since usually pushState() is done in response to user input. (We could also block the event if we detect it's no longer consistent with the current state, but that would mean hitting back twice in a row would only fire one back event, which seems dodgy also.) Would keeping 'popstate' async, without dropping any events, be ok with Gecko? (I've gotten an ok from Safari, Chrome, and Opera to make the changes described in the blog post above, and currenty plan to do those. I'm not aware of any other implementations of this API.) What was the outcome here? I suspect that we'd like to keep it sync in Firefox, but I haven't really thought through the implications. CC'ing some people that have worked on history traversal for Gecko. / Jonas
Re: [whatwg] Feedback on UndoManager 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 each node removed when a automatic transaction is created, the browser records that nodes old parent and previous sibling. Then we can say that when the automatic transaction is undone, the browser checks that the old previous sibling is still a child of the parent (unless the previous sibling was null), if the test passes, the browser inserts the removed node after the previous sibling in the parent. We could also remember both the following and previous sibling in order to be more resilient against unrecorded mutations. It'll be nice if we could specify that precisely. From what Anne told me today, all DOM operations are defined in terms of http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#concept-node-insertand http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#concept-node-removeso we can probably define what should happen when unapplying/reapplying either one. - Ryosuke
[whatwg] Automatic transaction should support changing the value of input/textarea
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 current proposal doesn't support this because input/textarea's value is only reflected in the shadow DOM in some UA implementations and IDL attribute. Should we special case the value IDL attribute of HTMLInputElement and HTMLTextAreaElement in UndoManager spec? Best, Ryosuke Niwa Software Engineer Google Inc.
Re: [whatwg] iframe sandbox, object tag
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 data=something.html (which is in the HTML5 spec) - thoughts and opinions also welcome here. That's probably a win too. Do people actually do this enough that it's worth spending time on? My concern here is that it might be confusing that @sandbox works for object when it contains a HTML page, but not when it contains a plugin. That's a good point. Maybe it would be best on frame but not on object. Adam
