Re: [whatwg] Fixing undo on the Web - UndoManager and Transaction
On Fri, Aug 5, 2011 at 7:12 PM, Jonas Sicking jo...@sicking.cc wrote: On Fri, Aug 5, 2011 at 5:17 PM, Ryosuke Niwa rn...@webkit.org wrote You're right that you can redo what the UA did after you unapplied the managed transaction UA inserted. So maybe replace isn't really that useful after all. But I had an impression that having to replay UA's DOM changes is annoying. But getting rid of replace will certainly make the API simpler, and we might able to address the latter concern by introducing a function that take a mutation list and re-applies it. You'll need to be able to replay the UA's DOM changes anyway since you need to redo them if the user undos and redos. That is a very good point. Let me think about it a little harder and see if we've missed anything. If not, we can get rid of this wacky method. And there might be some custom UI that shows up around the inserted text. For this I wouldn't imagine you want to replace the managed transaction anyway since you still want to let the UA deal with undo/redo, right? Instead I'd merge another transaction which adds the custom UI with the managed one that the UA created. That's also a good point. - Ryosuke
Re: [whatwg] Fixing undo on the Web - UndoManager and Transaction
Hi everyone, I have updated my document on http://rniwa.com/editing/undomanager.html to address all responses I've got so far. Most of it is about clarifying details and adding some examples. Now, I'd really like to get your opinions on what event(s) we should have for this to work. The minimum list I can think of is the following: - Undo - Redo - EditingAction - Transaction (or Transacted) Undo, Undo, and EditingAction are synchronous, cancelable, bubbling events that fire immediately before undo, redo, or user editing action or execCommand is to be executed respectively. Transaction (or Transacted or whatever you'd like to call it) is an event that fires after new transaction is inserted (not cancelable). - Ryosuke On Tue, Jul 26, 2011 at 11:34 PM, Ryosuke Niwa rn...@webkit.org wrote: Hi all, In the last couple of weeks, I've been working with developers of CKEditor, TinyMCE, and Google Docs to come up with *new API for undo and redo*. Why? Because* undo and redo are broken on the Web today*. Whenever Web apps try to add a custom editing operation without using execCommand or do a fix up after browser executes a user editing action, user agents get confused by DOM mutations made by the apps and won't be able to undo or redo user editing actions and execCommand. This forces Web apps to re-implement undo and redo themselves, and in fact, *many rich text editors store innerHTML of a contenteditable element* as a string in their internal undo transaction history (a.k.a undo stack). Also, there's no way for Web apps to add new undo item and populate undo and redo menus on user agent's native UI. In addition, if an editor app has a widget with input/textarea, then the undo stack of the editor gets confused when the widget goes away because the undo transaction history exists only per document. In order to solve above and numerous other problems, we've come to a conclusion that we need to *add UndoManager and Transaction*. *UndoManager* is an interface for managing undo transaction history. It exists on a document and an element with the *undoscope* content attribute. UndoManager applies new transaction (i.e. make undoable DOM changes) and manage them. The main purpose of UndoManager is to communicate the list of undoable items with the user agent so that the user agent can provide a native UI (e.g. populating menu items with them). A *transaction* is a collection of DOM mutations that can be applied, unapplied, or reapplied. UndoManager manages transactions and execute unapply and reapply upon undo and redo respectively. There are two types of DOM transactions: - *Managed transaction* - the app supplies apply() and the user agent automatically takes care of undo and redo. It is *compatible with user editing actions and editing commands*, and allows Web apps to easily add new editing operations or fix up DOM after user editing actions or editing commands and still have the user agent manage the undo and redo. - *Manual transaction* - the app supplies apply(), unapply(), and reapply() and *the app takes the full control of undo and redo*. However, it is NOT compatible with user editing actions, editing commands, or managed transactions, meaning that, the user agents won't be able to undo or redo them. This transaction is useful for apps such as a collaborative editor that implements domain-specific undo or redo. You can see more concrete definitions of UndoManager and Transaction at: https://rniwa.com/editing/undomanager.html and see a list of uses cases at https://rniwa.com/editing/undomanager-usecases.html. The documents are incomplete and I need your feedback in order to refine details. Best regards, Ryosuke Niwa Software Engineer Google Inc.
Re: [whatwg] Proposal to extend registerProtocolHandler
On Tue, Aug 2, 2011 at 5:53 AM, Ian Hickson i...@hixie.ch wrote:
On Tue, 26 Jul 2011, James Kozianski wrote:
Here are the use cases I had in mind:
1. Allow sites to conditionally show UI to promote the advantages of
registering the site as a handler.
(requires isRegistered)
2. Allow sites to provide settings screens which allow users to register
/ deregister handlers from within the site.
(requires isRegistered, and deregisterProtocolHandler)
The presence of an ignored list - sites who don't have permission to use
registerProtocolHandler - necessitates Michael Davidson's suggestion
that isRegistered() should return a tri-state value (REGISTERED,
DECLINED, NOTASKED). Otherwise sites that have been 'ignored' by a user
won't be able to tell if they should show their promotional UI or not.
Could you elaborate on what kind of UI we'retrying to enable here?
Based on the above use cases, it seems the API that directly addresses
them is:
navigator.shouldShowHandlerPromo('mailto:') = true/false
navigator.getCurrentHandlerState('mailto:') =
'display UI to unregister'
'display UI to register'
'tell user browser-specific way to re-enable previously declined
registration' (?)
navigator.unregisterHandler('mailto:')
...and equivalent for MIME types. Is that really all that is needed here?
(Ignore the names of the methods, they're not the names I'd use.)
shouldShowHandlerPromo() seems to capture the intent of the isRegistered()
function quite well. I can't think of any valid use cases apart from showing
promotional UI. A concrete example of the kind of UI we're trying to enable
is gmail's notifications UI [1].
getCurrentHandlerState() also seems to be fine. The intended result is that
a web developer can have something like a settings page that lets users
modify their protocol handler settings for that site, eg a form with radio
buttons for enable / disable. Again, gmail has an example of the UI we'd
like to enable [2].
Cheers,
James
[1]
http://t1.gstatic.com/images?q=tbn:ANd9GcSqpKN5FmbWKiC-6e-ptj6KJ_qbiyPuPj2M1YZO2wwIOAf6qdX8
[2]
http://img.technified.net/tf/Gmail-Desktop-notifications-for_14988/gmail-desktop-notification-settings.png
Re: [whatwg] Fixing undo on the Web - UndoManager and Transaction
On Tue, Aug 9, 2011 at 12:31 AM, Jonas Sicking jo...@sicking.cc wrote: I still see UndoManager.replace in there. I still haven't heard any use cases that won't be solved better with a beforeEditingAction event (and solved ok simply using the undo() function until we have a beforeEditingAction standardized). Right. I think we should remove it but I wanted to go talk with a bunch of developers first so they're still pending. Likewise I still haven't heard of any examples where the apply function isn't simply init+reapply. So it still seems better to me to have a init/apply/unapply split rather than a apply/reapply/unapply split. This is also pending for developer feedback. - Ryosuke
Re: [whatwg] Need clarification on DOM exceptions thrown by canvas 2D drawImage
On Mon, Aug 8, 2011 at 10:08 PM, Jeff Muizelaar jmuizel...@mozilla.com wrote: On 2011-08-08, at 4:58 PM, Ian Hickson wrote: On Mon, 8 Aug 2011, Justin Novosad wrote: This inquiry is regarding this page of the specification: http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html In section 4.8.11.1.10 Images, about drawImage(), it is stated that If one of the sw or sh arguments is zero, the implementation must raise an INDEX_SIZE_ERR exception There are no other references to other circumstances under which INDEX_SIZE_ERR should be thrown, and there is no indication of what the correct behavior is when the source rectangle is completely or partially outside the bounds of the source image. The spec used to throw exceptions on out-of-bounds source rectangles, but that causes breakage because floats are imprecise (e.g. http://www.jigzone.com/xmockup/oCanvasBug.php failed in Opera because 79.01 79 as 64-bit double, whereas other browsers presumably rounded to 32-bit float first), so it had to be changed. (http://html5.org/r/5373 first, then changed again because of http://www.w3.org/Bugs/Public/show_bug.cgi?id=10799 to be consistent with filtering behaviour.) A bit lower down in the same section, the spec says: When the filtering algorithm requires a pixel value from outside the original image data, it must instead use the value from the nearest edge pixel. (That is, the filter uses 'clamp-to-edge' behavior.) The clamp-to-edge behavior doesn't really work well with Coregraphics' drawImage call. This means that this behaviour is not implemented in Firefox on OS X and I expect WebKit doesn't implement it for a similar reason. I was actually hoping the spec could be changed to the simpler behaviour of just clamping the source rectangle to the bounds of the image. This behaviour is easy to implement on all platforms and is still quite reasonable. Does the clamp-to-edge behaviour work fine when the source rectangle is entirely inside the image? e.g. the image 8800 8800 0088 0088 (where each digit is a pixel) drawn at 2x scale with bilinear filtering should give 88862000 88862000 88862000 66653222 22235666 00026888 00026888 00026888 because of the filtering requirements. If CoreGraphics can't do that then it's broken (per the spec) regardless of how source rectangles are handled. Or is it able to do clamp-to-edge fine up to the edge of the source image, just not extend that beyond the image when the source rectangle is expanded further? -- Philip Taylor exc...@gmail.com
[whatwg] Microdata getItems()
I just want to confirm that my understanding of this is correct: getItems() will return a NodeList of top level microdata items and this is irrespective of whether or not the items are actually valid in terms of their type? That is, it is the developer's responsibility to confirm that the vCard has an fn and an n before further processing? It makes sense to me because I don't expect the browser to be downloading random vocabularies off the internet to check these things, but it doesn't seem to be explicitly referenced in the spec. There is a section which talks about de-referencing says that the browser can dereference the URL to provide item specific processing, but only if the applicable specification allows it. One further question - if an itemtype attribute is present there must also be an itemscope. However if I remove itemscope from the element the Opera beta implementation still returns it as a top level microdata item even though it is now invalid. Is this expected behaviour? Rob
[whatwg] relationship between Document and HTMLDocument
§3.1.1 includes the following:
interface HTMLDocument { ... };
Document implements HTMLDocument;
If I'm reading WebIDL correctly, this means that this expression must be
false:
document instanceof HTMLDocument
And also that this code will have no visible effect on the document object:
HTMLDocument.prototype.foo = function() { ... }
Furthermore, if I want to monkeypatch a method like getElementsByName()
that is defined by HTML, the correct place to do that is on
Document.prototype, not HTMLDocument.prototype
Currently, of course (tested in FF, Chrome and Safari), browsers treat
HTMLDocument as if it were declared like this:
interface HTMLDocument : Document { ... };
This means that in the current generation of browsers:
document instanceof HTMLDocument// = true
HTMLDocument.prototype.foo = function() {...} // affects document
Document.prototype.getElementsByName // undefined; can't monkeypatch it
I would guess (but have no data) that web compatibility will make these
behaviors difficult to change.
I assume that the use of an implements declaration rather than direct
inheritance is done to create a clean boundary between the DOM spec and
the HTML spec. But it seems to me that this clean boundary does not
reflect messy reality.
Ian: any chance you'd change HTML to specify that HTMLDocument is a
regular subclass of Document?
Anne: that would probably mean that you'd have to change the DOM spec to
say that DOMImplementation.create*Document() creates an HTMLDocument
even though your spec does not define that interface...
David
Re: [whatwg] Need clarification on DOM exceptions thrown by canvas 2D drawImage
Thanks Philip, that really cleared things up for me. Any chance you might adjust the 2d.drawImage.outsidesource.html test to reflect this change in the spec? because of the filtering requirements. If CoreGraphics can't do that then it's broken (per the spec) regardless of how source rectangles are handled. Or is it able to do clamp-to-edge fine up to the edge of the source image, just not extend that beyond the image when the source rectangle is expanded further? I second that. And in support of the spec, let me just say that the clamp-to-edge is essential for many existing canvas-based games that use large images as sprite maps. Without clamping to the edge of the source rectangle you would get color bleeding between adjacent sprites when the draw operation magnifies the sprite, or even just when it is not perfectly pixel-aligned. -Justin
Re: [whatwg] Need clarification on DOM exceptions thrown by canvas 2D drawImage
On 8/9/11 11:29 AM, Justin Novosad wrote: I second that. And in support of the spec, let me just say that the clamp-to-edge is essential for many existing canvas-based games that use large images as sprite maps. Without clamping to the edge of the source rectangle We're talking about clamping to the edge of the backing store, not clamping to the edge of the source rectangle, unless I missed something. There's no clamping to the edge of the source rectangle specified in the spec, as far as I can tell. -Boris
Re: [whatwg] relationship between Document and HTMLDocument
On 8/9/11 11:18 AM, David Flanagan wrote: I assume that the use of an implements declaration rather than direct inheritance is done to create a clean boundary between the DOM spec and the HTML spec. Or just to reflect Ian's belief that all documents should implement all document intefaces. In particular, the current spec text (which indeed does not match either older DOM specs or current implementations) requires all Document objects to implement the HTMLDocument interface. I don't believe that's the case in current UAs, fwiw... -Boris
Re: [whatwg] File API Streaming Blobs
FYI I'm working on an experimental extension to Chromium to allow media data to be streamed into a media element via JavaScript. Here is the draft spechttp://html5-mediasource-api.googlecode.com/svn/tags/0.2/draft-spec/mediasource-draft-spec.html and pending WebKit patch https://bugs.webkit.org/show_bug.cgi?id=64731 related to this work. I have simple WebM VOD playback w/ seeking working where all media data is fetched via XHR. Aaron On Mon, Aug 8, 2011 at 7:16 PM, Charles Pritchard ch...@jumis.com wrote: On 8/8/2011 2:51 PM, Glenn Maynard wrote: On Mon, Aug 8, 2011 at 4:31 PM, Simon Heckmann si...@simonheckmann.demailto: si...@simonheckmann.de** wrote: Well, not directly an answer to your question, but the use case I had in mind is the following: A large encrypted video (e.g. HD movie with 2GB) file is stored using the File API, I then want to decrypt this file and start playing with only a minor delay. I do not want to decrypt the entire file before it can be viewed. As long as such as use case gets covered I am fine with everything. Assuming you're thinking of DRM, are there any related use cases other than crypto? Encryption for DRM, at least, isn't a very compelling use case; client-side Javascript encryption is a very weak level of protection (putting aside, for now, the question of whether the web can or should be attempting to handle DRM in the first place). If it's not DRM you're thinking of, can you clarify? Jonas Sickling brought up a few cases for XHR-based streaming of arraybuffers: progressive rendering of word docs and PDFs. WebP and WebM have had interesting packaging hacks. Packaging itself, whether DRM or not, is compelling. PDF supports embedded data, a wide range of formats. GPAC provides many related tools (MP4 based, I believe): http://gpac.wp.institut-**telecom.fr/http://gpac.wp.institut-telecom.fr/ The audio and video tags drop frames It seems to me that if a listener is not registered to the stream, data would just be dropped. As an alternative, the author could register a fixed length circular buffer. For instance, I could create 1 megabyte arrayview, run URL.createBlobStream(**ArrayView) and use .append(data). That kind of structure may support multicast (multiple audio/video elements) and improved XHR2 semantics. The circular buffer, itself, is easy to prototype: subarray works well with typed arrays. Otherwise relevant, is the work on raw audio data that Firefox and Chromium have released as experimental extensions. It does work on a buffer-based system. -Charles
Re: [whatwg] Need clarification on DOM exceptions thrown by canvas 2D drawImage
On Tue, Aug 9, 2011 at 11:56 AM, Boris Zbarsky bzbar...@mit.edu wrote: On 8/9/11 11:29 AM, Justin Novosad wrote: I second that. And in support of the spec, let me just say that the clamp-to-edge is essential for many existing canvas-based games that use large images as sprite maps. Without clamping to the edge of the source rectangle We're talking about clamping to the edge of the backing store, not clamping to the edge of the source rectangle, unless I missed something. There's no clamping to the edge of the source rectangle specified in the spec, as far as I can tell. It sounds like it would make fast GPU-accelerated blitting difficult, even in fairly simple cases. -- Glenn Maynard
Re: [whatwg] Need clarification on DOM exceptions thrown by canvas 2D drawImage
It sounds like it would make fast GPU-accelerated blitting difficult, even in fairly simple cases. Not that bad. I can think of two ways: A) create a cropped texture just for the sub rectangle B) implement your own clamping in the shader I think A) is problematic because some platforms do not have non-power-of-two textures, though that problem is slowly fading away. Chrome does B) -Justin
Re: [whatwg] relationship between Document and HTMLDocument
On 8/9/11 8:53 AM, Boris Zbarsky wrote: On 8/9/11 11:18 AM, David Flanagan wrote: I assume that the use of an implements declaration rather than direct inheritance is done to create a clean boundary between the DOM spec and the HTML spec. Or just to reflect Ian's belief that all documents should implement all document intefaces. In particular, the current spec text (which indeed does not match either older DOM specs or current implementations) requires all Document objects to implement the HTMLDocument interface. I don't believe that's the case in current UAs, fwiw... -Boris Yes, that is the case in FF and Chrome, at least. I didn't bring that up because my intuition is that browsers could make that change (adding HTMLDocument members to non-HTML documents) without as much web compatibility impact. David
Re: [whatwg] relationship between Document and HTMLDocument
On 8/9/11 1:59 PM, David Flanagan wrote: Yes, that is the case in FF and Chrome, at least. I didn't bring that up because my intuition is that browsers could make that change (adding HTMLDocument members to non-HTML documents) without as much web compatibility impact. Maybe. Adding them to SVG documents, for example, might have nontrivial compat impact... -Boris
Re: [whatwg] Fixing undo on the Web - UndoManager and Transaction
On Tue, Aug 9, 2011 at 1:17 AM, Jonas Sicking jo...@sicking.cc wrote:
On Tue, Aug 9, 2011 at 12:42 AM, Ryosuke Niwa rn...@webkit.org wrote:
On Tue, Aug 9, 2011 at 12:31 AM, Jonas Sicking jo...@sicking.cc wrote:
Likewise I still haven't heard of any examples where the apply function
isn't simply init+reapply. So it still seems better to me to have a
init/apply/unapply split rather than a apply/reapply/unapply split.
This is also pending for developer feedback.
I've talked about this with Alex, and we both agreed that having
apply/reapply split is cleaner because in many cases you'd like to know
whether you're in redo or not. i.e. more work is done in reapply than in
apply.
Excellent. For what it's worth, apart from those two items, the only
difference between our proposals is the use of explicit Transaction objects,
which is purely a syntactical difference. I would be super interested to get
developer feedback on that difference too (though I think I know what Alex
Russell will say :) ).
I also talked about this with Alex. We both agreed that the tricky part
will be when we add the transaction event. It appears that the listener of
such an event wants to see a transaction object and access properties of it.
Having to call methods on undoManager in the listeners seem unnatural.
The main advantage that I see with your proposal is that it makes it easy to
create a reusable subclass for a ManualTransaction:
A big advantage I see with my proposal is that it explicitly creates an
object, and makes it easier for scripts to add more properties. In the case
of manual transactions, apply functions most definitely need to add some
properties on the transaction object in order to remember what has been
removed or added.
But I do agree that having to do new ManagedTransaction every time you
create a transaction may be too verbose. Alex proposes that we make the
transaction object duck-typed. So we'll have something like:
myEditor.undoManager.managedTransaction(
{apply: function() {...}, label: ...});
myEditor.undoManager.manualTransaction(
{apply: function() {...}, unapply: function() {...}, reapply: function()
{...}});
It's much less verbose than my proposal but provides a way for scripts to
add arbitrary objects of their choice.
- Ryosuke
Re: [whatwg] Microdata getItems()
On Tue, 9 Aug 2011, Rob Crowther wrote: I just want to confirm that my understanding of this is correct: getItems() will return a NodeList of top level microdata items and this is irrespective of whether or not the items are actually valid in terms of their type? That is, it is the developer's responsibility to confirm that the vCard has an fn and an n before further processing? Correct. Browsers aren't expected to know about the vocabularies, let alone validate them. One further question - if an itemtype attribute is present there must also be an itemscope. However if I remove itemscope from the element the Opera beta implementation still returns it as a top level microdata item even though it is now invalid. Is this expected behaviour? No. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] relationship between Document and HTMLDocument
On Tue, 9 Aug 2011, David Flanagan wrote:
�3.1.1 includes the following:
interface HTMLDocument { ... };
Document implements HTMLDocument;
If I'm reading WebIDL correctly, this means that this expression must be
false:
document instanceof HTMLDocument
And also that this code will have no visible effect on the document object:
HTMLDocument.prototype.foo = function() { ... }
Furthermore, if I want to monkeypatch a method like getElementsByName() that
is defined by HTML, the correct place to do that is on Document.prototype, not
HTMLDocument.prototype
Currently, of course (tested in FF, Chrome and Safari), browsers treat
HTMLDocument as if it were declared like this:
interface HTMLDocument : Document { ... };
This means that in the current generation of browsers:
document instanceof HTMLDocument// = true
HTMLDocument.prototype.foo = function() {...} // affects document
Document.prototype.getElementsByName // undefined; can't monkeypatch it
I would guess (but have no data) that web compatibility will make these
behaviors difficult to change.
Possibly. I think an alternative is to make the HTML spec just add all the
members to Document, and then define window.HTMLDocument as returning the
Document interface object. This would make instanceof and monkeypatching
work as today.
I assume that the use of an implements declaration rather than direct
inheritance is done to create a clean boundary between the DOM spec and
the HTML spec.
No, it was done because inheritance here makes no sense. A Document is a
Document, you can take it and replace its root html element with a root
svg element, or mix html and svg, or any number of other similar
things, and it seems to me that it should all work. Why have different
Document objects? What if an html file has some svg in it, should it
not be able to get to the SVG API? etc.
But it seems to me that this clean boundary does not reflect messy
reality.
Indeed, this is an example of a new feature that browsers haven't
implemented yet.
Ian: any chance you'd change HTML to specify that HTMLDocument is a
regular subclass of Document?
Not unless we find no other way to fix the bugs in the current API in a
backwards-compatible way. :-)
On Tue, 9 Aug 2011, Boris Zbarsky wrote:
In particular, the current spec text (which indeed does not match either
older DOM specs or current implementations) requires all Document
objects to implement the HTMLDocument interface. I don't believe that's
the case in current UAs, fwiw...
Correct. This is an instance of the spec attempting to show the way
forward.
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] relationship between Document and HTMLDocument
On 8/9/11 12:53 PM, Ian Hickson wrote:
On Tue, 9 Aug 2011, David Flanagan wrote:
�3.1.1 includes the following:
interface HTMLDocument { ... };
Document implements HTMLDocument;
If I'm reading WebIDL correctly, this means that this expression must be
false:
document instanceof HTMLDocument
And also that this code will have no visible effect on the document object:
HTMLDocument.prototype.foo = function() { ... }
Furthermore, if I want to monkeypatch a method like getElementsByName() that
is defined by HTML, the correct place to do that is on Document.prototype, not
HTMLDocument.prototype
Currently, of course (tested in FF, Chrome and Safari), browsers treat
HTMLDocument as if it were declared like this:
interface HTMLDocument : Document { ... };
This means that in the current generation of browsers:
document instanceof HTMLDocument// = true
HTMLDocument.prototype.foo = function() {...} // affects document
Document.prototype.getElementsByName // undefined; can't monkeypatch it
I would guess (but have no data) that web compatibility will make these
behaviors difficult to change.
Possibly. I think an alternative is to make the HTML spec just add all the
members to Document, and then define window.HTMLDocument as returning the
Document interface object. This would make instanceof and monkeypatching
work as today.
So you'd declare HTMLDocument with the [NoInterfaceObject] extended
attribute and then add attribute HTMLDocument to the Window interface?
That changes HTMLDocument from non-enumerable to enumerable, but that
seems unlikely to be a compatibility issue. That works for me, I think.
David
Re: [whatwg] relationship between Document and HTMLDocument
On Tue, 9 Aug 2011, David Flanagan wrote: Possibly. I think an alternative is to make the HTML spec just add all the members to Document, and then define window.HTMLDocument as returning the Document interface object. This would make instanceof and monkeypatching work as today. So you'd declare HTMLDocument with the [NoInterfaceObject] extended attribute and then add attribute HTMLDocument to the Window interface? That would have the same effect, but what I had in mind was actually to change the HTML spec to not define an HTMLDocument interface, instead renaming it to Document and adding the 'partial' WebIDL modifier. We'd also have to do this for SVGDocument and other document objects; before doing this it would be good to see if it's something that is generally agreeable to everyone. That changes HTMLDocument from non-enumerable to enumerable, but that seems unlikely to be a compatibility issue. That works for me, I think. Could you elaborate on this? I'm not sure what you mean exactly. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Fixing undo on the Web - UndoManager and Transaction
On Tue, Aug 9, 2011 at 12:03 PM, Ryosuke Niwa rn...@webkit.org wrote:
On Tue, Aug 9, 2011 at 1:17 AM, Jonas Sicking jo...@sicking.cc wrote:
On Tue, Aug 9, 2011 at 12:42 AM, Ryosuke Niwa rn...@webkit.org wrote:
On Tue, Aug 9, 2011 at 12:31 AM, Jonas Sicking jo...@sicking.cc
wrote:
Likewise I still haven't heard of any examples where the
apply function
isn't simply init+reapply. So it still seems better to me to have a
init/apply/unapply split rather than a apply/reapply/unapply split.
This is also pending for developer feedback.
I've talked about this with Alex, and we both agreed that having
apply/reapply split is cleaner because in many cases you'd like to know
whether you're in redo or not. i.e. more work is done in reapply than in
apply.
Could you please provide examples. I feel like I'm fighting an elusive
shadow.
I.e. please provide an example where apply isn't just init+reapply. There
are many cases isn't a particularly compelling argument unless you can show
these cases :-)
And ideally also some estimate how common that case will be compared to
apply simply being init+reapply. This is important since if that is very
rare, people can always implement it themselves using init+reapply semantics
by having a flag on the object which indicates if you're in the first call
or not.
Excellent. For what it's worth, apart from those two items, the only
difference between our proposals is the use of explicit Transaction objects,
which is purely a syntactical difference. I would be super interested to get
developer feedback on that difference too (though I think I know what Alex
Russell will say :) ).
I also talked about this with Alex. We both agreed that the tricky part
will be when we add the transaction event. It appears that the listener of
such an event wants to see a transaction object and access properties of it.
Having to call methods on undoManager in the listeners seem unnatural.
The main advantage that I see with your proposal is that it makes it easy
to create a reusable subclass for a ManualTransaction:
A big advantage I see with my proposal is that it explicitly creates an
object, and makes it easier for scripts to add more properties. In the case
of manual transactions, apply functions most definitely need to add some
properties on the transaction object in order to remember what has been
removed or added.
But I do agree that having to do new ManagedTransaction every time you
create a transaction may be too verbose. Alex proposes that we make the
transaction object duck-typed. So we'll have something like:
myEditor.undoManager.managedTransaction(
{apply: function() {...}, label: ...});
myEditor.undoManager.manualTransaction(
{apply: function() {...}, unapply: function() {...}, reapply: function()
{...}});
It's much less verbose than my proposal but provides a way for scripts to
add arbitrary objects of their choice.
I like this! (except for the apply/reapply/unapply split, please do answer
the question above)
The example used in this thread would become something like (independent of
if we use init/apply/unapply or apply/reapply/unapply):
myEditor.undoManager.manualTransaction(
{ apply: function () { this.nodeBefore.parentNode.insertBefore(this.text,
this.nodeBefore); },
unapply: function () { this.text.parentNode.removeChild(this.text); },
text: document.createTextNode('hello'),
nodeBefore: window.getSelection().anchorNode
});
/ Jonas
Re: [whatwg] relationship between Document and HTMLDocument
On 8/9/11 1:58 PM, Ian Hickson wrote: On Tue, 9 Aug 2011, David Flanagan wrote: Possibly. I think an alternative is to make the HTML spec just add all the members to Document, and then define window.HTMLDocument as returning the Document interface object. This would make instanceof and monkeypatching work as today. So you'd declare HTMLDocument with the [NoInterfaceObject] extended attribute and then add attribute HTMLDocument to the Window interface? That would have the same effect, but what I had in mind was actually to change the HTML spec to not define an HTMLDocument interface, instead renaming it to Document and adding the 'partial' WebIDL modifier. We'd also have to do this for SVGDocument and other document objects; before doing this it would be good to see if it's something that is generally agreeable to everyone. Is the partial keyword a brand-new feature of WebIDL? I didn't see them discussed on public-script-coord at all... A partial interface sounds like it would work to me. That changes HTMLDocument from non-enumerable to enumerable, but that seems unlikely to be a compatibility issue. That works for me, I think. Could you elaborate on this? I'm not sure what you mean exactly. The HTMLDocument interface object is current (at least in FF, and per the WebIDL spec) non-enumerable. It doesn't show up in for/in loops on the window. If the HTML spec were to add an attribute to the Window object to define the HTMLDocument property, WebIDL would make that property enumerable. It would also change from a data property to an accessor property. I'm not arguing that these changes would be a problem, just noting them. The much bigger change, of course, is that HTMLDocument would be === Document.
Re: [whatwg] relationship between Document and HTMLDocument
On Tue, 9 Aug 2011, David Flanagan wrote: The HTMLDocument interface object is current (at least in FF, and per the WebIDL spec) non-enumerable. It doesn't show up in for/in loops on the window. If the HTML spec were to add an attribute to the Window object to define the HTMLDocument property, WebIDL would make that property enumerable. It would also change from a data property to an accessor property. Ah, ok. Well in any case the goal is to be backwards-compatible with legacy content, while moving us to a world where HTML and SVG can coexist in the same document and access their respective Document-level APIs. Whatever it takes to do that is whatever we'll have to do. Might well involve WebIDL changes, or HTML spec changes, or whatnot. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Fixing undo on the Web - UndoManager and Transaction
On Tue, Aug 9, 2011 at 1:59 PM, Jonas Sicking jo...@sicking.cc wrote:
On Tue, Aug 9, 2011 at 12:03 PM, Ryosuke Niwa rn...@webkit.org wrote:
On Tue, Aug 9, 2011 at 1:17 AM, Jonas Sicking jo...@sicking.cc wrote:
On Tue, Aug 9, 2011 at 12:42 AM, Ryosuke Niwa rn...@webkit.org wrote:
On Tue, Aug 9, 2011 at 12:31 AM, Jonas Sicking jo...@sicking.cc
wrote:
Likewise I still haven't heard of any examples where the
apply function
isn't simply init+reapply. So it still seems better to me to have a
init/apply/unapply split rather than a apply/reapply/unapply split.
This is also pending for developer feedback.
I've talked about this with Alex, and we both agreed that having
apply/reapply split is cleaner because in many cases you'd like to know
whether you're in redo or not. i.e. more work is done in reapply than in
apply.
Could you please provide examples. I feel like I'm fighting an elusive
shadow.
For example, in editing apps, you have to restore selection on redo.
Presumably, the UA can auto-restore selection in managed transactions but
restoring selection in manual selection is hard since DOM after redo might
look completely different from the DOM after the first apply.
(I've sent out a massive email to a bunch of Googlers who have worked on
RTE, but unfortunately some of them are OOO until mid or late September so
please be patient with me about developer feedbacks).
On the other hand, what are use cases that are better addressed by your
proposal? Do you have specific examples in your mind? Also, the following
code will provide the same functionality as your proposal:
apply: function () {init(); action();}
unapply: unapply
reapply: action
I like this! (except for the apply/reapply/unapply split, please do answer
the question above)
The example used in this thread would become something like (independent of
if we use init/apply/unapply or apply/reapply/unapply):
myEditor.undoManager.manualTransaction(
{ apply: function () { this.nodeBefore.parentNode.insertBefore(this.text,
this.nodeBefore); },
unapply: function () { this.text.parentNode.removeChild(this.text); },
text: document.createTextNode('hello'),
nodeBefore: window.getSelection().anchorNode
});
Yeah, this looks much cleaner than the current syntax. Let's make this
change then (duck typed object).
- Ryosuke
Re: [whatwg] Fixing undo on the Web - UndoManager and Transaction
On Tue, Aug 9, 2011 at 2:44 PM, Ryosuke Niwa rn...@webkit.org wrote:
On Tue, Aug 9, 2011 at 1:59 PM, Jonas Sicking jo...@sicking.cc wrote:
On Tue, Aug 9, 2011 at 12:03 PM, Ryosuke Niwa rn...@webkit.org wrote:
On Tue, Aug 9, 2011 at 1:17 AM, Jonas Sicking jo...@sicking.cc wrote:
On Tue, Aug 9, 2011 at 12:42 AM, Ryosuke Niwa rn...@webkit.org wrote:
On Tue, Aug 9, 2011 at 12:31 AM, Jonas Sicking jo...@sicking.cc
wrote:
Likewise I still haven't heard of any examples where the
apply function
isn't simply init+reapply. So it still seems better to me to have a
init/apply/unapply split rather than a apply/reapply/unapply split.
This is also pending for developer feedback.
I've talked about this with Alex, and we both agreed that having
apply/reapply split is cleaner because in many cases you'd like to know
whether you're in redo or not. i.e. more work is done in reapply than in
apply.
Could you please provide examples. I feel like I'm fighting an elusive
shadow.
For example, in editing apps, you have to restore selection on redo.
Presumably, the UA can auto-restore selection in managed transactions but
restoring selection in manual selection is hard since DOM after redo might
look completely different from the DOM after the first apply.
(I've sent out a massive email to a bunch of Googlers who have worked on
RTE, but unfortunately some of them are OOO until mid or late September so
please be patient with me about developer feedbacks).
On the other hand, what are use cases that are better addressed by your
proposal? Do you have specific examples in your mind? Also, the following
code will provide the same functionality as your proposal:
apply: function () {init(); action();}
unapply: unapply
reapply: action
Selection restoration is indeed a important point, i'll have to think about
that.
I don't think it's a matter of which use cases can or can't be solved with
either solution. It's pretty clear to me that all scenarios can be solved
with either API. It's just a matter of which pattern is more common and so
which one we should make more convenient. If almost everyone puts the same
code in apply and reapply then we're just creating more work for people.
Here's how you'd implement the apply/reapply/unapply syntax using simply
apply/unapply
apply: function() { if (!this.applied) { action1(); this.applied = true; }
else { action2(); }
unapply: unapply
I like this! (except for the apply/reapply/unapply split, please do answer
the question above)
The example used in this thread would become something like (independent
of if we use init/apply/unapply or apply/reapply/unapply):
myEditor.undoManager.manualTransaction(
{ apply: function () {
this.nodeBefore.parentNode.insertBefore(this.text, this.nodeBefore); },
unapply: function () { this.text.parentNode.removeChild(this.text); },
text: document.createTextNode('hello'),
nodeBefore: window.getSelection().anchorNode
});
Yeah, this looks much cleaner than the current syntax. Let's make this
change then (duck typed object).
Awesome!
/ Jonas
Re: [whatwg] Fixing undo on the Web - UndoManager and Transaction
On Tue, Aug 9, 2011 at 4:59 PM, Jonas Sicking jo...@sicking.cc wrote: On Tue, Aug 9, 2011 at 12:03 PM, Ryosuke Niwa rn...@webkit.org wrote: On Tue, Aug 9, 2011 at 1:17 AM, Jonas Sicking jo...@sicking.cc wrote: On Tue, Aug 9, 2011 at 12:42 AM, Ryosuke Niwa rn...@webkit.org wrote: On Tue, Aug 9, 2011 at 12:31 AM, Jonas Sicking jo...@sicking.cc wrote: Likewise I still haven't heard of any examples where the apply function isn't simply init+reapply. So it still seems better to me to have a init/apply/unapply split rather than a apply/reapply/unapply split. This is also pending for developer feedback. I've talked about this with Alex, and we both agreed that having apply/reapply split is cleaner because in many cases you'd like to know whether you're in redo or not. i.e. more work is done in reapply than in apply. Could you please provide examples. I feel like I'm fighting an elusive shadow. I.e. please provide an example where apply isn't just init+reapply. There are many cases isn't a particularly compelling argument unless you can show these cases :-) And ideally also some estimate how common that case will be compared to apply simply being init+reapply. This is important since if that is very rare, people can always implement it themselves using init+reapply semantics by having a flag on the object which indicates if you're in the first call or not. As an author, I would really love to have as much information as possible about what the user was trying to do. I might want to keep my own bookkeeping about what is going on in the document, in some other format besides HTML. For example, if I were writing a collaborative editing app, and I decided that any user could unapply/reapply any change, I might end up with a sequence like this: Susan made change X Bob unapplied change X Susan reapplied change X Bob unapplied change X Susan reapplied change X ... It would be great to show that in the document history view of my app very clearly. I think knowing that a change was unapplied/reapplied instead of just showing text diffs between revisions would be great. -Annie
Re: [whatwg] Fixing undo on the Web - UndoManager and Transaction
On Tue, Aug 9, 2011 at 2:55 PM, Jonas Sicking jo...@sicking.cc wrote:
I don't think it's a matter of which use cases can or can't be solved with
either solution. It's pretty clear to me that all scenarios can be solved
with either API.
Right, they're isomorphic.
It's just a matter of which pattern is more common and so which one we
should make more convenient. If almost everyone puts the same code in apply
and reapply then we're just creating more work for people.
Here's how you'd implement the apply/reapply/unapply syntax using simply
apply/unapply
apply: function() { if (!this.applied) { action1(); this.applied = true; }
else { action2(); }
unapply: unapply
One thing I don't like about this approach is that it requires a flag. With
my proposal, all you need to do is to call a function. Also, we can make it
so that when you don't supply a value to reapply (i.e. reapply is null),
then undoManager automatically calls apply instead (I always intended this
behavior from the beginning but I've apparently left this details out).
- Ryosuke
Re: [whatwg] Fixing undo on the Web - UndoManager and Transaction
On Tue, Aug 9, 2011 at 2:59 PM, Annie Sullivan sulli...@google.com wrote: On Tue, Aug 9, 2011 at 4:59 PM, Jonas Sicking jo...@sicking.cc wrote: On Tue, Aug 9, 2011 at 12:03 PM, Ryosuke Niwa rn...@webkit.org wrote: On Tue, Aug 9, 2011 at 1:17 AM, Jonas Sicking jo...@sicking.cc wrote: On Tue, Aug 9, 2011 at 12:42 AM, Ryosuke Niwa rn...@webkit.org wrote: On Tue, Aug 9, 2011 at 12:31 AM, Jonas Sicking jo...@sicking.cc wrote: Likewise I still haven't heard of any examples where the apply function isn't simply init+reapply. So it still seems better to me to have a init/apply/unapply split rather than a apply/reapply/unapply split. This is also pending for developer feedback. I've talked about this with Alex, and we both agreed that having apply/reapply split is cleaner because in many cases you'd like to know whether you're in redo or not. i.e. more work is done in reapply than in apply. Could you please provide examples. I feel like I'm fighting an elusive shadow. I.e. please provide an example where apply isn't just init+reapply. There are many cases isn't a particularly compelling argument unless you can show these cases :-) And ideally also some estimate how common that case will be compared to apply simply being init+reapply. This is important since if that is very rare, people can always implement it themselves using init+reapply semantics by having a flag on the object which indicates if you're in the first call or not. As an author, I would really love to have as much information as possible about what the user was trying to do. I might want to keep my own bookkeeping about what is going on in the document, in some other format besides HTML. For example, if I were writing a collaborative editing app, and I decided that any user could unapply/reapply any change, I might end up with a sequence like this: Susan made change X Bob unapplied change X Susan reapplied change X Bob unapplied change X Susan reapplied change X ... It would be great to show that in the document history view of my app very clearly. I think knowing that a change was unapplied/reapplied instead of just showing text diffs between revisions would be great. I'm not quite sure I understand what API you are arguing for and how that API would help you. If you're wanting to show that a change was unapplied/reapplied, wouldn't you also want to show who did the unapply/reapply? In that case you'd have to do your own book keeping anyway, no? / Jonas
Re: [whatwg] Fixing undo on the Web - UndoManager and Transaction
On Tue, Aug 9, 2011 at 3:11 PM, Ryosuke Niwa rn...@webkit.org wrote:
On Tue, Aug 9, 2011 at 2:55 PM, Jonas Sicking jo...@sicking.cc wrote:
I don't think it's a matter of which use cases can or can't be solved with
either solution. It's pretty clear to me that all scenarios can be solved
with either API.
Right, they're isomorphic.
It's just a matter of which pattern is more common and so which one we
should make more convenient. If almost everyone puts the same code in apply
and reapply then we're just creating more work for people.
Here's how you'd implement the apply/reapply/unapply syntax using simply
apply/unapply
apply: function() { if (!this.applied) { action1(); this.applied = true; }
else { action2(); }
unapply: unapply
One thing I don't like about this approach is that it requires a flag. With
my proposal, all you need to do is to call a function. Also, we can make it
so that when you don't supply a value to reapply (i.e. reapply is null),
then undoManager automatically calls apply instead (I always intended this
behavior from the beginning but I've apparently left this details out).
Sure, your API is more convenient in certain situations. But it also
encourages code duplication (I'll note that in the examples you
originally provided in this thread you always ended up duplicating
code between apply/reapply), which easily leads to bugs.
Another point to keep in mind is that we can always end up adding
features that makes certain use cases more convenient. There is
literally an infinite amount of things people will want to do and APIs
we can add to make it easier for them to do it. The question we need
to ask ourselves is where to draw the line. The way to do that is to
look at which use cases requires which features, and how common those
use cases are.
I do definitely agree that making the reapply function optional helps
a lot in that at least pages don't have to worry about the feature if
they're not using it. If we do that though we should probably rename
the 'apply' property for managed transactions since it's semantics are
pretty different. 'apply' for managed transactions are only called
once when the transaction is first added. 'apply' for manual
transactions are potentially called every time the transaction is
(re)applied.
/ Jonas
Re: [whatwg] Fixing undo on the Web - UndoManager and Transaction
On Tue, Aug 9, 2011 at 3:29 PM, Annie Sullivan sulli...@chromium.org wrote: On Tue, Aug 9, 2011 at 6:25 PM, Jonas Sicking jo...@sicking.cc wrote: On Tue, Aug 9, 2011 at 2:59 PM, Annie Sullivan sulli...@google.com wrote: On Tue, Aug 9, 2011 at 4:59 PM, Jonas Sicking jo...@sicking.cc wrote: On Tue, Aug 9, 2011 at 12:03 PM, Ryosuke Niwa rn...@webkit.org wrote: On Tue, Aug 9, 2011 at 1:17 AM, Jonas Sicking jo...@sicking.cc wrote: On Tue, Aug 9, 2011 at 12:42 AM, Ryosuke Niwa rn...@webkit.org wrote: On Tue, Aug 9, 2011 at 12:31 AM, Jonas Sicking jo...@sicking.cc wrote: Likewise I still haven't heard of any examples where the apply function isn't simply init+reapply. So it still seems better to me to have a init/apply/unapply split rather than a apply/reapply/unapply split. This is also pending for developer feedback. I've talked about this with Alex, and we both agreed that having apply/reapply split is cleaner because in many cases you'd like to know whether you're in redo or not. i.e. more work is done in reapply than in apply. Could you please provide examples. I feel like I'm fighting an elusive shadow. I.e. please provide an example where apply isn't just init+reapply. There are many cases isn't a particularly compelling argument unless you can show these cases :-) And ideally also some estimate how common that case will be compared to apply simply being init+reapply. This is important since if that is very rare, people can always implement it themselves using init+reapply semantics by having a flag on the object which indicates if you're in the first call or not. As an author, I would really love to have as much information as possible about what the user was trying to do. I might want to keep my own bookkeeping about what is going on in the document, in some other format besides HTML. For example, if I were writing a collaborative editing app, and I decided that any user could unapply/reapply any change, I might end up with a sequence like this: Susan made change X Bob unapplied change X Susan reapplied change X Bob unapplied change X Susan reapplied change X ... It would be great to show that in the document history view of my app very clearly. I think knowing that a change was unapplied/reapplied instead of just showing text diffs between revisions would be great. I'm not quite sure I understand what API you are arguing for and how that API would help you. If you're wanting to show that a change was unapplied/reapplied, wouldn't you also want to show who did the unapply/reapply? In that case you'd have to do your own book keeping anyway, no? Yes, if you're keeping additional metadata, you have to do your own bookkeeping, but it's much easier to get the info about whether the change was applied or reapplied if the API is set up so that you have an apply/reapply instead of init/apply. We're talking about a line of code setting a single boolean flag. That's not a whole lot of code. And for a very narrow usecase that can hardly be considered the common usecase. I.e. wanting to display if a change has been unapplied/reapplied, but not wanting to show any other metadata about the change (such as who or when), in a collaborative editor. Any feature that is so easy to replace and is going to be used that rarely I'd cut in a heartbeat. It did sound like selection management could be a much stronger use case though. / Jonas
