Re: [whatwg] Fixing undo on the Web - UndoManager and Transaction

On Thu, Oct 27, 2011 at 6:22 PM, Jonas Sicking wrote: > Wait, the last bullet point doesn't mean that changes to IDL > properties are in general rolled back, does it? That would be > extremely hard to implement in general. It also creates all sorts of > weird behavior. Would you for example want

Re: [whatwg] Fixing undo on the Web - UndoManager and Transaction

On Thu, Oct 27, 2011 at 4:23 PM, Ryosuke Niwa wrote: > Hi all, > I've updated the document: http://rniwa.com/editing/undomanager.html per > discussions. > Summary of changes: > > "transaction" is renamed to "DOM transaction" > The value of isAutomatic is read immediately before the transaction is

Re: [whatwg] Fixing undo on the Web - UndoManager and Transaction

Hi all, I've updated the document: http://rniwa.com/editing/undomanager.html per discussions. Summary of changes: - "transaction" is renamed to "DOM transaction" - The value of isAutomatic is read immediately before the transaction is applied - Swapped the definition of clearUndo and

Re: [whatwg] Feedback on UndoManager spec

On Wed, Oct 26, 2011 at 9:42 AM, Aryeh Gregor wrote: > > 9) In section 3.1 Mutations of DOM, you define "DOM changes" and "DOM > State" by reference to DOM 3. It would be better if you gave explicit > lists, for clarity. I think the only things that qualify as DOM > changes to a node are > > * C

Re: [whatwg] Feedback on UndoManager spec

On Thu, Oct 27, 2011 at 10:48 AM, Aryeh Gregor wrote: > On Wed, Oct 26, 2011 at 2:39 PM, Ryosuke Niwa wrote: > > I meant properties authors added to nodes. e.g. > > span.myProperty = true; > > Should span be removed by some automatic transaction, authors may expect > it > > to be restored on und

[whatwg] When a script element's child nodes are changed

§4.3.1 The Script Element says: When a |script | element that is not marked as being "parser-inserted"

Re: [whatwg] Feedback on UndoManager spec

On Thu, Oct 27, 2011 at 3:10 PM, Jonas Sicking wrote: > On Thu, Oct 27, 2011 at 11:28 AM, Ojan Vafai wrote: > > On Thu, Oct 27, 2011 at 10:48 AM, Aryeh Gregor wrote: > >> > >> On Wed, Oct 26, 2011 at 2:39 PM, Ryosuke Niwa wrote: > >> > >> > The same is true for having apply and reapply. Jonas

Re: [whatwg] Feedback on UndoManager spec

On Thu, Oct 27, 2011 at 11:28 AM, Ojan Vafai wrote: > On Thu, Oct 27, 2011 at 10:48 AM, Aryeh Gregor wrote: >> >> On Wed, Oct 26, 2011 at 2:39 PM, Ryosuke Niwa wrote: >> >> > The same is true for having apply and reapply. Jonas wanted to get rid >> > of >> > reapply altogether and just have >> >

Re: [whatwg] Feedback on UndoManager spec

On Thu, Oct 27, 2011 at 2:28 PM, Ojan Vafai wrote: > I disagree. I think the boolean makes things more complicated. Boolean > arguments stink. Every time you want to use this API you need to go look up > the documentation to remember whether the boolean is "isReapply" or > "isApply". There's no su

Re: [whatwg] Feedback on UndoManager spec

On Thu, Oct 27, 2011 at 10:48 AM, Aryeh Gregor wrote: > On Wed, Oct 26, 2011 at 2:39 PM, Ryosuke Niwa wrote: > > The same is true for having apply and reapply. Jonas wanted to get rid of > > reapply altogether and just have > > void apply(in boolean isReapply) > > In this world, you could do > >

Re: [whatwg] Feedback on UndoManager spec

On Wed, Oct 26, 2011 at 2:39 PM, Ryosuke Niwa wrote: > I meant properties authors added to nodes. e.g. > span.myProperty = true; > Should span be removed by some automatic transaction, authors may expect it > to be restored on undo. That sounds like the ideal behavior, unless it's too difficult t

Re: [whatwg] Signed XHTML

On Thu, Oct 20, 2011 at 9:57 PM, Martin Boßlet wrote: > Are there plans in this direction? Would functionality like this have a > chance to be considered for the standard? The chances are extremely slim. XML signatures depend on XML canonicalization which is notoriously difficult to implement co

Re: [whatwg] New attributes would degrade better than new elements

"Jukka K. Korpela" wrote: >27.10.2011 9:55, Ashley Sheridan wrote: > >>> There is no _required_ functionality or default rendering for >or >>> and no special attributes for them. What you lose by >having >>> them as elements rather than attributes is that you cannot style >them in >>> a mann

Re: [whatwg] New attributes would degrade better than new elements

> How does this relate to the question of adding element vs. adding attributes? I am saying that they also added which is the most famous tag to date(added in HTML 4), so maybe we should have used and that way all browsers would support it no? > They could do just the same with . Don't you th

Re: [whatwg] New attributes would degrade better than new elements

27.10.2011 11:42, Simon Pieters wrote: It's difference between working on all browsers and working on some browsers as well as being tweakable when JavaScript is enabled. is not stylable in IE6 because it doesn't support attribute selectors. Granted, but a) IE6 is dying, whereas IE7 and IE8

Re: [whatwg] New HTML5 Form type

I very much encourage this idea. I fret frequently when I see the unsupported features of the HTTP protocol not being used because of missing support in browsers and servers. Like the PUT and DELETE. And this enchancement of the AUTH. A more seamless integration of the HTTP AUTH to the client si

Re: [whatwg] New attributes would degrade better than new elements

On Wed, 26 Oct 2011 23:36:23 +0200, Jukka K. Korpela wrote: So, it's not a big deal. It's difference between working on all browsers and working on some browsers as well as being tweakable when JavaScript is enabled. is not stylable in IE6 because it doesn't support attribute selecto

Re: [whatwg] New attributes would degrade better than new elements

27.10.2011 9:55, Ashley Sheridan wrote: There is no _required_ functionality or default rendering for or and no special attributes for them. What you lose by having them as elements rather than attributes is that you cannot style them in a manner that works on all browsers. > is a block l