| 04:29 | <wirepair> | hsivonen: thank you for this html5 parser and the ability to set your own transition handler, it is exactly what i needed :> |
| 05:39 | <dekiss> | how will old browsers parse html5 shemantic elements - header footer section article? |
| 07:40 | <zcorpan> | dekiss2: depends on the browser |
| 07:45 | <zcorpan> | jgraham: Hixie: i don't think we should change the spec for the newline without first trying to get it implemented. we tried to get it implemented in presto and it worked :-) |
| 07:56 | <hsivonen> | wirepair: you're welcome. are you using it in Java? |
| 08:04 | <wirepair> | hsivonen: yeah |
| 08:08 | MikeSmith | wonders eh what is the BarProp interface |
| 08:10 | MikeSmith | and finds http://www.whatwg.org/specs/web-apps/current-work/multipage/browsers.html#barprop |
| 08:25 | <zcorpan> | the definitions of status bar and toolbar seem a bit poor |
| 08:26 | <zcorpan> | since the toolbar is sometimes at the bottom and the status bar can be e.g. inside the address bar |
| 08:27 | <MikeSmith> | zcorpan: the definitions look word-for-word the same with each other |
| 08:27 | <MikeSmith> | oh |
| 08:27 | <zcorpan> | not quite |
| 08:28 | <MikeSmith> | "below or after" vs "above or before" |
| 08:29 | zcorpan | files |
| 08:31 | <MikeSmith> | zcorpan: seems like you could suggest some wording for what they are. Since I'd imagine the reason Hixie doesn't already describe what they are is that he wasn't t able to come up with wording that accurately describes what they are |
| 08:32 | <zcorpan> | Hixie usually says he just wants to know the problem, not the solution :-P |
| 08:41 | <MikeSmith> | yeah treu |
| 08:47 | <MikeSmith> | but your descriptions look good to me :-) |
| 09:27 | <jgraham> | zcorpan: I can live with that. On that subject, feel free to look at https://critic.hoppipolla.co.uk/r/523 if you have time ;) |
| 09:28 | <zcorpan> | jgraham: ok |
| 11:28 | <annevk> | So I looked at the createElement() bug... https://www.w3.org/Bugs/Public/show_bug.cgi?id=24271 |
| 11:29 | <MikeSmith> | annevk: and..? |
| 11:29 | <annevk> | And apart from severe disinterest, it seems there are some issues there that do not relate to 4th vs 5th |
| 11:30 | <annevk> | Because initially I was going to reply that I don't care how 4th vs 5th plays out as nobody cares about XML |
| 11:30 | <annevk> | However, U+0083 and U+00B5 seem forbidden by both as far as I can tell |
| 11:35 | <MikeSmith> | annevk: so it should just throw for those instead? |
| 11:37 | <MikeSmith> | oh I guess I don't know what it does now for the No cases of those |
| 11:37 | <annevk> | Right. As far as I can tell Chrome is the only sane browser per XML, but it is insane for implementing the 5th edition. (The last two examples are testing 4th vs 5th.) |
| 11:37 | <MikeSmith> | throws |
| 11:37 | <MikeSmith> | annevk: OK |
| 12:33 | <annevk> | Okay, so Gecko has bugs in its XML parser as far as I can tell |
| 12:33 | <annevk> | data:text/xml,<%C2%B5/> |
| 12:34 | <ondras> | works for me. is that incorrect? |
| 12:35 | <annevk> | As far as I can tell U+00B5 is not a valid XML Name |
| 12:35 | <annevk> | So that should give a parse error |
| 12:38 | <ondras> | yeah, hmm, the valid range seems to start at 0xc0 apparently |
| 12:55 | <MikeSmith> | does Gecko still use expat? |
| 13:30 | <jgraham> | MikeSmith: Yes |
| 13:35 | <annevk> | So with SimonSapin I checked some other code points, wasting yet more time |
| 13:36 | <annevk> | Seems most other code points in the U+0080 to U+00C0 range do not work |
| 13:38 | <jgraham> | zcorpan: Am I missing something about https://critic.hoppipolla.co.uk/be224de9?review=487 ? |
| 13:38 | <jgraham> | The unreviewed parts |
| 13:38 | <jgraham> | (not claiming you have special insight into the tests, but you might know if there is some strangeness in the spec I have overlooked) |
| 13:39 | <zcorpan> | jgraham: i think i recall ms2ger saying he left those for you to review |
| 13:39 | <Ms2ger> | What'd I do? |
| 13:40 | <jgraham> | zcorpan: Yeah he did |
| 13:40 | <Ms2ger> | Yeah, the testharness.js-inside-a-frame thing |
| 13:40 | <jgraham> | So that doesn't work |
| 13:40 | <jgraham> | I can comment on that |
| 13:40 | <jgraham> | But I don't understand the pass condition on the test |
| 13:41 | <Ms2ger> | Did you notice the parentNode bits? |
| 13:41 | <jgraham> | Ahhhh |
| 13:41 | <jgraham> | No |
| 13:41 | <jgraham> | Why would you do that? |
| 13:41 | <Ms2ger> | Microsoft |
| 13:41 | <jgraham> | But why? |
| 13:41 | <Ms2ger> | I claim no understanding |
| 13:41 | <zcorpan> | seems bogus, just change it to expect the right element directly :-) |
| 13:43 | <jgraham> | OK, commented |
| 13:44 | <zcorpan> | i don't understand why it needs to run the script from a frame |
| 13:44 | <zcorpan> | why doesn't it just run it in the frameset document and use about:blank in the frames? |
| 13:45 | <zcorpan> | maybe set the log element manually to one of the frame's body or so |
| 13:47 | <jgraham> | zcorpan: I had some notion that running scripts there didn't work, but maybe I invented that |
| 13:47 | <zcorpan> | oh you set an output document, not an element |
| 13:52 | <blackhair> | shankha93 are you from IIT J? |
| 13:52 | <SimonSapin> | annevk: https://bugzilla.mozilla.org/show_bug.cgi?id=501837 / http://www.w3.org/XML/xml-V10-4e-errata#E09 |
| 13:53 | <zcorpan> | i can't get it to work though. http://software.hixie.ch/utilities/js/live-dom-viewer/saved/2733 |
| 13:53 | <zcorpan> | bbl |
| 13:53 | <Ms2ger> | sankha93 seems mostly on a bad connection |
| 13:54 | <sankha93> | oh, I don't know always my network has problems with freenode :( |
| 13:54 | <sankha93> | blackhair: how did you know my college name? |
| 13:55 | <annevk> | SimonSapin: yeah, B5 is not allowed in either 4th or 5th edition |
| 13:56 | <annevk> | SimonSapin: that's why it's special |
| 13:56 | <SimonSapin> | ah, I confused it with B7 |
| 14:00 | <annevk> | Was B7 ever allowed at the start? |
| 14:01 | <annevk> | People keep derailing my overloading thread :/ |
| 14:02 | <SimonSapin> | in 4th edition |
| 14:02 | <blackhair> | sankha93: scrollback.io - ring any bells ? |
| 14:03 | <annevk> | SimonSapin: not per http://www.w3.org/TR/2006/REC-xml-20060816/#NT-Name |
| 14:04 | <SimonSapin> | it’s in Extender which is in NameChar |
| 14:04 | <annevk> | SimonSapin: but NameChar is not allowed at the start |
| 14:04 | <SimonSapin> | ah, right |
| 14:04 | <SimonSapin> | anyway |
| 14:14 | <MikeSmith> | https://twitter.com/kuvos/status/422721878508056577 "Are there other elements besides <table> children that disappear when you document.write() them outside table? Not related to nesting <p>'s." |
| 14:14 | <MikeSmith> | (question from Peter van der Zee) |
| 14:16 | <Ms2ger> | So what happened to https://github.com/w3c/web-platform-tests/pull/509 ? |
| 14:20 | <annevk> | MikeSmith: given that the parser is context-dependent, and he doesn't define the context, the answer could be either almost all elements or none |
| 14:21 | <annevk> | Ms2ger: seems like you should reopen that |
| 15:21 | <jgraham> | Quick review anyone? https://critic.hoppipolla.co.uk/r/546 |
| 15:22 | <jgraham> | Ms2ger: ^ |
| 15:22 | Ms2ger | startes a browser |
| 15:22 | <Ms2ger> | startes? |
| 15:28 | <jgraham> | startles? |
| 15:30 | <Ms2ger> | if os.path.exists(override_path): with open(override_path) ... |
| 15:30 | <Ms2ger> | Do we care about race conditions there? |
| 15:32 | <jgraham> | Not really? |
| 15:32 | <jgraham> | I could use try/except ofc |
| 15:32 | <Ms2ger> | Yeah, I thought so |
| 15:33 | <Ms2ger> | Intentional that config.json can only override, not add keys? |
| 15:34 | <jgraham> | Yes |
| 15:34 | <Ms2ger> | r+ |
| 15:35 | <jgraham> | Takk |
| 15:44 | <jgraham> | MikeSmith: You might be interested in that. You can now create a config.json that will override what's in config.default.json but will be ignored by git |
| 16:15 | <annevk> | Ffffffuuuuu |
| 16:15 | <annevk> | <a href="http://%61.com">test</a> points to a.com |
| 16:15 | <annevk> | <a href="http://%41.com">test</a> points to A.com, well that is weird |
| 16:15 | <annevk> | (Firefox) |
| 16:15 | <zcorpan> | jgraham: http://software.hixie.ch/utilities/js/live-dom-viewer/saved/2734 is supposed to work but doesn't, any idea? |
| 16:15 | <annevk> | In Chrome both are a.com |
| 16:16 | <zcorpan> | annevk: is that level of crazy necessary for web compat? |
| 16:16 | <annevk> | Chrome even supports %ef%bc%85%ef%bc%94%ef%bc%91.com |
| 16:17 | <jgraham> | zcorpan: Not sure |
| 16:17 | <annevk> | Which is more or less equal to what I just had, except another level of percent-encoding |
| 16:17 | <annevk> | See https://www.w3.org/Bugs/Public/show_bug.cgi?id=24257 |
| 16:18 | <zcorpan> | annevk: yeah. seems to me like this is something that would only show up in test cases and attacks |
| 16:19 | <annevk> | The question is of course what we should do. We could say no to this, but what do we say yes to? |
| 16:19 | <zcorpan> | yes to \ :-) |
| 16:21 | <zcorpan> | maybe i can run a grep, but not sure what to look for |
| 16:24 | <jgraham> | zcorpan: setup() won't run there |
| 16:25 | <annevk> | Hmm actually, Firefox does not appear to do any percent-decoding |
| 16:25 | <annevk> | There is a bug in the UI that makes it look like it does |
| 16:29 | <zcorpan> | jgraham: ok. that makes it a bit hard to set output_document to a document that hasn't loaded yet. maybe output_window is better? i can use about:blank and append a div, but it seems a bit hacky |
| 16:30 | <jgraham> | zcorpan: Yeah, perhaps |
| 16:30 | <jgraham> | I don't remember exactly what the original case was. Possibly something with SVG that payman was doing |
| 16:44 | <zcorpan> | jgraham: http://software.hixie.ch/utilities/js/live-dom-viewer/saved/2735 |
| 16:45 | <zcorpan> | jgraham: i get an exception in blink |
| 16:46 | <jgraham> | zcorpan: I think the right thing is to fix this on the testharness side |
| 16:46 | <zcorpan> | jgraham: yes |
| 16:47 | <jgraham> | zcorpan: |
| 16:47 | <jgraham> | Hmm |
| 16:47 | <jgraham> | try setting output_document = function() {return window[0].document} |
| 16:47 | <jgraham> | in setup called before onload |
| 16:50 | <zcorpan> | that doesn't help, functions and documents aren't allowed to be cloned in postMessage |
| 16:50 | <zcorpan> | properties: this_obj.properties |
| 16:56 | <jgraham> | That seems very unnecessary |
| 16:56 | <jgraham> | (including the properties there) |
| 17:03 | <zcorpan> | yeah |
| 17:04 | <zcorpan> | i realise that changing output_document to output_window doesn't help without also making the evaluation late |
| 17:15 | <dglazkov> | good morning, Whatwg! |
| 17:15 | <MikeSmith> | jgraham: yeah saw that (config.json change) thanks, I think that will be better for the w3c-test.org case |
| 17:16 | <jgraham> | MikeSmith: Turns out it will be better for me too ;) |
| 17:17 | <MikeSmith> | yay |
| 17:19 | <Hixie> | zcorpan: if you could comment on https://www.w3.org/Bugs/Public/show_bug.cgi?id=14703 that would be fantastic |
| 17:20 | <zcorpan> | annevk: i see things like <link rel="alternate" media="handheld" href="http://m.snapdeal.com%2F"/> and <a href="http://www.charlotteolympia.com%20" target="_blank"> |
| 17:24 | <annevk> | zcorpan: see https://www.w3.org/Bugs/Public/show_bug.cgi?id=24191#c4 |
| 17:24 | <annevk> | zcorpan: both of those should probably always fail |
| 17:24 | <zcorpan> | Hixie: yeah, i'll look into it some more |
| 17:25 | <Hixie> | zcorpan: thanks. i'm going to the vet now, but i'll look in an hour or two and see if i can finish the edit. |
| 17:52 | <zcorpan> | annevk: http://pastebin.com/2Y5QwuDb |
| 17:52 | <annevk> | those URLs seem pretty broken |
| 17:53 | <zcorpan> | annevk: if you want with -H i can rerun (i.e. the url of the page containing the link) |
| 17:55 | <zcorpan> | annevk: yeah but some do actually work in some browsers, but it's pretty rare (the set is 102,000 pages) |
| 17:56 | <zcorpan> | i'll leave it for you to analyze the data further if you want :-) bbl |
| 17:57 | <annevk> | Hmm |
| 18:00 | <annevk> | smola: how do you want to be acknowledged? |
| 18:00 | <annevk> | smola: is "Santiago M. Mola" as in Bugzilla? Or without the M. or with it written out? |
| 18:00 | <annevk> | s/is// |
| 18:02 | <smola> | annevk: "Santiago M. Mola" is ok |
| 18:02 | <gsnedders> | Yay, SGML like syntax in linguistic corpora: "<shouting>Mum, can I have a drink?</>". |
| 18:03 | <gsnedders> | (This isn't all too surprising, in the 80s a fair number of linguistic tools used SGML) |
| 19:08 | <Hixie> | man i wish the links in cssom were more obviously links |
| 19:08 | <Hixie> | i can barely see them, especially when scrolling |
| 19:23 | <Hixie> | anyone know when a "CSS style sheet" has its "CSS rules" set to something? |
| 19:36 | <SimonSapin> | Hixie: http://dev.w3.org/csswg/css-syntax/#parse-a-stylesheet maybe? |
| 19:36 | <SimonSapin> | though it may not be in sync with CSSOM terminology |
| 19:37 | <Hixie> | when is that invoked? |
| 19:37 | <Hixie> | seems like the appropriate place for it to happen |
| 19:38 | <SimonSapin> | I don’t think we have clear spec text about this, but it should be invoked when processing the content of <style> or the response for <link rel=stylesheet> |
| 19:45 | <smola> | annevk: we still have to check for 0x0020 in domain after ToASCII |
| 19:46 | <annevk> | smola: stuff decomposes to that? |
| 19:46 | <smola> | you can get 0x0020 in the result through non-ASCII whitespace |
| 19:46 | <annevk> | of course you can :/ |
| 19:46 | <smola> | GOO\u00a0\u3000goo.com <- this one from the WebKit tests |
| 19:47 | <smola> | brb |
| 19:47 | <annevk> | I guess we could just do it after |
| 19:47 | <Hixie> | SimonSapin: k, i'll assume that'll get fixed later :-) |
| 19:47 | <Hixie> | SimonSapin: so long as it's on the radar |
| 19:48 | <annevk> | It's somewhat annoying to iterate over the labels and then iterate over each code point of those labels, but still |
| 19:48 | <SimonSapin> | Hixie: I’m not sure it’s on the radar :/ |
| 19:48 | <Hixie> | i can file a bug if you like |
| 19:49 | <SimonSapin> | www-style would be best, we have too many bug trackers that nobody reads |
| 19:49 | <SimonSapin> | (yes, it’s a mess) |
| 19:49 | <Hixie> | oh i assumed that the link to file a bug in the cssom spec was the preferred place for filing bugs on cssom |
| 19:49 | <Hixie> | should i be sending them to www-style instead? |
| 19:50 | <Hixie> | few people seem to keep close enough track of mailing lists to ensure that everything gets resolved |
| 19:50 | <Hixie> | so i kinda prefer filing them elsewhere |
| 19:50 | <Hixie> | but whatever works for you |
| 19:50 | <SimonSapin> | hum, maybe zcorpan follows bugzilla |
| 19:50 | Ms2ger | assumes www-style is as reliable an issue tracker as /dev/null |
| 19:51 | <Hixie> | (there's a reason i promise to respond to all html spec feedback sent to whatwg@ -- it's the only way i can guarantee that thinks don't fall through the cracks) |
| 19:51 | <SimonSapin> | I assume he put the Bugzilla link, so for CSSOM that’s probably fine |
| 19:51 | <Hixie> | k |
| 19:51 | <Hixie> | filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=24283 |
| 19:52 | <Hixie> | i wonder when i should create the style sheet for <style> |
| 19:54 | <annevk> | I suspect that's synchronous |
| 19:55 | <annevk> | You create the <style> element and its constructor will parse and create style sheet if there are contents and initialize the properties |
| 19:55 | <SimonSapin> | servo does it asynchronously (CSS parsing doesn’t block HTML parsing) |
| 19:55 | <annevk> | SimonSapin: how do you deal with scripts? |
| 19:56 | <SimonSapin> | there is no CSSOM yet |
| 19:56 | <SimonSapin> | maybe it’ll turn out we can’t do that without breaking the web, idk |
| 19:56 | <annevk> | SimonSapin: e.g. <style>body{background:lime}</style><script>alert(document.styleSheets[0].cssRules[0].cssText)</script> |
| 19:57 | <gsnedders> | Seems like a good fit for semaphores for style parsing/script execution |
| 19:57 | <annevk> | SimonSapin: you can, but at some point you need blocking |
| 19:57 | <gsnedders> | Which would avoid blocking until necessary. |
| 19:57 | <SimonSapin> | I guess accessing document.styleSheets will block script the same way waiting on layout results block scripts |
| 19:58 | <Hixie> | i'm more worried about things like <style>body{background:lime} <script>alert(document.styleSheets[0].cssRules[0].cssText)</script> body{background:blue} </style> |
| 19:58 | <annevk> | Hixie: seems more likely indeed :p |
| 19:58 | <Hixie> | (in xml) |
| 19:59 | <gsnedders> | (seems less likely then) :P |
| 19:59 | <Hixie> | (obviously in html it's not an issue since you can't put elements there without script) |
| 19:59 | <annevk> | That is beautiful though |
| 20:00 | <annevk> | Hixie: document.styleSheets.length is 0 for me there |
| 20:00 | <jgraham> | Really if that's the only example that breaks, we are all good |
| 20:00 | <annevk> | Hixie: in both Firefox and Chrome |
| 20:01 | <annevk> | Hixie: which does indeed argue against what I argued, which was silly anyway from a parser point of view |
| 20:01 | <Hixie> | maybe a better test would be <script>setInterval(function () { console.log(document.styleSheets[0].length) }, 100)</script><style> body{background:lime} /* long pause */ body{background:blue} </style> |
| 20:01 | <gsnedders> | Yeah, seems pretty irrelevant. I mean, it's not like there's masses of XML in the first place… |
| 20:01 | <annevk> | It matters how the pieces fit together |
| 20:02 | <jgraham> | It is of course possible to construct test cases that aren't amenable to parallisation |
| 20:02 | <jgraham> | It is an open question which of them actually break the web |
| 20:03 | <jgraham> | Or which represent an example of something that's commonplace on the web and so leads to breakage if not handled in serial |
| 20:03 | <gerrrttt> | gp hello dudes |
| 20:03 | <jgraham> | It is possible that the web has locked itself into requiring minimal-parallelisation |
| 20:04 | <jgraham> | But let's hope now |
| 20:04 | <jgraham> | *not |
| 20:04 | <gsnedders> | That would be very sad. :( |
| 20:04 | <annevk> | data:text/xml,<html xmlns="http://www.w3.org/1999/xhtml"><style>body{background:lime} <script>alert(1)</script> body{background:blue} </style><body/></html> |
| 20:05 | <annevk> | Hixie: with that test I cannot get it to render green, no matter how long I wait |
| 20:05 | <Hixie> | man, you're quicker at making these tests than i am |
| 20:05 | <Hixie> | are you getting anything to render at all? |
| 20:06 | <annevk> | Hixie: granted, I guess you might be able to get a difference with your other test depending on how things fit together |
| 20:06 | <Hixie> | or is it just that it blocks? |
| 20:06 | <annevk> | Hixie: it blocks |
| 20:06 | <Hixie> | oh, for xml, not for html parsing |
| 20:06 | <Hixie> | i missed your data: url |
| 20:06 | <Hixie> | i'm writing an html version |
| 20:06 | <Hixie> | but good to know |
| 20:06 | <Hixie> | maybe we just parse on </style> |
| 20:07 | <Hixie> | that would certainly be nice an simple to deal with |
| 20:07 | <Hixie> | and |
| 20:07 | <annevk> | I also tried this |
| 20:07 | <annevk> | data:text/xml,<html xmlns="http://www.w3.org/1999/xhtml"><style>body{background:red}</style><style>body{background:lime} <script>alert(1)</script> body{background:blue} </style><body/></html> |
| 20:07 | <annevk> | Also blocks :/ |
| 20:07 | <annevk> | No red |
| 20:07 | <Hixie> | yeah you probably need to try putting a <body> before the <style>, with some text in it |
| 20:07 | <annevk> | Good point |
| 20:07 | <annevk> | data:text/xml,<html xmlns="http://www.w3.org/1999/xhtml"><style>body{background:red}</style><body>test</body><style>body{background:lime} <script>alert(1)</script> body{background:blue} </style></html> |
| 20:08 | <annevk> | Is red, then blue |
| 20:08 | <Hixie> | makes sense if it's waiting for </style> |
| 20:08 | <Hixie> | what happens if you try to read offsetHeight ? |
| 20:08 | <Hixie> | in the alerting script? |
| 20:08 | <smola> | annevk: what version of Firefox are you testing with? |
| 20:08 | <Hixie> | or something else that forces layout recalc |
| 20:08 | <annevk> | smola: 29.0a1 (2014-01-06) |
| 20:09 | <annevk> | data:text/xml,<html xmlns="http://www.w3.org/1999/xhtml"><body/><style>body{background:red}</style><style>body{background:lime} <script>alert(document.documentElement.offsetHeight)</script> body{background:blue} </style></html> |
| 20:09 | <smola> | annevk: ok |
| 20:09 | <annevk> | Same colors, alerts 8 |
| 20:09 | <gsnedders> | Things that annoy me: Firefox, once it has downloaded an upload, waits to be restarted. This means if you don't restart, it'll eventually be waiting to restart into an outdated build, instead of downloading yet another, but up-to-date one. |
| 20:09 | annevk | updates Nightly |
| 20:10 | <annevk> | gsnedders: yes yes yes! |
| 20:10 | annevk | is in that circus at the moment |
| 20:10 | <gsnedders> | I just updated to the 2014-01-02 build! |
| 20:11 | <gsnedders> | From 2014-01-01! |
| 20:13 | <annevk> | smola: 29.0a1 (2014-01-13) now :-) |
| 20:13 | <gsnedders> | So the university library just redid their website to use some shiny third party system. It's now horrendously hard to search by ISBN. :( |
| 20:27 | <Hixie> | man it's hard to get browsers to render incrementally |
| 20:28 | <Hixie> | http://www.hixie.ch/tests/evil/page-loading/incremental/003.cgi |
| 20:28 | <Hixie> | ok well i've never seen a "1" |
| 20:28 | <Hixie> | so i guess yep, it waits for </style> |
| 20:34 | <annevk> | and changes to the contents cause re-parsing as well |
| 20:34 | <annevk> | hmm |
| 20:34 | <annevk> | what if the inner <script> sets the contents? |
| 20:34 | <annevk> | and then alerts? |
| 20:38 | <annevk> | Hmm, so in data:text/xml,<html xmlns="http://www.w3.org/1999/xhtml"><body/><style>body{background:lime} <script>document.documentElement.childNodes[1].textContent="body{background:purple}"</script> body{background:blue} </style></html> you can effect the tree while parsing |
| 20:38 | <annevk> | What if you remove the parent element? |
| 20:39 | <annevk> | Wait what? |
| 20:40 | <annevk> | data:text/xml,<html xmlns="http://www.w3.org/1999/xhtml"><body/><style><script>document.removeChild(document.documentElement.childNodes[1])</script> body{background:blue} </style></html> |
| 20:40 | <annevk> | <style> remains in the tree... |
| 20:40 | <annevk> | Hixie: any clue how that works? |
| 20:41 | <Hixie> | you'd have to check the xml parser spec |
| 20:41 | <Hixie> | oh wait. there isn't one. |
| 20:41 | <annevk> | Good one |
| 20:41 | <Hixie> | http://www.hixie.ch/tests/evil/page-loading/incremental/004.cgi |
| 20:41 | <annevk> | I'm reminded of jgraham who told me I already wasted a morning on XML |
| 20:41 | <Hixie> | that changes the style while the parser is running in html |
| 20:41 | <Hixie> | looks like it doesn't parse if the style is parser-provided |
| 20:52 | <annevk> | "The JQuery syntax should integrate Blink. All functions $() should run natively" :-) |
| 20:52 | <jory> | document.querySelector is pretty verbose when you compare it to $ |
| 20:53 | <TabAtkins_> | find() is pretty close to $(), though. |
| 20:53 | <annevk> | It would not be on Window |
| 20:53 | <dekiss> | where can I apply to help building HTML |
| 20:53 | <annevk> | You don't apply really, you just help out |
| 20:54 | <TabAtkins> | I thought we decided it would be okay to override the existing window.find()? |
| 20:55 | <annevk> | I'm not privy to that discussion. In fact, we're not going to name it find() as far as I know, but query(), as find() clashed. |
| 20:55 | <TabAtkins> | Hm, I didn't know that. |
| 20:56 | <Hixie> | find() clashes with the find in page API |
| 20:56 | <Hixie> | but i believe we're planning on dropping that API |
| 20:56 | <Hixie> | so it might not clash for long |
| 20:56 | <TabAtkins> | Yeah, that's what I was referring to. |
| 20:58 | <annevk> | At some point it might be some module-like thing, although I don't really see modules reducing the boilerplate much... |
| 21:00 | <annevk> | I think that's what I dislike most about modules, the increase in boilerplate for simple things. You'll just get people wrapping a bunch of modules in some other module and at some point it becomes hard to count all the turtles. |
| 21:00 | <TabAtkins> | ...What are you responding to, Anne? |
| 21:01 | <annevk> | Just trying to imagine the way forward from TC39's perspective. |
| 21:01 | <TabAtkins> | Right, but what is "it" which might be some module-like thing? |
| 21:03 | <annevk> | Oh, find/query |
| 21:03 | <annevk> | And everything else... |
| 21:07 | <Ms2ger> | SimonSapin, not exaggerated much :) |
| 21:08 | <SimonSapin> | Ms2ger: You’re hurting my feelings :) |
| 21:13 | <dekiss> | annevk-cloud thanks, sorry for late reply :S |
| 21:45 | <dekiss> | annevk-cloud how to help more specifically, here in the channel? or mailing list or..? |
| 21:46 | <Ms2ger> | Write tests |
| 21:46 | <Ms2ger> | Review tests |
| 21:46 | <Ms2ger> | Write specs |
| 21:46 | <Ms2ger> | Review specs |
| 21:46 | <Ms2ger> | Write implementations |
| 21:46 | <Ms2ger> | Review implementations |
| 21:51 | <annevk-cloud> | What Ms2ger just said dekiss; you can find pointers on the WHATWG Wiki |
| 21:55 | <Domenic_> | http://wiki.whatwg.org/wiki/FAQ for the lazy |
| 22:08 | <annevk> | data:text/xml,<html xmlns="http://www.w3.org/1999/xhtml"><body/><style>body{background:blue}<script>document.removeChild(document.documentElement.childNodes[1])</script></style></html> |
| 22:08 | <annevk> | Both Gecko and Chrome throw "NotFoundError" |
| 22:09 | <annevk> | However, if you change document.removeChild into alert it will give you the element you expect |
| 22:09 | <Ms2ger> | Hmm? What else would it do? |
| 22:09 | <annevk> | Which suggests there is a bug in http://dom.spec.whatwg.org/#concept-node-pre-remove for XML I guess? |
| 22:10 | <Ms2ger> | document.documentElement.childNodes[1] is a grandchild of document |
| 22:10 | <annevk> | Combined with the XML parser not being defined. |
| 22:10 | <annevk> | Oh |
| 22:11 | <annevk> | Thanks Ms2ger! |
| 22:11 | <Ms2ger> | Np :) |
| 22:12 | <annevk> | data:text/xml,<html xmlns="http://www.w3.org/1999/xhtml"><body/><style>body{background:blue}<script>document.documentElement.removeChild(document.documentElement.childNodes[1])</script>body{background:red}</style></html> |
| 22:12 | <astearns> | I'd prepend "report implementation bugs" to Ms2ger's list above |
| 22:12 | <Ms2ger> | astearns, sure, if you put in "accurate" :) |
| 22:13 | <astearns> | that could be added to all of the list items :) |
| 22:13 | <annevk> | So the question is more what the parser does once such an element is removed. |
| 22:13 | <Ms2ger> | Review accurate specs? Nah, that's not useful |
| 22:13 | <annevk> | data:text/xml,<html xmlns="http://www.w3.org/1999/xhtml"><body/><style>body{background:blue}<script>alert(document.documentElement.childNodes.length)</script>body{background:red}</style><test/></html> |
| 22:13 | <annevk> | Points out the <script> executes while parsing |
| 22:14 | <annevk> | data:text/xml,<html xmlns="http://www.w3.org/1999/xhtml"><body/><style>body{background:blue}<script>alert(document.documentElement.childNodes[1].textContent)</script>body{background:red}</style><test/></html> |
| 22:14 | <annevk> | Points out you it executes at </script> |
| 22:14 | <annevk> | So if <style> is gone at that point, how does the parsing still go correctly? |
| 22:15 | <Hixie> | why would it not? |
| 22:15 | <annevk> | Man, this XML thing keeps being fascinating |
| 22:16 | <annevk> | data:text/xml,<html xmlns="http://www.w3.org/1999/xhtml"><body/><style>body{background:blue}<script>var s=document.documentElement.childNodes[1];document.documentElement.removeChild(s)</script>body{background:red}</style><script>alert(s.textContent)</script></html> |
| 22:17 | <annevk> | Ah okay, so it simply puts the content into the removed element and then once that closes goes back to the original tree |
| 22:21 | <Hixie> | same as the html parser |
| 23:03 | <TabAtkins> | ...I have no idea how my code worked before. |
| 23:04 | <Hixie> | been there |
| 23:04 | <Hixie> | a schrödinbug |
| 23:06 | <TabAtkins> | It's not really, though. I just did something unrelated which showed me that I had named one function's argument a certain thing, but I was using a completely different name for it inside the function. |
| 23:07 | <TabAtkins> | I still don't know how it's working. |
| 23:07 | <TabAtkins> | Unless I'm leaking an "editor" variable globally somewhere? |
| 23:10 | <Hixie> | oh it does still work? |
| 23:10 | <Hixie> | i meant the case where you find something shouldn't work, and mysteriously, it stops working, despite the fact that it used to work fine before you noticed it shouldn't work. |
| 23:11 | <Hixie> | SimonSapin: environment encoding thing: done |
| 23:11 | <TabAtkins> | Right, I know what a schrodinbug is. |
| 23:11 | <Hixie> | i now have a requirement that basically says "the A from spec B is the C from spec D, if any, or else the E from spec F" |
| 23:11 | <TabAtkins> | This is one where my code currently works, but I don't know how. |
| 23:11 | <SimonSapin> | Hixie: r8390 right? Thanks, will review tomorrow |
| 23:12 | <Hixie> | TabAtkins: that sounds even more frustrating, possibly |
| 23:12 | <Hixie> | SimonSapin: next one, i think |
| 23:13 | <SimonSapin> | right |
| 23:22 | <TabAtkins> | Following in Anne's proud tradition, my blog comments are unusable in FF for the next two months. |