| 03:12 | <ferret__> | hello |
| 03:13 | <ferret__> | hello |
| 04:55 | <MikeSmith> | Hixie: I updated the dates in the boilerplate files |
| 04:56 | <MikeSmith> | so if you could please push to W3C so those get rebuilt I'd appreciate it |
| 04:56 | <MikeSmith> | so if you could please push to W3C so those get rebuilt I'd appreciate it |
| 05:25 | <zcorpan> | Hixie: maybe try to fiddle with word-spacing |
| 05:26 | <zcorpan> | Hixie: maybe try to fiddle with word-spacing |
| 05:26 | <Hixie> | MikeSmith: i'm mid-way through a ridiculously involved edit right now but should be able to do that monday - is that ok? |
| 05:26 | <Hixie> | MikeSmith: (if not i can do it sooner but it's a pain to back things out then push them back in again) |
| 05:26 | <Hixie> | MikeSmith: i'm mid-way through a ridiculously involved edit right now but should be able to do that monday - is that ok? |
| 05:26 | <Hixie> | MikeSmith: (if not i can do it sooner but it's a pain to back things out then push them back in again) |
| 05:27 | <Hixie> | zcorpan: yeah, i should try that |
| 05:27 | <Hixie> | zcorpan: yeah, i should try that |
| 05:27 | <MikeSmith> | Hixie: Monday is fine |
| 05:28 | <MikeSmith> | Hixie: Monday is fine |
| 05:28 | <MikeSmith> | we publish on Tuesday |
| 05:28 | <Hixie> | k |
| 05:28 | <MikeSmith> | we publish on Tuesday |
| 05:28 | <Hixie> | k |
| 14:06 | <annevk> | hsivonen: we can just follow http://dvcs.w3.org/hg/encoding/raw-file/tip/Overview.html no? |
| 14:06 | <annevk> | hsivonen: if we are going to support other encodings, might as well support the same set we support through other APIs |
| 14:07 | <annevk> | hsivonen: we can just follow http://dvcs.w3.org/hg/encoding/raw-file/tip/Overview.html no? |
| 14:07 | <annevk> | hsivonen: if we are going to support other encodings, might as well support the same set we support through other APIs |
| 14:07 | <annevk> | hsivonen: my plan is for them all to converge anyway |
| 14:07 | <annevk> | hsivonen: my plan is for them all to converge anyway |
| 14:10 | <hsivonen> | annevk: ok |
| 14:10 | <hsivonen> | annevk: ok |
| 14:44 | <smaug____> | hmm, where is this handling for callbacks defined... |
| 14:45 | <smaug____> | hmm, where is this handling for callbacks defined... |
| 16:46 | <Stalker[lv]> | Hello, all! I've got a problem validating my webpage with one meta tag. Does w3c validator looks in whatwg's wiki when validating html5 page? |
| 16:46 | <Stalker[lv]> | Hello, all! I've got a problem validating my webpage with one meta tag. Does w3c validator looks in whatwg's wiki when validating html5 page? |
| 16:47 | <MikeSmith> | Stalker[lv]: no the meta checking is hard-coded |
| 16:47 | <MikeSmith> | for now at least |
| 16:47 | <MikeSmith> | Stalker[lv]: no the meta checking is hard-coded |
| 16:47 | <MikeSmith> | for now at least |
| 16:47 | <MikeSmith> | when something new gets registered and there's clearly agreement about it, somebody adds it to the validator |
| 16:48 | <MikeSmith> | when something new gets registered and there's clearly agreement about it, somebody adds it to the validator |
| 16:48 | <MikeSmith> | is there are specific value you're using that it's flagging as an error? |
| 16:48 | <MikeSmith> | is there are specific value you're using that it's flagging as an error? |
| 16:50 | <Stalker[lv]> | it's metatag, which tells to skype toolbar not to add ugly "call via skype" links |
| 16:50 | <Stalker[lv]> | it's metatag, which tells to skype toolbar not to add ugly "call via skype" links |
| 16:50 | <Stalker[lv]> | <meta name="SKYPE_TOOLBAR" CONTENT="SKYPE_TOOLBAR_PARSER_COMPATIBLE"> |
| 16:51 | <Stalker[lv]> | <meta name="SKYPE_TOOLBAR" CONTENT="SKYPE_TOOLBAR_PARSER_COMPATIBLE"> |
| 16:52 | <Stalker[lv]> | tried to use JS+jQuery skype remover, but it doesn't work with all skype toolbar versions, so I have to use this tag. Also, there's place for "valid html" badge :) |
| 16:52 | <Stalker[lv]> | tried to use JS+jQuery skype remover, but it doesn't work with all skype toolbar versions, so I have to use this tag. Also, there's place for "valid html" badge :) |
| 16:52 | <MikeSmith> | Stalker[lv]: so if there is a spec somewhere for that this "SKYPE_TOOLBAR" thing is, then you have a start on it possibly being register-able |
| 16:53 | <MikeSmith> | Stalker[lv]: so if there is a spec somewhere for that this "SKYPE_TOOLBAR" thing is, then you have a start on it possibly being register-able |
| 16:53 | <MikeSmith> | but if there is no spec anywhere, then there's no good way for people to be able to know how to use interoperably |
| 16:54 | <MikeSmith> | but if there is no spec anywhere, then there's no good way for people to be able to know how to use interoperably |
| 16:57 | <AryehGregor> | Hmm, so a failed script load fires an error event, and it bubbles in Gecko but not WebKit/Presto. |
| 16:57 | <AryehGregor> | Spec says it shouldn't bubble. |
| 16:57 | AryehGregor | tests IE |
| 16:58 | <AryehGregor> | Hmm, so a failed script load fires an error event, and it bubbles in Gecko but not WebKit/Presto. |
| 16:58 | <AryehGregor> | Spec says it shouldn't bubble. |
| 16:58 | AryehGregor | tests IE |
| 16:58 | <AryehGregor> | Nope, doesn't bubble in IE either. |
| 16:58 | <AryehGregor> | Nope, doesn't bubble in IE either. |
| 16:58 | <AryehGregor> | Why doesn't it bubble? Bubbling seems useful here. Exceptions hit window.onerror, so a failed script load logically may as well too, no? |
| 16:59 | <AryehGregor> | Why doesn't it bubble? Bubbling seems useful here. Exceptions hit window.onerror, so a failed script load logically may as well too, no? |
| 17:00 | <AryehGregor> | Nobody seems to fire error events for failed stylesheet loads. :( |
| 17:01 | <AryehGregor> | Nobody seems to fire error events for failed stylesheet loads. :( |
| 17:10 | <Stalker[lv]> | MikeSmith, https://jira.skype.com/browse/SCW-65 - there's mention of this tag. also in wiki is link to atricle about it.. |
| 17:11 | <Stalker[lv]> | MikeSmith, https://jira.skype.com/browse/SCW-65 - there's mention of this tag. also in wiki is link to atricle about it.. |
| 17:11 | MikeSmith | looks |
| 17:11 | MikeSmith | looks |
| 17:12 | <MikeSmith> | Stalker[lv]: in what wiki? |
| 17:12 | <MikeSmith> | Stalker[lv]: in what wiki? |
| 17:12 | <MikeSmith> | Stalker[lv]: anyway if you wanted to take the time you could write up an actual spec for it yourself |
| 17:13 | <MikeSmith> | that's what others have done for some similar cases |
| 17:13 | <MikeSmith> | you could add it to the whatwg wiki |
| 17:13 | <MikeSmith> | that's what others have done for some similar cases |
| 17:13 | <MikeSmith> | you could add it to the whatwg wiki |
| 17:14 | <MikeSmith> | like this: http://wiki.whatwg.org/wiki/Meta_referrer |
| 17:14 | <MikeSmith> | like this: http://wiki.whatwg.org/wiki/Meta_referrer |
| 17:20 | <TabAtkins> | jwheare: The spec was actually inspired by a relatively similar JS implementation, where we just built a layout in using position:absolute hooked up to a constraint solver. |
| 17:20 | <TabAtkins> | jwheare: I can ask if it's releasable code. |
| 17:20 | <TabAtkins> | jwheare: The spec was actually inspired by a relatively similar JS implementation, where we just built a layout in using position:absolute hooked up to a constraint solver. |
| 17:20 | <TabAtkins> | jwheare: I can ask if it's releasable code. |
| 17:20 | <jwheare> | TabAtkins: yeah, alex showed me it i think. he mentioned it was internal |
| 17:21 | <jwheare> | TabAtkins: yeah, alex showed me it i think. he mentioned it was internal |
| 17:21 | <TabAtkins> | Yup. |
| 17:21 | <TabAtkins> | That doesn't mean it's secret, just that I think we have to file something with the open-source people if we want to release it. |
| 17:21 | <TabAtkins> | Yup. |
| 17:21 | <TabAtkins> | That doesn't mean it's secret, just that I think we have to file something with the open-source people if we want to release it. |
| 17:22 | <jwheare> | would be good to play around with it. i'm basically gonna need to implement something like it for irccloud |
| 17:22 | <jwheare> | would be good to play around with it. i'm basically gonna need to implement something like it for irccloud |
| 17:25 | <TabAtkins> | I'll ask about it and get back to you. |
| 17:25 | <TabAtkins> | I'll ask about it and get back to you. |
| 17:31 | <AryehGregor> | Oh, wait, people do fire error events for failed stylesheet loads, good. |
| 17:31 | <AryehGregor> | Oh, wait, people do fire error events for failed stylesheet loads, good. |
| 18:31 | <aklein> | smaug____: yt? |
| 18:31 | <aklein> | smaug____: yt? |
| 18:34 | <smaug____> | aklein: yes |
| 18:34 | <smaug____> | though, just going out |
| 18:34 | <smaug____> | aklein: yes |
| 18:34 | <smaug____> | though, just going out |
| 18:34 | <smaug____> | (in 5 mins) |
| 18:34 | <aklein> | smaug____: k, I was just going to try one more time :) |
| 18:35 | <smaug____> | (in 5 mins) |
| 18:35 | <aklein> | smaug____: k, I was just going to try one more time :) |
| 18:35 | <smaug____> | to convince case-insensitive filtering? |
| 18:35 | <smaug____> | to convince case-insensitive filtering? |
| 18:35 | <smaug____> | IMO it is simpler without it |
| 18:35 | <aklein> | smaug____: yeah...consider a hypothetical future webdev who observes HREF and then calls setAttribute('HREF', someURL). I claim they'll be surprised. |
| 18:35 | <aklein> | the implementation is certainly simpler |
| 18:36 | <smaug____> | IMO it is simpler without it |
| 18:36 | <aklein> | smaug____: yeah...consider a hypothetical future webdev who observes HREF and then calls setAttribute('HREF', someURL). I claim they'll be surprised. |
| 18:36 | <aklein> | the implementation is certainly simpler |
| 18:36 | <aklein> | but the HTML dom world very much behaves as if it were case insensitive. |
| 18:36 | <aklein> | but the HTML dom world very much behaves as if it were case insensitive. |
| 18:36 | <smaug____> | aklein: well, they they are surprised even with the current APIs |
| 18:36 | <smaug____> | Attr.name is lowercase |
| 18:36 | <aklein> | heh |
| 18:37 | <smaug____> | aklein: well, they they are surprised even with the current APIs |
| 18:37 | <smaug____> | Attr.name is lowercase |
| 18:37 | <aklein> | heh |
| 18:38 | <aklein> | yet Element.tagName is uppercase |
| 18:38 | <aklein> | yet Element.tagName is uppercase |
| 18:38 | <aklein> | yet getElementsByTagName('div') works just fine |
| 18:38 | <smaug____> | this is a new API and we don't need to complicate it with special cases |
| 18:39 | <aklein> | yet getElementsByTagName('div') works just fine |
| 18:39 | <smaug____> | this is a new API and we don't need to complicate it with special cases |
| 18:39 | <smaug____> | getElementsByTagName is ancient, so that can't be changed |
| 18:39 | <smaug____> | getElementsByTagName is ancient, so that can't be changed |
| 18:40 | <smaug____> | .tagName is lowercase |
| 18:40 | <smaug____> | er |
| 18:40 | <smaug____> | it is whatever what used when creating the element |
| 18:40 | <smaug____> | .tagName is lowercase |
| 18:40 | <smaug____> | er |
| 18:40 | <smaug____> | it is whatever what used when creating the element |
| 18:40 | <smaug____> | s/what/was/ |
| 18:40 | <smaug____> | so, .tagName is case-sensitive |
| 18:40 | <aklein> | smaug____: nope: http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#dom-element-tagname |
| 18:41 | <smaug____> | s/what/was/ |
| 18:41 | <smaug____> | so, .tagName is case-sensitive |
| 18:41 | <aklein> | smaug____: nope: http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#dom-element-tagname |
| 18:41 | <smaug____> | ah, is the spec wrong :) |
| 18:41 | <smaug____> | anyway, that is all legacy |
| 18:41 | <smaug____> | ah, is the spec wrong :) |
| 18:41 | <smaug____> | anyway, that is all legacy |
| 18:41 | <smaug____> | we don't have to ruin the API with legacy stugg |
| 18:41 | <smaug____> | stuff |
| 18:42 | <smaug____> | we don't have to ruin the API with legacy stugg |
| 18:42 | <smaug____> | stuff |
| 18:42 | <aklein> | but MutationObservers have to live in the same world as all the legacy stuff, so it seems weird to make them behave differently |
| 18:42 | <aklein> | but MutationObservers have to live in the same world as all the legacy stuff, so it seems weird to make them behave differently |
| 18:42 | <aklein> | ah well, I'll let you go for now |
| 18:42 | <smaug____> | I want MutationObservers to behave the way rest of the world |
| 18:43 | <aklein> | ah well, I'll let you go for now |
| 18:43 | <smaug____> | I want MutationObservers to behave the way rest of the world |
| 18:43 | <smaug____> | Attr.name is lowercase in HTML docs |
| 18:43 | smaug____ | runs |
| 18:43 | <smaug____> | Attr.name is lowercase in HTML docs |
| 18:43 | smaug____ | runs |
| 18:45 | <smaug____> | aklein: oh, indeed .tagName is uppercase. I was accidentally testing xhtml doc :/ |
| 18:45 | <smaug____> | now I really run |
| 18:45 | <smaug____> | aklein: oh, indeed .tagName is uppercase. I was accidentally testing xhtml doc :/ |
| 18:45 | <smaug____> | now I really run |
| 18:45 | <smaug____> | back later |
| 18:46 | <smaug____> | back later |
| 18:53 | <AryehGregor> | Is the fact that browsers fire a bubbling error event at scripts with uncaught exceptions documented? I don't see it glancing at HTML. |
| 18:54 | <AryehGregor> | Is the fact that browsers fire a bubbling error event at scripts with uncaught exceptions documented? I don't see it glancing at HTML. |
| 19:07 | <smaugN900> | aklein: case-sensitive is also compatible with current DOMAttrModified with which one needs to filter using attr nodes |
| 19:07 | <smaugN900> | aklein: case-sensitive is also compatible with current DOMAttrModified with which one needs to filter using attr nodes |
| 20:02 | <AryehGregor> | Given a <script>, there's no way to tell whether it's run successfully yet or not, right? |
| 20:02 | <AryehGregor> | Meaning, if I do document.querySelectorAll("script") or something, I can't figure out which (if any) haven't run yet. |
| 20:02 | <AryehGregor> | Or never ran at all, e.g., had errors. |
| 20:02 | <AryehGregor> | Given a <script>, there's no way to tell whether it's run successfully yet or not, right? |
| 20:02 | <AryehGregor> | Meaning, if I do document.querySelectorAll("script") or something, I can't figure out which (if any) haven't run yet. |
| 20:02 | <AryehGregor> | Or never ran at all, e.g., had errors. |
| 20:02 | <TabAtkins> | Besides having the script alter itself at the end of running, right? |
| 20:03 | <TabAtkins> | Besides having the script alter itself at the end of running, right? |
| 20:03 | <AryehGregor> | Right, I don't want to modify the scripts themselves. |
| 20:03 | <AryehGregor> | (since there are zillions) |
| 20:03 | <AryehGregor> | Right, I don't want to modify the scripts themselves. |
| 20:03 | <AryehGregor> | (since there are zillions) |
| 20:03 | <TabAtkins> | Then no clue. |
| 20:04 | <TabAtkins> | Then no clue. |
| 20:04 | <AryehGregor> | Hmm, afterscriptexecute bubbles. |
| 20:04 | <AryehGregor> | Maybe I could use that. |
| 20:04 | <AryehGregor> | Hmm, afterscriptexecute bubbles. |
| 20:04 | <AryehGregor> | Maybe I could use that. |
| 20:04 | <AryehGregor> | With a capturing event listener. |
| 20:05 | <AryehGregor> | With a capturing event listener. |
| 20:05 | <AryehGregor> | Won't help for scripts that have already run, of course. |
| 20:06 | <AryehGregor> | Won't help for scripts that have already run, of course. |
| 20:06 | <Hixie> | AryehGregor: change their contents and reinsert them into the dom; if they do anything then they weren't run. :-) |
| 20:07 | <Hixie> | AryehGregor: change their contents and reinsert them into the dom; if they do anything then they weren't run. :-) |
| 20:07 | <Hixie> | AryehGregor: (the key being a <script> can only run once) |
| 20:07 | <Hixie> | AryehGregor: (the key being a <script> can only run once) |
| 20:07 | <AryehGregor> | Hixie, so something like: script.textContent = "alert('bad')"; var nextSibling = script.nextSibling; script.parentNode.removeChild(script); script.insertBefore(script, nextSibling); ? |
| 20:08 | <AryehGregor> | Hixie, so something like: script.textContent = "alert('bad')"; var nextSibling = script.nextSibling; script.parentNode.removeChild(script); script.insertBefore(script, nextSibling); ? |
| 20:08 | <AryehGregor> | And unset the src. |
| 20:08 | <AryehGregor> | That's kind of evil genius. |
| 20:08 | AryehGregor | tries |
| 20:08 | <AryehGregor> | And unset the src. |
| 20:08 | <AryehGregor> | That's kind of evil genius. |
| 20:08 | AryehGregor | tries |
| 20:09 | <Hixie> | AryehGregor: something like that. or maybe even better, if you want to not screw up the original element, clone it, remove .src, set the contents to something harmless like ';', and then insert that |
| 20:09 | <Hixie> | AryehGregor: since the "has executed" state propagates to clones |
| 20:10 | <Hixie> | AryehGregor: something like that. or maybe even better, if you want to not screw up the original element, clone it, remove .src, set the contents to something harmless like ';', and then insert that |
| 20:10 | <Hixie> | AryehGregor: since the "has executed" state propagates to clones |
| 20:10 | <Hixie> | (remove async and defer as well) |
| 20:10 | <Hixie> | (remove async and defer as well) |
| 20:18 | <Hixie> | are any of the people who wanted path objects not to have transforms but instead for the methods to get matrix arguments around? |
| 20:19 | <Hixie> | are any of the people who wanted path objects not to have transforms but instead for the methods to get matrix arguments around? |
| 20:20 | <TabAtkins> | Matrix-based transforms are the devil. |
| 20:20 | <TabAtkins> | Matrix-based transforms are the devil. |
| 20:21 | <Philip`> | As in requiring users of the API to do the matrix maths themselves and pass the result into the API? |
| 20:22 | <Philip`> | As in requiring users of the API to do the matrix maths themselves and pass the result into the API? |
| 20:22 | <Hixie> | the matrix object has the regular transformation stuff on it, that's not hte issue |
| 20:22 | <Hixie> | (it's just SVGMatrix) |
| 20:22 | <Philip`> | Ah |
| 20:22 | <Hixie> | the matrix object has the regular transformation stuff on it, that's not hte issue |
| 20:22 | <Hixie> | (it's just SVGMatrix) |
| 20:22 | <Philip`> | Ah |
| 20:22 | Philip` | hasn't had time/energy/nonlaziness to try looking at any of this yet :-( |
| 20:23 | Philip` | hasn't had time/energy/nonlaziness to try looking at any of this yet :-( |
| 20:23 | <Hixie> | my question is whether those people think it's ok for Pattern to implement the transform stuff directly or whether there should be some method that takes a matrix there, too |
| 20:23 | <Hixie> | and if the latter, which method |
| 20:23 | <Hixie> | my question is whether those people think it's ok for Pattern to implement the transform stuff directly or whether there should be some method that takes a matrix there, too |
| 20:23 | <Hixie> | createPattern()? |
| 20:23 | <Hixie> | fill()? |
| 20:23 | <Hixie> | pattern.setPatternTransform()? |
| 20:23 | <Hixie> | and if the latter, which method |
| 20:23 | <WeirdAl> | Hey, folks, DOM4 question: when I call Node.addEventListener("foo", function listener(evt) { /* ... */ }, true), what is the |this| object inside the listener function? |
| 20:23 | <Hixie> | createPattern()? |
| 20:23 | <Hixie> | fill()? |
| 20:23 | <Hixie> | pattern.setPatternTransform()? |
| 20:23 | <WeirdAl> | Hey, folks, DOM4 question: when I call Node.addEventListener("foo", function listener(evt) { /* ... */ }, true), what is the |this| object inside the listener function? |
| 20:23 | <Hixie> | WeirdAl: Window |
| 20:24 | <Hixie> | WeirdAl: Window |
| 20:24 | <WeirdAl> | Hixie - reading the spec, I couldn't find a clear reference to that, even though it's the usual behavior in DOM3... worth doc'ing? |
| 20:25 | <WeirdAl> | Hixie - reading the spec, I couldn't find a clear reference to that, even though it's the usual behavior in DOM3... worth doc'ing? |
| 20:25 | <Hixie> | it's specified somewhere, though i forget where |
| 20:25 | <Hixie> | webidl maybe? |
| 20:25 | <Hixie> | maybe the js spc? |
| 20:25 | <Hixie> | it's specified somewhere, though i forget where |
| 20:25 | <Hixie> | webidl maybe? |
| 20:25 | <Hixie> | maybe the js spc? |
| 20:25 | <WeirdAl> | js spec, as in ECMAScript 5th Ed? |
| 20:25 | <Hixie> | or whatever the latest version is |
| 20:25 | <Hixie> | probably webidl |
| 20:26 | <WeirdAl> | js spec, as in ECMAScript 5th Ed? |
| 20:26 | <Hixie> | or whatever the latest version is |
| 20:26 | <Hixie> | probably webidl |
| 20:26 | <Hixie> | oh actually i was wrong |
| 20:27 | <Hixie> | oh actually i was wrong |
| 20:27 | <Hixie> | seems the |this| value should be the Function itself |
| 20:27 | <WeirdAl> | ugh |
| 20:27 | <WeirdAl> | that's almost certainly a change from DOM3 |
| 20:27 | <Hixie> | http://dev.w3.org/2006/webapi/WebIDL/#dfn-callback-this-value |
| 20:27 | <Hixie> | seems the |this| value should be the Function itself |
| 20:27 | <WeirdAl> | ugh |
| 20:27 | <WeirdAl> | that's almost certainly a change from DOM3 |
| 20:27 | <Hixie> | http://dev.w3.org/2006/webapi/WebIDL/#dfn-callback-this-value |
| 20:27 | <Hixie> | heycam|away: "By default, the object itself is used as the callback this value" is lacking conformance criteria (it's a description, it neither defines something nor requires something) |
| 20:28 | <Hixie> | heycam|away: "By default, the object itself is used as the callback this value" is lacking conformance criteria (it's a description, it neither defines something nor requires something) |
| 20:28 | <Hixie> | oh no i'm wrong! |
| 20:28 | <Hixie> | oh no i'm wrong! |
| 20:28 | <Hixie> | the default callback this value for Functions is 'null' |
| 20:28 | <WeirdAl> | :) |
| 20:29 | <Hixie> | the default callback this value for Functions is 'null' |
| 20:29 | <WeirdAl> | :) |
| 20:29 | <WeirdAl> | imho, that's as it should be - not a function, not window, not the global |
| 20:29 | <Hixie> | heycam|away: specifically, "By default, the callback this value when invoking a callback function is null" seems to try to override the above, but in practice it just contradicts it and doesn't leave it well defined |
| 20:29 | <WeirdAl> | imho, that's as it should be - not a function, not window, not the global |
| 20:29 | <Hixie> | heycam|away: specifically, "By default, the callback this value when invoking a callback function is null" seems to try to override the above, but in practice it just contradicts it and doesn't leave it well defined |
| 20:29 | <Hixie> | heycam|away: and "callback this value" in the algorithm below that links to the description i quoted earlier, which is why i was confused |
| 20:30 | <Hixie> | heycam|away: and "callback this value" in the algorithm below that links to the description i quoted earlier, which is why i was confused |
| 20:30 | <Hixie> | WeirdAl: yeah but i expect ES says to use the global of it's null |
| 20:30 | <Hixie> | WeirdAl: yeah but i expect ES says to use the global of it's null |
| 20:31 | <Hixie> | WeirdAl: yeah, JS spec 10.4.3 ("Entering Function Code") step 2 says "Else if thisArg is null or undefined, set the ThisBinding to the global object" |
| 20:32 | <Hixie> | WeirdAl: yeah, JS spec 10.4.3 ("Entering Function Code") step 2 says "Else if thisArg is null or undefined, set the ThisBinding to the global object" |
| 20:33 | <Hixie> | WeirdAl: and HTML says for <script> objects: "The global object is the Window object of document" http://www.whatwg.org/specs/web-apps/current-work/#the-script-settings-determined-from-the-node |
| 20:33 | <Hixie> | WeirdAl: so to answer your question, it's defined. WebIDL says it's null, ES says null means global object, and HTML says global object means Window. |
| 20:33 | <Hixie> | WeirdAl: and HTML says for <script> objects: "The global object is the Window object of document" http://www.whatwg.org/specs/web-apps/current-work/#the-script-settings-determined-from-the-node |
| 20:33 | <Hixie> | WeirdAl: so to answer your question, it's defined. WebIDL says it's null, ES says null means global object, and HTML says global object means Window. |
| 20:43 | <zcorpan> | why is it "level 1"? CSS Variables Module Level 1 |
| 20:43 | <zcorpan> | why is it "level 1"? CSS Variables Module Level 1 |
| 20:43 | <TabAtkins> | zcorpan: Because it's not based on anything from level 2, so it resets. |
| 20:44 | <TabAtkins> | zcorpan: Because it's not based on anything from level 2, so it resets. |
| 20:45 | <zcorpan> | animations etc is also level 1? |
| 20:45 | <zcorpan> | animations etc is also level 1? |
| 20:45 | <astearns> | all of the level 3 specs are based on 2.1 - what causes the increment? |
| 20:46 | <astearns> | all of the level 3 specs are based on 2.1 - what causes the increment? |
| 20:46 | <TabAtkins> | No, Animations is level 3 because nobody was watching too hard when it was named. |
| 20:46 | <TabAtkins> | it should have been level 1 |
| 20:46 | <TabAtkins> | No, Animations is level 3 because nobody was watching too hard when it was named. |
| 20:46 | <TabAtkins> | it should have been level 1 |
| 20:47 | <zcorpan> | i think calling it "css1 variables" (which is short for css variables level 1) is confusing because it implies it was present in css1 |
| 20:47 | <Hixie> | is (x,y) a coordinate, or are (x,y) coordinates? |
| 20:47 | <zcorpan> | Hixie: former |
| 20:47 | Hixie | waves his "just drop all versioning" flag |
| 20:47 | <Hixie> | zcorpan: thanks |
| 20:47 | <zcorpan> | i think calling it "css1 variables" (which is short for css variables level 1) is confusing because it implies it was present in css1 |
| 20:47 | <Hixie> | is (x,y) a coordinate, or are (x,y) coordinates? |
| 20:47 | <zcorpan> | Hixie: former |
| 20:47 | Hixie | waves his "just drop all versioning" flag |
| 20:47 | <Hixie> | zcorpan: thanks |
| 20:47 | <astearns> | 'level living' |
| 20:48 | <astearns> | 'level living' |
| 20:48 | <zcorpan> | levelless css wfm |
| 20:48 | <zcorpan> | levelless css wfm |
| 20:48 | <TabAtkins> | For all practical purposes CSS is levelless. |
| 20:49 | <TabAtkins> | For all practical purposes CSS is levelless. |
| 20:49 | <zcorpan> | TabAtkins: so on a different note, do you think the css wg would be willing to put quirks mode requirements in their specs? |
| 20:50 | <zcorpan> | TabAtkins: so on a different note, do you think the css wg would be willing to put quirks mode requirements in their specs? |
| 20:50 | <Hixie> | ok the spec live on whatwg.org (single page only) now has the path stuff updated to use DrawingStyle objects instead of on-path line styles and font styles |
| 20:50 | <Hixie> | now doing the transform changes |
| 20:50 | <TabAtkins> | zcorpan: In all the specs, or just a "Quirks Mode spec" kind of thing? |
| 20:50 | <Hixie> | ok the spec live on whatwg.org (single page only) now has the path stuff updated to use DrawingStyle objects instead of on-path line styles and font styles |
| 20:50 | <Hixie> | now doing the transform changes |
| 20:50 | <TabAtkins> | zcorpan: In all the specs, or just a "Quirks Mode spec" kind of thing? |
| 20:50 | <Hixie> | othermaciej: any opinion on whether patterns should implement the transform stuff or whether we should use SVGMatrix objects somewhere to transform patterns in fill too? |
| 20:51 | <Hixie> | othermaciej: any opinion on whether patterns should implement the transform stuff or whether we should use SVGMatrix objects somewhere to transform patterns in fill too? |
| 20:51 | <Hixie> | othermaciej: and if the latter, where should the matrix go? createPattern()? A method on the pattern object? fill()? |
| 20:51 | <zcorpan> | TabAtkins: well i think it would be best if it was defined as part of the proper spec because a quirk spec needs to override the proper spec and that can be a bit messy |
| 20:51 | <Hixie> | othermaciej: and if the latter, where should the matrix go? createPattern()? A method on the pattern object? fill()? |
| 20:51 | <zcorpan> | TabAtkins: well i think it would be best if it was defined as part of the proper spec because a quirk spec needs to override the proper spec and that can be a bit messy |
| 20:52 | <TabAtkins> | zcorpan: I suspect that requiring a "Quirks Mode" section in every spec wouldn't be well-received. |
| 20:53 | <TabAtkins> | zcorpan: I suspect that requiring a "Quirks Mode" section in every spec wouldn't be well-received. |
| 20:53 | <Hixie> | shouldn't be a section |
| 20:53 | <Hixie> | should just be the way html does it |
| 20:53 | <Hixie> | shouldn't be a section |
| 20:53 | <zcorpan> | what Hixie said |
| 20:53 | <Hixie> | should just be the way html does it |
| 20:53 | <zcorpan> | what Hixie said |
| 20:54 | <othermaciej> | Hixie: I am not up to speed on what is planned for patterns |
| 20:54 | <TabAtkins> | What's the way HTML does it? I haven't really noticed quirks stuff anywhere. |
| 20:54 | <TabAtkins> | What's the way HTML does it? I haven't really noticed quirks stuff anywhere. |
| 20:54 | <Hixie> | othermaciej: the old plan before you pointed out it was silly to put all the transform apis on Path objects, was to make CanvasPattern objects have a built-in transform in the same way, so as to allow the pattern itself to be transformed (rotated, translated, skewed, etc) when used for fills and strokes |
| 20:54 | <Hixie> | TabAtkins: exactly |
| 20:55 | <Hixie> | othermaciej: the old plan before you pointed out it was silly to put all the transform apis on Path objects, was to make CanvasPattern objects have a built-in transform in the same way, so as to allow the pattern itself to be transformed (rotated, translated, skewed, etc) when used for fills and strokes |
| 20:55 | <Hixie> | TabAtkins: exactly |
| 20:55 | <Hixie> | TabAtkins: it just says "and now do x. if in quirks mode, do y, otherwise do z. then do q...." |
| 20:55 | <zcorpan> | TabAtkins: e.g. http://simon.html5.org/specs/quirks-mode#the-blocks-ignore-line-height-quirk should be specified as part of http://www.w3.org/TR/CSS21/visudet.html#propdef-line-height |
| 20:55 | <Hixie> | TabAtkins: it just says "and now do x. if in quirks mode, do y, otherwise do z. then do q...." |
| 20:55 | <zcorpan> | TabAtkins: e.g. http://simon.html5.org/specs/quirks-mode#the-blocks-ignore-line-height-quirk should be specified as part of http://www.w3.org/TR/CSS21/visudet.html#propdef-line-height |
| 20:56 | <TabAtkins> | I personally prefer it in a big list somewhere. |
| 20:56 | <Hixie> | really? why? |
| 20:57 | <TabAtkins> | I personally prefer it in a big list somewhere. |
| 20:57 | <Hixie> | really? why? |
| 20:57 | <TabAtkins> | The only effect of quirks on new content is parsing-level stuff. |
| 20:57 | <TabAtkins> | The only effect of quirks on new content is parsing-level stuff. |
| 20:57 | <TabAtkins> | Which shouldn't be in individual specs anyway. |
| 20:57 | <TabAtkins> | Which shouldn't be in individual specs anyway. |
| 20:57 | <zcorpan> | new content shouldn't use quirks mode at all |
| 20:57 | <Hixie> | yeah |
| 20:57 | <Hixie> | what's new content got to do with what the specs say? |
| 20:58 | <zcorpan> | new content shouldn't use quirks mode at all |
| 20:58 | <Hixie> | yeah |
| 20:58 | <Hixie> | what's new content got to do with what the specs say? |
| 20:58 | <TabAtkins> | I meant new specs. |
| 20:58 | <TabAtkins> | I meant new specs. |
| 20:58 | Hixie | decides to put transforms in createPattern() |
| 20:58 | <zcorpan> | having it in a bit list makes it harder for implementors to figure out how it integrates with the spec proper |
| 20:58 | Hixie | decides to put transforms in createPattern() |
| 20:58 | <zcorpan> | having it in a bit list makes it harder for implementors to figure out how it integrates with the spec proper |
| 20:58 | <zcorpan> | TabAtkins: it wouldn't need to be in new specs if the new spec doesn't have any quirks |
| 20:58 | <othermaciej> | Hixie: I'd have to do some research on what other pattern APIs do for this, if anything |
| 20:59 | <zcorpan> | TabAtkins: it wouldn't need to be in new specs if the new spec doesn't have any quirks |
| 20:59 | <othermaciej> | Hixie: I'd have to do some research on what other pattern APIs do for this, if anything |
| 20:59 | <TabAtkins> | If it's limited to CSS2.1 and Selectors, then I'm less opposed. |
| 20:59 | <TabAtkins> | If it's limited to CSS2.1 and Selectors, then I'm less opposed. |
| 20:59 | <zcorpan> | TabAtkins: some quirks are about fine details about table layout, and css 2.1 doesn't define table layout |
| 21:00 | <zcorpan> | TabAtkins: some quirks are about fine details about table layout, and css 2.1 doesn't define table layout |
| 21:00 | <WeirdAl> | Hixie - my monitor's acting up - I'll try to reread through channel logs |
| 21:00 | <Hixie> | othermaciej: k |
| 21:00 | <WeirdAl> | Hixie - my monitor's acting up - I'll try to reread through channel logs |
| 21:00 | <Hixie> | othermaciej: k |
| 21:01 | <othermaciej> | Hixie: how exactly do patterns work, are they ultimately a bitmap? |
| 21:01 | <Hixie> | TabAtkins: values and units, box model, table -- that's probably it as far as affected css specs go, right zcorpan? |
| 21:01 | <TabAtkins> | zcorpan: There's no CSS3 Table spec, so that's all right. ^_^ |
| 21:01 | <WeirdAl> | Hixie - ah, your answer does make sense. |
| 21:01 | <Hixie> | othermaciej: sure |
| 21:01 | <othermaciej> | Hixie: how exactly do patterns work, are they ultimately a bitmap? |
| 21:01 | <Hixie> | TabAtkins: values and units, box model, table -- that's probably it as far as affected css specs go, right zcorpan? |
| 21:01 | <TabAtkins> | zcorpan: There's no CSS3 Table spec, so that's all right. ^_^ |
| 21:01 | <WeirdAl> | Hixie - ah, your answer does make sense. |
| 21:01 | <Hixie> | othermaciej: sure |
| 21:01 | <zcorpan> | TabAtkins: and some level 3 specs that redefine 2.1 better would be better suited to cover quirks than 2.1 (like e.g. text-decoration) |
| 21:01 | <WeirdAl> | but it'd sure be nice to not have to read fifteen different specs to get the answer ;) |
| 21:02 | <zcorpan> | TabAtkins: and some level 3 specs that redefine 2.1 better would be better suited to cover quirks than 2.1 (like e.g. text-decoration) |
| 21:02 | <WeirdAl> | but it'd sure be nice to not have to read fifteen different specs to get the answer ;) |
| 21:02 | <zcorpan> | TabAtkins: i hope there will be :-P |
| 21:02 | <zcorpan> | TabAtkins: i hope there will be :-P |
| 21:03 | <Hixie> | WeirdAl: well, i'm all in favour of reducing the numebr of specs. personally i think it'd be great to merge webidl and js, maybe even webidl and dom core, but i doubt anyone's gonna go for that. and people are already arguing that html does too much, so i doubt they'd be up for merging any of those with html... |
| 21:03 | <TabAtkins> | zcorpan: When someone sufficiently masochistic volunteers, there will be. |
| 21:03 | <Hixie> | WeirdAl: well, i'm all in favour of reducing the numebr of specs. personally i think it'd be great to merge webidl and js, maybe even webidl and dom core, but i doubt anyone's gonna go for that. and people are already arguing that html does too much, so i doubt they'd be up for merging any of those with html... |
| 21:03 | <TabAtkins> | zcorpan: When someone sufficiently masochistic volunteers, there will be. |
| 21:03 | <WeirdAl> | Hixie - I'm of mixed opinion on that... |
| 21:04 | <WeirdAl> | Hixie - I'm of mixed opinion on that... |
| 21:04 | <WeirdAl> | but I do think the undo manager spec rniwa is working on should be folded in as a chapter of HTML5 |
| 21:04 | <zcorpan> | Hixie: and selectors, and maybe some others -- i don't have a good overview of the various css modules |
| 21:04 | <WeirdAl> | but I do think the undo manager spec rniwa is working on should be folded in as a chapter of HTML5 |
| 21:04 | <zcorpan> | Hixie: and selectors, and maybe some others -- i don't have a good overview of the various css modules |
| 21:05 | <Hixie> | WeirdAl: it will eventually, i expect. it used to be part of html, it's just easier for him to work on it separately for now |
| 21:05 | <Hixie> | zcorpan: fair enough |
| 21:05 | <Hixie> | WeirdAl: it will eventually, i expect. it used to be part of html, it's just easier for him to work on it separately for now |
| 21:05 | <rniwa> | WeirdAl: it might make more sense to merge it into AryehGregor's editing spec |
| 21:05 | Hixie | thinks most of the css modules should be folded into one anyway :-P |
| 21:05 | <Hixie> | rniwa: yeah but that will eventually make it back to html too, probably |
| 21:05 | <Hixie> | zcorpan: fair enough |
| 21:05 | <rniwa> | WeirdAl: it might make more sense to merge it into AryehGregor's editing spec |
| 21:05 | Hixie | thinks most of the css modules should be folded into one anyway :-P |
| 21:05 | <Hixie> | rniwa: yeah but that will eventually make it back to html too, probably |
| 21:05 | WeirdAl | thinks we need a metaspec: a spec saying "Here's where you find the spec for this" :p |
| 21:05 | <rniwa> | Hixie: yeah, that makes sense in the long ru |
| 21:06 | WeirdAl | thinks we need a metaspec: a spec saying "Here's where you find the spec for this" :p |
| 21:06 | <rniwa> | Hixie: yeah, that makes sense in the long ru |
| 21:06 | <Hixie> | WeirdAl: platform.html5.org |
| 21:06 | <rniwa> | Hixie: but will probably take a decade or two before that happens :( |
| 21:06 | <Hixie> | WeirdAl: platform.html5.org |
| 21:06 | <Hixie> | rniwa: prolly :-) |
| 21:06 | <WeirdAl> | yikes! |
| 21:06 | <rniwa> | Hixie: but will probably take a decade or two before that happens :( |
| 21:06 | <Hixie> | rniwa: prolly :-) |
| 21:06 | <WeirdAl> | yikes! |
| 21:07 | <zcorpan> | Hixie: are there quirks i've listed under "CSS" that you think belong in html instead? |
| 21:07 | <Hixie> | WeirdAl: (to be fair, big chunks of that are just "html") |
| 21:07 | <Hixie> | zcorpan: url? |
| 21:07 | <zcorpan> | http://simon.html5.org/specs/quirks-mode#css |
| 21:07 | <zcorpan> | Hixie: are there quirks i've listed under "CSS" that you think belong in html instead? |
| 21:07 | <Hixie> | WeirdAl: (to be fair, big chunks of that are just "html") |
| 21:07 | <Hixie> | zcorpan: url? |
| 21:07 | <zcorpan> | http://simon.html5.org/specs/quirks-mode#css |
| 21:07 | <Hixie> | WeirdAl: (though of course, "css" is a bit vague in that list and should be split out into its component specs since there's not just one css spec) |
| 21:08 | <Hixie> | WeirdAl: (though of course, "css" is a bit vague in that list and should be split out into its component specs since there's not just one css spec) |
| 21:08 | <Hixie> | WeirdAl: (so it might be a bit of a wash in the end) |
| 21:08 | WeirdAl | shakes his head ruefully |
| 21:08 | <Hixie> | WeirdAl: (so it might be a bit of a wash in the end) |
| 21:08 | WeirdAl | shakes his head ruefully |
| 21:09 | <Hixie> | zcorpan: "The table cell nowrap minimum width calculation quirk" might need to have something in HTML, but it would have to refer to something in CSS, so might not be worth it |
| 21:09 | <Hixie> | zcorpan: "The table cell nowrap minimum width calculation quirk" might need to have something in HTML, but it would have to refer to something in CSS, so might not be worth it |
| 21:09 | <Hixie> | zcorpan: can "The text decoration doesn't propagate into tables quirk" be defined as a CSS rule? if so, ->html |
| 21:10 | <Hixie> | zcorpan: can "The text decoration doesn't propagate into tables quirk" be defined as a CSS rule? if so, ->html |
| 21:10 | <zcorpan> | Hixie: it can't |
| 21:10 | <Hixie> | k |
| 21:10 | <Hixie> | zcorpan: looks like i can take "The table cell width resets nowrap quirk", file a bug |
| 21:10 | <zcorpan> | Hixie: it can't |
| 21:10 | <Hixie> | k |
| 21:10 | <Hixie> | zcorpan: looks like i can take "The table cell width resets nowrap quirk", file a bug |
| 21:10 | <Hixie> | zcorpan: other than that, i think you're right and it should go into the css spec |
| 21:10 | <Hixie> | zcorpan: i'm surprised there aren't more html quirks that i've missed |
| 21:11 | <Hixie> | zcorpan: other than that, i think you're right and it should go into the css spec |
| 21:11 | <Hixie> | zcorpan: i'm surprised there aren't more html quirks that i've missed |
| 21:11 | <zcorpan> | that's already filed |
| 21:11 | <zcorpan> | that's already filed |
| 21:11 | <Hixie> | cool |
| 21:11 | <zcorpan> | there was one more that i just filed |
| 21:11 | <Hixie> | cool |
| 21:11 | <zcorpan> | there was one more that i just filed |
| 21:11 | <zcorpan> | "just" as in "didn't spec", not "right now" |
| 21:12 | <zcorpan> | "just" as in "didn't spec", not "right now" |
| 21:12 | <Hixie> | k |
| 21:12 | <Hixie> | k |
| 21:12 | <Hixie> | still, that's pretty good :-) |
| 21:12 | <zcorpan> | yeah |
| 21:13 | <Hixie> | still, that's pretty good :-) |
| 21:13 | <zcorpan> | yeah |
| 21:16 | <zcorpan> | Hixie: The font element text decoration color quirk can't be specified as a css rule, either. should it be under "css" instead? |
| 21:17 | <zcorpan> | Hixie: The font element text decoration color quirk can't be specified as a css rule, either. should it be under "css" instead? |
| 21:18 | Hixie | shrugs |
| 21:18 | Hixie | shrugs |
| 21:18 | <Hixie> | that's a mere intraspec organisation issue |
| 21:18 | <Hixie> | up to you entirely :-) |
| 21:19 | <Hixie> | that's a mere intraspec organisation issue |
| 21:19 | <Hixie> | up to you entirely :-) |
| 21:23 | <zcorpan> | i moved it |
| 21:24 | <zcorpan> | i moved it |
| 21:24 | <zcorpan> | Hixie: there's one more quirk that i hope we can drop but might not be successful, style="{ ... }" |
| 21:24 | <zcorpan> | Hixie: there's one more quirk that i hope we can drop but might not be successful, style="{ ... }" |
| 21:28 | <Hixie> | zcorpan: k |
| 21:28 | <Hixie> | zcorpan: k |
| 21:39 | <Ms2ger> | <Hixie> is (x,y) a coordinate, or are (x,y) coordinates? |
| 21:39 | <Ms2ger> | Latter |
| 21:39 | <Ms2ger> | <Hixie> is (x,y) a coordinate, or are (x,y) coordinates? |
| 21:39 | <Ms2ger> | Latter |
| 21:40 | <smaug____> | WeirdAl: you asked something about 'this' |
| 21:40 | <smaug____> | with event listeners |
| 21:40 | <smaug____> | WeirdAl: you asked something about 'this' |
| 21:40 | <smaug____> | with event listeners |
| 21:40 | <WeirdAl> | yeah, I just wanted to know what the specs say it should be when the listener is a function and not an object |
| 21:41 | <WeirdAl> | yeah, I just wanted to know what the specs say it should be when the listener is a function and not an object |
| 21:41 | <smaug____> | it is event.currentTarget |
| 21:41 | <smaug____> | DOM4 |
| 21:41 | <smaug____> | it is event.currentTarget |
| 21:41 | <smaug____> | DOM4 |
| 21:41 | <WeirdAl> | ok |
| 21:42 | <WeirdAl> | ok |
| 21:43 | <Hixie> | Ms2ger: zcorpan disagreed and he was first |
| 21:43 | <Hixie> | Ms2ger: zcorpan disagreed and he was first |
| 21:43 | <zcorpan> | Ms2ger: x is a coordinate for a line, y is a coordinate for a line, (x, y) is a coordinate for a point. no? |
| 21:43 | <Ms2ger> | Say what? |
| 21:44 | <zcorpan> | Ms2ger: x is a coordinate for a line, y is a coordinate for a line, (x, y) is a coordinate for a point. no? |
| 21:44 | <Ms2ger> | Say what? |
| 21:44 | <Hixie> | smaug____: it is? |
| 21:44 | <Hixie> | smaug____: it is? |
| 21:44 | <Hixie> | smaug____: oh yeah, look at that |
| 21:44 | <Hixie> | WeirdAl: smaug____ is right, dom4 overrides webidl here |
| 21:45 | <Hixie> | smaug____: oh yeah, look at that |
| 21:45 | <Hixie> | WeirdAl: smaug____ is right, dom4 overrides webidl here |
| 21:45 | <smaug____> | Hixie: yes |
| 21:45 | <WeirdAl> | ok. It wasn't clear from my cursory reading :) |
| 21:45 | <WeirdAl> | ok. It wasn't clear from my cursory reading :) |
| 21:45 | <Hixie> | search for "this value" |
| 21:46 | <Hixie> | search for "this value" |
| 21:46 | <WeirdAl> | ah, right there, ok |
| 21:46 | <WeirdAl> | ah, right there, ok |
| 21:46 | WeirdAl | is chagrined |
| 21:47 | WeirdAl | is chagrined |
| 21:57 | <zcorpan> | smaug____: i think the spec isn't wrong for tagName |
| 21:57 | <zcorpan> | smaug____: i think the spec isn't wrong for tagName |
| 21:57 | <smaug____> | zcorpan: no no, that was my mistake |
| 21:57 | <Ms2ger> | He was accidentally using XML |
| 21:57 | <Ms2ger> | How you do that, no idea |
| 21:57 | <smaug____> | I was testing accidentally xhtml |
| 21:58 | <smaug____> | zcorpan: no no, that was my mistake |
| 21:58 | <Ms2ger> | He was accidentally using XML |
| 21:58 | <Ms2ger> | How you do that, no idea |
| 21:58 | <smaug____> | I was testing accidentally xhtml |
| 21:58 | <smaug____> | Ms2ger: I guess I opened new tab |
| 21:58 | <zcorpan> | smaug____: ah. ok |
| 21:58 | <smaug____> | and about:newTab is xhtml or something |
| 21:58 | <smaug____> | Ms2ger: I guess I opened new tab |
| 21:58 | <Ms2ger> | Ah, right |
| 21:58 | <smaug____> | silly me |
| 21:58 | <zcorpan> | smaug____: ah. ok |
| 21:58 | <smaug____> | and about:newTab is xhtml or something |
| 21:58 | <Ms2ger> | Ah, right |
| 21:58 | <smaug____> | silly me |
| 21:59 | <zcorpan> | AryehGregor: uncaught exceptions in scripts don't fire a bubbling error event |
| 22:00 | <zcorpan> | AryehGregor: they invoke window.onerror() with three arguments, not involving any event |
| 22:00 | <AryehGregor> | Oh, they just fire straight at window? |
| 22:00 | <AryehGregor> | Oh, sneaky. |
| 22:00 | <zcorpan> | nope |
| 22:00 | <AryehGregor> | What defines that? |
| 22:00 | <zcorpan> | html |
| 22:00 | <zcorpan> | AryehGregor: they invoke window.onerror() with three arguments, not involving any event |
| 22:00 | <AryehGregor> | Oh, they just fire straight at window? |
| 22:00 | <AryehGregor> | Oh, sneaky. |
| 22:00 | <zcorpan> | nope |
| 22:00 | <AryehGregor> | What defines that? |
| 22:00 | <zcorpan> | html |
| 22:03 | <Ms2ger> | There are tests, even |
| 22:03 | <Ms2ger> | There are tests, even |
| 22:04 | <AryehGregor> | So window.onerror really is used for two totally different things. |
| 22:04 | <zcorpan> | the spec has two entry points |
| 22:04 | <zcorpan> | http://dev.w3.org/html5/spec/webappapis.html#create-a-script |
| 22:04 | <zcorpan> | "Otherwise, report the error ..." |
| 22:04 | <AryehGregor> | (W3C version? Really?) |
| 22:04 | <AryehGregor> | So window.onerror really is used for two totally different things. |
| 22:04 | <zcorpan> | the spec has two entry points |
| 22:04 | <zcorpan> | http://dev.w3.org/html5/spec/webappapis.html#create-a-script |
| 22:04 | <zcorpan> | "Otherwise, report the error ..." |
| 22:04 | <AryehGregor> | (W3C version? Really?) |
| 22:04 | <zcorpan> | and http://dev.w3.org/html5/spec/webappapis.html#runtime-script-errors-in-documents |
| 22:04 | <zcorpan> | whatwg didn't want to load for me :( |
| 22:05 | <zcorpan> | and http://dev.w3.org/html5/spec/webappapis.html#runtime-script-errors-in-documents |
| 22:05 | <zcorpan> | whatwg didn't want to load for me :( |
| 22:06 | <zcorpan> | and workers have onerror stuff as well |
| 22:06 | <zcorpan> | and workers have onerror stuff as well |
| 22:39 | <Hixie> | MikeSmith: ok, should be published |
| 22:40 | <Hixie> | MikeSmith: ok, should be published |
| 22:45 | <smaug____> | aklein: looks like webkit handles documentfragments inconsistently |
| 22:46 | <smaug____> | aklein: looks like webkit handles documentfragments inconsistently |
| 22:46 | <smaug____> | when inserting documentfragment to some other node, each removal from documentfragment get separate record |
| 22:46 | <smaug____> | when inserting documentfragment to some other node, each removal from documentfragment get separate record |
| 22:46 | <smaug____> | aklein: but they are all added in one record to the new parent |
| 22:47 | <smaug____> | aklein: but they are all added in one record to the new parent |
| 22:47 | <smaug____> | gecko will create only 2 records. One for removals, one for additions |
| 22:47 | <smaug____> | spec bug has been filed |
| 22:47 | <smaug____> | (it doesn't define this case) |
| 22:47 | <smaug____> | gecko will create only 2 records. One for removals, one for additions |
| 22:47 | <smaug____> | spec bug has been filed |
| 22:47 | <smaug____> | (it doesn't define this case) |
| 22:59 | <Hixie> | heycam: why are dictionary types not distinguishable? |
| 22:59 | <Hixie> | heycam: why are dictionary types not distinguishable? |
| 23:00 | <Hixie> | heycam: is there no type checking beyond "is an Object" for dictionary arguments? i.e. no checking that fields are present? |
| 23:00 | <Hixie> | heycam: is there no type checking beyond "is an Object" for dictionary arguments? i.e. no checking that fields are present? |
| 23:08 | <aklein> | smaug____: not surprising...WebKit doesn't treat document fragments nearly atomically enough, I'm hacking on that this week |
| 23:09 | <aklein> | smaug____: not surprising...WebKit doesn't treat document fragments nearly atomically enough, I'm hacking on that this week |
| 23:09 | <heycam> | Hixie, that's right |
| 23:10 | <heycam> | Hixie, that's right |
| 23:10 | <Hixie> | :-( |
| 23:10 | <aklein> | smaug____: I suspect that replaceChild may also be handled differently |
| 23:10 | <Hixie> | :-( |
| 23:10 | <aklein> | smaug____: I suspect that replaceChild may also be handled differently |
| 23:10 | <smaug____> | ok |
| 23:11 | <smaug____> | ok |
| 23:42 | <zewt> | reading the indexeddb spec makes me :| |
| 23:43 | <zewt> | reading the indexeddb spec makes me :| |
| 23:43 | <zewt> | If these steps are running asynchronously, return the created transaction and queue up the remaining steps. |
| 23:44 | <zewt> | If these steps are running asynchronously, return the created transaction and queue up the remaining steps. |