00:02:21 (discussion of lightweight vs. CSS element boxes) 00:02:37 annevk: "--" has to be at the beginning? 00:03:29 (yes, but this is all new) 00:09:05 (discussion of pseudos, what they are, what tree they live in, etc.) 00:10:11 (discussion about conclusions) 00:10:28 Domenic: this is largely background and groundwork 00:10:35 ending for the day! 03:45:46 Zakim has left #tagmem 03:56:52 dka has joined #tagmem 03:58:16 JeniT has joined #tagmem 03:59:30 timbl has joined #tagmem 04:11:35 JeniT has joined #tagmem 08:59:07 dka_ has joined #tagmem 09:31:50 darobin has joined #tagmem 12:02:16 timbl has joined #tagmem 12:54:49 dka has joined #tagmem 13:45:56 timbl has joined #tagmem 14:13:29 https://pbs.twimg.com/media/BkI7VdfCAAA8h6i.png 15:30:09 dka has joined #tagmem 15:32:21 timbl has joined #tagmem 15:57:53 timbl has joined #tagmem 16:03:11 JeniT has joined #tagmem 16:14:17 this is running here in SF today: http://www.w3.org/2014/04/annotation/submissions/ 16:22:10 scribenick: wycats 16:26:45 twirl has joined #tagmem 16:27:36 Scribe: Yehuda 16:38:04 For discussion this morning: https://www.w3.org/wiki/TAG/Reviews 16:41:51 Topic: Tracking our reviews 16:41:59 https://github.com/w3ctag/spec-reviews/issues 16:42:02 dherman has joined #tagmem 16:42:07 https://github.com/w3ctag/spec-reviews/commits/master 16:42:12 Yves: Most of you may not be aware that we need to report from time to time to the AC and Jeff to show the progress of the TAG 16:42:34 ... we discussed this morning about documenting that our new work style is actually working and having good effects on the specification and general work on APIs 16:42:49 ... I put together a dashboard to show the work we're doing 16:43:01 ... it's not like the previous product page - we don't need to document actions 16:43:17 ... just dates and the impact we've had on the specification 16:43:37 ... for example, with Push, we can see that we've had effects 16:43:46 wycats: do Jeff and the AC know what we're doing? 16:43:48 dka: yes 16:43:54 ... this is about recording it for our own purposes 16:44:09 ... and showing the positive impact 16:44:27 ... the idea is to do it in a light-touch way so we're not adding a ton of bureaucracy 16:45:02 wycats: I thought the style of work on the quota management API was very good 16:46:08 Domenic: I just added quota management 16:46:15 ... and Sergey's work on web animations 16:46:46 Yves: we don't want a heavyweight process here, just a basic dashboard 16:47:12 dka: Github has a lot of stuff in it, and this is a way to track where we've had an impact 16:47:13 Yves: or not 16:47:19 16:48:55 wycats: I was really happy about the CSS dashboard, and having a way to point people at what we're doing sounds great 16:49:08 ... I've had people approach me with thoughts and helping them see what we're doing is awesome 16:49:28 dka: People can add stuff whenever, and this shouldn't add any more work for people who want to do reviews 16:50:31 Topic: Website 16:50:37 dka: I ripped off the web apps WG for us 16:50:54 http://www.w3.org/2001/tag/Overview-beta.html 16:54:07 scribenick: slightlyoff 16:54:19 dka: how does package url relate to zip urls? 16:54:22 wycats: they're the same 16:54:33 Topic: Package URLs 16:55:04 wycats: the reason this is important because we already have a packaging problem. JavaScript exascerbates this 16:55:17 wycats: having maintainable content requires that you use multiple files 16:55:30 wycats: in JS, e.g., ember apps, people use server-side concatenation 16:55:52 wycats: this can mostly resemble a package of JS in one file. This is important to the way the web works today. 16:56:13 wycats: however, I and Sam and Dave have done a bad thing with ES6 modules 16:56:22 wycats: also the WC folks ahve done the same thign with imports 16:56:41 wycats: we could have added syntax in ES6 modules that let you do "inline modules" for use in concatenation 16:56:47 wycats: but we didn't do that 16:56:54 dherman: (clarification) 16:57:08 (one stream of bytes) 16:57:19 dka: you decided not to do this? 16:57:35 like mime multipart? 16:57:51 wycats: yes. Andreas Rossberg of V8 pointed out that we were trying to solve a network problem; meanwhile people on the committee were advocating that poeple write this way when it wasn't for this use-case 16:58:28 wycats: separately we also noticed that there are other places on the web where they have this problem (base64 encoding images inlining, inlining templates, etc.) 16:59:13 slightlyoff: we also built compilers that inline templates (Dojo & Closure) 16:59:25 wycats: we noticed that trying to solve this in JS was the wrong layer to solve it at 16:59:34 dka: sprites, etc. 16:59:45 q+ to push back on mnot and probe how he thinks real server user will ever configure apache. 16:59:45 wycats: so we punted to the W3C and said "they'll solve it" 16:59:57 timbl: mnot would say that HTTP 2.0 will solve it 17:00:27 wycats: because of the way people are doing bundling today, we're going to remove the current solution (inlining) in the module world 17:00:39 wycats: and we find the "HTTP 2.0 or bust" message to not be compelling 17:01:32 wycats: the way I'm imagining the system needing to work, these systems will start to predict what's needed and try to pre-emptively serve 17:02:05 wycats: and they'll have to get very sophisticated to reason about the set of related resources 17:02:26 dherman: we're going to have to continue to reckon with a world where people can't control the servers they deploy on 17:02:42 timbl: yes. Every time we need to control the server we fail. e.g., real content type 17:03:14 timbl: in practice, we've seen this pushback so much that I'm astonished mnot is making the argument 17:04:05 slightlyoff: FB, twitter, and Google all have lots of control 17:04:20 slightlyoff: the initial HTTP2.0 deployment environment doesn't look like an average webdev's experience 17:05:05 (discussion about SPDY, manifests, prediction, etc.) 17:05:36 (discussion of using the term "JIT") 17:06:15 (discussion of how to learn about related resources, etc.) 17:07:28 dherman: we need an interim solution in a pre-SPDY world 17:07:59 wycats: ember will *need* to be 100 files in a module world and we need a way to address that 17:08:27 timbl: I like the idea that a zipfile is an optimization and you don't refer to it directly 17:08:44 Yves: (question about using packaging) 17:09:45 slightlyoff: (discussion of layered packages) 17:10:13 Yves: was asking about local resources vs. over the network. wycats was targeting the network case 17:10:22 background: https://github.com/w3ctag/packaging-on-the-web 17:10:40 wycats: so there's one constraint -- having read Jeni's document -- discussing relative URLs 17:11:00 wycats: there's the idea that you might have a directory and want to have urls like "../" continue to work 17:11:26 wycats: e.g., I have thinger/index.html and an image at ../images/foo.png 17:11:46 JeniT: the idea was that the package would deal with fully resolved URLs 17:13:16 wycats: I think the relative lookup is the normal way people will want to use the system 17:13:23 JeniT: are you talking about files in the package relating to each other? 17:13:48 wycats: JeniT's proposal requires Content-Location header 17:13:52 for every item in the file 17:14:20 wycats: I'm trying to understand...if you don't specify Content-Location, would it be relative to the root of the package? 17:14:26 JeniT: how could you refer to it? 17:14:34 wycats: relative to the root of the package? 17:14:50 (some confusion) 17:15:18 JeniT: where would you get the filename if you don't do that? 17:15:30 wycats: oooh....I see...that's the name of the file 17:16:06 Yves: if you want to use a plain zip (vs. mulit-part mime), you could have location relative to the root of the document 17:16:11 wycats: how is this backwards compatible? 17:16:25 JeniT: you can continue to have the files on disk on the system 17:16:41 wycats: so if I have a script tag, and that's the entry point to the package, how do I refer to the files in the package? 17:17:11 JeniT: you point to the file you want to reference from your script element and it's loaded from the package 17:17:16 wycats: I'm confused...did I miss something? 17:17:32 JeniT: I tried to split up "how do we package it" from "how do we refer to it" 17:17:49 slightlyoff: JeniT's proposal is an overlay 17:17:54 https://github.com/w3ctag/packaging-on-the-web 17:18:01 https://github.com/w3ctag/packaging-on-the-web#requesting-a-package 17:18:26 (note that the tag is how the package is ref'd) 17:18:42 slightlyoff: this gives rise to my issue; you need a way to get the original HTML from the package 17:19:24 wycats: yeah, if I have the full app in the package, how do i reference index.html out of the package? 17:21:46 JeniT: I was thinking you'd have all the files on your filesystem, and you'd reference other files in packages from whatever your entry point is 17:21:52 slightlyoff: this creates a challenge for signing 17:23:16 JeniT: you can include all the files in the package, no? 17:23:32 slightlyoff: yes, but what do I do for going to app.example.com? 17:23:39 Yves: it's the inverse to 209 17:24:02 JeniT: you could use 209 if it could be generalized 17:24:18 timbl: if you send mulit-part mail, there's one that's the "top-level" message in the package 17:25:03 timbl: there's a clear distinction that the cover note is the thing being sent 17:25:04 annevk has joined #tagmem 17:25:11 JeniT: yeah, it could just be the first one in the package 17:25:22 RRSAgent, pointer? 17:25:22 See http://www.w3.org/2014/04/02-tagmem-irc#T17-25-22 17:25:24 wycats: I have a question about the 17:26:19 wycats: if I have in a document...do I konw where that goes? do I have to block on package download? 17:26:26 slightlyoff: this is why I brought up extent 17:26:36 JeniT: I think it has to go on the 17:26:50 wycats: this seems like my custom separator... 17:28:33 wycats: if you say something like... 17:28:51 ... 17:29:04 JeniT: the other thing that was raised on the mailing list was some sort of glob 17:30:36 slightlyoff: I'd like the globbing to match up with whatever SW's do 17:30:53 wycats: this is the moral equivalent of what I'd proposed before 17:31:20 wycats: you (dherman) objected because you wanted to find a separator to avoid the ergonomic cost of having to put the link tag in everywhere 17:31:31 dherman: we want the common programming patters not to require opt-in 17:31:47 dherman: *every* time you use jquery, you need a link tag? 17:31:58 Yves: this a pre-HTTP2.0 solution 17:32:12 wycats: we don't think this is a transient thing...will need it for a long time 17:32:26 wycats: imagine if this configured the browser (ES 6 module) loader 17:32:54 wycats: JeniT's making the point that URLs matter and that if we use this overlay, we can not change the URLs 17:35:19 (discussion of spriting, packaging, etc.) 17:35:51 (wycats outlines JeniT's proposal to dherman) 17:36:01 dka has joined #tagmem 17:36:09 dherman: somethign about this is making me worried 17:36:36 dherman: this reminds me of Alex Limi's proposal...but that was on a much more fine-grained basis that required configuraiton 17:37:57 http://limi.net/articles/resource-packages 17:38:20 discussion of CDNs, annoyance of configuration 17:39:56 annevk: this seems isomorphic to alex limi's proposal 17:40:16 Yves: the server could be smart about sending a header + package 17:40:25 JeniT: i looked at this. Does require a lot of configuration 17:41:01 see https://github.com/w3ctag/packaging-on-the-web#package-requests for that discussion 17:41:37 timbl: we should define a level of conformance about server capabilities 17:41:55 wycats: I think mod_spdy is eventually going to be a good solution for sites with dev-ops teams, etc. 17:42:11 q? 17:42:16 Zakim has joined #tagmem 17:42:29 wycats: I hope that ghpages et all get the benfits 17:42:43 JeniT: annevk, you talked about this being tried (and failing) before 17:42:58 JeniT: is the environment different such that this will work better? 17:43:48 dherman: I thikn I can answer; this is very close to Alex Limi's proposal. There was another proposal (lost to time) that required more configuration. Alex Limi's work stopped at "SPDY will fix it". We're re-opening the discussion 17:44:00 dka: what is the deliverable? 17:44:20 wycats: the open question is Alex's concern about top-level? 17:44:37 dka: back to deliverable. What needs to be done? Who needs to do it? 17:44:40 dka: where? 17:44:43 wycats: I think the TAG is fine 17:44:55 dka: TAG is fine but theres an IPR issue, perhaps 17:45:12 dka: I'd like to understand what the shorter-term deliverable from us is 17:45:50 wycats: I missed a bunch of your proposal when I read it...I can perhaps accent the bits that help those like me who might have missed those bits 17:45:57 JeniT: it was written as proposal and not spec 17:46:07 JeniT: we can re-frame it as a spec and re-do it 17:46:54 wycats: was there a reason why in encapsulation section you rejected message-http as the boundary/header in multi-part mime? 17:46:58 JeniT: it was just kludgy 17:47:48 JeniT: it's horrible with multi-part because you ahve to have this parameter on the Content-Type. I thought, why not create a new Content-Type that sniffs th boundary instead. semantically mulit-part but has the sniffing added. 17:47:49 wycats: works for me 17:47:58 wycats: the concern is server configuration 17:48:29 (discussion of configuration difficulty) 17:49:47 JeniT: 3 scenarios: (missed), spriting, and serving up the whole app from the package 17:50:19 JeniT: in that case (3rd) you have to serve up the starting page and the send the package 17:50:30 slightlyoff: smart servers should send the package + a 209-like-thing 17:51:13 (discussion of packaging, noting URL bar identifies a single thing) 17:51:26 annevk: this is using fragments? 17:51:29 group: no 17:52:48 slightlyoff: you can imagine a spec going either way about blocking or not 17:53:26 Yves: if you have that big a package... 17:53:37 slightlyoff: it's not about size. It's about blocking re: preload scanner 17:54:15 timbl: when you say that could be expensive... 17:54:30 slightlyoff: not in CPU, but in opportunity cost for missed download time 17:54:40 (discussion of costs) 17:55:30 (discussion about what to do with missing extent in the 17:55:31 ) 17:56:46 (discussion about optional vs. mandatory prefix/extents) 17:57:13 wycats: I think we're converging on the requirement 17:57:25 dherman: we should check with precsanner implementers 17:57:38 timbl: does this mean that packaging tools on the server need to be smart? 17:58:14 (discussion of headers and in-package metadata about extents) 17:58:27 it's nice that you can explain the tag in terms of service worker 17:59:41 timbl: is there a way that the requests could be redirected to packages in a stronger way? redirect to a package if we have an extent registered? 18:00:24 JeniT: in what I'd proposed, there was a Link header for retreiving CSV data so that for thigns which aren't HTML you can still reference packages 18:00:56 (discussion of header version) 18:03:16 wycats: we should make sure there's a way for the SW to handle this sort of thing as a polyfill 18:03:33 (discussion to about SW install flow) 18:03:58 dherman: so then the SW can handle this without requiring new clients 18:04:07 wycats: it'd be great if you could install some sort of a codec handler 18:04:20 wycats: ...depending on perf 18:04:43 wycats: there's likely going to be some sort of perf tradeoff 18:04:47 (agreement) 18:04:59 Action: JeniT to make a respec document out of the proposal 18:05:00 Created ACTION-857 - Make a respec document out of the proposal [on Jeni Tennison - due 2014-04-09]. 18:05:06 ACTION: Jeni to make a new document on package URLs. 18:05:06 Created ACTION-858 - Make a new document on package urls. [on Jeni Tennison - due 2014-04-09]. 18:05:53 plinss: a proceedural question. I've heard conflicting things about wether or not the TAG can produce specs 18:06:11 dka: as everyone knows, the W3C operates under and RF policy 18:06:21 dka: everyone in the TAG is here as an Invited Expert 18:06:28 (per the charter) 18:07:11 dka: from an IPR perspective, if the TAG creates a spec, we're not automatically licensed under the W3C patent policy 18:07:46 wycats: Domenic, e.g., isn't an employee of a member company 18:08:35 dka: we can produce REC track docs, but we generally move things to WGs for expertise reasons 18:08:59 dka: e.g., this is why SW needs to be produced at WebApps 18:09:24 (everyone agrees this would suck) 18:10:37 (background around why TAG doesn't have patent policy) 18:13:25 See: http://www.w3.org/2003/12/22-pp-faq#taglic 18:15:52 wycats: we've put in the work. Would be good to get to the end from here without restarting the entire debate 18:17:20 slightlyoff: perhaps sysapps would take the work? 18:24:24 break 18:24:28 Topic: break 18:46:31 dka has joined #tagmem 19:12:17 dka has joined #tagmem 19:28:32 twirl has joined #tagmem 19:29:05 timbl has joined #tagmem 19:54:25 dka, http://plane.ardupilot.com/ 19:55:03 http://diydrones.com/ etc 19:55:40 JeniT has joined #tagmem 20:02:39 Zakim has left #tagmem 20:14:46 annevk has joined #tagmem 20:15:14 Topic: Integrity URLs 20:15:33 wycats: a good use case for integrity URLs is caching 20:15:38 JeniT: there are lots of caveats 20:15:45 action: dan to talk to PSIG on whether or not it’s possible to amend the TAG charter to allow for rec track docs to run under the standard W3C IPR rules. 20:15:45 Created ACTION-859 - Talk to psig on whether or not it’s possible to amend the tag charter to allow for rec track docs to run under the standard w3c ipr rules. [on Daniel Appelquist - due 2014-04-09]. 20:15:52 http://w3c.github.io/webappsec/specs/subresourceintegrity/ 20:15:58 wycats: the spec right now does say that this is a use case 20:16:08 JeniT/wycats: the caveats are about origins and security 20:16:11 http://w3c.github.io/webappsec/specs/subresourceintegrity/#caching-optional-1 20:16:31 wycats: the spec currently finds places URLs are used and adds places where you can add `integrity="""` 20:17:02 wycats: but finding every place URLs are used and adding attributes is a maintenance nightmare, sometimes impossible, lots of work, bad bad bad 20:17:36 wycats: I was thinking this is similar to packaging URLs and we might want to solve it the same way 20:17:40 wycats: maybe a Link tag? 20:18:12 JeniT: maybe site-wide would be better, e.g. a manifesty thing in a .well-known location 20:18:20 annevk: that seems problematic 20:18:37 annevk: you need this for CORS too 20:18:46 annevk: there are not that many things 20:19:00 wycats/dherman: there are many things 20:19:10 annevk: APIs should take a dictionary 20:19:30 annevk: the alternative is a generalized URL format that contains this metadata 20:19:37 wycats: we tried that with the package thing... 20:19:56 dherman: I'm not sure what I think ... it would be interesting to enumerate them 20:19:57 maybe use RDFa or microdata (?!?) 20:20:07 but that doesn't help in CSS 20:20:12 annevk: we've done the enumeration for many things, e.g. CSP or service worker 20:20:43 (discussion of `new Image` example) 20:20:54 annevk: CORS requires explicit metadata at fetch time 20:21:34 wycats: there are many different metadata things related to each fetch and they all use different syntax and it's hard 20:21:41 annevk: I agree 20:21:52 (meta violent agreement) 20:22:38 wycats: your objection to a Link tag or manifest solution is that it's too far away from the actual resource 20:22:51 wycats: I'm not sure that applies to integrity 20:23:13 annevk: (counterexample of an image in a templating system) 20:23:45 wycats: fair, but the crossorigin solution (extra attributes) extended to everything seems bad 20:24:26 annevk: what about a fetch attribute that takes a microsyntax expressing all these things 20:24:36 annevk: works in CSS and JS too 20:24:57 annevk: backward-compact in CSS works fine using fallback properties 20:25:57 Domenic: I'm worried about JS APIs mostly... how do we retrofit 20:26:13 (discussion of potential solutions ... usually just add a new parameter) 20:26:22 annevk: srcset is a big problem 20:26:43 annevk: even if crossorigin makes sense to apply to all the URLs in a srcset, integrity does not 20:26:47 annevk: integrityset!? 20:26:53 annevk: fetches!?!?!?! 20:27:00 s/fetches/fetchset 20:27:17 the existing design for providing metadata for URLs is RDF 20:27:27 wycats: I generally dislike microsyntax ... grumble grumble ... 20:28:00 wycats: I think the action item is to find all the extension points and consider how to invent a microsyntax, so that integrity could be hooking into an existing thing instead of having to do this work all over again and independently 20:28:07 slightlyoff: how are they explaining how verification is done? 20:28:09 wycats: it's very short 20:29:35 http://w3c.github.io/webappsec/specs/subresourceintegrity/#validation-3 20:29:47 wycats: I feel like this should be using webcrypto's algorithms?> 20:30:50 slightlyoff: at a minimum if a user agent provides integrity they should provide web crypto's SHA 256/512 20:31:07 (discussion of how webcrypto doesn't mandate things) 20:31:43 wycats: this whole integrity thing should be polyfillable with service worker + web cvrypto 20:31:51 s/cvrypto/crypto 20:33:25 (discussion of how to tie in to WebCrypto) 20:33:32 wycats: I think I am proposing a spec review of the integrity spec 20:34:19 wycats: I can try to do this but need help from annevk to understand all the constraints 20:34:30 wycats: there are two strategies 20:34:40 wycats: we need to create a new metadata mechanism on top of URLs regardless 20:34:50 wycats: we need to figure out how to express this everywhere 20:34:55 wycats: our options are either "close" or "far" 20:35:02 annevk: I have a pretty good handle on where URLs exist 20:35:08 annevk: srcset is the most problematic 20:35:24 wycats: we can just say it's legacy... 20:35:31 Domenic: already!?! 20:35:39 (some general incredulity) 20:35:53 JeniT: it is worth looking at RDF and RDFa for metadata about documents 20:36:20 JeniT: it doesn't help with CSS or JS but it does help with HTML 20:36:34 annevk: also it has many levels of indirection that will be problematic for authors 20:36:43 JeniT: I don't think so... you can put things inline with RDFa... 20:38:07 JeniT: I'd be happy to do a sketch of how it would look in RDFa 20:38:29 http://www.w3.org/TR/rdfa-lite/ 20:39:29 wycats: I agree it would be a shame if we come up something extremely similar and not identical 20:39:47 Action: wycats and others to do an integrity URL spec review 20:39:47 Created ACTION-860 - And others to do an integrity url spec review [on Yehuda Katz - due 2014-04-09]. 20:40:20 timbl, you were talking about http://en.wikipedia.org/wiki/Extensible_Metadata_Platform 20:40:30 Action: wycats to collaborate with annevk on a plan for general metadata on URLs 20:40:30 Created ACTION-861 - Collaborate with annevk on a plan for general metadata on urls [on Yehuda Katz - due 2014-04-09]. 20:41:41 plinss: integrity URLs are heading in the direction (but not quite getting to) is doing cryptographic signatures, instead of just hashes 20:41:49 wycats: I think slightlyoff wants signatures also 20:42:03 slightlyoff: I sense that there is a need to be able to verify the contents of bundles etc. 20:42:12 slightlyoff: I think a packaging system is the first step 20:42:33 Domenic: can someone clarify how this is different from HTTPS? 20:42:53 slightlyoff: HTTPS is transport-level] 20:43:23 plinss: this would allow me to, once I get the resource, send it to you along with its signature so that you know it came from the original source 20:43:31 .. instead of from me 20:43:41 s/../... 20:44:00 plinss: this could enable valuable other things in the future, e.g. a peer-to-peer mode 20:44:37 wycats: what's nice about this is that it solves the "omg too much javascript" problem, at least insofar as there are popular frameworks. E.g. jQuery gets downloaded very few times. 20:45:47 wycats: Google Ajax CDN is not perfect 20:45:54 Domenic: is there a potential for malicious collisions? 20:46:23 (you'd have to find a collision, which is not at all easy) 20:48:45 timbl/wycats: (discussion of the incentive structure this creates for library consumers) 20:49:37 wycats: rapid library releases actually encourage adoption of the latest version 20:49:43 wycats: I want this 21:00:31 | 21:00:38 s/|// 21:09:12 https://github.com/w3ctag/promises-guide 21:09:58 + outstanding https://github.com/w3ctag/promises-guide/pull/21 21:11:10 Topic: Promises Guide 21:12:04 Domenic: (goes through the sections of the Promises Guide) 21:15:32 Domenic: suggests that people say "Promise objects are defined in [ECMAScript]" 21:15:54 annevk: points out that people are using WebIDL anyway, which references ECMAScript already 21:17:22 wycats: TC39 has been defining event loop concurrency and the browser has to hook into it 21:18:31 (discussion about "continue running the following steps async" 21:20:15 (discussion about tasks, microtasks, and "queue a task") 21:20:44 dka has joined #tagmem 21:22:27 (discussion about "run the following steps asynchronous", spawning a thread, await in ES7) 21:24:36 dherman: we're talking about the meta-language vs. object-language 21:24:55 Domenic: (explains what his spec is doing) 21:25:43 annevk: in a normal situation, the spec would say "enqueue a task" 21:29:13 Domenic: what language do we need to offer people about how to talk about running steps asynchronousl 21:30:33 annevk: (talks about ways to explain how async works using the platform) 21:30:41 dherman: this is where the extensible web goes off the rails 21:31:21 dka: who is this document for? 21:32:30 ... we need to tell people what TO do if we are telling them what NOT to do 21:32:55 ... we should tell them what TO do first 21:33:01 ... then tell them about antipatterns afterward 21:34:16 dherman: about "run these steps asynchronously"... if there's a network fetch, shouldn't you say "when such and such happens, run these steps" 21:34:45 timbl has joined #tagmem 21:35:47 annevk: (shows the XHR spec) 21:36:56 dherman: I'm not sure how to read this 21:37:08 (discussion about threads vs. running things async on the main thread) 21:39:41 (discussion about how algorithms can keep running after returning) 21:41:01 annevk: it seems like we're just discussing how to word things 21:43:06 wycats: dherman, what are your thoughts? 21:45:55 dherman: I've been doing a lot of thinking on the run-to-completion programming model 21:46:02 ... it's fiendishly difficult to nail it down 21:46:14 ... trying to get my head around what invariants we're trying to enforce 21:46:37 ... this came to a head when I started fighting back against people who want to add data races into JS 21:46:44 ... I really want to articulate why it's so critical 21:46:56 ... I have been fighting the Balrog for years - YOU SHALL NOT PASS 21:47:13 ... Yehuda is worried about avoiding a run-to-completion violation 21:47:53 annevk: I'm not trying to change anything about the run to completion model 21:48:05 dherman: the only way to know that is to read the spec carefully 21:48:11 annevk: but how can you know? 21:48:19 dherman: this is a constant vigilance we need to be careful about 21:49:04 wycats: I think we need to beef up the meta-language so it can more easily protect against invariants 21:49:08 dherman: yes 21:49:16 annevk: I would love to migrate to something better 21:50:04 wycats: this may be an extensible web hazard - we may have unobservable data races that we expose by accident 21:50:15 annevk: I would love for TC39 to take over the role of WebIDL 21:51:36 Domenic: WebIDL has a lot more than just some types 21:51:52 annevk: WebIDL provides a central place for the platform to address general meta-language questions 21:52:01 dherman: this is sometimes called "elaborative semantics" 21:53:16 (discussion about ownership of the meta-language) 21:54:35 dka: flagging that we have gone far beyond promises 21:55:49 dka: should we be involving more WebIDL people? 21:56:04 wycats + annevk: Cameron would love to have someone do this 21:56:55 slightlyoff: we can use this to improve the idioms 21:57:50