Re: [whatwg] Fixing undo on the Web - UndoManager and Transaction
On Fri, 05 Aug 2011 02:31:10 +0200, Ryosuke Niwa rn...@webkit.org wrote: Not sure. This happens all the time in design mode. We've had plenty of crash reports that only reproduce when there are no document element. It might also be hard to implement such a behavior in WebKit at least because documents / frames have the undo stack managed by OS X or embedders and having to fake non-existence of the undo stack might be tricky. Fair enough, maybe it would be best to say there's an undo stack scoped to Document nodes, but exposed on its documentElement to keep the API simple (only on Element nodes). -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] Discrepancies between HTML and ES rules for parsing an integer or float
On Fri, Aug 5, 2011 at 1:57 AM, Jonas Sicking jo...@sicking.cc wrote: It would make sense to me to match ES here. The main concern is of course website compat. Could someone detail what the differences would be compared to what implementations/the HTML5 spec do now? As far as I know, the only difference between the HTML and ES algorithms is handling of non-ASCII whitespace: ES treats it as whitespace, HTML does not. Specifically, ES treats StrWhiteSpaceChar as leading whitespace: http://es5.github.com/#x15.1.2.2 That includes any Unicode space separator (Zs), which in particular changes over time (which seems to be Hixie's main objection IIUC). HTML uses skip whitespace: http://www.whatwg.org/specs/web-apps/current-work/multipage/common-microsyntaxes.html#signed-integers Which if you follow the breadcrumbs means only [ \t\n\r\f]. So it's almost never going to make any difference in practice, we're talking only about corner cases. I have a simple test-case at http://www.w3.org/Bugs/Public/show_bug.cgi?id=12296#c4 that shows all browsers strip leading \x0b (vertical tab) when converting DOM attributes to ints, which matches ES and not HTML. For parsing floats this would not seem like a problem though since attributes containing floats is relatively new IIRC. Yes, that's correct. There's definitely no compat issue here with floats, but really there's not going to be any with ints either, since it's going to be exceedingly rare that anyone will put Unicode whitespace in DOM attributes that are reflected as integers and then rely on them working. So it's just a question of if we'd prefer the algorithms to match or not.
Re: [whatwg] Fixing undo on the Web - UndoManager and Transaction
On Fri, Aug 5, 2011 at 9:57 AM, Jonas Sicking jo...@sicking.cc wrote: Why treat documentElement specially here? Just make the documentElement *not* have a undoManager by default and have it just use it's ancestor's, just like all other elements. The document is an ancestor of the documentElement after all. Anne had a different idea to make documentElement have the root undoManager to avoid adding a new property to Document. I personally like your approach but I don't know enough about Web IDLs to give a call. Anyone else have opinions on this? - Ryosuke
Re: [whatwg] Fixing undo on the Web - UndoManager and Transaction
On Fri, Aug 5, 2011 at 10:01 AM, Ryosuke Niwa rn...@webkit.org wrote: On Fri, Aug 5, 2011 at 9:57 AM, Jonas Sicking jo...@sicking.cc wrote: Why treat documentElement specially here? Just make the documentElement *not* have a undoManager by default and have it just use it's ancestor's, just like all other elements. The document is an ancestor of the documentElement after all. Anne had a different idea to make documentElement have the root undoManager to avoid adding a new property to Document. I personally like your approach but I don't know enough about Web IDLs to give a call. Anyone else have opinions on this? I don't think this is a WebIDL issue really. Given the inconsistencies that it introduces in that a property appears on documentElement, but isn't actually associated with the element, and the fact that people will have to wrote the longer syntax document.documentElement.undoManager rather than document.undoManager, I think it's better to just expose it on the Document. Adding things to the Window object is always iffy as that's the global object, adding things to Document isn't really a big deal IMHO. / Jonas
[whatwg] drawFocusRing Review
The current description of draw*FocusRing does not have inform the user in the correct priority. It currently follows cases where the user should be informed, but the steps have been aborted. Please review the following an provide feedback. This attempts to serve the use cases put forward for focus ring management. In the first case, the system manages the focus ring, using its own style or using the style set out by the current canvas context. The canvas is not dirtied, though the author does have an opportunity to continue drawing focus indicators onto the canvas. In the second example, it is up to the author to decide on what visualizations they will use. They will likely draw to the canvas, but they may decide to handle the visualization differently (such as moving another canvas layer over the current canvas, and painting a bounding box). In both examples, the accessibility api is informed of the current focus. Change proposal follows: The |drawFocusRing(element)| method, when invoked, must run the following steps: 1. If the element is not focused or is not a descendant of the element with focus, then return false and abort these steps. 2. If supporting accessibility, inform the user that the focus ring is at the location computed from the bounds of the path. User agents may wait until the next time the event loop reaches its update the rendering step to inform the user. 3. If the user has requested the use of particular focus rings (e.g. high-contrast focus rings) then draw a focus ring of the appropriate style along the path, following platform conventions. Some platforms only draw focus rings around elements that have been focused from the keyboard, and not those focused from the mouse. Other platforms simply don't draw focus rings around some elements at all unless relevant accessibility features are enabled. This API is intended to follow these conventions. User agents that implement distinctions based on the manner in which the element was focused are encouraged to classify focus driven by the |focus()| method based on the kind of user interaction event from which the call was triggered (if any). The focus ring should not be subject to the shadow effects, the global alpha, or the global composition operators, but /should/ be subject to the clipping region. 4. Otherwise, draw a focus along the path using the current path style settings. The focus ring should not be subject to the shadow effects, the global alpha, or the global composition operators, but /should/ be subject to the clipping region. 5. Return true. The |drawCustomFocusRing(element)| method, when invoked, must run the following steps: 1. If the element is not focused or is not a descendant of the element with focus, then return false and abort these steps. 2. If supporting accessibility, inform the user that the focus ring is at the location computed from the bounds of the path. User agents may wait until the next time the event loop reaches its update the rendering step to inform the user. 3. Return true.
Re: [whatwg] [editing] HTML Editing APIs specification ready for implementer feedback
On Thu, Aug 4, 2011 at 5:22 PM, Ryosuke Niwa rn...@webkit.org wrote:
I see. It's an interesting point. In WebKit, we're quite inconsistent in
relying on CSS/rendering engine and pure DOM. This is an inherent issue in
RTE because user would like the editor to work like WYSIWYG yet we have to
produce conforming markup :(
Yeah, it's a problem. The basic issue is that there are no standard
interfaces to query things like what's the height of this br? or
are these two nodes in the same line box? from CSS, so I have
nothing to reference and browser engines might not even know the
information. So I hack around it with a mix of pure-DOM definitions,
and just not defining things clearly.
Right. But you definitely don't want to place a caret / selection end point
inside a node with visibility : hidden. So to that extent, you'd have to
mention it somewhere (definitely when you're normalizing selection end
points).
Hmm, I'm not sure. Text that's visibility: hidden looks the same to
the user as text that's color: transparent, so why should it behave
differently for selections?
I still don't understand exactly when sibling criteria returns true and
which node new parent instructors returns. Where are these algorithm
defined?
The wrap algorithm takes three inputs: a list of nodes, and two
algorithms. The callers provide the sibling criteria and new parent
instructions algorithms. Take a look at the callers of the wrap
algorithm and hopefully it will be clearer. Do you have any
suggestions on how to make this clearer in the spec? Maybe the note I
just added at the beginning
http://aryeh.name/spec/editing/editing.html#wrapping-a-list-of-nodes
helps?
Not really. Surprisingly or not, it's a very common technique used
throughout WebKit's editing code. I just wished we could avoid adding br
if we were to only remove them later.
That would be nice, but it's hard to figure out sometimes. Like if
the selection is in p{}br/p, and a script does insertHTML to add
foo, we want to remove the br, but if it adds !-- foo -- we
want to keep it. And if you select p{br}/p and insertHTML to
add !-- foo --, we need to make a new br regardless. I could
write it so that it checks after the fact if the br is extraneous,
but it seemed easier to just remove it in the beginning and then add a
new one later if needed.
CSS makes me sad sometimes. :(
I see. That's very unfortunate. Can we defined the list in terms of the
phrasing content though? Or define phrasing content in terms of your
definition?
There are complications. For instance, HTML defines a, ins, and
del as being phrasing content only if they contain only phrasing
content, which isn't useful for our purposes. The idea of phrasing
content is meant to be concerned with authoring conformance, and it
doesn't seem well suited to what we need. But I'd like to see
something worked out in the long term to harmonize them, yeah. It's
just not an immediate need, it can wait.
I personally think Gecko and Opera's behavior makes more sense here.
I don't. Partly it's for the reason I give in the comment next to
backColor's action: it's
incoherent from a user perspective. For instance, if you try it on
paragraphs the background will have big gaps where the margins are. If
you try it on an inline element that's a child of the editing host, it
will do nothing or apply the background to everything or such, even
though such an inline element is visually indistinguishable from one
sitting inside a div. This would only make sense if we take
considerable effort to ensure that block elements all have no margins,
or if we wrap things in a div if they have margins, or something like
that.
background-color on block elements doesn't make sense from a WYSIWYG
perspective, because it behaves differently based on whether an
element has margin vs. padding, or whether there's a wrapper around a
block or just br's, etc. These differences normally aren't visible
in rendering, so making command behavior depend on them is confusing.
Also, the way the spec defines it is the way both IE and WebKit
behave, so that's a large majority of the market and is probably the
most compatible.
This is a WebKit bug that I've been intending to
fix: https://bugs.webkit.org/show_bug.cgi?id=11089.
Okay, changed: http://aryeh.name/gitweb.cgi?p=editing;a=commitdiff;h=b599880c
I don't think so although I might have missed something. I just think that
introducing the concept of typing style might make the spec easier to read
and understand.
I don't like the use of the word style here, because it doesn't fit
for createLink. I could change it from state override and value
override to typing state and typing value, I guess. But it
doesn't just affect typing, either: it also affects the return value
of queryCommandState()/queryCommandValue(). Thus override, because
it overrides the normal definition of state/value.
See the comment next to inline command activated values for
Re: [whatwg] Fixing undo on the Web - UndoManager and Transaction
Why is there a need for a 'reapply' action? How is it different from the 'apply' action? In the case of collaborative editing apps, reapply is different from apply because the backend server may have a tree of transaction history and may need to consult on demand in order to determine exactly what mutations have to happen. Looking at your examples other emails in this thread I do understand the idea better I think. However, it seems to me that apply is the same as reapply plus some initialization. This leads me to two questions: 1. Would it be better make the split be init/apply/unapply rather than apply/unapply/reapply. The latter seems to cause a lot of code duplication between apply and reapply as can be seen in your examples. IMHO the former is also more understandable, but that might be a matter of taste. 2. If we do go with the init/apply/unapply approach, would it make sense to skip init and just ask people to do it manually before creating the transaction? Or at least make init optional? What is the purpose of the UndoManager.replace function and it's replaceGroup argument? In general I'm not sure I fully understand transaction groups. Are they different from simply a set of transactions which have been merged together such that they are done/undone together? Yeah, sorry about that. I should clarify that part of the design. UndoManager.replace The key observation is that ManagedTransaction is constrained to work only with a proper sequence of managed transactions. Whenever an app inserts a manual transaction or directly mutates the DOM under the same editing host, the UA won't be able to unapply/reapply the existing ManagedTransaction created by user editing actions; i.e. inserting a manual transaction breaks the existing managed transactions. Follow you so far... Without this constraint, however, the UA is required to keep track of all DOM mutations happening in the undo scope :( ...but now you lost me :) For the record, my vision was that the editor will keep track of the mutations *it* does to the DOM and inserts managed transactions for those into the UndoManager. Any other mutations to the DOM the editor completely ignores. If the page makes other mutations to the DOM, it should use the UndoManager and create a managed transaction for it. If it doesn't, the page is on its own. If the UndoManager is asked to undo or redo a managed transaction and the DOM doesn't look the same as it had expected, then it should do the best it can. In some cases this means that it won't produce useful mutations, but this only happens if the page has done BadThings (tm). Given this constraint, the apps that do use managed transactions such as collaborative editing apps need to replace the managed transactions inserted by the UA by the corresponding manual transaction when user types text. The vision I had for how this is done is that the editor code should fire events before it makes any modifications to the DOM. The website should be able to cancel this event and instead perform it's own modifications to the DOM. Until the various editor implementations are there, the website can always undo the editor transaction and then create its own manual transaction and insert in the UndoManager. Transaction Group When a user types hello, he isn't really typing all of hello at once but rather inserting character h, e, l, l, and o, letting the UA insert each letter as a separate managed transaction in the order. However, when the user undoes or redoes this typing command, the entire hello needs to removed. This is accomplished as grouping 5 managed transactions for inserting h, e, l, l, and o as a transaction group. Cool, that matches my understanding. Is there a reason that you're not allowing manual transactions to be part of a transaction group though? Why expose explicit Transaction objects. What value does that provide? I admit this is more of stylistic issue rather than the technical limitation but given a transaction already has label and apply properties, it seemed more natural for it to be an object. That'll allow us to add more properties in the future. In particular, I really wanted to provide a mutation list as discussed on the mutation events replacement thread on public-webapps. This allows apps to determine which transaction did what without having to listening to each mutation event, and makes it easier to replace managed transactions by manual transactions as described above. Hmm.. this is indeed an interesting idea. Though I would imagine that it's even more interesting for the page to know the semantics of the modification rather than knowing what exact DOM modifications are performed. I.e. understand that a transaction means break current text into two paragraphs rather than insert new element with name 'p'. Remove text from other element. Add text to newly inserted element. This in order to be able to reapply
Re: [whatwg] Fixing undo on the Web - UndoManager and Transaction
On Fri, Aug 5, 2011 at 1:59 PM, Jonas Sicking jo...@sicking.cc wrote: In the case of collaborative editing apps, reapply is different from apply because the backend server may have a tree of transaction history and may need to consult on demand in order to determine exactly what mutations have to happen. Looking at your examples other emails in this thread I do understand the idea better I think. However, it seems to me that apply is the same as reapply plus some initialization. This leads me to two questions: No. As far as I understand it, reapply needs to do more work because the undo stack is managed by the server in such cases. The script running on the client may not even know what to do. 2. If we do go with the init/apply/unapply approach, would it make sense to skip init and just ask people to do it manually before creating the transaction? Or at least make init optional? As it stands, apply, unapply, and reapply are optional because it's desirable to add some transactions that only do work in undo/redo in some cases. Without this constraint, however, the UA is required to keep track of all DOM mutations happening in the undo scope :( ...but now you lost me :) For the record, my vision was that the editor will keep track of the mutations *it* does to the DOM and inserts managed transactions for those into the UndoManager. Did you mean manual transactions? The user agents will keep track of changes done to the DOM inside apply method for *managed transactions*. On the other hand, the user agent won't keep track of changed for manual transactions. In a sense, manual transactions have the same effect as modifying DOM directly (without going through UndoManager) except it can be hooked up with the user agent's undo transaction history. The reason we need a proper sequence of managed transactionshttp://rniwa.com/editing/undomanager.html#proper-sequence-of-managed-transactionsis because the reference points (e.g. node, offset, etc...) stored by the user agent for managed transactions to unapply or reapply them will be stale when scripts directly modifies DOM or apply a manual transaction. If we were to make this work (i.e. the user agents can always unapply or reapply managed transactions regardless of what happens to the DOM state), then the user agents must keep track of every single DOM change and update the internal representation of the managed transactions as needed. Any other mutations to the DOM the editor completely ignores. If the page makes other mutations to the DOM, it should use the UndoManager and create a managed transaction for it. If it doesn't, the page is on its own. If the UndoManager is asked to undo or redo a managed transaction and the DOM doesn't look the same as it had expected, then it should do the best it can. In some cases this means that it won't produce useful mutations, but this only happens if the page has done BadThings (tm). Right. This is how managed transactions are used. Given this constraint, the apps that do use managed transactions such as collaborative editing apps need to replace the managed transactions inserted by the UA by the corresponding manual transaction when user types text. The vision I had for how this is done is that the editor code should fire events before it makes any modifications to the DOM. The website should be able to cancel this event and instead perform it's own modifications to the DOM. Yes, that'll be an option as well (although we need some event like beforeEditingAction). But there are cases where the script wants to let the user agent modify the DOM, and then learn what it did instead of preventing the default action and manually simulating it because the latter involves a lot of work. Until the various editor implementations are there, the website can always undo the editor transaction and then create its own manual transaction and insert in the UndoManager. Right, this use case is supported by my proposal. But the point of replace is to leave the changes made by the user agent alone but replace the entry by your own manual transaction so that undo and redo will work. Cool, that matches my understanding. Is there a reason that you're not allowing manual transactions to be part of a transaction group though? I didn't intend to disallow that. Are there some statements that imply this? I'll definitely want manual transactions to be able to form a transaction group. It defeats the whole point otherwise. I admit this is more of stylistic issue rather than the technical limitation but given a transaction already has label and apply properties, it seemed more natural for it to be an object. That'll allow us to add more properties in the future. In particular, I really wanted to provide a mutation list as discussed on the mutation events replacement thread on public-webapps. This allows apps to determine which transaction did what without having to listening
Re: [whatwg] input type=barcode?
2011/8/3 Kornel Lesiński kor...@geekhood.net: On Wed, 03 Aug 2011 16:26:41 +0100, Tab Atkins Jr. jackalm...@gmail.com wrote: What do you think? Implementing this seems rather complicated for such a niche use. It also seems better to let sites handle this by themselves so these physical codes can evolve more easily. It actually seems relatively useful, given that I use the barcode/QRCode reader in my phone quite a lot. Niche needs + inter-app communication sounds like something Web Intents could do (http://webintents.org). This was my first reaction too. Something like input type=text method=barcodereader could allow the browser to use a built-in barcode reader if it has one, or fire up a web app using webintents/webactivities which would use the camera to read the barcode. / Jonas
Re: [whatwg] [editing] HTML Editing APIs specification ready for implementer feedback
On Tue, Aug 2, 2011 at 8:31 PM, Ryosuke Niwa rn...@webkit.org wrote: I've read a part of sections 7 and 8 but I've kind of lost here. The spec is very detailed and I can't really get a high-level view of what will happen. It might be helpful to have some high-level summary of what it tries to do for each algorithm something like one at the beginning of 7.6. I've added a whole bunch of high-level summary: http://www.w3.org/Bugs/Public/show_bug.cgi?id=13633 Tell me if there are any parts where it could use more.
Re: [whatwg] Fixing undo on the Web - UndoManager and Transaction
On Fri, Aug 5, 2011 at 2:40 PM, Ryosuke Niwa rn...@webkit.org wrote: On Fri, Aug 5, 2011 at 1:59 PM, Jonas Sicking jo...@sicking.cc wrote: In the case of collaborative editing apps, reapply is different from apply because the backend server may have a tree of transaction history and may need to consult on demand in order to determine exactly what mutations have to happen. Looking at your examples other emails in this thread I do understand the idea better I think. However, it seems to me that apply is the same as reapply plus some initialization. This leads me to two questions: No. As far as I understand it, reapply needs to do more work because the undo stack is managed by the server in such cases. The script running on the client may not even know what to do. Can you give an example where this is needed? 2. If we do go with the init/apply/unapply approach, would it make sense to skip init and just ask people to do it manually before creating the transaction? Or at least make init optional? As it stands, apply, unapply, and reapply are optional because it's desirable to add some transactions that only do work in undo/redo in some cases. But as things stand, if you don't supply a 'apply' function, then nothing will happen when the transaction is first inserted, and if you don't supply a 'reapply' function then nothing will happen when a transaction is redone. So effectively you'll have to supply both even if the IDL says they are optional. Though I guess you can always supply the same function for apply and reapply, but that means you can't use the convenient inline syntax that you've used in your examples. Or does 'reapply' default to the 'apply' function if it's not provided? Without this constraint, however, the UA is required to keep track of all DOM mutations happening in the undo scope :( ...but now you lost me :) For the record, my vision was that the editor will keep track of the mutations *it* does to the DOM and inserts managed transactions for those into the UndoManager. Did you mean manual transactions? No. What I mean by editor above is the UA code which responds to keyboard events and modifies the DOM based on those. I.e. the code implementing @contenteditable. I hope that makes things more clear. Given this constraint, the apps that do use managed transactions such as collaborative editing apps need to replace the managed transactions inserted by the UA by the corresponding manual transaction when user types text. The vision I had for how this is done is that the editor code should fire events before it makes any modifications to the DOM. The website should be able to cancel this event and instead perform it's own modifications to the DOM. Yes, that'll be an option as well (although we need some event like beforeEditingAction). Yes, that's exactly what I was thinking. I think such an event (or set of events) is needed anyway in order to let people implement their own tweaks on the @contenteditable implementation. For example some pages might want the enter key to interact with bullet lists differently or insert some other element than a b when the user selects some text and presses ctrl-b (my understanding is that it's a common request to be able to tweak how @contenteditable reacts to certain editing operations). Such an event would let them do this. But there are cases where the script wants to let the user agent modify the DOM, and then learn what it did instead of preventing the default action and manually simulating it because the latter involves a lot of work. Can you give examples? For example in the collaborative editing case I would think that the page generally wants to get a semantic understanding of the editing operations so that it can reapply them even if the DOM looks somewhat different when an action is redone. I.e. even if someone else has edited the page by the time the action is redone. Until the various editor implementations are there, the website can always undo the editor transaction and then create its own manual transaction and insert in the UndoManager. Right, this use case is supported by my proposal. But the point of replace is to leave the changes made by the user agent alone but replace the entry by your own manual transaction so that undo and redo will work. *If* this is only needed until @contenteditable implementations improves by firing events like 'beforeEditingAction', then I would prefer not to add it. If it's needed for other reasons too, then of course we should. But I'd like to understand those other reasons. Cool, that matches my understanding. Is there a reason that you're not allowing manual transactions to be part of a transaction group though? I didn't intend to disallow that. Are there some statements that imply this? I'll definitely want manual transactions to be able to form a transaction group. It defeats the whole point otherwise. Ah, good, I
Re: [whatwg] Discrepancies between HTML and ES rules for parsing an integer or float
On Fri, Aug 5, 2011 at 8:43 AM, Aryeh Gregor a...@aryeh.name wrote: On Fri, Aug 5, 2011 at 1:57 AM, Jonas Sicking jo...@sicking.cc wrote: It would make sense to me to match ES here. The main concern is of course website compat. Could someone detail what the differences would be compared to what implementations/the HTML5 spec do now? As far as I know, the only difference between the HTML and ES algorithms is handling of non-ASCII whitespace: ES treats it as whitespace, HTML does not. Specifically, ES treats StrWhiteSpaceChar as leading whitespace: http://es5.github.com/#x15.1.2.2 That includes any Unicode space separator (Zs), which in particular changes over time (which seems to be Hixie's main objection IIUC). HTML uses skip whitespace: http://www.whatwg.org/specs/web-apps/current-work/multipage/common-microsyntaxes.html#signed-integers Which if you follow the breadcrumbs means only [ \t\n\r\f]. So it's almost never going to make any difference in practice, we're talking only about corner cases. I have a simple test-case at http://www.w3.org/Bugs/Public/show_bug.cgi?id=12296#c4 that shows all browsers strip leading \x0b (vertical tab) when converting DOM attributes to ints, which matches ES and not HTML. For parsing floats this would not seem like a problem though since attributes containing floats is relatively new IIRC. Yes, that's correct. There's definitely no compat issue here with floats, but really there's not going to be any with ints either, since it's going to be exceedingly rare that anyone will put Unicode whitespace in DOM attributes that are reflected as integers and then rely on them working. So it's just a question of if we'd prefer the algorithms to match or not. Sounds good. I'm for such a change yes. / Jonas
Re: [whatwg] Fixing undo on the Web - UndoManager and Transaction
On Fri, Aug 5, 2011 at 5:06 PM, Jonas Sicking jo...@sicking.cc wrote: Though I guess you can always supply the same function for apply and reapply, but that means you can't use the convenient inline syntax that you've used in your examples. Or does 'reapply' default to the 'apply' function if it's not provided? Yes. That's the plan. I guess I left that detail out? For the record, my vision was that the editor will keep track of the mutations *it* does to the DOM and inserts managed transactions for those into the UndoManager. Did you mean manual transactions? No. What I mean by editor above is the UA code which responds to keyboard events and modifies the DOM based on those. I.e. the code implementing @contenteditable. I hope that makes things more clear. Oh, yes definitely. The UA will keep track of mutations they made in order to unapply and reapply those managed transactions. I think such an event (or set of events) is needed anyway in order to let people implement their own tweaks on the @contenteditable implementation. Right. But there are cases where the script wants to let the user agent modify the DOM, and then learn what it did instead of preventing the default action and manually simulating it because the latter involves a lot of work. Can you give examples? e.g. in a simple collaborative editing app, you may want to let UA implement basic editing operations even though you want control over the undo transaction history and need to tweak markup afterwards. For example in the collaborative editing case I would think that the page generally wants to get a semantic understanding of the editing operations so that it can reapply them even if the DOM looks somewhat different when an action is redone. I.e. even if someone else has edited the page by the time the action is redone. 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. If it's needed for other reasons too, then of course we should. But I'd like to understand those other reasons. e.g. some apps may want to use br instead of p or div for paragraph separator. And there might be some custom UI that shows up around the inserted text. - Ryosuke
Re: [whatwg] Fixing undo on the Web - UndoManager and Transaction
On Fri, Aug 5, 2011 at 5:17 PM, Ryosuke Niwa rn...@webkit.org wrote: On Fri, Aug 5, 2011 at 5:06 PM, Jonas Sicking jo...@sicking.cc wrote: For example in the collaborative editing case I would think that the page generally wants to get a semantic understanding of the editing operations so that it can reapply them even if the DOM looks somewhat different when an action is redone. I.e. even if someone else has edited the page by the time the action is redone. 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. If it's needed for other reasons too, then of course we should. But I'd like to understand those other reasons. e.g. some apps may want to use br instead of p or div for paragraph separator. For these I would imagine you cancel the beforeEditingAction event and do your own DOM modifications. 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. / Jonas
Re: [whatwg] [editing] HTML Editing APIs specification ready for implementer feedback
Aryeh Gregor a...@aryeh.name, 2011-08-04 14:22 -0400: On Wed, Aug 3, 2011 at 5:06 PM, Ehsan Akhgari eh...@mozilla.com wrote: Is it possible to get a unique QA contact (or default CC address) for this component please, so that people who are interested in watching it can watch that email address instead of member-webapi-...@w3.org? Would this be possible, Mike? I changed the QA contact to sideshowbarker+html-editing-...@gmail.com (a unique address used just for this bugzilla component), so anybody who wants to get all bugmail for this component can do that by going to here: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email ...and adding sideshowbarker+html-editing-...@gmail.com to the Add users to my watch list field near the bottom. Ehsan, if that's not what you had in mind, let me know and I can get something else set up. --Mike -- Michael[tm] Smith http://people.w3.org/mike/+
