| 01:14 | <rniwa> | AryehGregor: yt? |
| 01:14 | <rniwa> | AryehGregor: yt? |
| 05:30 | <rniwa> | AryehGregor: yt? |
| 05:31 | <rniwa> | AryehGregor: yt? |
| 05:31 | <rniwa> | or is there anyone else familiar with Callback in Web IDL? |
| 05:31 | <heycam> | rniwa, hey |
| 05:31 | <rniwa> | or is there anyone else familiar with Callback in Web IDL? |
| 05:31 | <heycam> | rniwa, hey |
| 05:31 | <rniwa> | heycam: hi |
| 05:31 | <rniwa> | heycam: do you know Callback? |
| 05:31 | <heycam> | rniwa, yeah |
| 05:32 | <rniwa> | heycam: hi |
| 05:32 | <rniwa> | heycam: do you know Callback? |
| 05:32 | <heycam> | rniwa, yeah |
| 05:32 | <rniwa> | heycam: so I thought I can turn http://rniwa.com/editing/undomanager.html#dom-domtransaction into a dictionary |
| 05:32 | <rniwa> | heycam: but it isn't so simple |
| 05:33 | <rniwa> | heycam: so I thought I can turn http://rniwa.com/editing/undomanager.html#dom-domtransaction into a dictionary |
| 05:33 | <rniwa> | heycam: but it isn't so simple |
| 05:33 | <rniwa> | heycam: because they're callback functions, they can't be GC'ed like other objects :( |
| 05:33 | <heycam> | rniwa, oh I see, since it's got Functions |
| 05:33 | <rniwa> | heycam: yeah... |
| 05:33 | <rniwa> | heycam: because they're callback functions, they can't be GC'ed like other objects :( |
| 05:33 | <heycam> | rniwa, oh I see, since it's got Functions |
| 05:33 | <rniwa> | heycam: yeah... |
| 05:33 | <heycam> | rniwa, so what I did when removing [Callback] from the spec was to replace it with two things |
| 05:33 | <heycam> | rniwa, one was the "callback Foo = returntype (args);" syntax |
| 05:33 | <heycam> | that's just for single functions |
| 05:33 | <rniwa> | heycam: kind of embarrassing story but I didn't realize that it won't work 'til I started to implement it |
| 05:34 | <heycam> | rniwa, so what I did when removing [Callback] from the spec was to replace it with two things |
| 05:34 | <heycam> | rniwa, one was the "callback Foo = returntype (args);" syntax |
| 05:34 | <heycam> | that's just for single functions |
| 05:34 | <rniwa> | heycam: kind of embarrassing story but I didn't realize that it won't work 'til I started to implement it |
| 05:34 | <heycam> | and the other is "callback interface Something { attribute whatever; void somefunction(); }" |
| 05:34 | <heycam> | and the other is "callback interface Something { attribute whatever; void somefunction(); }" |
| 05:34 | <heycam> | so I think you want the latter |
| 05:34 | <rniwa> | heycam: right. |
| 05:34 | <rniwa> | heycam: yeah, so I do want the latter |
| 05:34 | <rniwa> | heycam: but then I can't really get rid of the interface |
| 05:34 | <rniwa> | heycam: i.e. can't just do document.undoManager.transact({ executeAutomatic: function () { |
| 05:34 | <rniwa> | this.executeAutomatic = function () { alert('foo'); } |
| 05:34 | <rniwa> | alert('bar'); |
| 05:34 | <rniwa> | }, undo: function () { alert('baz'); } }); // alerts 'bar' |
| 05:35 | <heycam> | so I think you want the latter |
| 05:35 | <rniwa> | heycam: right. |
| 05:35 | <rniwa> | heycam: yeah, so I do want the latter |
| 05:35 | <rniwa> | heycam: but then I can't really get rid of the interface |
| 05:35 | <rniwa> | heycam: i.e. can't just do document.undoManager.transact({ executeAutomatic: function () { |
| 05:35 | <rniwa> | this.executeAutomatic = function () { alert('foo'); } |
| 05:35 | <rniwa> | alert('bar'); |
| 05:35 | <rniwa> | }, undo: function () { alert('baz'); } }); // alerts 'bar' |
| 05:35 | <heycam> | rniwa, no you can do that |
| 05:35 | <heycam> | rniwa, no you can do that |
| 05:35 | <rniwa> | heycam: really/ |
| 05:35 | <rniwa> | heycam: does it support implicit instantiation? |
| 05:35 | <rniwa> | heycam: really/ |
| 05:35 | <rniwa> | heycam: does it support implicit instantiation? |
| 05:35 | <heycam> | rniwa, yeah, for callback interfaces when it comes to convert the JS value into the "callback interface" value, it'll just inspect the properties on the JS Object for the attributes/methods |
| 05:35 | <rniwa> | heycam: okay. |
| 05:35 | <heycam> | rniwa, it should keep a reference to the JS Object ltself, not make a copy or anything, too |
| 05:36 | <heycam> | rniwa, yeah, for callback interfaces when it comes to convert the JS value into the "callback interface" value, it'll just inspect the properties on the JS Object for the attributes/methods |
| 05:36 | <rniwa> | heycam: okay. |
| 05:36 | <heycam> | rniwa, it should keep a reference to the JS Object ltself, not make a copy or anything, too |
| 05:36 | <rniwa> | heycam: maybe it's just that webkit's binding code doesn't support it then :\ |
| 05:36 | <rniwa> | heycam: maybe it's just that webkit's binding code doesn't support it then :\ |
| 05:36 | <rniwa> | heycam: right, that'll defeat the point of using callback interface |
| 05:36 | <heycam> | rniwa, there are rules in the spec about how attributes are read/written and operations are invoked on "user objects", which are JS objects that implement callback interfaces |
| 05:36 | <rniwa> | heycam: yeah, I was just reading that section |
| 05:36 | <heycam> | rniwa, hmm, so you *want* to make a copy of the properties on the object passed in? |
| 05:37 | <rniwa> | heycam: right, that'll defeat the point of using callback interface |
| 05:37 | <heycam> | rniwa, there are rules in the spec about how attributes are read/written and operations are invoked on "user objects", which are JS objects that implement callback interfaces |
| 05:37 | <rniwa> | heycam: yeah, I was just reading that section |
| 05:37 | <heycam> | rniwa, hmm, so you *want* to make a copy of the properties on the object passed in? |
| 05:37 | <rniwa> | heycam: no |
| 05:37 | <rniwa> | heycam: I do want to keep the original object |
| 05:37 | <rniwa> | heycam: no |
| 05:37 | <rniwa> | heycam: I do want to keep the original object |
| 05:37 | <rniwa> | heycam: but... not all functions need to be present on the object |
| 05:37 | <rniwa> | heycam: that's what makes it much more complicated |
| 05:37 | <rniwa> | heycam: DOMTransaction has 5 properties but any one of them can be omitted :( |
| 05:38 | <rniwa> | heycam: but... not all functions need to be present on the object |
| 05:38 | <rniwa> | heycam: that's what makes it much more complicated |
| 05:38 | <rniwa> | heycam: DOMTransaction has 5 properties but any one of them can be omitted :( |
| 05:38 | <heycam> | rniwa, ok -- at least the rules should convert the undefined you get from getting the properties into the null |
| 05:38 | <heycam> | rniwa, ok -- at least the rules should convert the undefined you get from getting the properties into the null |
| 05:38 | <rniwa> | heycam: ah, ok |
| 05:38 | <heycam> | rniwa, I guess you're concerned about the fact that dictionaries let you specify default values for their members |
| 05:38 | <heycam> | or know whether they are omitted or not |
| 05:39 | <rniwa> | heycam: ah, ok |
| 05:39 | <heycam> | rniwa, I guess you're concerned about the fact that dictionaries let you specify default values for their members |
| 05:39 | <heycam> | or know whether they are omitted or not |
| 05:39 | <heycam> | oh hang on |
| 05:39 | <heycam> | oh hang on |
| 05:39 | <heycam> | so currently you have them written as "attribute Function? …" |
| 05:39 | <rniwa> | heycam: well, my problem is more of the fact this is very unusual interface obejct |
| 05:39 | <rniwa> | heycam: yeah, i think that's incorrect |
| 05:39 | <heycam> | actually that might be more correct :) |
| 05:39 | <rniwa> | heycam: but I couldn't find a way to right optional interface methods :( |
| 05:39 | <heycam> | if you want to allow the author to omit them |
| 05:39 | <rniwa> | s/right/write |
| 05:40 | <heycam> | so currently you have them written as "attribute Function? …" |
| 05:40 | <rniwa> | heycam: well, my problem is more of the fact this is very unusual interface obejct |
| 05:40 | <rniwa> | heycam: oh |
| 05:40 | <rniwa> | heycam: yeah, i think that's incorrect |
| 05:40 | <heycam> | actually that might be more correct :) |
| 05:40 | <rniwa> | heycam: but I couldn't find a way to right optional interface methods :( |
| 05:40 | <heycam> | if you want to allow the author to omit them |
| 05:40 | <rniwa> | s/right/write |
| 05:40 | <rniwa> | heycam: oh |
| 05:41 | <heycam> | but that's interesting I hadn't thought of that difference before |
| 05:41 | <heycam> | but that's interesting I hadn't thought of that difference before |
| 05:41 | <rniwa> | heycam: anyway, my concern is that there are no other web standards that use objects like this |
| 05:41 | <rniwa> | heycam: and i was wondering if there were a better way. |
| 05:42 | <rniwa> | heycam: anyway, my concern is that there are no other web standards that use objects like this |
| 05:42 | <rniwa> | heycam: and i was wondering if there were a better way. |
| 05:42 | <heycam> | yeah I am not sure if I have seen someone use "callback interface" yet |
| 05:42 | <heycam> | yeah I am not sure if I have seen someone use "callback interface" yet |
| 05:42 | <rniwa> | e.g. because they're callback functions that then get called much later when user-initiated undo/redo are involved |
| 05:42 | <heycam> | NodeFilter if rewritten with Web IDL would use it, iirc |
| 05:42 | <rniwa> | they have to be kept alive during normal GC cycles |
| 05:43 | <rniwa> | e.g. because they're callback functions that then get called much later when user-initiated undo/redo are involved |
| 05:43 | <heycam> | NodeFilter if rewritten with Web IDL would use it, iirc |
| 05:43 | <rniwa> | they have to be kept alive during normal GC cycles |
| 05:43 | <heycam> | still, if you had a dictionary with say some Node members, then they could have references kept to them by the DOM method, so I think it's the same thing here even though they're Functions |
| 05:43 | <heycam> | actually I'm not sure if any APIs *do* keep references to Node dictionary members like that |
| 05:44 | <heycam> | still, if you had a dictionary with say some Node members, then they could have references kept to them by the DOM method, so I think it's the same thing here even though they're Functions |
| 05:44 | <heycam> | actually I'm not sure if any APIs *do* keep references to Node dictionary members like that |
| 05:46 | <heycam> | rniwa, anyway I think the strong reference to the Functions that get passed in here would just be part of the semantics of whatever function accepts the DOMTransaction objects |
| 05:46 | <heycam> | rniwa, so probably the bindings code itself doesn't need to worry about it |
| 05:47 | <heycam> | rniwa, anyway I think the strong reference to the Functions that get passed in here would just be part of the semantics of whatever function accepts the DOMTransaction objects |
| 05:47 | <heycam> | rniwa, so probably the bindings code itself doesn't need to worry about it |
| 05:48 | <rniwa> | heycam: hm... possible. |
| 05:49 | <rniwa> | heycam: hm... possible. |
| 05:49 | <rniwa> | heycam: at least in webkit, we don't support Function type yet |
| 05:49 | <heycam> | s/strong reference/keeping of the strong reference/ |
| 05:49 | <heycam> | ok |
| 05:49 | <rniwa> | heycam: at least in webkit, we don't support Function type yet |
| 05:49 | <heycam> | s/strong reference/keeping of the strong reference/ |
| 05:49 | <heycam> | ok |
| 05:49 | <rniwa> | heycam: so that'll be an interesting journey :( |
| 05:49 | <heycam> | s/:(/:)/ :) |
| 05:50 | <rniwa> | heycam: so that'll be an interesting journey :( |
| 05:50 | <heycam> | s/:(/:)/ :) |
| 05:56 | <rniwa> | heycam: thanks for the clarification |
| 05:56 | rniwa | goes back on hacking |
| 05:56 | <heycam> | rniwa, no problem |
| 05:56 | <rniwa> | heycam: thanks for the clarification |
| 05:56 | rniwa | goes back on hacking |
| 05:56 | <heycam> | rniwa, no problem |
| 06:02 | <rniwa> | heycam: I guess I'll have to add Callback keyword? |
| 06:02 | <ruby_on_tails> | can anyone tell me why the canvas renders and then vanishes here http://thecodeplayer.com/walkthrough/ps3 (hit view code). but if i take the first 2 lines of the draw() out of it, it works fine |
| 06:03 | <rniwa> | heycam: I guess I'll have to add Callback keyword? |
| 06:03 | <ruby_on_tails> | can anyone tell me why the canvas renders and then vanishes here http://thecodeplayer.com/walkthrough/ps3 (hit view code). but if i take the first 2 lines of the draw() out of it, it works fine |
| 06:03 | <heycam> | rniwa, yes I think you should write it as "callback interface DOMTransaction { … }" |
| 06:03 | <heycam> | rniwa, yes I think you should write it as "callback interface DOMTransaction { … }" |
| 06:03 | <heycam> | rniwa, without the [NoInterfaceObject], since callback interfaces imply that |
| 06:03 | <rniwa> | heycam: right. |
| 06:03 | <heycam> | rniwa, without the [NoInterfaceObject], since callback interfaces imply that |
| 06:03 | <rniwa> | heycam: right. |
| 06:03 | <rniwa> | heycam: I think it was me reading some very old version of WebIDL spec |
| 06:04 | <rniwa> | heycam: I think it was me reading some very old version of WebIDL spec |
| 06:04 | <heycam> | rniwa, yeah the callback stuff changed in the last couple of months |
| 06:04 | <heycam> | rniwa, yeah the callback stuff changed in the last couple of months |
| 06:51 | <espadrine> | ] |
| 06:51 | <espadrine> | ] |
| 07:48 | <Hixie> | does overflow affect descendants that are position:fixed? |
| 07:48 | <Hixie> | per spec? |
| 07:48 | <Hixie> | does overflow affect descendants that are position:fixed? |
| 07:48 | <Hixie> | per spec? |
| 07:59 | <zcorpan> | is a position:fixed element a 'block container box'? |
| 07:59 | <Hixie> | probably |
| 07:59 | <zcorpan> | is a position:fixed element a 'block container box'? |
| 07:59 | <Hixie> | probably |
| 07:59 | <zcorpan> | then afaict the spec says "yes" (can't find anything that calls it out explicitly), but all my browsers disagree |
| 08:00 | <zcorpan> | then afaict the spec says "yes" (can't find anything that calls it out explicitly), but all my browsers disagree |
| 08:00 | <Hixie> | chrome 19 clips 'em |
| 08:00 | <Hixie> | chrome 19 clips 'em |
| 08:00 | <Hixie> | and it regresses a thing i'm doing :-) |
| 08:00 | <Hixie> | TabAtkins_: ^ maybe css should change if all the browsers agree on this |
| 08:01 | <Hixie> | and it regresses a thing i'm doing :-) |
| 08:01 | <Hixie> | TabAtkins_: ^ maybe css should change if all the browsers agree on this |
| 08:13 | <annevk> | oh, interface can be used as argument name again too now |
| 08:14 | <annevk> | oh, interface can be used as argument name again too now |
| 08:17 | <annevk> | heycam|away: event handler stuff looks okay now I guess |
| 08:17 | <annevk> | heycam|away: event handler stuff looks okay now I guess |
| 08:35 | <annevk> | heycam|away: I thought callback interface meant the interface is exposed? |
| 08:35 | <annevk> | heycam|away: oh wait, only if there's constants I guess |
| 08:36 | <annevk> | heycam|away: I thought callback interface meant the interface is exposed? |
| 08:36 | <annevk> | heycam|away: oh wait, only if there's constants I guess |
| 09:51 | <niloy> | If I put an event handler on 'scroll' event, how can I determine if the scroll was 'horizontal' or 'vertical'? |
| 09:52 | <niloy> | If I put an event handler on 'scroll' event, how can I determine if the scroll was 'horizontal' or 'vertical'? |
| 10:07 | <annevk> | is there a bug on upgrading HTML to the new callback syntax? |
| 10:08 | <annevk> | is there a bug on upgrading HTML to the new callback syntax? |
| 10:58 | <annevk> | http://dvcs.w3.org/hg/encoding/raw-file/tip/Overview.html#utf-16 |
| 10:58 | <annevk> | http://dvcs.w3.org/hg/encoding/raw-file/tip/Overview.html#utf-16 |
| 10:58 | <annevk> | guess I could have done some more arithmetic shifting instead of * 0x400 ... |
| 10:59 | <annevk> | guess I could have done some more arithmetic shifting instead of * 0x400 ... |
| 12:28 | <Philip`> | ruby_on_tails: I don't see any problem in that demo |
| 12:29 | <Philip`> | ruby_on_tails: I don't see any problem in that demo |
| 12:29 | <ruby_on_tails> | Philip`: did you hit the play button ? |
| 12:30 | <ruby_on_tails> | Philip`: did you hit the play button ? |
| 12:30 | <annevk> | how would you say bitwise or in prose? |
| 12:31 | <annevk> | how would you say bitwise or in prose? |
| 12:31 | <Philip`> | ruby_on_tails: No, but if I do then I don't any problem with the moving orange circle at the end of it |
| 12:31 | <annevk> | is 'Let <var title>byte2</var> be <var>code point</var> bitwise or 0x00FF' understandable? |
| 12:32 | <Philip`> | ruby_on_tails: No, but if I do then I don't any problem with the moving orange circle at the end of it |
| 12:32 | <annevk> | is 'Let <var title>byte2</var> be <var>code point</var> bitwise or 0x00FF' understandable? |
| 12:32 | <ruby_on_tails> | Philip`: doesnt the typing become very slow after setinterval is defined ? |
| 12:32 | <ruby_on_tails> | and the output starts to flicker |
| 12:32 | <ruby_on_tails> | Philip`: doesnt the typing become very slow after setinterval is defined ? |
| 12:32 | <ruby_on_tails> | and the output starts to flicker |
| 12:34 | <Philip`> | ruby_on_tails: I'd guess that problem is because setInterval won't call draw until 33ms after reloading the code, and the code-replaying thing is probably updating and reloading the code after not much more than 33ms, so it doesn't get much of a chance to render before resetting |
| 12:35 | <Philip`> | ruby_on_tails: I'd guess that problem is because setInterval won't call draw until 33ms after reloading the code, and the code-replaying thing is probably updating and reloading the code after not much more than 33ms, so it doesn't get much of a chance to render before resetting |
| 12:35 | <ruby_on_tails> | Philip`: the actual problem that i am facing is not with the render but with the stacking of the set intervals, the iframe is given a new js code which has a set interval every 33ms, all those setintervals stack up and slow down the entire thing |
| 12:35 | <Philip`> | annevk: Maybe write it as "OR" to distinguish it more clearly from normal prose? |
| 12:36 | <ruby_on_tails> | Philip`: the actual problem that i am facing is not with the render but with the stacking of the set intervals, the iframe is given a new js code which has a set interval every 33ms, all those setintervals stack up and slow down the entire thing |
| 12:36 | <Philip`> | annevk: Maybe write it as "OR" to distinguish it more clearly from normal prose? |
| 12:36 | <Philip`> | ruby_on_tails: Oh, I suppose that sounds possible, since you're never clearing the intervals |
| 12:37 | <Philip`> | ruby_on_tails: Oh, I suppose that sounds possible, since you're never clearing the intervals |
| 12:37 | <ruby_on_tails> | Philip`: the code that you see is supposed to come from users of the site who may not use clearintervals all the time |
| 12:37 | <ruby_on_tails> | Philip`: the code that you see is supposed to come from users of the site who may not use clearintervals all the time |
| 12:37 | <ruby_on_tails> | so currently i am thinking of going from 1-99999 and clear everything between 2 iframe injections ? thats the only solution i have got |
| 12:38 | <ruby_on_tails> | so currently i am thinking of going from 1-99999 and clear everything between 2 iframe injections ? thats the only solution i have got |
| 12:40 | <Philip`> | Could you run the code inside an iframe, and make it restart with a fresh document after each code change? |
| 12:40 | <Philip`> | like what http://software.hixie.ch/utilities/js/live-dom-viewer/ does |
| 12:40 | <Philip`> | Could you run the code inside an iframe, and make it restart with a fresh document after each code change? |
| 12:40 | <Philip`> | like what http://software.hixie.ch/utilities/js/live-dom-viewer/ does |
| 12:40 | <Philip`> | (iframe.contentWindow.document.open(); iframe.contentWindow.document.write(...); iframe.contentWindow.document.close(); etc) |
| 12:41 | <Philip`> | (iframe.contentWindow.document.open(); iframe.contentWindow.document.write(...); iframe.contentWindow.document.close(); etc) |
| 12:43 | <annevk> | Philip`: thanks |
| 12:43 | <annevk> | Philip`: thanks |
| 12:43 | <Philip`> | Alternatively, add a setInterval wrapper (var oldSI = window.setInterval; var intervals = []; window.setInterval = function(...) { var i = oldSI(...); intervals.push(i); return i; } etc) so you can tell what to explicitly clear |
| 12:44 | <Philip`> | Alternatively, add a setInterval wrapper (var oldSI = window.setInterval; var intervals = []; window.setInterval = function(...) { var i = oldSI(...); intervals.push(i); return i; } etc) so you can tell what to explicitly clear |
| 12:44 | <annevk> | http://dvcs.w3.org/hg/encoding/raw-file/tip/Overview.html#utf-16-encoder |
| 12:45 | <annevk> | http://dvcs.w3.org/hg/encoding/raw-file/tip/Overview.html#utf-16-encoder |
| 12:45 | <ruby_on_tails> | Philip`: its curretly refreshing the iframe on the right |
| 12:45 | <ruby_on_tails> | Philip`: its curretly refreshing the iframe on the right |
| 12:46 | <annevk> | I guess I should also define "decode utf-8" for the utf-8 only formats |
| 12:46 | <annevk> | I guess I should also define "decode utf-8" for the utf-8 only formats |
| 12:46 | <annevk> | (besides decoding as utf-8 it also skips a BOM if there is one) |
| 12:47 | <annevk> | (besides decoding as utf-8 it also skips a BOM if there is one) |
| 12:47 | <ruby_on_tails> | Philip`: the setinterval keeps running even after the iframe refreshes |
| 12:47 | <ruby_on_tails> | Philip`: the setinterval keeps running even after the iframe refreshes |
| 12:47 | <ruby_on_tails> | Philip`: what is that setinterval wrapper ? could explain a bit ? |
| 12:47 | <annevk> | "utf-8 decode" works better |
| 12:48 | <ruby_on_tails> | Philip`: what is that setinterval wrapper ? could explain a bit ? |
| 12:48 | <annevk> | "utf-8 decode" works better |
| 12:52 | <annevk> | is it code point-based formats |
| 12:52 | <annevk> | or code-point-based |
| 12:52 | <annevk> | or code point based |
| 12:52 | <annevk> | is it code point-based formats |
| 12:52 | <annevk> | or code-point-based |
| 12:52 | <annevk> | or code point based |
| 12:52 | <Philip`> | ruby_on_tails: The timers seem to stop in e.g. http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cscript%3EsetInterval%28function%28%29{alert%281%29}%2C%204000%29%3C%2Fscript%3E whenever I change the code (e.g. change "1" to "2", and it no longer alerts 1) |
| 12:53 | <Philip`> | ruby_on_tails: The timers seem to stop in e.g. http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cscript%3EsetInterval%28function%28%29{alert%281%29}%2C%204000%29%3C%2Fscript%3E whenever I change the code (e.g. change "1" to "2", and it no longer alerts 1) |
| 12:53 | <annevk> | nm for now |
| 12:53 | <Philip`> | annevk: code[hypen]point[en dash]based, I think |
| 12:53 | <annevk> | nm for now |
| 12:53 | <Philip`> | annevk: code[hypen]point[en dash]based, I think |
| 12:54 | <ruby_on_tails> | Philip`: am not sure if i get it |
| 12:54 | <ruby_on_tails> | Philip`: am not sure if i get it |
| 12:54 | <Philip`> | s/hypen/hyphen/ |
| 12:55 | <Philip`> | s/hypen/hyphen/ |
| 12:55 | <Philip`> | (Also I don't know if that's a real convention or if I'm just imagining it) |
| 12:55 | <Philip`> | (Also I don't know if that's a real convention or if I'm just imagining it) |
| 12:56 | <annevk> | http://dvcs.w3.org/hg/encoding/raw-file/tip/Overview.html#utf-8-decode |
| 12:56 | <annevk> | http://dvcs.w3.org/hg/encoding/raw-file/tip/Overview.html#utf-8-decode |
| 13:01 | <Philip`> | annevk: What if the stream is shorter than three bytes? |
| 13:01 | <Philip`> | annevk: What if the stream is shorter than three bytes? |
| 13:01 | <annevk> | then there's no match? |
| 13:02 | <annevk> | then there's no match? |
| 13:02 | <annevk> | you think that should be more explicit? |
| 13:02 | <annevk> | you think that should be more explicit? |
| 13:02 | <annevk> | is it also unclear in http://dvcs.w3.org/hg/encoding/raw-file/tip/Overview.html#decode ? |
| 13:02 | <annevk> | because I've been wondering about whether or not it was |
| 13:02 | <Philip`> | "the first three bytes" seems like an undefined concept in that case |
| 13:03 | <annevk> | is it also unclear in http://dvcs.w3.org/hg/encoding/raw-file/tip/Overview.html#decode ? |
| 13:03 | <annevk> | because I've been wondering about whether or not it was |
| 13:03 | <Philip`> | "the first three bytes" seems like an undefined concept in that case |
| 13:03 | <Philip`> | The expected behaviour is obvious, so I guess it depends on how pedantically correct you want to be |
| 13:03 | <Philip`> | The expected behaviour is obvious, so I guess it depends on how pedantically correct you want to be |
| 13:03 | <ruby_on_tails> | Philip`: sorry you are watching the wrong link, this is the one which gets very slow http://thecodeplayer.com/walkthrough/ps6 |
| 13:04 | <ruby_on_tails> | Philip`: sorry you are watching the wrong link, this is the one which gets very slow http://thecodeplayer.com/walkthrough/ps6 |
| 13:05 | <Philip`> | In #decode: "the offset given the in the cell in the" - too many "the"s |
| 13:05 | <Philip`> | In #decode: "the offset given the in the cell in the" - too many "the"s |
| 13:06 | <Philip`> | "if the first bytes of stream match all the bytes given" sounds alright to me, since the meaning is clear and it's not being invalidly specific about how many bytes to examine from stream |
| 13:07 | <Philip`> | "if the first bytes of stream match all the bytes given" sounds alright to me, since the meaning is clear and it's not being invalidly specific about how many bytes to examine from stream |
| 13:08 | <annevk> | made some clarification, thanks |
| 13:08 | <annevk> | made some clarification, thanks |
| 13:10 | <Philip`> | "Let byte2 be code point bitwise OR 0x00FF." - shouldn't that be AND? |
| 13:10 | <Philip`> | "Let byte2 be code point bitwise OR 0x00FF." - shouldn't that be AND? |
| 13:10 | <MikeSmith> | zcorpan, annevk - fyi http://www.w3.org/TR/2012/WD-html5-diff-20120315/ is alive |
| 13:11 | <MikeSmith> | zcorpan, annevk - fyi http://www.w3.org/TR/2012/WD-html5-diff-20120315/ is alive |
| 13:11 | <MikeSmith> | symlink won't be updated til Thursday |
| 13:11 | <MikeSmith> | http://www.w3.org/TR/html5-diff/ I mean |
| 13:11 | <MikeSmith> | symlink won't be updated til Thursday |
| 13:11 | <MikeSmith> | http://www.w3.org/TR/html5-diff/ I mean |
| 13:12 | <annevk> | Philip`: yes |
| 13:13 | <annevk> | Philip`: yes |
| 13:18 | <annevk> | also fixed btw |
| 13:18 | <annevk> | also fixed btw |
| 13:19 | <annevk> | MikeSmith: cool |
| 13:20 | <annevk> | MikeSmith: cool |
| 13:20 | <annevk> | MikeSmith: any chance we can finally claim http://www.w3.org/TR/html/ this update? |
| 13:20 | <annevk> | MikeSmith: any chance we can finally claim http://www.w3.org/TR/html/ this update? |
| 13:20 | <MikeSmith> | ah |
| 13:20 | <MikeSmith> | I'll talk with plh about it |
| 13:20 | <MikeSmith> | certainly would make sense |
| 13:21 | <MikeSmith> | ah |
| 13:21 | <MikeSmith> | I'll talk with plh about it |
| 13:21 | <MikeSmith> | certainly would make sense |
| 13:21 | <annevk> | thanks |
| 13:21 | <annevk> | thanks |
| 13:23 | <annevk> | HTML callback bug is https://www.w3.org/Bugs/Public/show_bug.cgi?id=15358 btw |
| 13:24 | <annevk> | filed it myself |
| 13:25 | <annevk> | HTML callback bug is https://www.w3.org/Bugs/Public/show_bug.cgi?id=15358 btw |
| 13:25 | <annevk> | filed it myself |
| 13:46 | <annevk> | I cleaned up some HTML bugs |
| 13:47 | <annevk> | I cleaned up some HTML bugs |
| 13:49 | <annevk> | why does http://dvcs.w3.org/hg/webperf/raw-file/tip/specs/RequestAnimationFrame/Overview.html not use partial Window? |
| 13:49 | <annevk> | why does http://dvcs.w3.org/hg/webperf/raw-file/tip/specs/RequestAnimationFrame/Overview.html not use partial Window? |
| 13:54 | <zcorpan> | MikeSmith: nice |
| 13:55 | <zcorpan> | MikeSmith: nice |
| 13:57 | <zcorpan> | MikeSmith: what about changes to html that happen between that and whatever ends up on w3.org/TR/html5 (like Path, and if stuff get reverted) |
| 13:57 | <zcorpan> | MikeSmith: what about changes to html that happen between that and whatever ends up on w3.org/TR/html5 (like Path, and if stuff get reverted) |
| 13:58 | <MikeSmith> | zcorpan: that? |
| 13:58 | <MikeSmith> | zcorpan: that? |
| 13:58 | <MikeSmith> | you mean http://www.w3.org/TR/html/ ? |
| 13:59 | <MikeSmith> | you mean http://www.w3.org/TR/html/ ? |
| 14:00 | <zcorpan> | that being http://www.w3.org/TR/2012/WD-html5-diff-20120315/ |
| 14:00 | <zcorpan> | MikeSmith: e.g. if http+aes gets reverted, it should be moved in the changelog in html5-diff |
| 14:01 | <zcorpan> | that being http://www.w3.org/TR/2012/WD-html5-diff-20120315/ |
| 14:01 | <zcorpan> | MikeSmith: e.g. if http+aes gets reverted, it should be moved in the changelog in html5-diff |
| 14:01 | <MikeSmith> | hmm |
| 14:01 | <MikeSmith> | yeah |
| 14:01 | <MikeSmith> | hmm |
| 14:01 | <MikeSmith> | yeah |
| 14:01 | <MikeSmith> | I guess will quietly push any updates to the TR version if needed |
| 14:02 | <MikeSmith> | I guess will quietly push any updates to the TR version if needed |
| 14:02 | <zcorpan> | currently the Path addition is missing |
| 14:03 | <zcorpan> | currently the Path addition is missing |
| 14:03 | <MikeSmith> | if you make the change I will push it to TR |
| 14:03 | <MikeSmith> | if you make the change I will push it to TR |
| 14:10 | <MikeSmith> | zcorpan: hmm I see that pubrules apparently requires a link to a mailing list |
| 14:11 | <MikeSmith> | zcorpan: hmm I see that pubrules apparently requires a link to a mailing list |
| 14:11 | <MikeSmith> | it doesn't matter what it says |
| 14:11 | <zcorpan> | http://dev.w3.org/cvsweb/html5/html4-differences/Overview.src.html.diff?r1=1.181;r2=1.182 (need to rebuild Overview.html or monkeypatch) |
| 14:12 | <zcorpan> | http://dev.w3.org/cvsweb/html5/html4-differences/Overview.src.html.diff?r1=1.181;r2=1.182 (need to rebuild Overview.html or monkeypatch) |
| 14:12 | <zcorpan> | MikeSmith: ok, i'll make it say to *not* use the mailing list :-) |
| 14:12 | <zcorpan> | MikeSmith: ok, i'll make it say to *not* use the mailing list :-) |
| 14:12 | <MikeSmith> | e.g., it could say, "There's a _public-html-comments mailing list_ but the appropriate forum for comments is s W3C Bugzilla |
| 14:12 | <annevk> | I can do make at some point |
| 14:12 | <annevk> | just tell me when you're done editing and I'll generate a new WD |
| 14:12 | <MikeSmith> | e.g., it could say, "There's a _public-html-comments mailing list_ but the appropriate forum for comments is s W3C Bugzilla |
| 14:12 | <annevk> | I can do make at some point |
| 14:12 | <annevk> | just tell me when you're done editing and I'll generate a new WD |
| 14:12 | <annevk> | takes less than a minute |
| 14:13 | <annevk> | takes less than a minute |
| 14:13 | <MikeSmith> | zcorpan: it wants both a mailto: link for the list address as well as a link to the archives |
| 14:13 | <zcorpan> | (<a href="mailto:public-html-comments⊙wo">public-html-comments⊙wo</a>, |
| 14:13 | <zcorpan> | a mailing list with a |
| 14:13 | <zcorpan> | <a href="http://lists.w3.org/Archives/Public/public-html-comments/"; title="Archive for HTML comments mailing-list">public |
| 14:13 | <zcorpan> | archive</a>, is no longer used for tracking comments.) |
| 14:14 | <MikeSmith> | zcorpan: it wants both a mailto: link for the list address as well as a link to the archives |
| 14:14 | <zcorpan> | (<a href="mailto:public-html-comments⊙wo">public-html-comments⊙wo</a>, |
| 14:14 | <zcorpan> | a mailing list with a |
| 14:14 | <zcorpan> | <a href="http://lists.w3.org/Archives/Public/public-html-comments/"; title="Archive for HTML comments mailing-list">public |
| 14:14 | <zcorpan> | archive</a>, is no longer used for tracking comments.) |
| 14:14 | <zcorpan> | sounds good? |
| 14:14 | <MikeSmith> | yah |
| 14:14 | <zcorpan> | sounds good? |
| 14:14 | <MikeSmith> | yah |
| 14:14 | <zcorpan> | http://dev.w3.org/cvsweb/html5/html4-differences/Overview.src.html.diff?r1=1.182;r2=1.183 |
| 14:15 | <zcorpan> | http://dev.w3.org/cvsweb/html5/html4-differences/Overview.src.html.diff?r1=1.182;r2=1.183 |
| 14:27 | <zcorpan> | http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1382 i don't understand what opera and gecko are doing here |
| 14:28 | <zcorpan> | http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1382 i don't understand what opera and gecko are doing here |
| 14:28 | <zcorpan> | chrome makes more sense |
| 14:28 | <zcorpan> | chrome makes more sense |
| 14:46 | <wirepair> | what... exactly is the point of the http+aes scheme? http://dev.w3.org/html5/spec-author-view/iana.html#http-aes-scheme |
| 14:46 | <wirepair> | what... exactly is the point of the http+aes scheme? http://dev.w3.org/html5/spec-author-view/iana.html#http-aes-scheme |
| 14:47 | <wirepair> | i've read it a few times and i just can't seem to wrap my head around *why* you'd want to put encryption keys in a url. |
| 14:47 | <MikeSmith> | annevk: please go ahead and re-make the diffs doc |
| 14:47 | <wirepair> | i've read it a few times and i just can't seem to wrap my head around *why* you'd want to put encryption keys in a url. |
| 14:47 | <MikeSmith> | annevk: please go ahead and re-make the diffs doc |
| 14:47 | <MikeSmith> | and check in the updated Overview.html |
| 14:47 | <MikeSmith> | if we have more changes later we can just do it again as needed |
| 14:48 | <MikeSmith> | and check in the updated Overview.html |
| 14:48 | <MikeSmith> | if we have more changes later we can just do it again as needed |
| 14:49 | <annevk> | done |
| 14:49 | <annevk> | done |
| 14:50 | <zcorpan> | oh, so opera and gecko just apply the "can't break around images" for the purpose of calculating the minimum width, but after that they are fine with breaking around images |
| 14:51 | <zcorpan> | oh, so opera and gecko just apply the "can't break around images" for the purpose of calculating the minimum width, but after that they are fine with breaking around images |
| 14:52 | <zcorpan> | and ie in compat view matches opera/gecko |
| 14:52 | <zcorpan> | ie non-compat quirks doesn't have this quirk |
| 14:53 | <zcorpan> | and ie in compat view matches opera/gecko |
| 14:53 | <zcorpan> | ie non-compat quirks doesn't have this quirk |
| 14:57 | <MikeSmith> | annevk: thanks |
| 14:57 | <MikeSmith> | annevk: thanks |
| 15:04 | <zcorpan> | ah, excellent, the Automatic table layout algo in css21 is non-normative |
| 15:05 | <zcorpan> | ah, excellent, the Automatic table layout algo in css21 is non-normative |
| 15:05 | <zcorpan> | i recall someone from mozilla having written a spec for table layout, but can't find it right now |
| 15:05 | <zcorpan> | i recall someone from mozilla having written a spec for table layout, but can't find it right now |
| 15:05 | <jgraham> | zcorpan: Go speak to dbaron |
| 15:05 | <jgraham> | He will explain table layout to you from memory |
| 15:06 | <jgraham> | zcorpan: Go speak to dbaron |
| 15:06 | <jgraham> | He will explain table layout to you from memory |
| 15:06 | zcorpan | finds http://dbaron.org/css/intrinsic/ |
| 15:08 | <zcorpan> | http://dbaron.org/css/intrinsic/#inline-intrinsic-min |
| 15:08 | <zcorpan> | excellent, what i want is a TODO :-) |
| 15:09 | <zcorpan> | http://dbaron.org/css/intrinsic/#inline-intrinsic-min |
| 15:09 | <zcorpan> | excellent, what i want is a TODO :-) |
| 15:10 | <smaug____> | so, the spec should refer to dbaron's brains? |
| 15:11 | <smaug____> | so, the spec should refer to dbaron's brains? |
| 15:11 | <jgraham> | Well ideally dbaron should serialize the content of his brain to some more durable format |
| 15:12 | <jgraham> | Well ideally dbaron should serialize the content of his brain to some more durable format |
| 15:12 | <smaug____> | but hey, it would be just a living standard |
| 15:13 | <smaug____> | but hey, it would be just a living standard |
| 15:14 | <jgraham> | The problem with living standards is that it's hard to clone their host body and init the clone's brain with the original data. We need the serialization for that. |
| 15:15 | <jgraham> | The problem with living standards is that it's hard to clone their host body and init the clone's brain with the original data. We need the serialization for that. |
| 15:29 | <annevk> | haha |
| 15:29 | <annevk> | taking living standard to a whole new level |
| 15:30 | <annevk> | haha |
| 15:30 | <annevk> | taking living standard to a whole new level |
| 17:12 | <Hixie> | Philip`, or anyone else: any opinions on ellipse apis before i spec this proposal? http://wiki.whatwg.org/wiki/Canvas#Ellipses |
| 17:13 | <Hixie> | Philip`, or anyone else: any opinions on ellipse apis before i spec this proposal? http://wiki.whatwg.org/wiki/Canvas#Ellipses |
| 17:13 | <Hixie> | i'm not 100% happy with making it take x and y radii arguments because that means you have to do a rotation to get a rotated ellipse |
| 17:13 | <Hixie> | i'm not 100% happy with making it take x and y radii arguments because that means you have to do a rotation to get a rotated ellipse |
| 17:14 | <AryehGregor> | You could have it take two foci instead of a center and radius. |
| 17:14 | <AryehGregor> | That's still just one extra argument over a circle. |
| 17:15 | <AryehGregor> | You could have it take two foci instead of a center and radius. |
| 17:15 | <AryehGregor> | That's still just one extra argument over a circle. |
| 17:15 | <Hixie> | so basically have ellipseArc and ellipseArcTo rather than arc and arcTo? |
| 17:15 | <Hixie> | so basically have ellipseArc and ellipseArcTo rather than arc and arcTo? |
| 17:15 | <Hixie> | rather than just overloading them i mean |
| 17:15 | AryehGregor | isn't familiar enough with canvas to say what API makes the most sense |
| 17:16 | <Hixie> | rather than just overloading them i mean |
| 17:16 | AryehGregor | isn't familiar enough with canvas to say what API makes the most sense |
| 17:16 | <AryehGregor> | Overloading on the number of arguments of a method that already takes five or six numeric arguments seems kind of confusing, though. |
| 17:16 | <AryehGregor> | Overloading on the number of arguments of a method that already takes five or six numeric arguments seems kind of confusing, though. |
| 17:18 | <Hixie> | (if i take foci don't i still need a semi-major axis distance?) |
| 17:19 | <Hixie> | (if i take foci don't i still need a semi-major axis distance?) |
| 17:20 | <AryehGregor> | Hmm. |
| 17:20 | <AryehGregor> | Hmm. |
| 17:20 | <AryehGregor> | Yeah, I think you need one more parameter in that case, you're right. You can have two different ellipses with the same foci. |
| 17:21 | <AryehGregor> | Yeah, I think you need one more parameter in that case, you're right. You can have two different ellipses with the same foci. |
| 17:21 | <Hixie> | only two? |
| 17:21 | <Hixie> | only two? |
| 17:21 | <Hixie> | surely i can have an infinite number |
| 17:21 | <AryehGregor> | Well, yes, of course. |
| 17:21 | <Hixie> | since two foci doesn't give you any data on the semi-minor axis |
| 17:21 | <AryehGregor> | I just meant that given two foci, there exist two distinct ellipses with those foci. |
| 17:22 | <Hixie> | surely i can have an infinite number |
| 17:22 | <AryehGregor> | Well, yes, of course. |
| 17:22 | <Hixie> | since two foci doesn't give you any data on the semi-minor axis |
| 17:22 | <AryehGregor> | I just meant that given two foci, there exist two distinct ellipses with those foci. |
| 17:22 | <AryehGregor> | There are actually more than two, but two is enough to make my suggestion bad. |
| 17:22 | <AryehGregor> | There are actually more than two, but two is enough to make my suggestion bad. |
| 17:24 | <Hixie> | i tried looking at the CG reference to see how they do it |
| 17:24 | <Hixie> | but of course that's the api that canvas was copied from |
| 17:24 | <Hixie> | i tried looking at the CG reference to see how they do it |
| 17:24 | <Hixie> | but of course that's the api that canvas was copied from |
| 17:24 | <Hixie> | so they don't |
| 17:24 | <Hixie> | same as us -_- |
| 17:25 | <Hixie> | so they don't |
| 17:25 | <Hixie> | same as us -_- |
| 17:26 | <Ms2ger> | "I'm at capacity (arguably over capacity) already." |
| 17:26 | <Ms2ger> | Arguably? |
| 17:27 | <Ms2ger> | "I'm at capacity (arguably over capacity) already." |
| 17:27 | <Ms2ger> | Arguably? |
| 17:32 | <MikeSmith> | Ms2ger: who said that? |
| 17:32 | <Ms2ger> | Hixie |
| 17:33 | <MikeSmith> | Ms2ger: who said that? |
| 17:33 | <Ms2ger> | Hixie |
| 17:57 | Ms2ger | wonders how to get dragonfly to open |
| 17:57 | Ms2ger | wonders how to get dragonfly to open |
| 18:06 | <jgraham> | Ms2ger: At what stage are you having a problem? |
| 18:07 | <jgraham> | Ms2ger: At what stage are you having a problem? |
| 18:07 | <Ms2ger> | Figured it out, the menu item was hidden three levels deep |
| 18:07 | <Ms2ger> | Figured it out, the menu item was hidden three levels deep |
| 18:07 | <jgraham> | That's the problem I have too |
| 18:07 | <Ms2ger> | AryehGregor, are you using the live dom viewer, and do you mind if I overwrite the test? :) |
| 18:07 | <AryehGregor> | Ms2ger, you can always overwrite the stuff I upload to Live DOM Viewer. |
| 18:08 | <jgraham> | That's the problem I have too |
| 18:08 | <Ms2ger> | AryehGregor, are you using the live dom viewer, and do you mind if I overwrite the test? :) |
| 18:08 | <AryehGregor> | Ms2ger, you can always overwrite the stuff I upload to Live DOM Viewer. |
| 18:08 | <AryehGregor> | Of course, I might overwrite what you upload too. :) |
| 18:08 | <AryehGregor> | Of course, I might overwrite what you upload too. :) |
| 18:08 | <Ms2ger> | If only I managed to :) |
| 18:09 | <Ms2ger> | If only I managed to :) |
| 18:10 | Ms2ger | curses IE's XSS protection |
| 18:10 | <Ms2ger> | They're wrong anyway, so *shrug* |
| 18:10 | <AryehGregor> | That's part of why upload/download is so much more useful. |
| 18:10 | <Ms2ger> | All to yourself again :) |
| 18:11 | Ms2ger | curses IE's XSS protection |
| 18:11 | <Ms2ger> | They're wrong anyway, so *shrug* |
| 18:11 | <AryehGregor> | That's part of why upload/download is so much more useful. |
| 18:11 | <Ms2ger> | All to yourself again :) |
| 18:11 | <Hixie> | looks like a lot of other apis do only x/y-aligned ellipses too |
| 18:11 | <Hixie> | looks like a lot of other apis do only x/y-aligned ellipses too |
| 18:12 | <Ms2ger> | Am I alone in finding Win8 hard to shut down? |
| 18:12 | <Ms2ger> | Am I alone in finding Win8 hard to shut down? |
| 18:12 | AryehGregor | just powers off the VM instead of sending a shutdown signal |
| 18:12 | <Philip`> | Shutting down is an obsolete concept |
| 18:13 | AryehGregor | just powers off the VM instead of sending a shutdown signal |
| 18:13 | <Philip`> | Shutting down is an obsolete concept |
| 18:18 | <jgraham> | Ms2ger: According to the interweb, everyone finds it hard to shut down |
| 18:19 | <jgraham> | Ms2ger: According to the interweb, everyone finds it hard to shut down |
| 18:19 | <Ms2ger> | Good |
| 18:19 | <Ms2ger> | Good |
| 18:19 | <jgraham> | Or at least enough people that there are supposedly youtube video tutorials on it |
| 18:19 | Ms2ger | is in favour of Microsoft shipping crap |
| 18:19 | <jgraham> | Or at least enough people that there are supposedly youtube video tutorials on it |
| 18:19 | Ms2ger | is in favour of Microsoft shipping crap |
| 18:52 | <AryehGregor> | Ms2ger, what's the rationale for this? It causes any quotes in test names or results to be backslash-escaped. http://dvcs.w3.org/hg/resources/rev/b2e673a7d8c7 |
| 18:53 | <AryehGregor> | Ms2ger, what's the rationale for this? It causes any quotes in test names or results to be backslash-escaped. http://dvcs.w3.org/hg/resources/rev/b2e673a7d8c7 |
| 18:53 | <Ms2ger> | XML :/ |
| 18:53 | <Ms2ger> | And the fact that it uses innerHTML |
| 18:53 | <Ms2ger> | XML :/ |
| 18:53 | <Ms2ger> | And the fact that it uses innerHTML |
| 18:53 | <AryehGregor> | More specifically? |
| 18:53 | Ms2ger | tries to remember the test |
| 18:54 | <AryehGregor> | More specifically? |
| 18:54 | Ms2ger | tries to remember the test |
| 18:54 | <AryehGregor> | If the problem is bad characters sneaking into test names, escape_html could entity-escape them. |
| 18:54 | <AryehGregor> | If the problem is bad characters sneaking into test names, escape_html could entity-escape them. |
| 18:54 | <AryehGregor> | format_value (and the part you copied into format_string) escapes in JS fashion, with backslashes, and in particular escapes innocuous stuff like quotes. |
| 18:54 | <AryehGregor> | I now have stuff like: Fail getComputedStyle(div).transformOrigin with \"transform: rotate(43deg); transform-origin: left 10px bottom -10px\", set via setAttribute() assert_approx_equals: Value of X part (actual: \"40px 15px\", expected: \"50px 25px\") expected 50 +/- 0.05 but got 40 |
| 18:55 | <AryehGregor> | format_value (and the part you copied into format_string) escapes in JS fashion, with backslashes, and in particular escapes innocuous stuff like quotes. |
| 18:55 | <AryehGregor> | I now have stuff like: Fail getComputedStyle(div).transformOrigin with \"transform: rotate(43deg); transform-origin: left 10px bottom -10px\", set via setAttribute() assert_approx_equals: Value of X part (actual: \"40px 15px\", expected: \"50px 25px\") expected 50 +/- 0.05 but got 40 |
| 18:55 | <Ms2ger> | Yeah :/ |
| 18:55 | <Ms2ger> | http://w3c-test.org/webapps/DOMCore/tests/submissions/Ms2ger/Document-createProcessingInstruction.xhtml was the one, I think |
| 18:55 | <Ms2ger> | Yeah :/ |
| 18:55 | <Ms2ger> | http://w3c-test.org/webapps/DOMCore/tests/submissions/Ms2ger/Document-createProcessingInstruction.xhtml was the one, I think |
| 18:55 | <AryehGregor> | That test should call format_value() itself on valid[i][0], valid[i][1], etc. |
| 18:56 | <AryehGregor> | That test should call format_value() itself on valid[i][0], valid[i][1], etc. |
| 18:56 | <AryehGregor> | That will add quotes and nice things like that too. |
| 18:56 | <AryehGregor> | You don't want to call it on the whole test name. |
| 18:56 | <AryehGregor> | That will add quotes and nice things like that too. |
| 18:56 | <Ms2ger> | OK |
| 18:56 | <AryehGregor> | You don't want to call it on the whole test name. |
| 18:56 | <Ms2ger> | OK |
| 18:56 | <AryehGregor> | Can I revert your testharness changes? |
| 18:56 | <Ms2ger> | Sure thing |
| 18:56 | <AryehGregor> | Okay, thanks. |
| 18:56 | <Ms2ger> | Well |
| 18:56 | <Ms2ger> | Hmm, I guess |
| 18:57 | <AryehGregor> | Can I revert your testharness changes? |
| 18:57 | <Ms2ger> | Sure thing |
| 18:57 | <AryehGregor> | Okay, thanks. |
| 18:57 | <Ms2ger> | Well |
| 18:57 | <Ms2ger> | Hmm, I guess |
| 18:57 | <Ms2ger> | Yes, go ahead |
| 18:57 | <AryehGregor> | Okay. |
| 18:57 | <Ms2ger> | Yes, go ahead |
| 18:57 | <AryehGregor> | Okay. |
| 18:59 | <AryehGregor> | Is there a convenient hg equivalent to git revert -n? |
| 18:59 | <AryehGregor> | Is there a convenient hg equivalent to git revert -n? |
| 19:04 | <Ms2ger> | hg backout? |
| 19:05 | <Ms2ger> | hg backout? |
| 19:05 | <AryehGregor> | That creates a commit. |
| 19:05 | <AryehGregor> | That creates a commit. |
| 19:05 | <Ms2ger> | Well, yes |
| 19:05 | <AryehGregor> | git revert -n doesn't create a commit. |
| 19:05 | <Ms2ger> | What does it do then? |
| 19:05 | <AryehGregor> | It just applies the diff. |
| 19:06 | <Ms2ger> | Well, yes |
| 19:06 | <AryehGregor> | git revert -n doesn't create a commit. |
| 19:06 | <Ms2ger> | What does it do then? |
| 19:06 | <AryehGregor> | It just applies the diff. |
| 19:06 | <AryehGregor> | I wound up doing hg diff -r 6 -r 4 | patch. |
| 19:06 | <AryehGregor> | I wound up doing hg diff -r 6 -r 4 | patch. |
| 19:06 | <AryehGregor> | Which conflicted because some context didn't match, but close enough. |
| 19:07 | <AryehGregor> | Which conflicted because some context didn't match, but close enough. |
| 19:11 | <rniwa> | AryehGregor: hi AryehGregor |
| 19:11 | <AryehGregor> | rniwa, hi! |
| 19:11 | <rniwa> | AryehGregor: did you see my email about nested transactions in undo manger? |
| 19:11 | <AryehGregor> | rniwa, yes. |
| 19:11 | <AryehGregor> | execCommand() should never be called recursively anyway now, because that will fire extra events. |
| 19:12 | <rniwa> | AryehGregor: hi AryehGregor |
| 19:12 | <AryehGregor> | rniwa, hi! |
| 19:12 | <rniwa> | AryehGregor: did you see my email about nested transactions in undo manger? |
| 19:12 | <AryehGregor> | rniwa, yes. |
| 19:12 | <AryehGregor> | execCommand() should never be called recursively anyway now, because that will fire extra events. |
| 19:12 | <AryehGregor> | There were a few places where my spec said to do that, and I'm in the middle of fixing them. |
| 19:12 | <AryehGregor> | There were a few places where my spec said to do that, and I'm in the middle of fixing them. |
| 19:33 | <StoneCypher> | is it possible to control <td> border miters? |
| 19:34 | <StoneCypher> | is it possible to control <td> border miters? |
| 19:53 | <Hixie> | heycam|away: can webidl distingush (five doubles and a boolean) from (six doubles), when it comes to overloading method ? |
| 19:53 | <Hixie> | methods, even |
| 19:54 | <Hixie> | heycam|away: can webidl distingush (five doubles and a boolean) from (six doubles), when it comes to overloading method ? |
| 19:54 | <Hixie> | methods, even |
| 19:54 | <Ms2ger> | Doesn't look like it |
| 19:55 | <Ms2ger> | Doesn't look like it |
| 19:55 | <Hixie> | crap |
| 19:55 | <AryehGregor> | Why not? |
| 19:55 | <Hixie> | that's unfortunate |
| 19:55 | <AryehGregor> | Also: why in heaven's name would you want such a confusing overload? |
| 19:56 | <Hixie> | crap |
| 19:56 | <AryehGregor> | Why not? |
| 19:56 | <Hixie> | that's unfortunate |
| 19:56 | <AryehGregor> | Also: why in heaven's name would you want such a confusing overload? |
| 19:56 | <AryehGregor> | Wouldn't a separate method be a lot clearer? |
| 19:56 | <AryehGregor> | Wouldn't a separate method be a lot clearer? |
| 19:56 | <Ms2ger> | Because we can! |
| 19:56 | <Ms2ger> | Well, we can't |
| 19:57 | <Ms2ger> | Because we can! |
| 19:57 | <Ms2ger> | Well, we can't |
| 19:57 | <Hixie> | it'd be pretty clear, in this case, in practice |
| 19:57 | <Hixie> | but anyway. lunch. |
| 19:57 | <Hixie> | it'd be pretty clear, in this case, in practice |
| 19:57 | <Hixie> | but anyway. lunch. |
| 20:18 | <rniwa> | AryehGregor: ah, ok. great. |
| 20:19 | <rniwa> | AryehGregor: ah, ok. great. |
| 20:19 | <rniwa> | AryehGregor: so just prohibit the nested transaction as wel? |
| 20:19 | <rniwa> | AryehGregor: so just prohibit the nested transaction as wel? |
| 20:21 | <AryehGregor> | rniwa, I guess. |
| 20:21 | <AryehGregor> | I'm not familiar enough with UndoManager to understand the implications, TBH. |
| 20:22 | <AryehGregor> | rniwa, I guess. |
| 20:22 | <AryehGregor> | I'm not familiar enough with UndoManager to understand the implications, TBH. |
| 20:26 | <rniwa> | sicking: ping |
| 20:26 | <rniwa> | AryehGregor: so the implication is simple |
| 20:26 | <rniwa> | AryehGregor: nobody is allowed to add new transaction while someone else's running a transaction |
| 20:27 | <rniwa> | sicking: ping |
| 20:27 | <rniwa> | AryehGregor: so the implication is simple |
| 20:27 | <rniwa> | AryehGregor: nobody is allowed to add new transaction while someone else's running a transaction |
| 20:27 | <rniwa> | AryehGregor: it might get a little tricky when there are cross-origin iframes |
| 20:27 | <rniwa> | AryehGregor: it might get a little tricky when there are cross-origin iframes |
| 20:27 | <rniwa> | AryehGregor: because the you sort of leak the information that a transaction is in progress |
| 20:27 | <AryehGregor> | Right, but I don't remember the use-cases etc. well enough to know what effect that would have in practice. |
| 20:27 | <rniwa> | but I don't think that's a big of deal |
| 20:27 | <rniwa> | ehsan: yt? |
| 20:27 | <AryehGregor> | Do cross-origin iframes share the same undo manager as their host page? That seems a little surprising. |
| 20:27 | <AryehGregor> | There's already information leak there, then, right? |
| 20:27 | <rniwa> | AryehGregor: no |
| 20:28 | <rniwa> | AryehGregor: because the you sort of leak the information that a transaction is in progress |
| 20:28 | <AryehGregor> | Right, but I don't remember the use-cases etc. well enough to know what effect that would have in practice. |
| 20:28 | <rniwa> | but I don't think that's a big of deal |
| 20:28 | <ehsan> | rniwa: yeah |
| 20:28 | <rniwa> | ehsan: yt? |
| 20:28 | <AryehGregor> | Do cross-origin iframes share the same undo manager as their host page? That seems a little surprising. |
| 20:28 | <AryehGregor> | There's already information leak there, then, right? |
| 20:28 | <rniwa> | AryehGregor: no |
| 20:28 | <rniwa> | AryehGregor: there should be undo manager per document |
| 20:28 | <ehsan> | rniwa: yeah |
| 20:28 | <rniwa> | AryehGregor: there should be undo manager per document |
| 20:28 | <rniwa> | AryehGregor: but that's also tricky for webkit & ie |
| 20:28 | <rniwa> | AryehGregor: but that's also tricky for webkit & ie |
| 20:28 | <rniwa> | AryehGregor: because undo stack shared across the entire page at the moment |
| 20:29 | <rniwa> | AryehGregor: because undo stack shared across the entire page at the moment |
| 20:29 | <AryehGregor> | Then you're already leaking information. E.g., you can take some action in the outer page, wait a while, and see if execCommand("undo") reverses it. If it doesn't, the user must have taken some action in the iframe that got reversed. |
| 20:29 | <AryehGregor> | Then you're already leaking information. E.g., you can take some action in the outer page, wait a while, and see if execCommand("undo") reverses it. If it doesn't, the user must have taken some action in the iframe that got reversed. |
| 20:29 | <rniwa> | AryehGregor: right. |
| 20:29 | <AryehGregor> | Actually, that means the outer page can use undo/redo to modify the DOM of the inner page. That seems like it might be "interesting" from a security perspective. |
| 20:29 | <rniwa> | AryehGregor: while i'm not going to talk about specifics, there's a bug about it. |
| 20:30 | <rniwa> | AryehGregor: right. |
| 20:30 | <AryehGregor> | Actually, that means the outer page can use undo/redo to modify the DOM of the inner page. That seems like it might be "interesting" from a security perspective. |
| 20:30 | <rniwa> | AryehGregor: while i'm not going to talk about specifics, there's a bug about it. |
| 20:30 | <rniwa> | AryehGregor: it's extremely tricky |
| 20:30 | <Ms2ger> | What's this "unrestricted float" thing in WebIDL? |
| 20:30 | <rniwa> | AryehGregor: it's extremely tricky |
| 20:30 | <Ms2ger> | What's this "unrestricted float" thing in WebIDL? |
| 20:30 | <rniwa> | to say the least |
| 20:30 | <rniwa> | to say the least |
| 20:30 | <rniwa> | ehsan: do you think prohibiting nested transaction is the way to go? |
| 20:30 | <AryehGregor> | Ms2ger, https://www.w3.org/Bugs/Public/show_bug.cgi?id=16075 |
| 20:30 | <ehsan> | rniwa: I still have not caught up with the thread |
| 20:30 | <rniwa> | ehsan: ok |
| 20:31 | <rniwa> | ehsan: do you think prohibiting nested transaction is the way to go? |
| 20:31 | <AryehGregor> | Ms2ger, https://www.w3.org/Bugs/Public/show_bug.cgi?id=16075 |
| 20:31 | <ehsan> | rniwa: I still have not caught up with the thread |
| 20:31 | <rniwa> | ehsan: ok |
| 20:31 | <rniwa> | ehsan, AryehGregor: I just want to make sure the API behaves sane |
| 20:31 | <ehsan> | rniwa: I'll look at the thread later today |
| 20:31 | <rniwa> | ehsan, AryehGregor: on somewhat related note, DOMTransaction interface needs to be a callback interface |
| 20:32 | <rniwa> | ehsan, AryehGregor: I just want to make sure the API behaves sane |
| 20:32 | <ehsan> | rniwa: I'll look at the thread later today |
| 20:32 | <rniwa> | ehsan, AryehGregor: on somewhat related note, DOMTransaction interface needs to be a callback interface |
| 20:32 | <rniwa> | and there are a quite few interesting stuff going on with respect to GC |
| 20:32 | <rniwa> | because they need to be kept alive until undo/redo are done |
| 20:32 | <rniwa> | and there are a quite few interesting stuff going on with respect to GC |
| 20:32 | <rniwa> | because they need to be kept alive until undo/redo are done |
| 20:32 | <Ms2ger> | AryehGregor, is there a bug on HTML to use it? |
| 20:32 | <AryehGregor> | Ms2ger, not AFAIK. |
| 20:32 | <rniwa> | ehsan, AryehGregor: however, they might be pruned earlier if undoManager gets destroyed... |
| 20:33 | <Ms2ger> | AryehGregor, is there a bug on HTML to use it? |
| 20:33 | <AryehGregor> | Ms2ger, not AFAIK. |
| 20:33 | <rniwa> | ehsan, AryehGregor: however, they might be pruned earlier if undoManager gets destroyed... |
| 20:56 | <smaug____> | rniwa: just curious, does the undomanager thingie define how much needs to be kept in undo/redo stacks ? |
| 20:56 | <rniwa> | smaug____: it does not. |
| 20:56 | <smaug____> | rniwa: just curious, does the undomanager thingie define how much needs to be kept in undo/redo stacks ? |
| 20:56 | <rniwa> | smaug____: it does not. |
| 20:56 | <smaug____> | undo can use quite some memory |
| 20:56 | <rniwa> | smaug____: right. |
| 20:56 | <rniwa> | smaug____: so we should probably add some limit to it |
| 20:56 | <smaug____> | yeah |
| 20:56 | <rniwa> | smaug____: but then... should we modify the page of undo stack pruning? |
| 20:56 | <rniwa> | notify* |
| 20:56 | <smaug____> | I think gecko has some limit |
| 20:57 | <smaug____> | undo can use quite some memory |
| 20:57 | <rniwa> | smaug____: right. |
| 20:57 | <rniwa> | smaug____: so we should probably add some limit to it |
| 20:57 | <smaug____> | yeah |
| 20:57 | <rniwa> | smaug____: but then... should we modify the page of undo stack pruning? |
| 20:57 | <rniwa> | notify* |
| 20:57 | <smaug____> | I think gecko has some limit |
| 20:57 | <smaug____> | ehsan might remember what that is |
| 20:57 | <smaug____> | ehsan might remember what that is |
| 20:58 | <ehsan> | smaug____: I don't think we impose a limit in fact |
| 20:58 | <smaug____> | there is max transaction count |
| 20:59 | <ehsan> | smaug____: I don't think we impose a limit in fact |
| 20:59 | <smaug____> | there is max transaction count |
| 20:59 | <ehsan> | smaug____: well we set it to -1, which means don't care |
| 20:59 | <smaug____> | bah :) |
| 21:00 | <ehsan> | smaug____: well we set it to -1, which means don't care |
| 21:00 | <smaug____> | bah :) |
| 21:00 | <ehsan> | smaug____: I don't see the point in imposing a limit... |
| 21:00 | <ehsan> | smaug____: I don't see the point in imposing a limit... |
| 21:00 | <ehsan> | web pages can already do stupid stuff if they wanna burn memory |
| 21:00 | <smaug____> | and do |
| 21:00 | <rniwa> | ehsan: I think chromium has a limit |
| 21:00 | <smaug____> | like irccloud |
| 21:00 | <ehsan> | and we don't need operations which are in an order of the length of the stack |
| 21:01 | <ehsan> | web pages can already do stupid stuff if they wanna burn memory |
| 21:01 | <smaug____> | and do |
| 21:01 | <rniwa> | ehsan: I think chromium has a limit |
| 21:01 | <smaug____> | like irccloud |
| 21:01 | <ehsan> | and we don't need operations which are in an order of the length of the stack |
| 21:01 | <ehsan> | rniwa: then I would suggest that they should lift it ;) |
| 21:01 | <ehsan> | smaug____: or, (sigh), gmail |
| 21:01 | <Yuhong> | http://ln.hixie.ch/?start=1137740632&count=1 |
| 21:01 | <ehsan> | rniwa: then I would suggest that they should lift it ;) |
| 21:01 | <ehsan> | smaug____: or, (sigh), gmail |
| 21:01 | <Yuhong> | http://ln.hixie.ch/?start=1137740632&count=1 |
| 21:01 | <smaug____> | ehsan: oh, even that |
| 21:01 | <Yuhong> | "The HTML5 spec says that if you use another DOCTYPE, UAs can switch to quirks mode, in which case all bets are off. I'm not even going to try to specify quirks mode parsing. Hopefully, by making the DOCTYPE short and memorable, it will encourage authors to use it more." |
| 21:01 | <smaug____> | and sure, google reader too |
| 21:01 | <Yuhong> | From Hixie. |
| 21:02 | <smaug____> | ehsan: oh, even that |
| 21:02 | <Yuhong> | "The HTML5 spec says that if you use another DOCTYPE, UAs can switch to quirks mode, in which case all bets are off. I'm not even going to try to specify quirks mode parsing. Hopefully, by making the DOCTYPE short and memorable, it will encourage authors to use it more." |
| 21:02 | <smaug____> | and sure, google reader too |
| 21:02 | <Yuhong> | From Hixie. |
| 21:02 | <ehsan> | jee, those like buttons? |
| 21:02 | <ehsan> | jee, those like buttons? |
| 21:02 | <smaug____> | google web devs clearly don't have the right tools the find leaks |
| 21:02 | <smaug____> | google web devs clearly don't have the right tools the find leaks |
| 21:02 | <ehsan> | don't get me started ;) |
| 21:02 | <smaug____> | "leaks" |
| 21:02 | <ehsan> | don't get me started ;) |
| 21:02 | <smaug____> | "leaks" |
| 21:02 | <Ms2ger> | Oh hey, karl heard about me |
| 21:02 | <Yuhong> | Two years before X-UA-Compatible was created. |
| 21:02 | <smaug____> | s/the/to/ |
| 21:02 | <rniwa> | smaug____, ehsan: i think webkit currently keeps undo stack for a page as long as the page is there |
| 21:03 | <Ms2ger> | Oh hey, karl heard about me |
| 21:03 | <Yuhong> | Two years before X-UA-Compatible was created. |
| 21:03 | <smaug____> | s/the/to/ |
| 21:03 | <rniwa> | smaug____, ehsan: i think webkit currently keeps undo stack for a page as long as the page is there |
| 21:03 | <rniwa> | so we need to change that before lifting the limit |
| 21:03 | <rniwa> | so we need to change that before lifting the limit |
| 21:03 | <rniwa> | e.g. prune entries in the undo stack for a frame when the frame is destroyed, etc... |
| 21:04 | <rniwa> | e.g. prune entries in the undo stack for a frame when the frame is destroyed, etc... |
| 21:04 | <ehsan> | rniwa: when you say frame, what do you mean? iframes? or rendering objects? |
| 21:04 | <rniwa> | ehsan: i mean DOM frames |
| 21:04 | <ehsan> | rniwa: when you say frame, what do you mean? iframes? or rendering objects? |
| 21:04 | <rniwa> | ehsan: i mean DOM frames |
| 21:04 | <smaug____> | undo should be per document |
| 21:04 | <rniwa> | smaug____: it is not for webkit and msie |
| 21:04 | <smaug____> | but it should be :) |
| 21:05 | <smaug____> | undo should be per document |
| 21:05 | <rniwa> | smaug____: it is not for webkit and msie |
| 21:05 | <smaug____> | but it should be :) |
| 21:05 | <rniwa> | smaug____: well, maybe. |
| 21:05 | <ehsan> | rniwa: I think smaug____ is right here, I don't know why they should have anything to do with frames |
| 21:05 | <ehsan> | rniwa: I think smaug____ is right here, I don't know why they should have anything to do with frames |
| 21:05 | <rniwa> | smaug____: but gecko/opera also uses different undo stack for each text form controls |
| 21:05 | <smaug____> | undomanager is something new anyway, so better to make a good API |
| 21:05 | <rniwa> | whereas webkit and msie don't |
| 21:05 | <ehsan> | rniwa: that's sort of a by-product of gecko's editor |
| 21:05 | <ehsan> | no good reason ;) |
| 21:05 | <rniwa> | smaug____: well but it change the user-initiated undo behavior |
| 21:06 | <rniwa> | smaug____: but gecko/opera also uses different undo stack for each text form controls |
| 21:06 | <smaug____> | undomanager is something new anyway, so better to make a good API |
| 21:06 | <smaug____> | rniwa: sure. I actually think there should be several undomanagers |
| 21:06 | <rniwa> | whereas webkit and msie don't |
| 21:06 | <ehsan> | rniwa: that's sort of a by-product of gecko's editor |
| 21:06 | <ehsan> | no good reason ;) |
| 21:06 | <rniwa> | smaug____: well but it change the user-initiated undo behavior |
| 21:06 | <smaug____> | rniwa: sure. I actually think there should be several undomanagers |
| 21:06 | <ehsan> | although that seems intuitive to me as a user... |
| 21:06 | <ehsan> | although that seems intuitive to me as a user... |
| 21:06 | <ehsan> | (that = treating each text control as a separate undo host) |
| 21:06 | <smaug____> | yeah |
| 21:07 | <ehsan> | (that = treating each text control as a separate undo host) |
| 21:07 | <smaug____> | yeah |
| 21:07 | <rniwa> | don't think we want to change the behavior here though |
| 21:07 | <rniwa> | don't think we want to change the behavior here though |
| 21:07 | smaug____ | doesn't know what behavior chrome has |
| 21:07 | <ehsan> | which behavior? |
| 21:07 | <rniwa> | that text form controls share the same undo manager |
| 21:07 | <rniwa> | smaug____: chrome=webkit here |
| 21:08 | smaug____ | doesn't know what behavior chrome has |
| 21:08 | <ehsan> | which behavior? |
| 21:08 | <rniwa> | ehsan: also, we don't provide any mechanisms to merge undo managers |
| 21:08 | <rniwa> | that text form controls share the same undo manager |
| 21:08 | <rniwa> | smaug____: chrome=webkit here |
| 21:08 | <rniwa> | ehsan: also, we don't provide any mechanisms to merge undo managers |
| 21:08 | <rniwa> | so this would mean that websites can never have a page that shares the same undo managers amongst text from controls |
| 21:08 | <rniwa> | which might be desirable in spreadsheet apps |
| 21:08 | <ehsan> | rniwa: so in webkit, if you have two text fields, type foo in one of them and go to the other and do cmd+z, foo gets deleted from the first box? |
| 21:08 | <rniwa> | ehsan: right. |
| 21:08 | <ehsan> | rniwa: wow |
| 21:08 | <smaug____> | ugh |
| 21:08 | <smaug____> | sounds bizarre |
| 21:09 | <rniwa> | so this would mean that websites can never have a page that shares the same undo managers amongst text from controls |
| 21:09 | <rniwa> | which might be desirable in spreadsheet apps |
| 21:09 | <ehsan> | rniwa: so in webkit, if you have two text fields, type foo in one of them and go to the other and do cmd+z, foo gets deleted from the first box? |
| 21:09 | <rniwa> | ehsan: right. |
| 21:09 | <ehsan> | rniwa: wow |
| 21:09 | <ehsan> | that sounds broken |
| 21:09 | <smaug____> | ugh |
| 21:09 | <smaug____> | sounds bizarre |
| 21:09 | <ehsan> | that sounds broken |
| 21:09 | ehsan | tries it to see for himself |
| 21:09 | <rniwa> | ehsan: but it's useful when you're filling up forms |
| 21:09 | <rniwa> | ehsan: and want to do undo a bunch |
| 21:09 | ehsan | tries it to see for himself |
| 21:09 | <rniwa> | ehsan: but it's useful when you're filling up forms |
| 21:09 | <rniwa> | ehsan: and want to do undo a bunch |
| 21:09 | <Ms2ger> | MikeSmith, yt? |
| 21:09 | <smaug____> | rniwa: so you need to remember which field you have filled in which order... |
| 21:10 | <Ms2ger> | MikeSmith, yt? |
| 21:10 | <smaug____> | before undoing |
| 21:10 | <smaug____> | rniwa: so you need to remember which field you have filled in which order... |
| 21:10 | <smaug____> | before undoing |
| 21:10 | <smaug____> | strange |
| 21:10 | <smaug____> | strange |
| 21:10 | <rniwa> | smaug____: i mean, people normally fills in forms from top-down |
| 21:10 | <rniwa> | smaug____: anyway i'm not about to argue about why we do this |
| 21:10 | <smaug____> | web apps could just move focus to previous field or something like that if field is emptied using undo |
| 21:10 | <smaug____> | rniwa: is that some ancient behavior in webkit? |
| 21:11 | <rniwa> | smaug____: i mean, people normally fills in forms from top-down |
| 21:11 | <rniwa> | smaug____: right. |
| 21:11 | <rniwa> | smaug____: anyway i'm not about to argue about why we do this |
| 21:11 | <smaug____> | web apps could just move focus to previous field or something like that if field is emptied using undo |
| 21:11 | <smaug____> | rniwa: is that some ancient behavior in webkit? |
| 21:11 | <rniwa> | smaug____: right. |
| 21:11 | <rniwa> | smaug____: yeah |
| 21:11 | <ehsan> | this seems very bizzare to me... |
| 21:11 | <rniwa> | smaug____: yeah |
| 21:11 | <ehsan> | this seems very bizzare to me... |
| 21:11 | <rniwa> | smaug____, ehsan: anyway, i don't think we can change this behavior |
| 21:11 | <ehsan> | although, it is a UX question |
| 21:11 | <rniwa> | because of legacy apps that depend on this particular behavior |
| 21:11 | <smaug____> | ( yeah, sounds like breaking all sorts of basic UX rules ) |
| 21:11 | <rniwa> | right, it's a UX issue |
| 21:11 | <ehsan> | it might be sane in the case of forms, but we can't assume that all two text fields in the same page belong to the same form! |
| 21:11 | <rniwa> | we try to follow the platform convention whenever possible |
| 21:12 | <rniwa> | smaug____, ehsan: anyway, i don't think we can change this behavior |
| 21:12 | <ehsan> | although, it is a UX question |
| 21:12 | <rniwa> | because of legacy apps that depend on this particular behavior |
| 21:12 | <smaug____> | ( yeah, sounds like breaking all sorts of basic UX rules ) |
| 21:12 | <rniwa> | right, it's a UX issue |
| 21:12 | <ehsan> | it might be sane in the case of forms, but we can't assume that all two text fields in the same page belong to the same form! |
| 21:12 | <rniwa> | we try to follow the platform convention whenever possible |
| 21:12 | <rniwa> | ehsan: right, that's why we want undoScope :) |
| 21:12 | <ehsan> | rniwa: well, here, platform convention is basically webkit's behavior :( |
| 21:12 | <ehsan> | so that's a logical loop ;) |
| 21:12 | <rniwa> | ehsan: right, that's why we want undoScope :) |
| 21:12 | <ehsan> | rniwa: well, here, platform convention is basically webkit's behavior :( |
| 21:12 | <ehsan> | so that's a logical loop ;) |
| 21:15 | <rniwa> | ehsan: as i said, IE does this too |
| 21:16 | <rniwa> | ehsan: as i said, IE does this too |
| 21:16 | <ehsan> | well yeah |
| 21:16 | <ehsan> | well yeah |
| 21:16 | <ehsan> | but we should see if this happens with the windows text control for example |
| 21:16 | <ehsan> | but we should see if this happens with the windows text control for example |
| 21:16 | <ehsan> | since that would be the real platform convention |
| 21:17 | <ehsan> | since that would be the real platform convention |
| 21:17 | <rniwa> | ehsan: yeah, but i can't find an app that have multiple form controls in a document |
| 21:17 | <rniwa> | most of examples i can find are modal dialogs |
| 21:18 | <rniwa> | ehsan: yeah, but i can't find an app that have multiple form controls in a document |
| 21:18 | <rniwa> | most of examples i can find are modal dialogs |
| 21:18 | <rniwa> | and they, of course, behave differently |
| 21:18 | <rniwa> | and they, of course, behave differently |
| 21:18 | <ehsan> | rniwa: I have one here in fact, gimme a sec |
| 21:19 | <ehsan> | rniwa: I have one here in fact, gimme a sec |
| 21:19 | ehsan | waits for his windows box to boot up |
| 21:19 | ehsan | waits for his windows box to boot up |
| 21:21 | <ehsan> | rniwa: ok, on native windows, each text field has its own undo stack |
| 21:22 | <ehsan> | rniwa: ok, on native windows, each text field has its own undo stack |
| 21:22 | <rniwa> | ehsan: yeah, because they're separate windows |
| 21:22 | <rniwa> | ehsan: yeah, because they're separate windows |
| 21:22 | <ehsan> | correct |
| 21:22 | <ehsan> | (several OS level windows, that is)_ |
| 21:22 | <rniwa> | ehsan: right. |
| 21:22 | <ehsan> | correct |
| 21:22 | <ehsan> | (several OS level windows, that is)_ |
| 21:22 | <rniwa> | ehsan: right. |
| 21:22 | <rniwa> | but i can't think of any windows app that has forms in the same page/document |
| 21:22 | <rniwa> | i can't think of such an ui |
| 21:22 | <rniwa> | anywhere |
| 21:22 | <ehsan> | so webkit doesn't adhere to platform conventions on windows ;) |
| 21:23 | <rniwa> | but i can't think of any windows app that has forms in the same page/document |
| 21:23 | <rniwa> | i can't think of such an ui |
| 21:23 | <rniwa> | anywhere |
| 21:23 | <ehsan> | so webkit doesn't adhere to platform conventions on windows ;) |
| 21:23 | <rniwa> | ehsan: it adheres to the platform in the sense that msie is the only windows app that have such an UI |
| 21:23 | <rniwa> | ehsan: and we match msie |
| 21:23 | <ehsan> | rniwa: thing like office automation apps have lots of such forms |
| 21:23 | <rniwa> | ehsan: it adheres to the platform in the sense that msie is the only windows app that have such an UI |
| 21:23 | <rniwa> | ehsan: and we match msie |
| 21:23 | <ehsan> | rniwa: thing like office automation apps have lots of such forms |
| 21:23 | <rniwa> | ehsan: that's an interesting point |
| 21:23 | <rniwa> | ehsan: what do they do? |
| 21:23 | <ehsan> | separate undo stacks |
| 21:23 | <rniwa> | ok |
| 21:23 | <ehsan> | honestly, I've never noticed an app do something differently |
| 21:23 | <rniwa> | odd |
| 21:23 | <ehsan> | I don't use IE and webkit that much personally |
| 21:24 | <rniwa> | ehsan: that's an interesting point |
| 21:24 | <rniwa> | ehsan: what do they do? |
| 21:24 | <ehsan> | separate undo stacks |
| 21:24 | <rniwa> | ok |
| 21:24 | <ehsan> | honestly, I've never noticed an app do something differently |
| 21:24 | <rniwa> | odd |
| 21:24 | <ehsan> | I don't use IE and webkit that much personally |
| 21:24 | <rniwa> | ehsan: we'll have to ask microsoft why do they do that way on msie |
| 21:24 | <rniwa> | ehsan: we'll have to ask microsoft why do they do that way on msie |
| 21:24 | <ehsan> | but my eyeballs nearly popped out when I saw this today ;) |
| 21:24 | <ehsan> | but my eyeballs nearly popped out when I saw this today ;) |
| 21:24 | <smaug____> | rniwa: I could imagine the IE behavior could be some ancient thingie |
| 21:24 | <smaug____> | from IE3 or such |
| 21:24 | <rniwa> | smaug____: posible. |
| 21:25 | <smaug____> | rniwa: I could imagine the IE behavior could be some ancient thingie |
| 21:25 | <smaug____> | from IE3 or such |
| 21:25 | <rniwa> | smaug____: posible. |
| 21:25 | <smaug____> | and behavior in web browsers at that time didn't need to have any reasoning :) |
| 21:26 | <smaug____> | and behavior in web browsers at that time didn't need to have any reasoning :) |
| 21:26 | <ehsan> | rniwa: take this as an example: http://www.bing.com/search?q=test&go=&qs=n&form=QBLH&filt=all&pq=test&sc=8-4&sp=-1&sk= |
| 21:26 | <ehsan> | rniwa: edit something in the first text box |
| 21:26 | <ehsan> | then scroll down |
| 21:26 | <ehsan> | rniwa: take this as an example: http://www.bing.com/search?q=test&go=&qs=n&form=QBLH&filt=all&pq=test&sc=8-4&sp=-1&sk= |
| 21:26 | <ehsan> | rniwa: edit something in the first text box |
| 21:26 | <ehsan> | then scroll down |
| 21:26 | <ehsan> | focus the other text box at the end of the page |
| 21:26 | <ehsan> | and do Cmd+X |
| 21:26 | <ehsan> | *Z |
| 21:26 | <ehsan> | no observable behavior |
| 21:26 | <ehsan> | and the edit in the first box suddenly gets unddone |
| 21:26 | <ehsan> | how can that be the desired UX? ;) |
| 21:27 | <ehsan> | focus the other text box at the end of the page |
| 21:27 | <ehsan> | and do Cmd+X |
| 21:27 | <ehsan> | *Z |
| 21:27 | <ehsan> | no observable behavior |
| 21:27 | <ehsan> | and the edit in the first box suddenly gets unddone |
| 21:27 | <ehsan> | how can that be the desired UX? ;) |
| 21:27 | <rniwa> | ehsan: as I said, I'm not going to make a UX argument here |
| 21:27 | <ehsan> | :) |
| 21:27 | <rniwa> | ehsan: as I said, I'm not going to make a UX argument here |
| 21:27 | <ehsan> | :) |
| 21:27 | <rniwa> | ehsan: all I know is that that's the behavior we chose to implement |
| 21:27 | <ehsan> | yeah ok fair enough |
| 21:27 | <rniwa> | and there might be some backward compatibility issues if we were to change it |
| 21:28 | <rniwa> | ehsan: all I know is that that's the behavior we chose to implement |
| 21:28 | <ehsan> | yeah ok fair enough |
| 21:28 | <rniwa> | and there might be some backward compatibility issues if we were to change it |
| 21:28 | <ehsan> | well implementations already have different behaviors here |
| 21:28 | <ehsan> | so I would decide that we should determine what the *correct* thing to do is |
| 21:28 | <ehsan> | well implementations already have different behaviors here |
| 21:28 | <ehsan> | so I would decide that we should determine what the *correct* thing to do is |
| 21:28 | <ehsan> | and then adopt that |
| 21:28 | <ehsan> | and it _is_ a UX question |
| 21:28 | <ehsan> | so don't take my argument as a UX decision :) |
| 21:29 | <ehsan> | and then adopt that |
| 21:29 | <ehsan> | and it _is_ a UX question |
| 21:29 | <ehsan> | so don't take my argument as a UX decision :) |
| 21:29 | <rniwa> | ehsan: yeah. |
| 21:29 | <rniwa> | ehsan: we'll need to ask MS & Apple first though |
| 21:29 | <rniwa> | i don't even know if they can change the behavior |
| 21:30 | <rniwa> | ehsan: yeah. |
| 21:30 | <rniwa> | ehsan: we'll need to ask MS & Apple first though |
| 21:30 | <rniwa> | i don't even know if they can change the behavior |
| 21:30 | <ehsan> | sadface |
| 21:30 | <rniwa> | if they have compat. issues, etc... then we can't converge it anyway |
| 21:30 | <ehsan> | yeah |
| 21:30 | <ehsan> | sadface |
| 21:30 | <rniwa> | if they have compat. issues, etc... then we can't converge it anyway |
| 21:30 | <ehsan> | yeah |
| 21:30 | <rniwa> | we should probably bring it up on public-webapps or so |
| 21:30 | <rniwa> | or directly email our friendly ms/apple folks :) |
| 21:30 | <ehsan> | fwiw, I would be fine with changing gecko if someone has a compelling argument for the alternate behavior |
| 21:31 | <rniwa> | we should probably bring it up on public-webapps or so |
| 21:31 | <rniwa> | or directly email our friendly ms/apple folks :) |
| 21:31 | <ehsan> | fwiw, I would be fine with changing gecko if someone has a compelling argument for the alternate behavior |
| 21:31 | <ehsan> | yep |
| 21:31 | <rniwa> | ehsan: you guys are lucky in that gecko isn't a part of some OS framework :) |
| 21:31 | <ehsan> | yep |
| 21:31 | <rniwa> | ehsan: you guys are lucky in that gecko isn't a part of some OS framework :) |
| 21:31 | <rniwa> | trident & webkit suffer a lot from their being part of OS frameworks :( |
| 21:31 | <ehsan> | rniwa: it will be soon! ;) |
| 21:31 | <smaug____> | walled garden behavior doesn't apply here ;) |
| 21:31 | <ehsan> | rniwa: but I don't see why that is a concern |
| 21:31 | <jdaggett> | jprmc, joe: mtg? |
| 21:31 | <smaug____> | this is about web API |
| 21:32 | <rniwa> | trident & webkit suffer a lot from their being part of OS frameworks :( |
| 21:32 | <ehsan> | rniwa: it will be soon! ;) |
| 21:32 | <smaug____> | walled garden behavior doesn't apply here ;) |
| 21:32 | <ehsan> | rniwa: but I don't see why that is a concern |
| 21:32 | <jdaggett> | jprmc, joe: mtg? |
| 21:32 | <smaug____> | this is about web API |
| 21:32 | <ehsan> | webkit can detect whether it's embedded in some apple OS thingy or not |
| 21:32 | <ehsan> | and can have different behaviors |
| 21:32 | <ehsan> | webkit can detect whether it's embedded in some apple OS thingy or not |
| 21:32 | <ehsan> | and can have different behaviors |
| 21:32 | <rniwa> | ehsan: i don't wanna do that.... there are a lot of dependencies internally in our codebase |
| 21:32 | <ehsan> | for example, gecko already does some things different for mail editing and regular web editing |
| 21:32 | <rniwa> | ehsan: and supporting two behaviors is just a nightmare |
| 21:32 | <smaug____> | that is implementation issue |
| 21:32 | <smaug____> | web api should be good |
| 21:33 | <rniwa> | ehsan: i don't wanna do that.... there are a lot of dependencies internally in our codebase |
| 21:33 | <ehsan> | for example, gecko already does some things different for mail editing and regular web editing |
| 21:33 | <smaug____> | and behavior in the web |
| 21:33 | <rniwa> | ehsan: and supporting two behaviors is just a nightmare |
| 21:33 | <smaug____> | that is implementation issue |
| 21:33 | <smaug____> | web api should be good |
| 21:33 | <smaug____> | and behavior in the web |
| 21:33 | <rniwa> | i tend to agree but there are practicality issue |
| 21:33 | <ehsan> | rniwa: I sympathize, but what I'm trying to say is that OS backwards compat is not a good argument |
| 21:33 | <rniwa> | s |
| 21:33 | <ehsan> | rniwa: web compat is, however |
| 21:33 | <rniwa> | well sure. but if nobody has a time to implement it, then our behavior won't change |
| 21:33 | <ehsan> | but I don't think this can affect web compat in any serious way |
| 21:34 | <rniwa> | i tend to agree but there are practicality issue |
| 21:34 | <rniwa> | i mean we can say that we can change the behavior |
| 21:34 | <ehsan> | rniwa: I sympathize, but what I'm trying to say is that OS backwards compat is not a good argument |
| 21:34 | <ehsan> | yeah |
| 21:34 | <rniwa> | s |
| 21:34 | <ehsan> | rniwa: web compat is, however |
| 21:34 | <rniwa> | well sure. but if nobody has a time to implement it, then our behavior won't change |
| 21:34 | <ehsan> | but I don't think this can affect web compat in any serious way |
| 21:34 | <rniwa> | i mean we can say that we can change the behavior |
| 21:34 | <ehsan> | yeah |
| 21:34 | <rniwa> | but if nobody will work on it, then it won't happen :( |
| 21:34 | <ehsan> | but that's a different issue :) |
| 21:34 | <rniwa> | but if nobody will work on it, then it won't happen :( |
| 21:34 | <ehsan> | but that's a different issue :) |
| 21:34 | <ehsan> | I think we should spec the right thing |
| 21:34 | <ehsan> | I think we should spec the right thing |
| 21:34 | <ehsan> | and don't let arcane OS level requirements hold us down |
| 21:34 | <ehsan> | whether an engine implements a spec completely and when is a different issue |
| 21:34 | <rniwa> | anyway, this whole argument won't move forward unless we can get apple/msft people to be involved |
| 21:35 | <ehsan> | and don't let arcane OS level requirements hold us down |
| 21:35 | <ehsan> | whether an engine implements a spec completely and when is a different issue |
| 21:35 | <rniwa> | anyway, this whole argument won't move forward unless we can get apple/msft people to be involved |
| 21:35 | <ehsan> | yeah, that we agree on :) |
| 21:35 | <ehsan> | yeah, that we agree on :) |
| 21:35 | <smaug____> | yeah, we should always spec the "right" thing, unless it breaks the web badly |
| 21:35 | <smaug____> | yeah, we should always spec the "right" thing, unless it breaks the web badly |
| 21:35 | <rniwa> | ehsan, smaug____: quite frankly, i'm not even sure if we need to spec this |
| 21:35 | <rniwa> | it's an UI issue so it could be left to implementors |
| 21:35 | <rniwa> | we tend not to spec UI issues in web standards as far as I know |
| 21:36 | <rniwa> | ehsan, smaug____: quite frankly, i'm not even sure if we need to spec this |
| 21:36 | <rniwa> | it's an UI issue so it could be left to implementors |
| 21:36 | <rniwa> | we tend not to spec UI issues in web standards as far as I know |
| 21:36 | <ehsan> | rniwa: wouldn't it affect the default undoScope though? |
| 21:36 | <rniwa> | ehsan: not really. |
| 21:36 | <ehsan> | rniwa: wouldn't it affect the default undoScope though? |
| 21:36 | <rniwa> | ehsan: not really. |
| 21:36 | <rniwa> | ehsan: it sort of does if user editing stuff inside input/textarea |
| 21:36 | <rniwa> | ehsan: but in that sense, gecko/opera's behavior is more problmatic |
| 21:37 | <rniwa> | ehsan: it sort of does if user editing stuff inside input/textarea |
| 21:37 | <rniwa> | ehsan: but in that sense, gecko/opera's behavior is more problmatic |
| 21:37 | <ehsan> | how so? |
| 21:37 | <rniwa> | ehsan: because setting values to input/textarea would being to the undo manager of the document |
| 21:37 | <rniwa> | ehsan: because setting values to input/textarea would being to the undo manager of the document |
| 21:37 | <rniwa> | whereas editing text inside input/textarea belong to the magic undo manager gecko/opera have for text form contorls |
| 21:37 | <ehsan> | well that depends on how it is specced |
| 21:37 | <rniwa> | so unless we somehow bound input/textarea's value to that magic undo manager |
| 21:37 | <ehsan> | setting the value can also change the undo manager for the text box |
| 21:37 | <ehsan> | if there is one |
| 21:38 | <rniwa> | whereas editing text inside input/textarea belong to the magic undo manager gecko/opera have for text form contorls |
| 21:38 | <ehsan> | well that depends on how it is specced |
| 21:38 | <rniwa> | so unless we somehow bound input/textarea's value to that magic undo manager |
| 21:38 | <ehsan> | setting the value can also change the undo manager for the text box |
| 21:38 | <ehsan> | if there is one |
| 21:38 | <rniwa> | possible. |
| 21:38 | <rniwa> | possible. |
| 21:38 | <rniwa> | but then you'll be exposing the internal undo manager... |
| 21:38 | <ehsan> | rniwa: please note that gecko doesn't really have a magic undo manager, it just creates one per input/textarea |
| 21:38 | <rniwa> | but then you'll be exposing the internal undo manager... |
| 21:38 | <ehsan> | rniwa: please note that gecko doesn't really have a magic undo manager, it just creates one per input/textarea |
| 21:38 | <ehsan> | and one for the whole page if it has a contenteditable element |
| 21:38 | <rniwa> | ehsan: right. i'm just calling it "magic" because it's invisible to scirpts |
| 21:38 | <ehsan> | ok yeah |
| 21:38 | <rniwa> | but maybe "invisible" is a better term |
| 21:38 | <ehsan> | yep |
| 21:38 | <smaug____> | rniwa: I assume input/textarea will have a separate undomanager in the spec |
| 21:38 | <rniwa> | smaug____: it doesn't |
| 21:39 | <ehsan> | and one for the whole page if it has a contenteditable element |
| 21:39 | <rniwa> | ehsan: right. i'm just calling it "magic" because it's invisible to scirpts |
| 21:39 | <ehsan> | ok yeah |
| 21:39 | <ehsan> | oh |
| 21:39 | <rniwa> | but maybe "invisible" is a better term |
| 21:39 | <ehsan> | well |
| 21:39 | <rniwa> | smaug____: nowhere in my spec does it say that |
| 21:39 | <ehsan> | yep |
| 21:39 | <smaug____> | rniwa: I assume input/textarea will have a separate undomanager in the spec |
| 21:39 | <rniwa> | smaug____: it doesn't |
| 21:39 | <ehsan> | oh |
| 21:39 | <ehsan> | well |
| 21:39 | <rniwa> | smaug____: nowhere in my spec does it say that |
| 21:39 | <ehsan> | so this _is_ a spec issue, and not merely a UI issue |
| 21:39 | <smaug____> | rniwa: or that the spec describes what an undomanager is, and HTML spec defines that input/textarea has such |
| 21:39 | <ehsan> | so this _is_ a spec issue, and not merely a UI issue |
| 21:39 | <smaug____> | rniwa: or that the spec describes what an undomanager is, and HTML spec defines that input/textarea has such |
| 21:39 | <rniwa> | smaug____: maybe. |
| 21:39 | <rniwa> | ehsan: sort of. |
| 21:39 | <ehsan> | yeah that makes sense to me |
| 21:40 | <rniwa> | smaug____: maybe. |
| 21:40 | <rniwa> | ehsan: sort of. |
| 21:40 | <ehsan> | yeah that makes sense to me |
| 21:40 | <smaug____> | also, should each contenteditable areas have own undomanager |
| 21:40 | <smaug____> | I think so |
| 21:40 | <rniwa> | ehsan: as it stands, value is tied to document's undo manager |
| 21:40 | <rniwa> | ehsan, smaug____: a bigger problem is with execCommand('undo') |
| 21:40 | <smaug____> | also, should each contenteditable areas have own undomanager |
| 21:40 | <smaug____> | I think so |
| 21:40 | <rniwa> | ehsan: as it stands, value is tied to document's undo manager |
| 21:40 | <rniwa> | ehsan, smaug____: a bigger problem is with execCommand('undo') |
| 21:40 | <smaug____> | so, that is designMode document then |
| 21:40 | <rniwa> | ehsan, smaug____: that currently undoes actions inside textarea/input at least on webkit |
| 21:40 | <rniwa> | don't know what gecko/msie do |
| 21:40 | <rniwa> | smaug____: no |
| 21:41 | <smaug____> | so, that is designMode document then |
| 21:41 | <rniwa> | ehsan, smaug____: that currently undoes actions inside textarea/input at least on webkit |
| 21:41 | <rniwa> | don't know what gecko/msie do |
| 21:41 | <rniwa> | smaug____: no |
| 21:41 | <rniwa> | smaug____: contenteditable and undo scope are separate |
| 21:41 | <rniwa> | smaug____: contenteditable and undo scope are separate |
| 21:41 | <rniwa> | smaug____: otherwise, you can't have multiple content editable regions that share the same undo manager |
| 21:41 | <rniwa> | smaug____: which is desirable for spreadsheet apps and others |
| 21:41 | <ehsan> | rniwa: I think gecko applies that command to the contenteditable stuff on the page and not the text box |
| 21:41 | <ehsan> | (not tested) |
| 21:42 | <rniwa> | smaug____: otherwise, you can't have multiple content editable regions that share the same undo manager |
| 21:42 | <rniwa> | smaug____: which is desirable for spreadsheet apps and others |
| 21:42 | <ehsan> | rniwa: I think gecko applies that command to the contenteditable stuff on the page and not the text box |
| 21:42 | <ehsan> | (not tested) |
| 21:42 | <smaug____> | ah, that is possible |
| 21:42 | <smaug____> | ah, that is possible |
| 21:43 | <rniwa> | ehsan: yeah gecko doesn't undo stuff inside text fields |
| 21:44 | <rniwa> | ehsan: yeah gecko doesn't undo stuff inside text fields |
| 21:44 | <ehsan> | at least that is what the code intends to happen ;) |
| 21:44 | rniwa | tests msier |
| 21:44 | <ehsan> | at least that is what the code intends to happen ;) |
| 21:44 | rniwa | tests msier |
| 21:44 | <rniwa> | msie* |
| 21:45 | <rniwa> | msie* |
| 21:45 | <smaug____> | (and connection to dns server died ( ) |
| 21:45 | <smaug____> | (and connection to dns server died ( ) |
| 21:45 | <rniwa> | ehsan: msie does undo in text fields |
| 21:46 | <rniwa> | ehsan: msie does undo in text fields |
| 21:46 | <ehsan> | :/ |
| 21:46 | <ehsan> | :/ |
| 21:46 | <ehsan> | this stuff is a mess in general |
| 21:47 | <ehsan> | this stuff is a mess in general |
| 21:47 | <rniwa> | ehsan: yup |
| 21:47 | <rniwa> | ehsan: yup |
| 21:47 | <rniwa> | ehsan: maybe we should standardize it :( |
| 21:47 | <rniwa> | AryehGregor: what do you think, Aryeh? |
| 21:47 | <AryehGregor> | About which? |
| 21:47 | ehsan | dies a little bit inside |
| 21:47 | <rniwa> | AryehGregor: standariziging undo behavior |
| 21:47 | <AryehGregor> | I'm in favor, of course! |
| 21:48 | <rniwa> | ehsan: maybe we should standardize it :( |
| 21:48 | <rniwa> | AryehGregor: what do you think, Aryeh? |
| 21:48 | <AryehGregor> | Easy to say. :) |
| 21:48 | <AryehGregor> | About which? |
| 21:48 | ehsan | dies a little bit inside |
| 21:48 | <rniwa> | AryehGregor: standariziging undo behavior |
| 21:48 | <AryehGregor> | I'm in favor, of course! |
| 21:48 | <AryehGregor> | Easy to say. :) |
| 21:48 | <rniwa> | AryehGregor: right now, msie/webkit undo things inside text fields by execCommand('undo') |
| 21:48 | <rniwa> | AryehGregor: right now, msie/webkit undo things inside text fields by execCommand('undo') |
| 21:48 | <rniwa> | AryehGregor: but gecko (and presumably) and opera don't |
| 21:48 | <rniwa> | AryehGregor, ehsan: but this behavior might be dependent by some legacy contents though |
| 21:48 | <AryehGregor> | execCommand("undo") should behave exactly the same as hitting Ctrl-Z, IMO. |
| 21:48 | <rniwa> | i mean being able to undo things in text fields seems like a useful API |
| 21:48 | <AryehGregor> | To the extent feasible. |
| 21:49 | <rniwa> | AryehGregor: but gecko (and presumably) and opera don't |
| 21:49 | <rniwa> | AryehGregor, ehsan: but this behavior might be dependent by some legacy contents though |
| 21:49 | <AryehGregor> | execCommand("undo") should behave exactly the same as hitting Ctrl-Z, IMO. |
| 21:49 | <rniwa> | i mean being able to undo things in text fields seems like a useful API |
| 21:49 | <AryehGregor> | To the extent feasible. |
| 21:49 | <rniwa> | AryehGregor: that's what all browsers do |
| 21:49 | <rniwa> | AryehGregor: that's what all browsers do |
| 21:49 | <AryehGregor> | Well, Gecko likes to throw if there's no editable content on the page. |
| 21:49 | <rniwa> | AryehGregor: and the behavior is different between msie/webkit and gecko/opera |
| 21:49 | <AryehGregor> | Well, Gecko likes to throw if there's no editable content on the page. |
| 21:49 | <rniwa> | AryehGregor: and the behavior is different between msie/webkit and gecko/opera |
| 21:49 | <rniwa> | AryehGregor: because msie/webkit share the same undo manager across the entire page whereas gecko/opera have separate undo managers for each form text control |
| 21:50 | <rniwa> | AryehGregor: because msie/webkit share the same undo manager across the entire page whereas gecko/opera have separate undo managers for each form text control |
| 21:50 | <AryehGregor> | Oh. |
| 21:50 | <AryehGregor> | Oh. |
| 21:50 | <AryehGregor> | Fun. |
| 21:50 | <smaug____> | execCommand('undo') could use the most recently used undomanager in the page |
| 21:51 | <AryehGregor> | Fun. |
| 21:51 | smaug____ | lost some context...looking at logs |
| 21:51 | <smaug____> | execCommand('undo') could use the most recently used undomanager in the page |
| 21:51 | smaug____ | lost some context...looking at logs |
| 21:52 | <rniwa> | smaug____: but the problem is that "the most recently used undomanager" is different depending on the browser :) |
| 21:52 | <rniwa> | smaug____: but the problem is that "the most recently used undomanager" is different depending on the browser :) |
| 21:52 | <rniwa> | AryehGregor: yeah.... |
| 21:52 | <AryehGregor> | What does Ctrl-Z do? Probably it picks the undo manager based on what's focused, right? |
| 21:53 | <rniwa> | AryehGregor: yeah.... |
| 21:53 | <AryehGregor> | What does Ctrl-Z do? Probably it picks the undo manager based on what's focused, right? |
| 21:53 | <AryehGregor> | Why can't execCommand() do that? |
| 21:53 | <AryehGregor> | Why can't execCommand() do that? |
| 21:53 | <smaug____> | rniwa: well, you need to just fix IE and webkit ;) |
| 21:53 | <rniwa> | AryehGregor: no |
| 21:53 | <rniwa> | AryehGregor: no |
| 21:53 | <AryehGregor> | :/ |
| 21:53 | <rniwa> | AryehGregor: it undoes the last editing action on the page |
| 21:53 | <AryehGregor> | :/ |
| 21:53 | <rniwa> | AryehGregor: it undoes the last editing action on the page |
| 21:53 | <rniwa> | smaug____: the question is whether we can change our behavior or not. |
| 21:54 | <rniwa> | smaug____: the question is whether we can change our behavior or not. |
| 21:54 | <rniwa> | smaug____: also there might be a good reason MSIE/WebKit do it this way |
| 21:54 | <rniwa> | smaug____: also there might be a good reason MSIE/WebKit do it this way |
| 21:54 | <rniwa> | i just don't know the history enough to give you any meaningful answer |
| 21:54 | <rniwa> | i just don't know the history enough to give you any meaningful answer |
| 21:54 | <smaug____> | rniwa: I haven't seen any gecko bug reports about its behavior |
| 21:54 | <rniwa> | smaug____: intuitively, either behavior is fine. |
| 21:54 | <rniwa> | user would just get used to it :) |
| 21:55 | <smaug____> | rniwa: I haven't seen any gecko bug reports about its behavior |
| 21:55 | <rniwa> | smaug____: intuitively, either behavior is fine. |
| 21:55 | <rniwa> | user would just get used to it :) |
| 21:55 | <smaug____> | and also, IE/webkit behavior just feels odd. But sure, if there is plenty of web content which relies on it ... |
| 21:55 | <smaug____> | and also, IE/webkit behavior just feels odd. But sure, if there is plenty of web content which relies on it ... |
| 21:55 | <rniwa> | smaug____, AryehGregor: my gut tells me there are quite few IE-specific contents that rely on this behavior |
| 21:56 | <rniwa> | smaug____, AryehGregor: my gut tells me there are quite few IE-specific contents that rely on this behavior |
| 21:56 | <rniwa> | anyway, it seems like the right strategy is to bring it up on public-webapps |
| 21:56 | <smaug____> | yeah |
| 21:56 | <rniwa> | anyway, it seems like the right strategy is to bring it up on public-webapps |
| 21:56 | <smaug____> | yeah |
| 21:59 | <rniwa> | smaug____, AryehGregor, ehsan: anyway, i've got to tell you that implementing undo manager spec turned out to be much harder than I had imagined :( |
| 22:00 | <rniwa> | as i said there are very interesting GC implications |
| 22:00 | <rniwa> | as i said there are very interesting GC implications |
| 22:00 | <smaug____> | rniwa: what kinds of GC implications ? |
| 22:00 | <rniwa> | and there are lots of edge cases, including the nested transactions, that we hadn't thought through well |
| 22:00 | <rniwa> | smaug____: basically, it needs to be treated like event handlers |
| 22:01 | <smaug____> | rniwa: what kinds of GC implications ? |
| 22:01 | <rniwa> | and there are lots of edge cases, including the nested transactions, that we hadn't thought through well |
| 22:01 | <rniwa> | smaug____: basically, it needs to be treated like event handlers |
| 22:01 | <rniwa> | smaug____: because dom transaction objects can outlive script context :( |
| 22:01 | <rniwa> | smaug____: because dom transaction objects can outlive script context :( |
| 22:01 | <smaug____> | (I guess I should review the draft, and r- if it has only one undomanager per document. ) |
| 22:01 | <rniwa> | smaug____: it'll add undo manager on all elements that have undoScope content attribute :) |
| 22:02 | <smaug____> | (I guess I should review the draft, and r- if it has only one undomanager per document. ) |
| 22:02 | <rniwa> | smaug____: or when undoScope DOM attribute is set true |
| 22:02 | <rniwa> | smaug____: it'll add undo manager on all elements that have undoScope content attribute :) |
| 22:02 | <rniwa> | smaug____: or when undoScope DOM attribute is set true |
| 22:02 | <smaug____> | rniwa: I'm not sure event listener behavior is spec'ed that clearly |
| 22:02 | <smaug____> | rniwa: I'm not sure event listener behavior is spec'ed that clearly |
| 22:02 | <smaug____> | in case the script context dies |
| 22:03 | <smaug____> | in case the script context dies |
| 22:03 | <smaug____> | in any case, I don't actually know how webkit does all the GCing |
| 22:03 | <smaug____> | in any case, I don't actually know how webkit does all the GCing |
| 22:03 | <rniwa> | smaug____: that's why "interesting" :( |
| 22:03 | <smaug____> | in Gecko undomanager would be just cycle collectable object, holding possibly some JS objects |
| 22:04 | <rniwa> | smaug____: that's why "interesting" :( |
| 22:04 | <smaug____> | in Gecko undomanager would be just cycle collectable object, holding possibly some JS objects |
| 22:04 | <smaug____> | a GC isn't enough for Gecko, it needs also a CC :) |
| 22:05 | <smaug____> | a GC isn't enough for Gecko, it needs also a CC :) |
| 22:05 | <rniwa> | smaug____: what's CC? |
| 22:05 | <smaug____> | cycle collector |
| 22:05 | <rniwa> | huh |
| 22:05 | <rniwa> | smaug____: what's cycle collector? |
| 22:06 | <rniwa> | smaug____: what's CC? |
| 22:06 | <smaug____> | cycle collector |
| 22:06 | <rniwa> | huh |
| 22:06 | <rniwa> | smaug____: what's cycle collector? |
| 22:06 | <rniwa> | smaug____: does it collect objects with cycles in them? |
| 22:06 | <rniwa> | smaug____: does it collect objects with cycles in them? |
| 22:06 | <smaug____> | it is for reference counted objects |
| 22:06 | <rniwa> | i see |
| 22:07 | <smaug____> | it is for reference counted objects |
| 22:07 | <rniwa> | i see |
| 22:07 | <smaug____> | CC and GC do in principle the same thing |
| 22:07 | <smaug____> | CC and GC do in principle the same thing |
| 22:07 | <smaug____> | GC handles live objects, CC tries to find to-be-deleted objects |
| 22:07 | <smaug____> | kind of |
| 22:08 | <smaug____> | GC handles live objects, CC tries to find to-be-deleted objects |
| 22:08 | <smaug____> | kind of |
| 22:09 | <rniwa> | i see. |
| 22:09 | rniwa | isn't familiar with gecko's GC |
| 22:10 | <rniwa> | i see. |
| 22:10 | rniwa | isn't familiar with gecko's GC |
| 22:10 | <smaug____> | Spidermonkey has GC, Gecko has CC |
| 22:11 | <smaug____> | Spidermonkey has GC, Gecko has CC |
| 22:11 | <gavin> | CC is a solution to the problem caused by refcounted objects interacting with GCed objects and creating cycles |
| 22:12 | <gavin> | CC is a solution to the problem caused by refcounted objects interacting with GCed objects and creating cycles |
| 22:12 | <smaug____> | CC is also a solution for cycles which don't involve GCed objects at all. |
| 22:13 | <smaug____> | CC is also a solution for cycles which don't involve GCed objects at all. |
| 22:13 | <gavin> | true |
| 22:13 | <gavin> | true |
| 22:16 | <rniwa> | smaug____, gavin: interesting |
| 22:16 | <rniwa> | i don't think webkit has tht |
| 22:16 | <rniwa> | that* |
| 22:16 | <rniwa> | so we have to use clever tricks to avoid cycles :( |
| 22:16 | <rniwa> | smaug____, gavin: interesting |
| 22:16 | <rniwa> | i don't think webkit has tht |
| 22:16 | <rniwa> | that* |
| 22:16 | <rniwa> | so we have to use clever tricks to avoid cycles :( |
| 22:19 | <ehsan> | rniwa: how well do they work in practice? |
| 22:20 | <ehsan> | rniwa: how well do they work in practice? |
| 22:23 | <rniwa> | ehsan: i don't know |
| 22:23 | <rniwa> | i'm not an expert in that area |
| 22:24 | <rniwa> | ehsan: i don't know |
| 22:24 | <rniwa> | i'm not an expert in that area |
| 22:28 | <rniwa> | ehsan: you should ask othermaciej :) |
| 22:29 | <rniwa> | ehsan: you should ask othermaciej :) |
| 22:29 | <rniwa> | ehsan: we were just talking about callback interface yesterday |
| 22:29 | <rniwa> | ehsan: he seemed knowledgable in this rea |
| 22:29 | <rniwa> | area* |
| 22:29 | <rniwa> | ehsan: we were just talking about callback interface yesterday |
| 22:29 | <rniwa> | ehsan: he seemed knowledgable in this rea |
| 22:29 | <rniwa> | area* |
| 22:33 | <othermaciej> | rniwa: I actually don't understand how it historically works, but I think the general approach is to teach GC how to find relevant GC roots from the document so that there is no need to GC protect GC objects references from refcounted objects |
| 22:33 | <othermaciej> | rniwa: I actually don't understand how it historically works, but I think the general approach is to teach GC how to find relevant GC roots from the document so that there is no need to GC protect GC objects references from refcounted objects |
| 22:33 | <othermaciej> | s/historically/currently/ |
| 22:34 | <othermaciej> | s/historically/currently/ |
| 22:37 | <rniwa> | othermaciej: you mean reachable* functions? |
| 22:38 | <rniwa> | othermaciej: you mean reachable* functions? |
| 22:38 | <othermaciej> | I don't know enough to relate it to code |
| 22:39 | <othermaciej> | I don't know enough to relate it to code |
| 23:52 | <smaug____> | rniwa: ping |
| 23:53 | <rniwa> | smaug____: pong |
| 23:53 | <rniwa> | smaug____: pong |
| 23:53 | <smaug____> | rniwa: (haven't read your draft yet..) so when is transact callback called, and why |
| 23:53 | <smaug____> | er |
| 23:53 | smaug____ | is reading this wrong |
| 23:53 | <rniwa> | smaug____: one of them is called immediately (execute/executeAutomatic) |
| 23:54 | <smaug____> | rniwa: (haven't read your draft yet..) so when is transact callback called, and why |
| 23:54 | <smaug____> | er |
| 23:54 | smaug____ | is reading this wrong |
| 23:54 | <rniwa> | smaug____: one of them is called immediately (execute/executeAutomatic) |
| 23:54 | <rniwa> | smaug____: undo/redo are called when undo/redo are involked |
| 23:54 | <rniwa> | smaug____: undo/redo are called when undo/redo are involked |
| 23:56 | <smaug____> | rniwa: so transact() adds something to the stack? |
| 23:57 | <smaug____> | rniwa: so transact() adds something to the stack? |
| 23:57 | <smaug____> | and then at some point the executeAutomatic of that object is called= |
| 23:57 | <rniwa> | smaug____: right. |
| 23:57 | <smaug____> | and then at some point the executeAutomatic of that object is called= |
| 23:57 | <rniwa> | smaug____: right. |
| 23:57 | <smaug____> | s/=/?/ |
| 23:57 | <rniwa> | smaug____: well executeAutomatic is called immediately |
| 23:57 | <rniwa> | smaug____: but UA records what happened happened and fixes it later |
| 23:57 | <rniwa> | smaug____: so executeAutomatic case is quite simple |
| 23:57 | <rniwa> | smaug____: tricky one is when things are manual |
| 23:58 | <smaug____> | s/=/?/ |
| 23:58 | <rniwa> | smaug____: well executeAutomatic is called immediately |
| 23:58 | <rniwa> | smaug____: but UA records what happened happened and fixes it later |
| 23:58 | <rniwa> | smaug____: so executeAutomatic case is quite simple |
| 23:58 | <rniwa> | smaug____: tricky one is when things are manual |
| 23:58 | <rniwa> | smaug____: we then have to call undo/redo much later when undo/redo are actually done |
| 23:58 | <rniwa> | smaug____: we then have to call undo/redo much later when undo/redo are actually done |
| 23:58 | <smaug____> | but ok, I should read the draft... |
| 23:58 | <smaug____> | I just started to think if there was any use for microtasks here. |
| 23:58 | <smaug____> | but probably not |
| 23:59 | <smaug____> | but ok, I should read the draft... |
| 23:59 | <smaug____> | I just started to think if there was any use for microtasks here. |
| 23:59 | <smaug____> | but probably not |
| 23:59 | <smaug____> | (I saw the email about nested transactions) |
| 23:59 | <smaug____> | (I saw the email about nested transactions) |