| 04:58 | <MikeSmith> | kochi1: I only just now finally had a chance to looks at your slides |
| 04:58 | <MikeSmith> | they look great |
| 04:58 | <MikeSmith> | the screenshots are great |
| 04:58 | <MikeSmith> | I think you'll be fine |
| 05:02 | <TabAtkins> | heycam: Yeah, but the token characters are just single guillemets, so you were close enough. ^_^ |
| 05:03 | <heycam> | all these different angle-looking brackets to get confused betwee :) |
| 05:03 | <heycam> | *between |
| 09:31 | <annevk> | ah shit, missed heycam |
| 12:12 | <Ms2ger> | zcorpan, if you ever are looking for something to test, I'd love to see what you'd come up with for the named getter on form / form.elements |
| 12:13 | <zcorpan> | Ms2ger: i've probably written tests for named getters on document and window, but maybe not on form |
| 12:36 | <Ms2ger> | Anyone with IE? |
| 12:37 | <Ms2ger> | Would be interested in its behaviour on http://software.hixie.ch/utilities/js/live-dom-viewer/saved/2484 |
| 12:40 | <gsnedders> | Are there really no tests for document.cookie? |
| 12:45 | <Ms2ger> | Hrm, didn't I create a PR for https://github.com/Ms2ger/web-platform-tests/compare/form-named-item ? |
| 12:46 | <Ms2ger> | Or did I |
| 12:46 | <Ms2ger> | https://github.com/w3c/web-platform-tests/pull/111 |
| 12:47 | <Ms2ger> | So, r? zcorpan gsnedders jgraham :) |
| 12:47 | <gsnedders> | If you tell me whether or not there are really no document.cookie tests? |
| 12:47 | <Ms2ger> | Where? |
| 12:47 | <gsnedders> | On web-platofmr-tests |
| 12:48 | <Ms2ger> | I see some |
| 12:48 | <gsnedders> | There are a few, but only indirectly |
| 12:48 | <Ms2ger> | Some about sandboxed iframes |
| 12:49 | <gsnedders> | And otherwise mostly used for the sake of implementing the tests. |
| 12:49 | <Ms2ger> | Some for websockets and eventsource |
| 12:50 | <Ms2ger> | ./XMLHttpRequest/responsexml-document-properties.htm |
| 12:51 | <Ms2ger> | ./old-tests/submission/W3C/domhtml/HTMLDocument12.html |
| 12:51 | <Ms2ger> | And that's about it |
| 12:57 | <gsnedders> | Someone should write some. |
| 12:58 | <Ms2ger> | Yeah, someone |
| 12:58 | <zcorpan> | get on it already, someone! |
| 12:58 | <gsnedders> | Someone is such a slacker. |
| 12:59 | <Ms2ger> | gsnedders, so I told you ;) |
| 12:59 | <zcorpan> | watcha waitin watcha waitin watcha waitin watcha waitin watcha waitin watcha waitin foooor?! |
| 12:59 | <gsnedders> | Ms2ger: I didn't say I would straight away. ;) |
| 13:01 | <zcorpan> | Ms2ger: critic link? |
| 13:01 | Ms2ger | tries to get one |
| 13:02 | <Ms2ger> | Ah, https://critic.hoppipolla.co.uk/r/116 |
| 13:02 | <Ms2ger> | Oh, jgraham reviewed it |
| 13:02 | Ms2ger | looks at his comments |
| 13:09 | <Ms2ger> | jgraham, addressed your comments |
| 13:19 | <zcorpan> | ok, in css spirit, please bikeshed https://www.w3.org/Bugs/Public/show_bug.cgi?id=23066 |
| 13:29 | <hsivonen> | Ms2ger: I find it amusing that https://bugzilla.mozilla.org/show_bug.cgi?id=909188 was about the daily WTF |
| 13:31 | <Ms2ger> | Ha |
| 13:31 | <Ms2ger> | I hadn't even noticed that |
| 13:31 | <Ms2ger> | zcorpan, contrary to popular belief, bz and dbaron are different people |
| 13:34 | <zcorpan> | Ms2ger: yeah. i wonder if i have misattributed earlier without noticing. i seem to store them in the same bucket in my head. :-/ |
| 13:34 | <Ms2ger> | How about roc? |
| 13:35 | <zcorpan> | no he has a bucket of his own |
| 13:41 | <Ms2ger> | Oh, I guess the Brits take today off for some reason |
| 13:58 | <matjas> | hsivonen: re: http://mathiasbynens.be/notes/etago#comment-8, as long as the string literal is closed correctly, is `<!--` really harmful? |
| 13:59 | <matjas> | i.e. http://software.hixie.ch/utilities/js/live-dom-viewer/saved/2485 seems safe |
| 13:59 | <matjas> | as long as the closing `"` is there |
| 14:15 | <gsnedders> | Ms2ger: s/Brits/English/ |
| 14:15 | <gsnedders> | Ms2ger: "Summer Bank Holiday (Not Scotland)" |
| 14:15 | <Ms2ger> | gsnedders, apologies |
| 14:16 | <gsnedders> | So actually s/Brits/English, Welsh, and Northern Irish/ |
| 14:16 | Ms2ger | is left wondering if the republicans in NI can take the day off |
| 14:21 | <gsnedders> | They probably use it to protest or something |
| 15:00 | <baku> | question about MessagePort: there are 2 flags: shipped and messagePortEnabled. shipped is set to true when the port is cloned. messagePortEnabled is set to true when start() is called. It's not clear to me what happens when: shipped=true and messagePortEnabled=false, shipped=false and messagePortEnabled=true, shipped=false and messagePortEnabled=false |
| 15:11 | <annevk> | zcorpan: ^^ |
| 15:12 | <zcorpan> | baku: shipped is only relevant for determining which task source to use |
| 15:13 | <baku> | zcorpan, so in which queue stores the task. is it? |
| 15:13 | <baku> | s/stores/to store/ |
| 15:13 | <zcorpan> | baku: e.g. if you create several MessageChannels in a document and post lots of messages on them, they all use the same task source so they are processed in the same order as posted |
| 15:14 | <zcorpan> | baku: but if you pass on the ports to other documents they use separate task sources so order is not guaranteed |
| 15:16 | <zcorpan> | matjas: your test case doesn't demonstrate the problem. also, behavior differs in pre-HTML5-parser browsers |
| 15:17 | <baku> | zcorpan, so, if a MessagePort is shipped (==cloned) the messages are enqueued to its port message queue. |
| 15:18 | <zcorpan> | matjas: it has nothing to do with the " |
| 15:18 | <baku> | zcorpan, otherwise we have to use this unshipped port message queue that is per event loop. |
| 15:18 | <zcorpan> | baku: yeah. although it's not quite 'per event loop' |
| 15:19 | <baku> | well.. this is what the spec says :) 'Each event loop has a task source called the unshipped port message queue' |
| 15:20 | <zcorpan> | oh. maybe you're right then :-) |
| 15:20 | <baku> | zcorpan, but I don't understand the porpoise ofthis unshipped port message queue and when it should be used. |
| 15:20 | <baku> | zcorpan, I mean, I understand when elements are appended, but it's not clear when I should use its content. |
| 15:22 | <zcorpan> | baku: before the spec used separate task sources for all ports, but then people started using lots of MessageChannels within a single document as a poor man's setImmediate(), and so the spec had a problem that the order was not guaranteed |
| 15:26 | <zcorpan> | matjas: e.g. http://software.hixie.ch/utilities/js/live-dom-viewer/saved/2486 |
| 15:26 | <matjas> | zcorpan: yeah, but at that point it’s not part of a string literal anymore |
| 15:27 | <zcorpan> | matjas: not relevant. http://software.hixie.ch/utilities/js/live-dom-viewer/saved/2487 |
| 15:27 | <matjas> | zcorpan: but http://software.hixie.ch/utilities/js/live-dom-viewer/saved/2489 is safe |
| 15:28 | <matjas> | so, it seems that as long as </script> is escaped as <\/script> (or similar), there’s no need to escape <!-- if it’s to be injected as part of a string literal |
| 15:28 | <zcorpan> | matjas: only in browsers with html5 parser |
| 15:28 | <matjas> | zcorpan: ah, so _that_’s the gotcha |
| 15:28 | <matjas> | thanks! |
| 15:29 | <zcorpan> | matjas: e.g. http://software.hixie.ch/utilities/js/live-dom-viewer/saved/2490 would make old browsers treat the whole thing as a big script |
| 15:29 | <zcorpan> | (if the last script end tag is missing they reparse) |
| 15:31 | <matjas> | confirmed, http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=2489 displays the alert in e.g. Firefox 2 |
| 15:31 | <zcorpan> | matjas: since it's easy to get a confusing result even in html5-parser browsers, the html spec makes unmatched <!-- an error |
| 15:32 | <zcorpan> | which v.nu checks |
| 15:32 | <matjas> | cool |
| 16:39 | <dglazkov> | good morning, Whatwg! |
| 16:39 | <Ms2ger> | Good evening |
| 16:43 | <jannis_1> | Good evening! |
| 16:45 | <TabAtkins> | heycam|away: The confusion is why there's a markup shortcut for tokens if you use bikeshed - <<<foo>>> generates a token link with the appropriate brackets. |
| 17:44 | <smaug____> | so how is "unshipped port message queue" supposed to work |
| 17:45 | <smaug____> | say there are two channels A and B, and ports a1, a2, b1, b2. Then one does a1.postMessage(...), b2.onmessage = function() {}; b2.postMessage(...); |
| 17:46 | <smaug____> | er, b1.postMessage() |
| 17:46 | <smaug____> | so b2 should get the message |
| 17:46 | <smaug____> | but what ends up to the "unshipped port message queue" ? |
| 17:47 | <smaug____> | what happens to the message posted to a1? |
| 17:47 | <smaug____> | Hixie_: ^ |
| 17:48 | <Hixie_> | what's the relationship between a and b? |
| 17:48 | <Hixie_> | like, why does b affect a at all? |
| 17:49 | <Hixie_> | all the unshipped port message queue does is make sure that messages on channels that haven't been sent through channels are delivered in relative order |
| 17:49 | <smaug____> | Hixie_: well, the spec says "Each event loop has a task source called the unshipped port message queue. " |
| 17:49 | <smaug____> | relative to what? |
| 17:50 | <Hixie_> | to other things in that queue |
| 17:50 | <smaug____> | Hixie_: so, if there is just one document/browsing context, there is one unshipped port message queue |
| 17:50 | <smaug____> | when does something end up to that queue? |
| 17:50 | <Hixie_> | right |
| 17:51 | <Hixie_> | it means that when you do a1.postMessage(); b1.postMessage();, you first fire a message at a2, and then you fire a message at b2. you never fire on b2 before a2. |
| 17:51 | <Hixie_> | this isn't guaranteed once you have shipped, say, b2 across a1 to a2. |
| 17:51 | <smaug____> | ahaa, so if a2 is never started, b2 |
| 17:51 | <smaug____> | never gets the message |
| 17:51 | <Hixie_> | what? no |
| 17:52 | <smaug____> | I'm trying to understand why not |
| 17:52 | <smaug____> | (note, I care only about the case when nothing is shipped) |
| 17:53 | <Hixie_> | looks like the spec is buggy in the case of unstarted ports |
| 17:53 | <baku> | another unclear stuff is what about if the port is sent to the same window: window.postMessage(a.port1); do we consider it as shipped? |
| 17:53 | <smaug____> | baku: ^ |
| 17:53 | <baku> | because we are still in the same document/browsing context. |
| 17:53 | <Hixie_> | baku: "shipped" is clearly defined -- you only consider something shipped once you run a step that says "Set new port's has been shipped flag to true" |
| 17:56 | <baku> | Hixie_, right. but what is not clear to me is that: the unshipped port message queue is used to keep messages in order when they are 'dispatched' in the same event loop/browser context. shipped flag is set to true when the port is cloned. |
| 17:56 | <Hixie_> | smaug____: ok, fixed. the unshipped port message queue ignores disabled port message queues. |
| 17:56 | <smaug____> | ok, thanks |
| 17:56 | <baku> | so it means that, cloning a port changes the queue for the messages also when the event loop/browser context doesn't change. |
| 17:56 | <Hixie_> | smaug____: good catch, thank _you_! |
| 17:56 | <Hixie_> | baku: yes |
| 17:57 | <Hixie_> | baku: the idea is that you don't know if the message channel you're sending the port through goes to the same event loop or not |
| 17:57 | <Hixie_> | baku: so you should be ready for the order to get unreliable either way |
| 17:57 | <baku> | Hixie_, ok |
| 17:57 | <Hixie_> | baku: in particular, some implementations turn all channels that have ever gone through another channel into a channel to a different "grand central station" thread |
| 17:57 | <Hixie_> | baku: so they actually can't guarantee order at that point anyway |
| 17:58 | <Hixie_> | (once you can cross threads, managing the messages when the end-points are flying around as well becomes kind of tricky) |
| 17:58 | <Hixie_> | (you either want a central dispatch thread to manage it, or you need to start setting up redirects to catch late messages) |
| 17:58 | <baku> | Hixie_, sure |
| 17:59 | <Hixie_> | note that once a message port's queue gets enabled, the relative order of messages does come back into play |
| 18:00 | <Hixie_> | so e.g. b2.start(); a1.postMessage(); b1.postMessage(); a2.start(); delivers a's message before b's. |
| 18:00 | <Hixie_> | you just silently ignore the disabled ones until it's started |
| 18:03 | <Hixie_> | smaug____: also moved some paragraphs around to try to make that area clearer. |
| 18:03 | <smaug____> | k |
| 18:04 | <smaug____> | will, re-read when reviewing the patch |
| 20:02 | <MikeSmith> | anybody have a clue why the following document would be causing a fatal parse error in the validator? |
| 20:02 | <MikeSmith> | http://w3c-test.org/web-platform-tests/master/html/semantics/forms/the-form-element/form-elements-nameditem-02.html |
| 20:03 | <MikeSmith> | http://validator.w3.org/nu/?doc=http://w3c-test.org/web-platform-tests/master/html/semantics/forms/the-form-element/form-elements-nameditem-02.htmla |
| 20:03 | <MikeSmith> | http://validator.w3.org/nu/?doc=http://w3c-test.org/web-platform-tests/master/html/semantics/forms/the-form-element/form-elements-nameditem-02.html |
| 20:03 | <Ms2ger> | Heh, I know that test |
| 20:04 | <Ms2ger> | Streaming |
| 20:05 | <Ms2ger> | MikeSmith, try <table><input></table> |
| 20:08 | <MikeSmith> | Ms2ger: ok |
| 20:08 | <MikeSmith> | the validator fails on it without indicating what the cause was |
| 20:08 | <Ms2ger> | The DOM you need is <input><table></table> |
| 20:09 | <Ms2ger> | But once you streamed the start of the table, you can't do that anymore |
| 20:09 | <MikeSmith> | I see |
| 20:18 | <zcorpan> | yeah, v.nu's parser is configured to fatal error on errors that require doing stuff that are already streamed |
| 20:19 | <zcorpan> | e.g. </head><!----><link> or <body><body foo> or <table>x |
| 20:19 | <zcorpan> | (i guess the comment isn't required) |
| 20:32 | <Hixie_> | wycats: yt? |
| 20:39 | <Hixie_> | anyone have a pointer to the latest thinking on ES6 modules? |
| 20:59 | <Hixie_> | does anyone know how es6 module loading interacts with synchronous reentrant script execution? |
| 21:03 | <wycats> | Hixie: I'm here |
| 21:03 | <Hixie_> | wycats: hey |
| 21:03 | <Hixie_> | wycats: originally i was going to say "please don't call ondemand that, it sounds like an event handler" |
| 21:03 | <Hixie_> | wycats: but now i have so many more questions about es6 modules and module loading |
| 21:03 | <wycats> | ES6 module imports are always async (except during sync eval, when they must be importing modules that are already in the registry) |
| 21:04 | <wycats> | And we're not going to call it on demand; it's an intentionally absurd name so we fix it before shipping |
| 21:04 | <Hixie_> | wycats: so what happens if you document.appendChild() an inline script that attempts to import something that's not loaded? |
| 21:04 | <wycats> | Syntax error |
| 21:05 | <Hixie_> | where would that be defined? do i have to say something in HTML to the effect of "this kind of script load is not allowed to be async", or do you automatically figure it out from the way there's JS on the stack? |
| 21:05 | <Hixie_> | i mean, at the spec level |
| 21:05 | <wycats> | the loader hooks are eval and evalAsync |
| 21:06 | <wycats> | So you'd want to decide which of those hooks to use from any given place in HTML |
| 21:06 | <Hixie_> | oh, i'm supposed to be invoking those from the html spec somehow? |
| 21:06 | <Hixie_> | interesting |
| 21:07 | <wycats> | The spec language for this is coming shortly |
| 21:07 | <Hixie_> | how about the fetching, is the interaction with HTTP done straight from JS, or will there be a hook i can use to say "use fetch.spec.whatwg.org" ? |
| 21:07 | <wycats> | The loader API really tightens up the semantics |
| 21:07 | <wycats> | The browser loader will define what its fetch hook does |
| 21:08 | <wycats> | The ES spec just calls into the fetch hook |
| 21:08 | <wycats> | Which is user overridable |
| 21:08 | <Hixie_> | ah, excellent |
| 21:08 | <wycats> | So theoretically you could use XHR |
| 21:08 | <wycats> | all the hooks but normalize are async |
| 21:09 | <Hixie_> | so the background here is that i'm trying to define some sort of better script loading mechanism in html |
| 21:09 | <Hixie_> | but i want to make sure it works with modules |
| 21:10 | <Hixie_> | is there some way i can prefill es6's notion of what modules are available, without having to fetch them all? e.g. we could have <script module="jquery" src="http://cdn.example.com/jquery.js">; ? |
| 21:10 | <wycats> | Yep |
| 21:10 | <wycats> | There's an exposed registry |
| 21:10 | <wycats> | Module names are simple strings |
| 21:11 | <wycats> | So you can put in "web/dom" |
| 21:11 | <Ms2ger> | r? http://critic.hoppipolla.co.uk/r/286 |
| 21:12 | <Hixie_> | wycats: "web/dom"? |
| 21:12 | <wycats> | An example module name |
| 21:12 | <Hixie_> | oh ok |
| 21:12 | <wycats> | import { document } from "web/Dom" |
| 21:13 | <wycats> | document.getElementById etc |
| 21:13 | <Hixie_> | let's not confuse matters by having examples that sound like web apis :-) |
| 21:13 | <wycats> | Your hook for prepopulation is the registry |
| 21:13 | <wycats> | Oh I was intentionally using a web api |
| 21:13 | <Hixie_> | i'm confused |
| 21:13 | <Hixie_> | i meant a page that has many scripts |
| 21:13 | <Hixie_> | would maybe want this registry populated with those scripts, right? |
| 21:13 | <Hixie_> | rather than wait until they are parsed |
| 21:14 | <wycats> | Scripts aren't modules :/ |
| 21:14 | <Hixie_> | oh? what's the difference |
| 21:14 | <wycats> | You're saying you want to populate the registry with module strings but not trigger an eager parse? |
| 21:15 | <Hixie_> | suppose the page has five scripts from CDNs |
| 21:15 | <Hixie_> | and they haven't arrived yet |
| 21:15 | <wycats> | Scripts are just top level programs. Modules are scoped |
| 21:15 | <Hixie_> | oh i mean <script>s |
| 21:15 | <Hixie_> | they could be modules |
| 21:15 | <Hixie_> | assume they are modules |
| 21:15 | <Hixie_> | anyway, there's also an inline <script> that says to import jquery or whatever |
| 21:16 | <Hixie_> | without some mechanism in the markup, the browser has no idea which of the five CDN-hosted files has jquery |
| 21:16 | <Hixie_> | since it won't even hear back from the CDN for another 200ms |
| 21:16 | <wycats> | I'm on my phone ATM... There are specific things to discuss here but they're hard to type on a phone |
| 21:16 | <wycats> | Tonight? |
| 21:17 | <Hixie_> | sure |
| 21:17 | <Hixie_> | ping me whenever |
| 21:18 | <wycats> | tl;dr there are thoughts on bundling that are related to what you're doing |
| 22:06 | <arv> | annevk, smaug____ What was the reason to copy the encoding when we clone document nodes? |
| 22:09 | <annevk> | arv: reason? I dunno. I thought we just wanted to define what Gecko did... |
| 22:09 | <annevk> | arv: there's observable effects for URLs and <form> though |
| 22:10 | <annevk> | holy backlog |
| 22:10 | <arv> | annevk: Ah... thanks, that answers my question. |