| 02:13 | <MikeSmith> | hsivonen: I hope the validator.nu instability isn't related to any changes I made to the sources recently |
| 02:14 | <MikeSmith> | hsivonen: Please let me know if I can help with troubleshooting |
| 02:17 | <MikeSmith> | hsivonen: I'm wondering if validator.nu might be running on a 32-bit system. If so I wonder if with the current validator codebase we might be reaching the point where it doesn't run so well on 32-bit systems. |
| 02:19 | <MikeSmith> | hsivonen: All the w3c validator.nu instances I manage are running on 64-bit systems, and my local testing environment is 64 bit, so I haven't been doing much to make sure it still works on 32-bit systems. |
| 02:21 | <MikeSmith> | hsivonen: I have observed that jing seems to do a huge amount of recursion in order to process the current schema, and on 32 bit systems that seems to exhaust the default Java thread stack size. |
| 02:23 | <MikeSmith> | hsivonen: So on 32 bit systems I think the current validator sources won't even run any longer unless you tell Java to increase the thread stack size to 512K |
| 02:33 | <MikeSmith> | Hixie: for some reason http://wiki.whatwg.org/wiki/MicrosyntaxDescriptions is getting served to validator.nu as application/xml |
| 02:41 | <a-ja> | Hixie: $RANDOM comment: <link rel=stylesheet scoped> plays better with CSP than <style scope>@import</style>...avoids all the nonce nonsense...am I missing something here? |
| 02:42 | <a-ja> | s/scope/scoped/ |
| 02:43 | <roc> | a-ja: are you suggesting that <style scoped> should go away? |
| 02:43 | <roc> | a-ja: because <style scoped> with an actual inline stylesheet is potentially very useful |
| 02:43 | <a-ja> | perhaps an impl experience for https://www.w3.org/Bugs/Public/show_bug.cgi?id=20166 |
| 02:44 | <a-ja> | roc: just saying it's a PITA with CSP |
| 02:44 | <a-ja> | roc: have to use 'unsafe-inine' or a nonce |
| 02:44 | <a-ja> | *inline |
| 02:47 | <a-ja> | roc: guess i'm arguing for scoped on link in addition to on style |
| 05:31 | <JakeA> | Hixie: wasn't this Kyle's "social media button" usecase? Load the script but don't run it until mousedown or something like that |
| 06:00 | <Hixie> | JakeA: yeah, i got confused about precaching vs aggressivey loading. |
| 08:34 | <zcorpan> | Ms2ger: the Ethiquable Madagascar 85% was really nice :-) |
| 08:36 | Ms2ger | takes note :) |
| 08:42 | <zcorpan> | MikeSmith: it seems people are starting to use <picture> markup about now (with picturefill). maybe time to implement it in v.nu (with a warning that it's not shipped in browsers yet)? |
| 08:43 | <zcorpan> | MikeSmith: srcset with x descriptor is shipped, but the other stuff not yet |
| 09:09 | <jgraham> | Does anyone know where hallvors hangs out these days? |
| 09:10 | <odinho> | Maybe the mozilla server. |
| 09:11 | <jgraham> | Oh, I was being dumb |
| 09:48 | jgraham | hands out the party hats |
| 09:56 | <darobin> | we get party hats? |
| 09:57 | <jgraham> | Yes. And there will be cake. |
| 09:59 | <jgraham> | (http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2004-June/211753.html) |
| 10:02 | <darobin> | oooh |
| 10:02 | <darobin> | I'd written that down and then forgot about it |
| 10:02 | <darobin> | happy birthday :) |
| 10:12 | <annevk> | 🎉 |
| 10:13 | <annevk> | 🍰 for jgraham |
| 10:15 | <jgraham> | Oh, a U+FFFD, just what I always wanted |
| 10:24 | <annevk> | jgraham: it might be displayed as such, but isn't it what's underneath that matters? |
| 10:26 | <annevk> | mpt: why the WhatWG casing? |
| 10:29 | <mpt> | annevk, long-standing house style — no acronym with pronouncable portions can have more than three capital letters (cf. Pantone, Nasa, Unicef) |
| 10:29 | <annevk> | mpt: your house style? |
| 10:30 | <mpt> | Yes. :) Otherwise it’s just a cheap way for organizations to grab attention by claiming that their name is entirely capitalized. |
| 10:56 | <zcorpan> | i'd prefer all-lowercase if you want less attention-grabbing :-P |
| 11:27 | <jgraham> | Haha |
| 11:27 | <jgraham> | html-wg chair asks for volunteer to do actual work |
| 11:28 | <jgraham> | Only response is "maybe we can look for someone else to do it" |
| 11:28 | <annevk> | jgraham: pointer? |
| 11:29 | <jgraham> | http://www.w3.org/mid/6f4822f9ac664bd6bdd52ab323882713⊙Bnpoc |
| 11:29 | <jgraham> | To be afir he didn't ask all that long ago |
| 11:29 | <jgraham> | So maybe someone will step forward |
| 11:30 | <jgraham> | But I wouldn't bet on it |
| 11:52 | <annevk> | http://www.macrumors.com/2014/06/03/lighting-cable-headphone-mfi/ hmm, headphone jack to become obsolete |
| 11:53 | <caitp> | colour me skeptical |
| 11:53 | <annevk> | jgraham: I wonder why they don't take guidance from their mode of operation and fork some existing tests |
| 11:54 | <jgraham> | annevk: I presume the problem is that there isn't anything to copy |
| 11:54 | <jgraham> | So nothing is happening |
| 11:54 | <annevk> | jgraham: I doubt they landed without tests |
| 12:06 | <jgraham> | annevk: Oh well if you mean like that, it's not a bad suggestion. Except everyone's existing tests are so ghettoised that porting them is also a huge amount of work |
| 13:27 | <tobie> | Are there any difference between these two WebIDL fragments: https://gist.github.com/tobie/5e89cd37dd8b819905c4 ? |
| 13:27 | <tobie> | (Outside of the fact that the NoInterfaceObject one can be reused in multiple interfaces) |
| 13:29 | <annevk> | I think not |
| 13:29 | <annevk> | However, this bit of IDL is super tricky and could use clearer wording and such |
| 13:32 | <tobie> | Can't that be said pretty much of each bit of idl? |
| 13:37 | <annevk> | tobie: a lot is quite clear, it's just that this implements/interface/[NoInterfaceObject]/partial interface/... is a bit of a pain |
| 13:37 | <annevk> | tobie: now that we know the requirements we can come up with something better |
| 13:37 | <tobie> | :) |
| 13:37 | <annevk> | tobie: and there's some suggestions in some bug on how to do that |
| 13:37 | <tobie> | k |
| 13:43 | <tobie> | I find input types of function extremely unintuitive too. |
| 13:45 | <tobie> | I'm still unsure whether foo(DOMString bar) means it'll throw or type coerce when passed say an object. |
| 13:49 | <Ms2ger> | Coerce |
| 13:49 | <JakeA> | annevk: I've been struck by a mystery food illness, so I've spent the morning lying in bed thinking about preflight requests triggered by the page. Think there's a security issue. Page makes XHR request with fancy headers, SW responds "yeeeep, go ahead" to the preflight, then allows the subsequent CORS request to hit the network. |
| 13:49 | <JakeA> | Circumvented CORS preflight |
| 13:50 | <JakeA> | Don't think preflight requests should ever go to the SW |
| 13:50 | <annevk> | JakeA: agreed |
| 13:50 | <JakeA> | but the request should go to the SW before the preflight |
| 13:51 | <annevk> | tobie: yeah it's not great |
| 13:51 | <annevk> | JakeA: the preflight is only to ensure the server knows about CORS, I think we can assume that in case of SW |
| 13:52 | <tobie> | Ms2ger: so when does it coerce and when does it throw? |
| 13:52 | <JakeA> | annevk: Which server? |
| 13:52 | <annevk> | JakeA: any |
| 13:53 | <Ms2ger> | tobie, when there's a sensible coercion, I guess |
| 13:53 | <annevk> | JakeA: so we need to alter http://fetch.spec.whatwg.org/#cors-fetch-with-preflight somehow |
| 13:53 | <tobie> | Ms2ger: haha |
| 13:53 | <JakeA> | annevk: You only need to preflight if SW doesn't handle the request |
| 13:54 | <tobie> | Ms2ger: So what exactly does input types tell us? |
| 13:54 | <Ms2ger> | tobie, what type you'll get after WebIDL has done its thing |
| 13:54 | <annevk> | JakeA: I guess that algorithm needs a step 0 to invoke "handle a fetch" |
| 13:55 | <JakeA> | annevk: agreed |
| 13:55 | <JakeA> | annevk: and a flag to prevent preflights going into the SW |
| 13:55 | <annevk> | JakeA: and then in addition we need to annotate the request object to make sure that in step 3 it does not ask the SW again |
| 13:56 | <JakeA> | :D |
| 13:57 | <annevk> | Bit unfortunate we need to have separate places for SW integration |
| 13:57 | <tobie> | Ms2ger: so when I say foo(DOMString s), what that means implementation wise is: coerce whatever you get into a DOMString. |
| 13:57 | <annevk> | tobie: it means ToString(s) |
| 13:58 | <annevk> | tobie: see http://heycam.github.io/webidl/#es-DOMString |
| 13:59 | <tobie> | Stupid question, but why don't we write: foo(ToString(s))? |
| 14:00 | <annevk> | tobie: because IDL is based on OMGIDL |
| 14:01 | <JakeA> | annevk: unless we continue to send preflights to the SW, but if the SW handles the preflight it must also handle the main request. Feels tricky to reason about though. |
| 14:01 | <JakeA> | having the SW handle preflights feels too tricky |
| 14:02 | <annevk> | JakeA: it doesn't make much sense either |
| 14:02 | <JakeA> | Agreed |
| 14:02 | <MikeSmith> | zcorpan: I've already implemented the schema support for <picture>/<source> and updated the schema for <img> with @sizes and @srcset |
| 14:02 | <MikeSmith> | zcorpan: https://github.com/validator/syntax/compare/picture |
| 14:03 | <zcorpan> | MikeSmith: oh. nice! |
| 14:03 | <MikeSmith> | zcorpan: well that part was easy. What remains is that I need to implement error-reporting parsing support for @sizes and @srcset |
| 14:03 | <zewt> | <picture>? yuck |
| 14:04 | <MikeSmith> | zcorpan: I plan to work on that this weekend |
| 14:04 | <Ms2ger> | tobie, because you don't have a "ToString" after you're done? |
| 14:04 | <zcorpan> | MikeSmith: these should be invalid https://gist.github.com/jeremys/73817e90bc3cf83aa4c5 |
| 14:05 | <Ms2ger> | tobie, but let's assume foo(ToString(s)) makes sense. What do you do for 'DOMString?'? |
| 14:05 | <tobie> | Ms2ger: what do you mean? |
| 14:05 | <zcorpan> | MikeSmith: "When a source element is a child of a picture element and has a following sibling source element or img element with a srcset attribute specified, it must have at least one of the following:" http://picture.responsiveimages.org/#the-source-element |
| 14:05 | <Ms2ger> | tobie, foo(DOMString? arg) |
| 14:06 | <tobie> | Oh, hadn't see the double "?" sorry |
| 14:06 | <tobie> | foo(ToString(s?)) |
| 14:07 | <tobie> | no sorry: foo(ToString(s)?) |
| 14:08 | <MikeSmith> | zcorpan: yeah there are some really unusual doc-conformance contraints in the picture spec. I'll need to write some custom code for those. There's no way to express them in the schema. |
| 14:08 | <zcorpan> | MikeSmith: feedback welcome if something is insane |
| 14:09 | <MikeSmith> | zcorpan: my feedback for now is, there's no precedent in the HTML for at least one of those constraints |
| 14:10 | <MikeSmith> | zcorpan: can't remember which one, but maybe it's the one you quoted above |
| 14:10 | <tobie> | Ms2ger: thing is, generally input types described allowed types, while we're using them here to describe transformations to any type. |
| 14:11 | <Ms2ger> | foo(ToString(s)?) doesn't make any sense to me |
| 14:11 | <zcorpan> | MikeSmith: i guess we can make it slightly simpler like require media to be present regardless of its value |
| 14:11 | <Ms2ger> | It's not a type you're converting to, and it's not an algorithm |
| 14:13 | <tobie> | Well, ToString() is the shorthand for an algorithm, no? |
| 14:14 | <annevk> | http://people.mozilla.org/~jorendorff/es6-draft.html#sec-tostring |
| 14:15 | <annevk> | Anyway, until someone maintains IDL chatting about it is rather moot |
| 14:15 | <MikeSmith> | zcorpan: well I suspect those contraints are symptoms or consequences indicating that authoring <picture><source> correctly is error-prone, so authors are going to make a lot of mistakes |
| 14:15 | <MikeSmith> | zcorpan: so it'll be nice to have validator support to help them catch the mistakes |
| 14:16 | <annevk> | JakeA: it's not that simple I think |
| 14:17 | <MikeSmith> | zcorpan: one constraint I guess you know we can't practically check is the one that says the specified dimensions have to match the intrinsic dimensions of the image (or whatever case where that's required) |
| 14:17 | <zcorpan> | MikeSmith: it's a bit hard to grasp how the stuff works and things have changed from e.g. the current TR/ version so yeah some pointers from the validator would be great |
| 14:17 | <annevk> | JakeA: "HTTP fetch" does a bunch of things to a request we would want to do in this case as well before passing it to the SW |
| 14:17 | <zcorpan> | MikeSmith: yeah. html has something similar for the width="" attribute |
| 14:17 | <zcorpan> | MikeSmith: could be checked for in devtools though when the image is loaded |
| 14:18 | <MikeSmith> | yeah |
| 14:19 | <MikeSmith> | zcorpan: I mean, we could check it in the validator. it's possible. But I think it would not be a good idea due to the performance cost |
| 14:19 | <JakeA> | annevk: hmm, so it needs to prep the final request, send it to the SW, if unhandled or default() do the preflight before making the final request |
| 14:19 | <zcorpan> | MikeSmith: agree |
| 14:21 | <annevk> | JakeA: and if it's handled, we want the normal "HTTP fetch" handling for the response I think |
| 14:22 | <MikeSmith> | zcorpan: anyway, thanks for that URL. I guess you know we're rightly going to need a lot of validator tests for this at some point. Ideally would be nice to have some while I'm implementing the validator support but that would require me to stop and write them first. So I'm going to forge ahead without them for now. I'm sure that's considered a sin, but I'm a sinner already so oh well |
| 14:22 | <JakeA> | annevk: agreed |
| 14:23 | <zcorpan> | MikeSmith: that's fine :-) |
| 14:23 | <annevk> | JakeA: it almost seems this algorithm should be merged into "HTTP fetch" as an additional flag |
| 14:23 | <zcorpan> | MikeSmith: i can write some tests tomorrow maybe |
| 14:24 | <annevk> | JakeA: which people hate, but it would handle all the cases |
| 14:24 | <JakeA> | annevk: Why the hate? |
| 14:25 | <JakeA> | I guess it's like one long function rather than a separate one for CORS preflight |
| 14:25 | <tobie> | annevk: sure, though, tbh, I'm still at the "trying to figure it out" phase at this point. |
| 14:25 | <annevk> | JakeA: not sure if there's much hate, but in general it would be less readable than having nice short functions |
| 14:25 | <JakeA> | heh |
| 14:25 | <JakeA> | true |
| 14:25 | <MikeSmith> | zcorpan: that'd be great if you can make time. I'll be a plane pretty much all day on Sunday so I'm planning to use that time to try to get most of the srcset/sizes parsing+reporting part done |
| 14:25 | <annevk> | JakeA: I don't really see a good alternative though |
| 14:26 | <zcorpan> | MikeSmith: i hope you'll be able to transform back into MikeSmith afterwards |
| 14:27 | <MikeSmith> | heh |
| 14:28 | <MikeSmith> | zcorpan: yeah I see I forgot the hyphen, "I'll be a-plane all day" |
| 14:28 | <JakeA> | annevk: If I make a cross-origin XHR request, but respondWith a non-opaque response, can we skip the CORS check? |
| 14:29 | <JakeA> | annevk: because .respondWith(new Request("Hello!")) would fail at the moment wouldn't it? |
| 14:29 | <annevk> | I was wondering why darobin was asking about document.origin rather than the myriad of other features in DOM with poor implementations support. Seems Glenn Adams made a test case |
| 14:29 | <zcorpan> | MikeSmith: i don't know what a-plane means :-( |
| 14:30 | <darobin> | annevk: indeed |
| 14:30 | <darobin> | but more generally I was wondering why something that strikes me as useful and not hard to implement wasn't there |
| 14:30 | <annevk> | darobin: exhibit n as to why things are broken over there |
| 14:31 | <annevk> | JakeA: yeah, I think it would be great if we made that work |
| 14:31 | <darobin> | annevk: I care about solutions — exhibits? *yawn* |
| 14:32 | <MikeSmith> | zcorpan: some quaint archaic verb form, like "He was a-horse in battle when he met his end", meaning he was riding a hore |
| 14:32 | <zewt> | riding a, err... |
| 14:32 | <annevk> | JakeA: I haven't really gotten there yet |
| 14:32 | <JakeA> | annevk: I guess step 11 nees to be part of the "if" in step 10 |
| 14:33 | <zcorpan> | MikeSmith: ok :-) |
| 14:33 | <darobin> | riding a hore? |
| 14:33 | darobin | won't presume which letter is missing there |
| 14:33 | <JakeA> | annevk: no worries, just spotting stuff as I see it |
| 14:34 | <annevk> | JakeA: ah yes, that prolly makes sense, only do CORS checks for network retrieved resources |
| 14:35 | <zewt> | am I the only one completely bewildered by bugs like "Define code values for the special keys on Sun keyboard" |
| 14:35 | <jgraham> | MikeSmith: Nice try, but your secret identity as transformer and star of a franchise of terrible* films has been revealed (*probably. I haven't ever watched them.) |
| 14:35 | <JakeA> | annevk: If the original request has a CORS flag, you'll still want to error on tainted responses from the SW |
| 14:36 | <annevk> | JakeA: yeah, wasn't sure if we should do that in the network layer or the API layer, fetch layer prolly makes sense |
| 14:36 | <annevk> | s/network/fetch/ |
| 14:38 | <MikeSmith> | jgraham: terrible in the Ivan the Terrible sense yeah |
| 14:48 | <annevk> | JakeA: okay so I guess I need to merge those two algorithms |
| 14:48 | <annevk> | JakeA: CORS fetch with preflight and HTTP fetch, unless you see another way |
| 14:54 | <annevk> | JakeA: I guess I'll introduce a "CORS preflight flag" that'll be set and it'll take care of the necessary branching |
| 14:54 | <JakeA> | annevk: yeah, I can't think of another way, seems like the best plan |
| 15:19 | <JakeA> | TabAtkins: https://twitter.com/tabatkins/status/474207822620921856 - tell me more sir |
| 15:31 | <JakeA> | TabAtkins: Sounds like what you want is a fetch that uses credentials & become non-tainted if CORS headers are there, but doesn't fail if CORS headers are absent. I don't think this happens anywhere already, but I want it for serviceworkers |
| 15:35 | <annevk> | JakeA: https://twitter.com/jaffathecake/status/474212681839575040 use crossorigin=use-credentials |
| 15:36 | <annevk> | nooo, not more modes :-( |
| 15:38 | <JakeA> | annevk: where's use-credentials mentioned? Makes sense, but I can't find it on http://www.whatwg.org/specs/web-apps/current-work/multipage/semantics.html#attr-link-crossorigin |
| 15:38 | <annevk> | JakeA: follow the link from there to http://www.whatwg.org/specs/web-apps/current-work/multipage/fetching-resources.html#cors-settings-attribute |
| 15:39 | <JakeA> | annevk: Gotcha! |
| 15:57 | <JakeA> | annevk: In terms of the extra mode, I'm concerned about how complicated caching a cross-domain resource is currently. But if anything, I hope to get to the bottom of why img responses with CORS headers (including credentials) must still be tainted |
| 16:20 | <annevk> | JakeA: caching those would be hard anyway as that requires more than just using a wildcard |
| 16:22 | <JakeA> | annevk: What does it need on top of Access-Control-Allow-Credentials: true? |
| 16:22 | <annevk> | JakeA: to make sure the headers are not static |
| 16:23 | <annevk> | JakeA: we don't want it to be trivial to expose credentialed resources |
| 16:26 | <JakeA> | annevk: what do you mean by "static" headers? |
| 16:27 | <annevk> | JakeA: headers which you could include without doing something conditional |
| 16:28 | <annevk> | I'm surprised you don't know about CORS |
| 16:28 | <annevk> | I wonder how many other developers don't |
| 16:34 | <JakeA> | annevk: It's not something I've used a whole lot, so I'm rusty on the headers. However, see http://vimeo.com/77497239#t=48m10s |
| 16:35 | <JakeA> | the room on average does really badly in those questions |
| 16:40 | <annevk> | JakeA: thanks for that |
| 16:40 | <annevk> | JakeA: third question is fun |
| 16:40 | <JakeA> | annevk: is that the text/plain one? |
| 16:41 | <annevk> | JakeA: yeah, ah, you gave the next one away at the end |
| 16:41 | <JakeA> | most people still got it wrong |
| 16:42 | <annevk> | heh |
| 16:42 | <annevk> | yeah, I guess they needed that tip |
| 16:53 | <annevk> | JakeA: https://github.com/whatwg/fetch/commit/7fd1a7a34edf06e230d99523190e0e8c059ebd01 |
| 16:53 | <annevk> | JakeA: I don't want setting .body to work |
| 16:54 | <annevk> | JakeA: not without something that gives guarantees of .body = x; .body == x |
| 16:57 | <JakeA> | annevk: agreed, would be nice if you could set body but happy to throw if it isn't a stream |
| 16:58 | <JakeA> | annevk: changes look good, will take a closer look tomorrow when I'm (hopefully) not all food poisoned |
| 17:19 | <astearns> | Hixie: I think you've been asking for something like this: http://globau.wordpress.com/2014/06/04/bugzilla-can-now-show-bugs-that-have-been-updated-since-you-last-visited-them/ |
| 17:19 | <astearns> | not exactly what you wanted, but closer |
| 19:22 | <Hixie> | jorendorff: so i think what i'm going to try to do is write up a description of how the Loader thing works, first. rather than try to just jump to writing extensions of it. |
| 19:26 | <jorendorff> | Hixie: ok. ping me on irc if you need anything, i suck at email |
| 19:27 | <jorendorff> | Hixie: description of how the Loader works at a spec level? |
| 19:27 | <Hixie> | yeah, like, writing an alternative equivalent spec for what there is now |
| 19:27 | <Hixie> | from what i understand, what there is now is literally generated from code |
| 19:27 | <Hixie> | which imho makes it hard to understand |
| 19:28 | <Hixie> | (might be easier to just read the original code, actually) |
| 19:32 | <jorendorff> | well, it's not literally generated from code, but the code did precede the text. |
| 19:34 | <jorendorff> | Adhering to ES spec conventions instead of using prose (or, inventing new conventions) is a big part of how awful it is |
| 19:35 | <jorendorff> | (I wrote a bunch of that, but don't tell anyone) |
| 19:35 | <jorendorff> | (Alan Smithee wrote it) |
| 19:36 | <Hixie> | examples and non-normative colour would go a long way :-) |
| 19:38 | <jorendorff> | agreed |
| 19:39 | <jorendorff> | non-normative what the hell is this thing would go a long way |
| 19:39 | <jorendorff> | on the individual parts |
| 19:39 | <jorendorff> | indeed many parts of that spec could use that kind of love |
| 19:45 | <zewt> | terrible spec style, but at least it tells you what to do instead of describing what the result should be, like way too many specs |
| 19:57 | <Hixie> | jorendorff: ok let's start with teh simplest question, i guess. Where do I start? Do I tell the ES system that I want to run a script (not a module) with a particular URL, or do I hand it some source? |
| 19:58 | <Hixie> | assuming just regular old <script> for now |
| 20:21 | <jorendorff> | Hixie: you want to know how <script> talks to the ES spec? looking |
| 20:22 | <jorendorff> | http://people.mozilla.org/~jorendorff/es6-draft.html#sec-runtime-semantics-scriptevaluation |
| 20:22 | <jorendorff> | note the NOTE |
| 20:24 | <Hixie> | so the answer to my question is i hand it some source, right? |
| 20:25 | <Hixie> | and presumably decided to Unicode? the ES spec doesn't do any character encoding conversion, right? |
| 20:25 | <Hixie> | decoded |
| 20:26 | <Hixie> | not decided |
| 20:29 | <Hixie> | jorendorff: how does http://people.mozilla.org/~jorendorff/es6-draft.html#sec-initialization fit into this? |
| 20:32 | <jorendorff> | Hmm. that section is relatively new |
| 20:32 | <jorendorff> | I don't know. |
| 20:33 | <jorendorff> | Hixie: when I want to understand how this works i look at http://people.mozilla.org/~jorendorff/es6-draft.html#sec-eval-x |
| 20:33 | <jorendorff> | Hixie: an indirect call to eval is very much like <script> |
| 20:38 | <jorendorff> | Hixie: even though it *looks* like character encoding conversion is happening there, it's really just saying "decode this string of 16-bit code units to unicode, using UTF-16" |
| 20:41 | <zewt> | that sounds like a conversion to me :) |
| 20:42 | <zewt> | ("decode 16-bit units to unicode using utf-16" says "collapse surrogate pairs to single unicode codepoints" to me) |
| 20:46 | <jorendorff> | zewt: yes, it is a conversion, but not in the sense hixie meant |
| 20:46 | <jorendorff> | the spec wants you to give it unicode, not bytes |
| 20:47 | <jorendorff> | confirmed |
| 20:57 | <Hixie> | jorendorff: yeah but for eval you don't have to create a realm and so on, right? |
| 20:58 | <Hixie> | it seems to me like #sec-initialization is the thing that's trying to define how <script>s work in a web page |
| 20:58 | <Hixie> | though it doesn't really map that cleanly |
| 20:58 | <jorendorff> | Hixie: you don't create a realm for each <script> either |
| 20:58 | <Hixie> | right |
| 20:58 | <Hixie> | hence the #sec-initialization step 7 |
| 20:58 | <Hixie> | though i've no idea what step 8 means |
| 20:59 | <Hixie> | and i doubt steps 7 and 8 actually describe what happens on the web |
| 20:59 | <jorendorff> | i'm glad you know what step 7 is about because i sure don't |
| 20:59 | <jorendorff> | "synchronously obtain source code" wat |
| 20:59 | <Hixie> | well i'm just guessing |
| 20:59 | <Hixie> | it doesn't say it's synchronous |
| 20:59 | <Hixie> | it says "In an implementation dependent manner" |
| 20:59 | <Hixie> | i have more of a problem with step 8 |
| 21:00 | <Hixie> | i wonder how step 5 can be abrupt |
| 21:01 | <Hixie> | seems to me that if http://people.mozilla.org/~jorendorff/es6-draft.html#sec-setdefaultglobalbindings fails when no script has yet run, you have a bad situation on your hands... |
| 21:02 | <jorendorff> | Hixie: abstractly, the realm and global for a given document are created super early, before parsing really even starts |
| 21:02 | <jorendorff> | Hixie: parsing, abstractly, adds DOM objects to the doctree, right? |
| 21:02 | jorendorff | doesn't really know |
| 21:02 | <Hixie> | very abstractly, es |
| 21:02 | <Hixie> | yes |
| 21:03 | <Hixie> | HTML has tons of prose around how <script>s execute |
| 21:03 | <Hixie> | but i don't have anything about realms |
| 21:03 | <jorendorff> | if so, and those are JS objects, then the realm has to exist first, for those objects to have suitable prototype chains |
| 21:03 | <Hixie> | i do create the global |
| 21:03 | <Hixie> | one would imagine |
| 21:03 | <jorendorff> | the realm is really just the global and all that javascripty stuff |
| 21:03 | <jorendorff> | so this initialization happens super early |
| 21:03 | <Hixie> | sadly it's not _all_ that javascripty stuff |
| 21:03 | <Hixie> | e.g. it doesn't include the script settings object |
| 21:04 | <Hixie> | which is critical for certain web apis to be defined accurately |
| 21:04 | <Hixie> | but that's another story |
| 21:04 | <Hixie> | #sec-initialization really doesn't match the web |
| 21:04 | <Hixie> | steps 7 and 8 don't work like that at all |
| 21:05 | <jorendorff> | for sure |
| 21:05 | <Hixie> | i guess HTML should run steps 1-5 of that algorithm |
| 21:05 | <jorendorff> | Hixie: both specs assuming they are in control of the event loop is not really tenable |
| 21:05 | <Hixie> | well that's another problem too, yeah |
| 21:05 | <Hixie> | one thing at a time though! |
| 21:06 | <jorendorff> | well, that's what step 8 signifies to me: this spec thinks it knows how to start processing tasks |
| 21:07 | <Hixie> | step 8 is wrong for more reasons than just that |
| 21:07 | <Hixie> | this algorithm implies that all the scripts are piled up, then all executed |
| 21:07 | <Hixie> | that's simply not how it works |
| 21:08 | <Hixie> | for example, in <script></script><script></script>, between the two scripts executing, the DOM is modified. |
| 21:12 | <Hixie> | jorendorff: btw where do i report typos? "When the abstract operation CreateIntrinsics with argument realmRec performs the following:" is grammatically dubious |
| 21:12 | <Hixie> | also step 12 of CreateIntrinsics has the wrong font |
| 21:13 | <Hixie> | and that algorithm references CreateBuildinFunction should seems to not exist |
| 21:15 | <jorendorff> | Hixie: bugs.ecmascript.org for typos; wrong font in PDF, same place |
| 21:15 | <jorendorff> | wrong font in HTML is most likely my fault and can be reported at https://github.com/jorendorff/es-spec-html/issues |
| 21:16 | <Hixie> | one bug per typo, or should i coallesce? |
| 21:16 | <jorendorff> | i always coalesce, but then when you find the next thing, file another bug, not a comment on the original |
| 21:16 | <Hixie> | sure |
| 21:24 | <Hixie> | jorendorff: i sent a mail to es-discuss about #sec-init |
| 22:18 | gsnedders | wonders what the cost of getting telemetry data for lone surrogates in document.write would be |
| 22:19 | <gsnedders> | Probably too much. :( |
| 22:19 | <gsnedders> | (Say data like "%" of document.write calls containing lone surrogates) |