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://&#xff05;61.com">test</a> points to a.com
16:15
<annevk>
<a href="http://&#xff05;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.