| 04:16 | <Domenic> | annevk or anyone: is HTMLCollection ever static? |
| 05:19 | <annevk> | Domenic: don't think so |
| 07:17 | <jochen__> | annevk: k |
| 08:09 | <schalkneethling> | morning |
| 08:10 | <schalkneethling> | I sent out a mail to the help@whatwg mailing list yesterday about the crossorigin attribute of the video element and so far have not received any helpful comments. Is there someone around that might be able to assist? |
| 08:11 | <schalkneethling> | I am curious about the value for this attribute and what restrictions that apply to CORS request |
| 08:13 | <schalkneethling> | here is the mail I sent for reference |
| 08:13 | <schalkneethling> | https://sneethling.pastebin.mozilla.org/8845530 |
| 08:46 | <annevk> | schalkneethling: it's a bit complicated due to https://github.com/whatwg/html/issues/95 not being done |
| 08:46 | <annevk> | schalkneethling: but effectively anonymous maps to only sending credentials for same-origin fetches |
| 08:47 | <annevk> | schalkneethling: and use-credentials means sending credentials for cross-origin fetches too |
| 08:47 | <schalkneethling> | thanks annevk and these credentials are sen via HTTP headers? |
| 08:47 | <annevk> | schalkneethling: and credentials means cookie headers and some more complicated stuff at the TLS layer |
| 08:48 | <annevk> | https://fetch.spec.whatwg.org/#http-network-fetch has most of the details |
| 08:48 | <schalkneethling> | thanks a lot annevk, much appreciated |
| 09:08 | <MikeSmith> | Domenic: thanks for the latest build-script review-- |
| 09:08 | <MikeSmith> | caught some good stuff |
| 09:10 | <MikeSmith> | w00t the CSP landeth |
| 09:20 | <MikeSmith> | fyi beverloo: http://stackoverflow.com/questions/32452581/html5-web-notification-icon-image-not-shown-if-more-notifications-will-be-creat |
| 09:50 | <schalkneethling> | what exactly are these credentials that are passed? I know you mentioned cookie headers, but what other credentials does this include? |
| 09:51 | <schalkneethling> | I reckon I am trying to understand the use case for using this attribute on a video element for example. |
| 09:51 | <schalkneethling> | annevk: ^^ |
| 09:51 | <annevk> | schalkneethling: see the link I gave |
| 09:52 | <annevk> | schalkneethling: you might use it if the video you show depends on whether or not the user is logged in |
| 09:52 | <annevk> | schalkneethling: e.g., you show a personalized video if the user is logged in, and a generic one if not |
| 09:53 | <schalkneethling> | ah! and so, anonymous will send those credentials for same origin request but not cross origin whereas use-credentials will send it for both |
| 09:53 | <annevk> | yes |
| 09:53 | <annevk> | anonymous is misnamed |
| 09:54 | <schalkneethling> | so essentially if you are loading video from a third party service, and that service required login credentials to determine whether you have access to the video or not, you would need to set crossorigin=use-credentials |
| 09:55 | <schalkneethling> | yeah, anonymous seems to imply no credentials at all. |
| 09:55 | <schalkneethling> | but I get it now I believe ;) Thanks again annevk |
| 10:29 | <nox> | annevk: Did you see my second adopting steps PR btw? |
| 10:44 | <beverloo> | MikeSmith, ty! +1 to your question, no idea what he means either, but I'll test around |
| 10:44 | <beverloo> | MikeSmith, fwiw, we're going to automatically dismiss Web Notifications starting Chrome 47 |
| 10:44 | <smaug____> | "Developers can set the argument r with either a promise that resolves with a Reponse object or a Reponse " I doubt "Reponse" is right there |
| 10:45 | <smaug____> | 4.5.4 in SW draft |
| 10:45 | <MikeSmith> | beverloo: ah cool |
| 10:45 | <smaug____> | ^ whoever is editing SW these days |
| 10:58 | <nox> | gsnedders: No idea if you even care, but <template> landed in Servo. o// |
| 11:55 | <MikeSmith> | https://bugs.webkit.org/show_bug.cgi?id=146336 "Chrome 43 decides that allowing the website to pollute your clipboard inside _any_ DOM event handler is no longer a concern" 😄 |
| 12:04 | <mkwst> | annevk: re: fetch and referrer, how is Fetch going to work with the concern yoav raises in https://lists.w3.org/Archives/Public/public-webappsec/2015Sep/0043.html? |
| 13:04 | <gsnedders> | nox: congrats! |
| 13:17 | <gsnedders> | jgraham: why did you stop caring about linear history for html5lib? |
| 13:22 | <jgraham> | gsnedders: "I forgot" |
| 13:31 | <nox> | Why would one care for linear history at all? |
| 13:34 | <Ms2ger> | Because it's much easier to figure out what happened |
| 13:35 | <gsnedders> | And in what order. |
| 13:43 | <nox> | How is "things happened at the merge" different from "things happened at the commit"? |
| 13:47 | <wanderview> | Domenic: can you help me understand what changed in https://github.com/whatwg/streams/pull/385 that deviates from our july discussion at mozilla? |
| 13:48 | <wanderview> | Domenic: is it just that we don't automatically unlock/release the reader when the end of the stream is reached? |
| 13:48 | <wanderview> | to avoid code using ReadableStreamReader() after its been unlocked |
| 13:49 | <annevk> | nox: yeah did, when I saw it initially I thought it should maybe be done differently, but I guess it's okay |
| 13:49 | <nox> | annevk: Wouldn't it be better to be safe now, and maybe revert it back later? |
| 13:49 | <annevk> | mkwst: Fetch already works fine with cross-origin stylesheets, that's why we allow cross-origin referrers for "passthrough requests" |
| 13:50 | <mkwst> | annevk: I was thinking about the client. That is, how do we know that the stylesheet is requesting the resource so that we can use its URL as the referrer. |
| 13:50 | <annevk> | mkwst: oh well CSS needs to set the URL correctly |
| 13:51 | <annevk> | mkwst: that's why referrer can be a URL |
| 13:51 | <mkwst> | annevk: I see. So, TabAtkins? :) |
| 13:51 | <annevk> | Yeah |
| 13:51 | <mkwst> | Where does one file bugs against whatever CSS spec I'd need to file a bug against? |
| 13:53 | <annevk> | I don't know |
| 13:56 | <Ms2ger> | www-style |
| 13:57 | <mkwst> | Ms2ger: That's not a bug tracker? :) |
| 13:57 | <astearns> | and yet it's the currently correct answer |
| 13:58 | <Ms2ger> | What makes you think you'd get a sensible process out of the csswg? |
| 14:11 | <nox> | It is that bad? |
| 14:11 | <nox> | Ms2ger: annevk says the one loop for adopting steps is fine. |
| 14:12 | <annevk> | nox: no that's not what I meant |
| 14:12 | <nox> | Disregard that, fix just got merged. |
| 14:12 | <Ms2ger> | Ha |
| 14:12 | <nox> | annevk: Yeah, I realise that now. :) |
| 14:12 | <annevk> | nox: although it might be... I haven't really figured out any bad effects yet |
| 14:12 | <nox> | With just img and template, can't think of one. |
| 14:12 | <annevk> | nox: I mostly meant that I thought the language should maybe be different, more like how it was originally, but decided against asking for that |
| 14:13 | <Ms2ger> | I agree it's probably fine now |
| 14:14 | <TabAtkins> | mkwst: Yeah, www-style is currently still the correct answer. Houdini switched to GH issues, and we're using it as a trial run to convince the rest of the group to make CSS the same. |
| 14:14 | <Ms2ger> | But I don't like running random code while one of my invariants is broken |
| 14:17 | <annevk> | Ms2ger: yeah, even with an adopt callback it would still not be problematic, but would be even more confusing and you'd have to know the callback runs as a nanotask, etc. |
| 14:17 | <annevk> | Ms2ger: seems better indeed to preserve invariants and allow implementations to optimize as they see fit |
| 14:17 | <annevk> | TabAtkins: there's also a whole bunch of Bugzilla components that Hixie and I used to file bugs in |
| 14:18 | <annevk> | TabAtkins: that sometimes get attention, but not as often as I'd like |
| 14:18 | <TabAtkins> | Right, which I need to trawl through and close out. |
| 14:19 | <annevk> | https://www.webkit.org/blog/3996/introducing-the-rendering-frames-timeline/ looks pretty interesting |
| 14:30 | <mkwst> | When is the WHATWG going to publish important work like http://www.w3.org/blog/news/archives/4965? |
| 15:43 | <nox> | gsnedders: I think there is a test that is wrong in html5lib-tests as per https://github.com/whatwg/html/pull/101. |
| 15:44 | <nox> | With "<html><ruby>a<rtc>b<rp></ruby></html>" the expectation in the tests is that the <rp> is the following sibling of <rtc>. |
| 15:45 | <nox> | But https://github.com/whatwg/html/pull/101/files#diff-36cd38f49b9afa08222c0dc9ebfe35ebR105566 says no implied end tag should be generated for <rtc>. |
| 16:06 | <annevk> | nox: in Chrome and Firefox <rp> ends up as a child, too |
| 16:06 | <nox> | annevk: In Safari it's the next sibling, but I guess we should shrug that. |
| 16:07 | <annevk> | nox: oh really? I wonder how that happened since Chrome copied their impl |
| 16:08 | <nox> | annevk: I'm not on latest OS X so I'm not sure I've got latest Safari. |
| 16:09 | <annevk> | Oh yeah, the logic WebKit landed is a little different |
| 16:09 | <annevk> | http://trac.webkit.org/changeset/167437/trunk/Source/WebCore/html/parser/HTMLTreeBuilder.cpp |
| 16:09 | <annevk> | I emailed some of the WebKit folks, but they didn't get back to me |
| 16:11 | <nox> | annevk: Sounds like déjà -vu. |
| 16:11 | <annevk> | nox: yeah, it's a bit harder to get in touch with them :-/ |
| 16:14 | <annevk> | nox: so html5lib-tests ended up with the wrong test somehow too? |
| 16:16 | <nox> | annevk: Yes. |
| 16:16 | <nox> | annevk: Expects <rtc></rtc><rb>… |
| 16:16 | <nox> | s/rb/rp/ |
| 16:23 | <annevk> | https://github.com/whatwg/html/pull/101#issuecomment-138619166 |
| 16:26 | <annevk> | When W3C forks, you've got three problems |
| 16:26 | <nox> | https://github.com/whatwg/html/pull/101#issuecomment-138621430 |
| 16:26 | <nox> | annevk: Hopefully it's a bug. |
| 16:26 | <nox> | At best it's a bug, |
| 16:26 | <Domenic> | annevk: I am at a computer with Edge now. Give me a live-dom-viewer test case? |
| 16:26 | <nox> | at worst it's undocumented crap. |
| 16:26 | <annevk> | Domenic: <rtc><script>w(getComputedStyle(document.querySelector("rtc")).display)</script> |
| 16:27 | <Domenic> | annevk: inline |
| 16:27 | <annevk> | Domenic: <ruby><rtc><rp> |
| 16:27 | <Domenic> | annevk: what about parser? |
| 16:27 | <Domenic> | annevk: ruby -> rtc -> rp |
| 16:27 | <annevk> | Domenic: <ruby><rt><rtc> |
| 16:28 | <Domenic> | annevk: ruby -> rt -> rtc |
| 16:28 | <annevk> | Domenic: <ruby><rp><rtc> |
| 16:28 | <Domenic> | annevk: ruby -> rp -> rtc |
| 16:28 | <annevk> | Domenic: seems like they haven't implemented HTML51 |
| 16:28 | <Domenic> | Yeah |
| 16:28 | <Domenic> | That is kind of what Travis's message implied but it wasn't 100% clear |
| 16:28 | <annevk> | Domenic: rtc shouldn't be a child in those scenarios |
| 16:29 | <annevk> | Domenic: yeah, not changing in forever sounded like they still support some really old stuff |
| 16:29 | <annevk> | Domenic: <ruby><rb><rt> |
| 16:29 | <Domenic> | annevk: ruby -> rb -> rt |
| 16:30 | <annevk> | Domenic: that sure looks like the pre-fork behavior, though I'm not a 100% what the old-IE behavior was |
| 16:30 | <Domenic> | yeah |
| 16:30 | <Domenic> | now we have what, three parsing behaviors and two style behaviors? |
| 16:30 | <annevk> | Domenic: three style behaviors if you count HTML51 |
| 16:31 | <annevk> | Domenic: Mozilla didn't actually implement the spec |
| 16:31 | <Domenic> | good times |
| 16:31 | <annevk> | Domenic: or maybe Mozilla's feedback never got addressed, I didn't bother to find out |
| 16:31 | <annevk> | Domenic: my style commit is for the Mozilla behavior |
| 16:31 | <Domenic> | I tend to agree with your latest plan of parsing changes only, no styling. But we should ping the browser people. |
| 16:32 | <Domenic> | I will write up a reply with @-mentions |
| 16:32 | <annevk> | thanks |
| 16:36 | <nox> | Will fix html5lib-tests. |
| 16:37 | <annevk> | nox: cool |
| 16:38 | <annevk> | nox: I'm somewhat curious how html5lib-tests ended up with the wrong tests |
| 16:38 | <annevk> | nox: I wonder if gsnedders knows |
| 16:38 | <nox> | annevk: I'm at 3 PRs already for this thing, one less or more… |
| 16:38 | <annevk> | nox: ugh |
| 16:38 | <nox> | Well, one was because I can't alphabet. |
| 16:38 | <nox> | And bot decided to go YOLO on me. |
| 16:38 | <annevk> | nox: darobin who made the HTML51 fork also contributed a patch to html5lib-tests |
| 16:38 | <nox> | https://github.com/servo/string-cache/pull/108 > https://github.com/servo/string-cache/pull/109 |
| 16:38 | <annevk> | nox: so I wonder if he got that patch wrong |
| 16:39 | <annevk> | nox: his html5lib-python impl was also wrong |
| 16:39 | <nox> | annevk: Oh wait, |
| 16:39 | <annevk> | nox: perhaps they decided on a change in parsing behavior and never let html5lib or WebKit know |
| 16:39 | <nox> | annevk: I think our tests are just outdated in html5ever. |
| 16:39 | <nox> | annevk: That patch seems to fix the test I said was wrong. |
| 16:40 | <annevk> | nox: https://github.com/html5lib/html5lib-tests/pull/27/files#diff-31f05185c1fa91686be8bf73cd5cd0bbR142 |
| 16:41 | <nox> | annevk: https://github.com/html5lib/html5lib-tests/pull/55/files |
| 16:41 | <annevk> | nox: so somewhere between December 2013 and WebKit's implementation, some change in behavior was decided upon |
| 16:41 | <nox> | annevk: Yes, in #54 and #55. |
| 16:43 | <annevk> | nox: as far as that test goes, sure (that only a single test need to be changed is somewhat worrying) |
| 16:43 | <annevk> | nox: but what about the specification? |
| 16:43 | <nox> | annevk: What do you mean? |
| 16:44 | <annevk> | nox: I mean that I think that on Dec 13 the specification prescribed the WebKit behavior and that on Feb 14 it no longer did, or some such, based on some feedback |
| 16:46 | <annevk> | nox: https://github.com/w3c/html/commit/e2ddb663fd04803d2be7f16026e2117ced167c01#diff-36cd38f49b9afa08222c0dc9ebfe35ebR100710 |
| 16:47 | <nox> | annevk: Oh! You're right. |
| 16:48 | <wanderview> | It seems JakeA grew a mustache... https://www.youtube.com/watch?v=tilH8jgLrXQ |
| 16:48 | <nox> | Not a bug in WebKit then, damn. :( |
| 16:48 | <annevk> | nox: well it's a bug in WebKit today, of sorts |
| 16:48 | <annevk> | nox: since the current spec says something else |
| 16:48 | <nox> | I mean, it didn't come into existence as a bug. |
| 16:48 | <nox> | That would be the best. |
| 16:48 | <annevk> | Nothing on the mailing list that suggests why they changed the specification though |
| 16:51 | <nox> | annevk: "New ruby model" |
| 16:51 | <nox> | Sounds clear. |
| 16:51 | <annevk> | ? |
| 16:51 | <nox> | annevk: Sarcasm. |
| 16:52 | <MikeSmith> | who was the WebKit reviewer for ththat patch? |
| 16:52 | <annevk> | Well, that Dec 13 email is somewhat clear, it's just that there's no email that explains they changed the parser again after making that change and after WebKit implemented the original text... |
| 16:52 | <annevk> | And tests against the original text landed in Python, etc. |
| 16:53 | <annevk> | The original text also didn't account properly for end-of-file behavior for fragment cases |
| 16:53 | <nox> | https://github.com/Igalia/webkit/commit/135c1f2d74a05733c5a0421745bc4e050db95d18? |
| 16:53 | <annevk> | MikeSmith: Darin |
| 16:54 | <annevk> | nox: hmm yeah, did that never land in WebKit or never make it into Safari? |
| 16:54 | <nox> | annevk: What do you mean? From what I read that's the wrong behaviour that I'm seeing in Safari. |
| 16:54 | <nox> | No? |
| 16:55 | <nox> | Cf. https://github.com/Igalia/webkit/commit/135c1f2d74a05733c5a0421745bc4e050db95d18#diff-bf6ceb92999573c891184de559e34448R196 |
| 16:55 | <annevk> | nox: sorry, I thought that was a follow up commit |
| 16:55 | <nox> | annevk: No problem. |
| 16:57 | <annevk> | So it seems like "HTML5" has a different parsing model from "HTML51" |
| 16:57 | <annevk> | And WebKit implements the former and Chromium and Gecko implement the latter |
| 16:57 | <annevk> | And Edge implements WHATWG HTML |
| 16:58 | <annevk> | That is, even http://www.w3.org/TR/2014/REC-html5-20141028/ has the "broken" parsing rules |
| 17:00 | <Domenic> | annevk, is this correct? is there a better description for (2)? https://www.irccloud.com/pastebin/HjhsQfdi/ |
| 17:00 | <annevk> | https://www.w3.org/Bugs/Public/show_bug.cgi?id=25212 hints of change too, but darobin didn't provide pointers |
| 17:02 | <annevk> | Domenic: yeah I think so, there's a couple other parsing differences most likely, but this is a good summary |
| 17:05 | <annevk> | https://www.w3.org/Bugs/Public/show_bug.cgi?id=26074 is another bug but not this one |
| 17:07 | <gsnedders> | annevk: It's been a long time since people did in-depth reviews for tests where we already have interop on, and the Ruby stuff was done mostly on trust on the basis that implementors will find the bugs |
| 17:07 | <gsnedders> | annevk: esp. given it seemed likely the spec would change after they landed |
| 17:08 | <annevk> | I can't find the root cause of HTML51 changing the parsing rules yet again :-( |
| 17:11 | <annevk> | And https://www.w3.org/Bugs/Public/show_bug.cgi?id=26074#c3 suggests WebKit implemented from the content model descriptions rather than the tree construction algorithm?! |
| 17:12 | <gsnedders> | ?! |
| 17:15 | <annevk> | Domenic: is Koji with Blink? |
| 17:15 | <annevk> | Domenic: I thought he might be independent |
| 17:16 | <Domenic> | annevk: no he's a Googler on Blink. |
| 17:16 | <annevk> | okay |
| 17:18 | <nox> | https://github.com/darobin/html-ruby/commit/94fd27f9fabf7613b7eee30b02d9b73bae99ecc9 |
| 17:18 | <annevk> | Domenic: it does seem like we should only make changes here once everyone or at least 3/4th agrees |
| 17:18 | <nox> | https://github.com/darobin/html-ruby/commit/ccf81bb51941d6e630b94a69626e6b96ce9d62fc Seems like it comes from this. |
| 17:19 | <Domenic> | annevk: yeah, that is my leaning as well. |
| 17:19 | <nox> | As in, if it's for fallback content, it should probably not end up in rtc. |
| 17:19 | <gsnedders> | nox: does html5ever have any test CLI interface reading a file/stdin and dumping some debug tree out? |
| 17:19 | <nox> | https://lists.w3.org/Archives/Public/www-archive/2013Sep/0058.html |
| 17:19 | <nox> | annevk, Domenic: |
| 17:19 | <nox> | Seems to be the one thread that matters. |
| 17:20 | <nox> | gsnedders: Yes, kinda. |
| 17:20 | <annevk> | nox: it can't be that because that is before anything landed in HTML5 |
| 17:20 | <nox> | gsnedders: The tool that produces the same output as html5lib-tests is unexposed though. |
| 17:21 | <nox> | annevk: Oh right. Well the only thing I can find is https://github.com/darobin/html-ruby/commit/94fd27f9fabf7613b7eee30b02d9b73bae99ecc9 then. |
| 17:23 | <ccardona-work> | Good morning/afternoon/evening WHATWG crew o/ |
| 17:27 | <gsnedders> | nox: /win 26 |
| 17:27 | <gsnedders> | um, uh |
| 17:27 | <gsnedders> | that doesn't work |
| 17:28 | <jgraham> | Trying to get rid of nox, indeed |
| 17:29 | <nox> | lol |
| 17:33 | <gsnedders> | nox: so is there any reasonable way to test it? :P |
| 17:34 | <nox> | gsnedders: Will look into it once I get home, but otherwise you can just write a tree_builder test and run html5ever's tests. |
| 17:35 | <gsnedders> | right, k |
| 18:01 | <wanderview> | JakeA: are you around still? |
| 18:05 | <nox> | gsnedders: What did you want to test btw? |
| 18:19 | <gsnedders> | nox: https://critic.hoppipolla.co.uk/showcomment?chain=12351 |
| 18:20 | <nox> | gsnedders: You evil person. |
| 18:20 | <gsnedders> | nox: not my test! |
| 18:20 | gsnedders | hides |
| 18:20 | <nox> | Ah ah. |
| 18:21 | <nox> | gsnedders: https://gist.github.com/nox/44f289320e3a57dac0de |
| 18:21 | <nox> | Fail. |
| 18:22 | <nox> | <em> in <aside> missing. |
| 18:23 | <nox> | gsnedders: Oh right, |
| 18:23 | <nox> | gsnedders: as long as it only involve the HTML namespace, |
| 18:23 | <nox> | gsnedders: You can do echo '…' | target/debug/examples/print-rcdom |
| 18:24 | <nox> | https://gist.github.com/nox/123af37323ff5c329336 |
| 18:26 | <nox> | gsnedders: Did we get active formatting markers or whatever wrong? |
| 18:27 | <nox> | Or is the test wrong? |
| 18:28 | <gsnedders> | nox: I think the test is wrong |
| 18:28 | <nox> | gsnedders: Good. |
| 18:28 | <gsnedders> | nox: it's from Blink and AFAICT only Blink pass |
| 18:28 | <gsnedders> | nox: But I haven't sat down to check what the spec says |
| 18:28 | <gsnedders> | nox: Because hand executing the AAA, ewww |
| 18:29 | <nox> | You know, |
| 18:29 | <nox> | when you say AAA, |
| 18:29 | <nox> | I read this as AAAAA, |
| 18:29 | <nox> | which designate the best kind of https://en.wikipedia.org/wiki/Andouillette. |
| 18:30 | <nox> | Which is better than AAA, for sure. |
| 18:41 | <nox> | gsnedders: Doesn't look like <em> is popped off the stack of active formatting elements. |
| 18:41 | <nox> | But "If the last (most recently added) entry in the list of active formatting elements is a marker, or if it is an element that is in the stack of open elements, then there is nothing to reconstruct; stop this algorithm." |
| 18:48 | <nox> | gsnedders: Try this: |
| 18:49 | <nox> | <b><em><foo><aside></b></em> |
| 18:49 | <nox> | <b><em><foo><foo><aside></b></em> |
| 18:49 | <nox> | <b><em><foo><foo><foo><aside></b></em> |
| 19:04 | <mkwst> | annevk: did you work out the null client for navigation thing? |
| 19:05 | <mkwst> | annevk: If the properties in Fetch are solid, I'll update MIX. If things are still in flux, I'll hold off a bit. |
| 19:18 | <mkwst> | annevk: Eh. It looks solid enough. :) Hopefully https://github.com/w3c/webappsec/commit/05c7c4caf52596baab0acb85083be3a1dd710ae2 makes sense. |
| 20:50 | <gsnedders> | nox: yeah, I've noticed this already. |
| 20:51 | <gsnedders> | nox: it's just working out what is right :P |
| 20:54 | <gsnedders> | nox: Edge seems to match WebKit/Blink here, blargh |
| 20:55 | <nox> | gsnedders: Looks weird that the em suddenly disappears when there are three foos. |
| 21:00 | <gsnedders> | nox: yes, but this is expected to avoid O(n^2) behaviour |
| 21:02 | <nox> | gsnedders: Oh ok. |
| 22:59 | <nox> | In HTML5, isn't the insertion point always either undefined or after the last consumed character that was fed into the input stream at that script nesting level? |
| 23:26 | <nox> | https://html.spec.whatwg.org/multipage/webappapis.html#dom-document-write I don't understand the part about script end tag in step 7. :( |
| 23:29 | <gsnedders> | nox: <script>document.write("</" + "script>");</script> is such a case, no? |
| 23:29 | <nox> | gsnedders: I think so. What is it supposed to do? |
| 23:32 | <gsnedders> | um, it doesn't do what I thought |
| 23:32 | <nox> | gsnedders: What was your intuition? To see if it's the same as mine. |
| 23:33 | <gsnedders> | <script>document.write("</" + "script>xxx");</script> |
| 23:33 | <gsnedders> | what happens to the xxx? |
| 23:34 | <nox> | Yeah. |
| 23:35 | <nox> | 1<script>document.write('2<','script><','/script>3');document.write('4<','script><','/script>5');</script>6 |
| 23:35 | <nox> | Err, |
| 23:35 | <nox> | 1<script>document.write('2<','/script>3');document.write('4<','/script>5');</script>6 |
| 23:36 | <nox> | I expected 124356, or 124536. |
| 23:36 | <nox> | I got 123456, so I don't understand the bits about </script>. |
| 23:36 | <gsnedders> | It's been years since I've touched this much though :) |
| 23:39 | <nox> | To me, it sounds like all arguments should be written in the input buffer, but some are processed at call-time, and some when the parser resumes. |