| 00:00 | <MikeSmith> | TabAtkins: OK but I couldn't see any other way to force it to check, e.g., "(max-width: 30em) 100vw" on its own (a <source-size-value>) and that wrapping-it-with-@media hack seemed to work |
| 00:01 | <TabAtkins> | What are you trying to *get* out of it? Wrapping it with @media is, I think, solely checking that there's no {} in the value, and that's by accident. It doesn't do anything else. |
| 00:02 | <MikeSmith> | ah OK |
| 00:04 | <MikeSmith> | what I think I was trying to get back when I first added it was just for now a way to do an additional syntax check on the <source-size-value> and <source-size> parts |
| 00:05 | <TabAtkins> | Okay, well the parser doesn't actually provide any ability to do further syntax checks. ^_^ If what you're asking for isn't one of the entry points, you have to syntax check yourself. |
| 00:06 | <MikeSmith> | OK |
| 00:07 | <MikeSmith> | TabAtkins: what I aim for longer term is to replace our ad-hoc media="" and sizes="" tokenizer in the validator with your JS tokenizer (via Rhino), because I think that'll be less work than writing a tokenizer in Java myself (and certainly I'm not going to magically have a bunch of time any time soon to write one in Java anyway) |
| 00:08 | <MikeSmith> | so I added that code to call your JS tokenizer via Rhino a few months just to see if the basic mechanism would be possible |
| 00:13 | <TabAtkins> | Makes sense. (Though writing a tokenizer to the spec still isn't hard.) |
| 00:27 | <MikeSmith> | yeah, just requires more time than I have atm |
| 00:28 | <MikeSmith> | anyway, what I have there for that part now "works" to the extent that it's at least not causing any spurious errors to be reported |
| 00:28 | <MikeSmith> | after I updated to the latest parse-css.js |
| 00:28 | <MikeSmith> | so I'm declaring victory for now |
| 00:31 | <MikeSmith> | so I can get a new standalone release out to Jorn Zaefferer for use in the grunt HTML checker he maintains, and out to the Bootstrap project for the thing they use that checks HTML in JSFiddle/JSBin/Codepen links people post in Bootstrap bug reports |
| 03:45 | <Hixie> | TabAtkins: 301 zcorpan |
| 03:46 | <Hixie> | well 307 i guess |
| 06:14 | GPHemsley | thinks a wiki should not be the canonical place for the APNG spec: https://wiki.mozilla.org/APNG_Specification |
| 06:15 | <tantek> | GPHemsley: wikis are the coolest places for specs, easiest to fix errata ;) |
| 06:15 | <GPHemsley> | There is fork development going on here: https://gist.github.com/SoniEx2/c679e771d506210378a5 |
| 06:15 | <tantek> | wow that URL is so much prettier. not. |
| 06:16 | <GPHemsley> | tantek: Perhaps, if your wiki was set up specifically for spec development. |
| 06:16 | <GPHemsley> | (which MozillaWiki is not) |
| 06:16 | <tantek> | yes, some template work helps with that |
| 06:16 | <tantek> | well the github gist wins - it loaded. while the wikimo link is still spinning on a blank page :( |
| 06:16 | <GPHemsley> | :( |
| 06:16 | <tantek> | oh it finally loaded :( |
| 06:16 | <GPHemsley> | That's not good |
| 06:17 | <GPHemsley> | Can you check to see what took so long, by any chance? |
| 06:17 | <tantek> | looking |
| 06:18 | <tantek> | just did a shift reload with the network inspector |
| 06:18 | <tantek> | oh hey "Secure Connection Failed" |
| 06:19 | <tantek> | trying again |
| 06:19 | <tantek> | wow that's a lot of network resources |
| 06:19 | <tantek> | still loading |
| 06:20 | <tantek> | 26 requests, 1531.82KB, 53.39s |
| 06:21 | <tantek> | that's pretty pathetic |
| 06:21 | <GPHemsley> | Are you logged in? |
| 06:21 | <tantek> | yes |
| 06:21 | <tantek> | the HTML took 671ms |
| 06:21 | <GPHemsley> | hmm... that |
| 06:21 | <GPHemsley> | 's actually shorter than what I'm seeing |
| 06:22 | <tantek> | then so much css and js |
| 06:22 | <tantek> | but then the really killers - woffs |
| 06:22 | <GPHemsley> | yeah |
| 06:22 | <tantek> | designery cheese |
| 06:22 | <GPHemsley> | loading the same thing 4 times |
| 06:22 | <GPHemsley> | and as text/plain |
| 06:22 | <tantek> | maybe I should block all woffs |
| 06:22 | <GPHemsley> | I'll be looking into that tomorrow |
| 06:22 | <tantek> | Helvetica is good enough :P |
| 06:23 | <GPHemsley> | But it seems like the biggest problem is the speed of the server |
| 06:23 | <GPHemsley> | These aren't huge files |
| 06:24 | <tantek> | goodness sakes, 4618ms to load bg-gradient-sand.png!!! |
| 06:25 | <tantek> | 9 font files |
| 06:26 | <GPHemsley> | But hmm, your speed is definitely much slower than mine |
| 06:27 | <GPHemsley> | I get the whole page in ~6 s |
| 06:27 | <GPHemsley> | 8.45 s this latest time |
| 06:27 | <GPHemsley> | and I have 30 requests |
| 06:27 | <GPHemsley> | Still, much room for improvement |
| 06:27 | <tantek> | I'm on a 1.5/700 ADSL if that makes any difference |
| 06:27 | <tantek> | yeah |
| 06:28 | <GPHemsley> | https://bugzilla.mozilla.org/show_bug.cgi?id=1133409 |
| 06:32 | <tantek> | thanks for the heads-up about APNG - captured: https://wiki.mozilla.org/Standards#Orgless_specs |
| 06:33 | <tantek> | GPHemsley, FWIW all the microformats and indiewebcamp specs are "living" wiki-developed. |
| 06:33 | <GPHemsley> | tantek: Are those wikis shared with other content? |
| 06:34 | <GPHemsley> | tantek: And/or have a restricted userbase? |
| 06:34 | <tantek> | microformats.org has a fairly strong auto-antispam setup but we get 1-2 a week |
| 06:35 | <tantek> | anyone can register, limited editing etc. |
| 06:35 | <tantek> | indiewebamp, requires that you naturally log in with your own domain |
| 06:35 | <tantek> | which, surprisingly, eliminates all spam |
| 06:35 | <tantek> | so no explicit restriction per se |
| 06:36 | <tantek> | and yes - shared with much other content - all the background research and brainstorming that goes into the specs |
| 06:40 | <GPHemsley> | tantek: But is there any non-spec-related content? What I'm getting at is, MozillaWiki is designed for a bunch of Mozilla-related things; it's not a spec-editing wiki. |
| 06:40 | <GPHemsley> | Like, the WHATWG wiki might be a different story |
| 06:40 | <tantek> | GPHemsley - sure - there are lists of implementations etc. |
| 06:41 | <GPHemsley> | I still consider that spec-related |
| 06:41 | <tantek> | microformats is fairly focused around the development of microformats (specs) and everything related - so you're likely right there |
| 06:41 | <tantek> | indiewebcamp is broader - it's a community site |
| 06:41 | <tantek> | events, how-tos, media lists etc. |
| 06:41 | <GPHemsley> | what specs does indiewebcamp handle, anyway? |
| 06:42 | <tantek> | but even there, all of those feed into documenting problems people have with existing websites etc. which get turned into experiments, and often converge into specs |
| 06:43 | <tantek> | indiewebcamp has a few "core" specs: indieauth, webmention, micropub |
| 06:43 | <tantek> | these are broadly implemented building blocks |
| 06:44 | <tantek> | and then a few more in development with varying levels of implementation like vouch |
| 06:44 | <tantek> | and then a bunch of "mini" specs that build on a bunch of the microformats specs |
| 06:45 | <tantek> | though your question makes it clear I should turn the above ^^^ into a wiki page :) |
| 06:45 | <tantek> | feel free to join #indiewebcamp for more |
| 06:58 | <tantek> | GPHemsley: captured: https://indiewebcamp.com/specifications |
| 07:01 | <GPHemsley> | cool |
| 08:39 | <annevk> | Mozilla's wiki is used for some B2G specifications |
| 09:30 | <annevk> | I would love to have more data around "DOM is slow" |
| 09:31 | <annevk> | There are some BlinkOn talks that go into it, and judging from what React is doing it seems somewhat clear what they optimize for, but it would be nice to have more data |
| 12:10 | <annevk> | https://speakerdeck.com/vjeux/react-css-in-js is a great set of slides on problems with CSS |
| 12:19 | <jgraham> | annevk: So, can I use that talk as evidence next time I hear that web developers aren't asking for encapsulation? |
| 12:20 | <annevk> | jgraham: seems like it |
| 12:20 | <annevk> | jgraham: though note that shadow DOM didn't really end up working for React either |
| 12:20 | <annevk> | jgraham: they eschew most of the DOM |
| 12:21 | <jgraham> | Well that might be true, but it's a slightly different issue to "do developers benefit from a situation where they can get actual encapsulation from components" |
| 12:21 | <jgraham> | From that talk the answer is clearly "yes" |
| 12:22 | <jgraham> | Since FB have also had to hack it on top of CSS |
| 12:22 | <annevk> | Yeah, it seems large projects very much need all that |
| 12:22 | <annevk> | And I'm sure their "DOM-like components" have it too |
| 12:24 | <jgraham> | Indeed |
| 12:24 | <jgraham> | I'm not really sure how React works, of if that's something we should be chasing for standardisation |
| 12:25 | <jgraham> | I do slightly worry that "DOM is slow" isn't going to get better if it has to embed the possibility of running script every time you parse an element |
| 12:27 | <annevk> | https://www.w3.org/Bugs/Public/show_bug.cgi?id=27310 has some debate about standardizing it, but I don't think as-is is going to work |
| 12:29 | <annevk> | React seems to use DOM for rendering, but can also use <canvas> or some kind of native API |
| 12:29 | <annevk> | But the actual data is kept in some kind of JS structure they refer to as the "virtual DOM" |
| 12:29 | <annevk> | https://speakerdeck.com/vjeux/oscon-react-architecture has a bunch of details too |
| 12:30 | <annevk> | I didn't know the idea originated from PHP's string concatenation |
| 12:31 | <annevk> | Kind of an interesting way for technology to evolve |
| 12:35 | <jgraham> | I just read the talk , or at least the parts of if that website actually displayed |
| 12:36 | <jgraham> | I expect the history part is writing a good story rather than writing something accurate |
| 12:36 | <annevk> | It seemed to have a hard time rendering the O notations |
| 12:36 | <jgraham> | Yeah |
| 12:36 | <jgraham> | Bugzilla seems to be down |
| 12:37 | <annevk> | Well Facebook does use XHP so the history does add up |
| 12:38 | <jgraham> | I'm not saying that the slides are a lie, just that the clean evolution from one idea to the next won't be true |
| 12:38 | <jgraham> | Anyway, I have heard that Elm is a more extreme/theoretically pure example of the same kind of pattern, with all the immutability required http://elm-lang.org/ |
| 12:38 | <jgraham> | But I still don't know what there is here that you could take to make the overall web better |
| 12:40 | <annevk> | Yeah, I'm trying to figure that out, but it is far from clear |
| 12:42 | <annevk> | But it would indeed be good to know before we start invoking more JavaScript during parsing, or add the shadow DOM (whether encapsulated or not) |
| 13:07 | <jgraham> | What's the normal way to deal with fallible algorithms in specs? i.e. something that can result either in some data or an error? |
| 13:10 | <Ms2ger> | "if it returned an error..." |
| 13:10 | <Ms2ger> | I don't know that we really have a good approach yet |
| 13:11 | <jgraham> | I feel like what I'm writing is very rust-influenced. I'm not sure that's good |
| 13:11 | <jgraham> | (algorithsm that can return objects of type error or type (something)) |
| 13:21 | <annevk> | jgraham: throw? |
| 13:21 | <annevk> | jgraham: but what Ms2ger suggests works too |
| 13:22 | <Ms2ger> | jgraham, I think Hixie does that too |
| 13:23 | <JakeA> | annevk: fetch(req) already makes the body of the request 'used', what changes does https://github.com/slightlyoff/ServiceWorker/issues/625 change? |
| 13:24 | <annevk> | JakeA: if there's no body you can do fetch(req); fetch(req) |
| 13:24 | <annevk> | JakeA: I want to disallow that |
| 13:24 | <annevk> | JakeA: and instead make a stronger tie between req and its fetching process |
| 13:26 | <JakeA> | annevk: Chrome fails on 2 fetches with the same request obj already, even with no body. Sooo… yey? |
| 13:27 | <terinjokes> | JakeA: btw, i'm in London this week |
| 13:28 | <JakeA> | terinjokes: I'm going to be on talk-writing lockdown all week :( well, if things go well I might be freer later in the week, but I'm already at the panic-poo stage |
| 13:30 | <terinjokes> | JakeA: as usual, i have terrible timing. |
| 13:30 | <JakeA> | nah, it's me, left things too late |
| 13:35 | <wanderview> | JakeA: chrome currently failing on second fetch of same request object is an impl detail, right? not clear where that is in the spec |
| 13:35 | <wanderview> | unless annevk changes it |
| 13:40 | <JakeA> | wanderview: I always thought that fetch(req) consumed the request, but you're right, the spec doesn't do that |
| 13:47 | <annevk> | JakeA: sounds good I guess |
| 13:47 | <annevk> | JakeA: yeah, "consuming" is the idea, though that still means that fetch(string) is inferior, but maybe that's fine for a convenience API |
| 13:48 | <annevk> | (and we can always decide to expose a registry-like thing later where fetch(string) can be controlled too) |
| 13:48 | <annevk> | wanderview: are there any caches in existence that handle this POST scenario? |
| 13:48 | <JakeA> | annevk: I'm happy with that. Although I'm dubious about request.abort() (I assume that's what you're suggesting?) |
| 13:48 | <annevk> | JakeA: yes |
| 13:49 | <annevk> | JakeA: and request.changePriority(...) and request.port.postMessage(...) |
| 13:49 | <wanderview> | annevk: no... Cache spec explicitly forbids POST right now... |
| 13:50 | <annevk> | JakeA: if you have a better idea to handle those use cases please mention them in the ticket |
| 13:51 | <annevk> | JakeA: for now I think I'll change the model of Request so that the object becomes immutable after passing it to fetch(), then we have more options as to how to handle things |
| 13:51 | <annevk> | wanderview: yeah, but outside SW, e.g. the browser cache |
| 13:51 | <annevk> | wanderview: it seems like a rather spurious use case |
| 13:51 | <annevk> | wanderview: and it would mean that each time you iterate over the cache keys you need to duplicate the body |
| 13:52 | <annevk> | wanderview: I don't think that's expected |
| 13:52 | <wanderview> | annevk: maybe JakeA knows... his comment that I linked suggested it was expected in the future |
| 13:52 | <wanderview> | annevk: thats exactly what we have to do and currently implement |
| 13:53 | <annevk> | wanderview: I guess most GET requests don't have a body so it's not too bad, but still... |
| 13:54 | <wanderview> | annevk: we don't actually read the body off disk unless someone tries to access the body from script... we just open the fd |
| 13:54 | <wanderview> | so I don't think its too painful |
| 13:57 | <wanderview> | JakeA: do extendable promises let us do the changePriority and postMessage use cases? |
| 13:59 | <JakeA> | annevk: wanderview: removing bodies from cached requests felt arbitrary at the time, but I think it's ok |
| 14:00 | <JakeA> | wanderview: nah, we'd still need mutation for that |
| 14:02 | <wanderview> | JakeA: it just seems in a number of issues we've come to the conclusion "devs expect to get an object back out that exactly matches what they put in"... for example, not coercing the URL on the response to match the request |
| 14:02 | <wanderview> | JakeA: dropping bodies seems to change from that approach |
| 14:02 | wanderview | might be biased since he spent so much time implementing Request bodies. :-) |
| 14:05 | <wanderview> | still... simplifying code is good if we can... so lets do it if it makes sense... |
| 14:27 | <annevk> | wanderview: JakeA: what happens if you try to cache a request that has a method other than GET? |
| 14:28 | <wanderview> | annevk: HEAD works I believe |
| 14:28 | <wanderview> | annevk: others reject... I think with a TypeError |
| 14:28 | <annevk> | wanderview: both HEAD and GET require that there's no body |
| 14:28 | <wanderview> | really? |
| 14:28 | <wanderview> | hmm |
| 14:28 | wanderview | is probably an idiot. |
| 14:29 | <wanderview> | I thought GET could have a body |
| 14:29 | <wanderview> | annevk: the fetch spec disallows this? |
| 14:29 | <annevk> | wanderview: see step 21 "If request's method is `GET` or `HEAD`, throw a TypeError. " |
| 14:30 | <wanderview> | annevk: where? |
| 14:30 | <annevk> | wanderview: https://fetch.spec.whatwg.org/#dom-request |
| 14:30 | <annevk> | wanderview: fairly recent addition: https://www.w3.org/Bugs/Public/show_bug.cgi?id=27846 |
| 14:31 | <wanderview> | annevk: ah... I feel less bad then |
| 14:31 | <annevk> | wanderview: I feel bad that you implemented support for bodies :-( |
| 14:31 | <annevk> | wanderview: JakeA: so perhaps for now this is not a problem |
| 14:31 | <wanderview> | annevk: it was mostly boilerplate... but I'd want to be quite certain we will never support bodies on requests before I remove it |
| 14:32 | <wanderview> | annevk: that also means JakeA can remove all the request.clone() methods from here and other docs: http://jakearchibald.com/2014/offline-cookbook/ |
| 14:33 | <wanderview> | well, once we actually implement that check |
| 14:37 | <wanderview> | annevk: oh... nsm already fixed it for us... I wonder if blink is aware of that spec change |
| 14:38 | <JakeA> | sorry, got caught up in something. *reads back* |
| 14:39 | JakeA | giggles at the idea of the cache "dropping bodies". It's a real badass. |
| 14:40 | <wanderview> | https://www.youtube.com/watch?v=grbSQ6O6kbs |
| 14:43 | <JakeA> | wanderview: ah, sorry, the reason POST is blocked from the cache was to avoid the body storage stuff. But yeah, we should be able to drop those .clones |
| 14:43 | <JakeA> | (once implementations update, if they need to) |
| 14:44 | <wanderview> | well, until that recent change in fetch spec, GET Request could synthetically be created with a body |
| 14:46 | <annevk> | I guess Chrome didn't really read the spec... |
| 14:46 | <wanderview> | annevk: what do you mean? |
| 14:47 | <annevk> | wanderview: from JakeA's comment it sounds like they assumed an invariant around GET/HEAD that wasn't actually there |
| 14:47 | <wanderview> | oh... not reusable Request objects |
| 14:47 | <wanderview> | oh |
| 14:48 | <annevk> | "the reason POST is blocked from the cache was to avoid the body storage stuff" means GET/HEAD having a body wasn't considered |
| 14:48 | <wanderview> | ah |
| 14:48 | wanderview | goes for more coffee... |
| 14:49 | <JakeA> | annevk: I thought you said it couldn't have a body? |
| 14:49 | <annevk> | JakeA: since January 17 |
| 14:49 | <JakeA> | best date ever |
| 14:50 | <JakeA> | I guess we should reopen https://github.com/slightlyoff/ServiceWorker/issues/550 then |
| 14:50 | <annevk> | (not JakeA's b-day in case you were wondering) |
| 14:51 | <annevk> | JakeA: yeah, GET/HEAD Request objects can be easily reused |
| 14:51 | <annevk> | JakeA: and if that's all the cache needs... |
| 14:55 | <JakeA> | annevk: so, in summary, fetch() will always "use up" requests, cache.put(req, res) will use up the response but not the request |
| 14:55 | <JakeA> | Is that correct? |
| 14:55 | <annevk> | JakeA: given the above invariants, yes |
| 14:56 | <annevk> | JakeA: though I wouldn't call it "use up" for fetch(); it marks it immutable, but it's still usable for post-fetch purposes, such as abort or messaging with the service worker event responsible for handling it |
| 14:56 | <JakeA> | annevk: and .clone() remains a way to use a request twice, as long as it's called before the request is used up |
| 14:57 | <JakeA> | true |
| 14:57 | <annevk> | .clone() is a way to reuse a request/response that has a body |
| 14:58 | <JakeA> | annevk: var r = new Request('/'); var r2 = r.clone(); fetch(r); fetch(r2); // does this work? |
| 14:58 | <annevk> | JakeA: yeah, should |
| 14:58 | <annevk> | r and r2 will share nothing |
| 14:58 | <JakeA> | annevk: ok, so cloning is also useful for requests without bodies |
| 14:58 | <annevk> | fair |
| 15:02 | <wanderview> | annevk: what are you proposing should happen in this case? cache.put(req, response); req.abort(); |
| 15:02 | <wanderview> | I bet devs will expect it to abort the put() |
| 15:03 | <wanderview> | does this mean every API taking a Request must now be abortable? |
| 15:03 | <JakeA> | annevk: Should new Request("/", {body: 'BAM'}) throw? |
| 15:03 | <annevk> | JakeA: yeah that would throw |
| 15:04 | <annevk> | JakeA: we could make method defaulting conditional (GET when no body is passed, POST when a body is passed) I suppose |
| 15:05 | <JakeA> | annevk: ah, sorry, that is in the spec already. Do I need cache.put to throw if the request has a body? Is there any way that can happen? |
| 15:05 | <JakeA> | annevk: nah, I think explicit method is fine here |
| 15:05 | <annevk> | wanderview: not sure, probably not, could be a reason to consider RequestKey... |
| 15:05 | <JakeA> | annevk: wanderview: Or abortable promises :D |
| 15:05 | <annevk> | JakeA: request can't have a body if method is either GET/HEAD |
| 15:06 | <annevk> | JakeA: abortable promises don't gel with declarative promises |
| 15:06 | <wanderview> | JakeA: well... same confusion with the other methods... Cache.put(req, res); req.changePriority(); // wtf does this do? |
| 15:07 | wanderview | wonders how many years it will take before he fully understands all the terminology used in this channel. |
| 15:07 | <annevk> | wanderview: we'd probably make it throw or a no-op if Request isn't in the right state |
| 15:07 | <JakeA> | wanderview: I guess .put should mark the request as immutab… oh shit we're back here |
| 15:07 | <annevk> | wanderview: terminology changes too often :-( |
| 15:08 | <wanderview> | yea... I don't like putting this stuff on Request... it goes from being a simple struct with a stream to being this stateful handle thing... which I think makes it a lot harder to understand |
| 15:09 | <wanderview> | why do I have to clone() the Request? because there are these methods on it that I don't use but might want to so I can't reuse the Request in another fetch? |
| 15:09 | <wanderview> | I guess I'd be interested to hear what web devs think |
| 15:09 | <annevk> | wanderview: you could fetch(req.url, req) to cheat :p |
| 15:11 | <JakeA> | wanderview: I've seen people expect to be able to add/modify headers as the request passes through the fetch event |
| 15:11 | <annevk> | JakeA: that's very different |
| 15:11 | <wanderview> | JakeA: you mean and then do respondWith(null)? |
| 15:11 | <wanderview> | or default or whatever it is |
| 15:11 | <JakeA> | wanderview: well, not call respondWith at all |
| 15:12 | <JakeA> | I dunno if we want that to work, but I've seen it |
| 15:12 | <annevk> | I think we might, but it's a very different use case from changePriority() as I pointed out in the issue |
| 15:12 | <wanderview> | JakeA: I think thats just an argument for https://github.com/slightlyoff/ServiceWorker/issues/607 |
| 15:13 | <wanderview> | sorry... wrong issue |
| 15:13 | <wanderview> | I meant removing event.default() |
| 15:13 | <wanderview> | oh... that is the right issue |
| 15:14 | <JakeA> | I still think we really want fetch() to return something more than a promise, something that represents an active request |
| 15:14 | <JakeA> | But I sort-of get why we can't have that |
| 15:14 | <wanderview> | JakeA: yea... I agree |
| 15:15 | <JakeA> | request.something() could start the request and return a richer object, with the promise hanging of .ready or something |
| 15:15 | <annevk> | My proposal is that we make Request immutable for now when passed to fetch(). This roughly matches Chrome. |
| 15:16 | <annevk> | That buys us some breathing room to consider how to handle abort() et al for a month or so. |
| 15:16 | <annevk> | Or longer if we think something might change... |
| 15:17 | <wanderview> | JakeA: request.something() instead of a fetch()? why not just controlledFetch() or one of the options I posted in the issue? |
| 15:18 | <JakeA> | annevk: That works for me. I guess cache.put should do the same |
| 15:18 | <JakeA> | wanderview: that works too. Ughghghghg but it's all worse than var activeRequest = fetch(req); activeRequest.abort(); |
| 15:18 | <wanderview> | yes |
| 15:19 | <annevk> | wanderview: JakeA: I'm proposing immutable for now since it seems likely that any alternative will take us a bit longer to settle on |
| 15:20 | <JakeA> | agreed |
| 15:20 | <wanderview> | ok |
| 15:23 | <JakeA> | annevk: Do you know the status of promise-extending? I guess the problem is fetch(req).then(r => r.json()), how the new promise retains the link to the in-flight request. Am I right? |
| 15:24 | <JakeA> | AFAIK it just does currentPromise.contructor.resolve(newPromise), so you'd keep the prototype methods, but lose state like the request |
| 15:33 | <annevk> | JakeA: the main problem is async/await I think |
| 15:33 | <annevk> | JakeA: just doesn't make much sense with those around |
| 15:34 | <annevk> | My solution for Request and fetch() isn't great... |
| 15:34 | <annevk> | E.g. what happens with fetch(req, someOverrides)? |
| 15:35 | <annevk> | Does req get modified? |
| 16:02 | <annevk> | JakeA: wanderview: created https://gist.github.com/annevk/56e97115f2c9c2e90c23 |
| 16:02 | <annevk> | JakeA: wanderview: has an overview of what we discussed |
| 16:16 | <JakeA> | annevk: that captures it. I'm keen to know more about the promise issues, I can't see how it causes issues with async/await. Guess Domenic knows? |
| 16:17 | <annevk> | JakeA: well async/await abstracts out the promise |
| 16:17 | <annevk> | JakeA: if you then start hanging things of it, you still need the object which is kind annoying |
| 16:18 | <JakeA> | annevk: It abstracts the completion of the promise. If you want concurrency you still end up with the promise objects, either var p1 = thing(); var p2 = otherThing(); await p1; await p2; or await Promise.all([thing(), otherThing()]) |
| 16:18 | <annevk> | JakeA: instead of await fetch() you get var r = fetch(); await r; |
| 16:19 | <JakeA> | fetch is one of the things that really benefits from concurrency |
| 16:19 | <annevk> | true true |
| 16:19 | <annevk> | would be interesting to hear what Domenic thinks |
| 16:20 | <annevk> | perhaps a subclass of a promise is less bad than I thought it would be |
| 16:20 | <annevk> | I think we might still want to make a few tweaks to how fetch(req) works though |
| 16:21 | <annevk> | e.g. if you get a modified Request it would be kind of nice to be able to inspect that, perhaps it should still be reusable, but at least the object should represent its "clipped" state |
| 16:23 | <JakeA> | I think the problem is with var p = fetch(req).then(doSomeOtherStuff) |
| 16:23 | <JakeA> | As in, how p retains the .abort() method |
| 16:23 | <annevk> | Retains? |
| 16:24 | <JakeA> | annevk: I believe new promises are created using the constructor or the original promise |
| 16:24 | <JakeA> | (I could be outdated or plain wrong) |
| 16:24 | <annevk> | You mean of? |
| 16:24 | <JakeA> | yeah sorry |
| 16:25 | <annevk> | How would that create a subclass? |
| 16:25 | <JakeA> | fetch(req).then(doSomeOtherStuff) would have .abort, but Promise.resolve(fetch(req)) would not |
| 16:25 | <wanderview> | JakeA: annevk: chrome still has fetch() behind an experimental flag, right? do we have to maintain backward compat here or can we break compat to get a better API for the long term? |
| 16:25 | <Ms2ger> | What's the point of a pref if you can't break stuff? |
| 16:26 | <annevk> | JakeA: reading http://people.mozilla.org/~jorendorff/es6-draft.html#sec-promise-constructor it seems like a subclass is fine |
| 16:26 | <annevk> | JakeA: oh you mean forwarding |
| 16:27 | <annevk> | JakeA: SpeciesConstructor in http://people.mozilla.org/~jorendorff/es6-draft.html#sec-promise.prototype.then makes me think that then() forwards |
| 16:28 | <wanderview> | personally I think we should just consider changing it to fetch().reponse().then(function (response) { } );... I guess unless promise extension works out |
| 16:28 | <annevk> | JakeA: resolve does not... |
| 16:28 | <annevk> | JakeA: but you could do FetchPromise.resolve() presumably... |
| 16:29 | <annevk> | wanderview: boilerplate :-( |
| 16:29 | <JakeA> | annevk: I hadn't seen the @@species stuff. But yeah, think it works the same way. So I guess each fetch promise would have to define an instance @@species to retain its link to the original request? |
| 16:29 | <wanderview> | annevk: better than magic, implicit state on Request IMO |
| 16:30 | <annevk> | JakeA: something like that |
| 16:31 | <wanderview> | and the difference between fetch().then() and fetch().response().then() is 12 characters |
| 16:31 | <annevk> | I'm warming up to the subclass idea |
| 16:31 | <wanderview> | ok |
| 16:31 | <annevk> | wanderview: I think fetch().ready.then(res) {} would be slightly better if we wanted to go down that route |
| 16:31 | <wanderview> | ok |
| 16:32 | <annevk> | wanderview: and perhaps move the text() methods and such on that control object too |
| 16:32 | <wanderview> | annevk: uh... no? Cache.match() returns Response objects that need text() |
| 16:33 | <annevk> | ah yes |
| 16:40 | <wanderview> | annevk: added fetch().ready.then() to your gist |
| 16:46 | <annevk> | wanderview: ta |
| 16:52 | <annevk> | https://twitter.com/thebabydino/status/567226220249886721 is pretty cool |
| 16:52 | <annevk> | I wish the CSS WG would standardize the psuedo-elements already |
| 16:53 | <JakeA> | the use of /deep/ and background-size for the selected-so-far bit of the track is really smart |
| 16:54 | <annevk> | That use of /deep/ should not actually work |
| 16:54 | <JakeA> | I gave up styling range for https://jakearchibald.github.io/svgomg/. I just used a load of divs & clickjacked a real range |
| 16:54 | <JakeA> | hah ok. I don't know that much about shadow dom |
| 17:30 | <wanderview> | is there anything in the SW spec that prevents multiple fetch events from being triggered for the same URL at the same time? I mean... second event while still waiting for first event to resolve its respondWith() promise |
| 17:36 | <annevk> | wanderview: why would we prevent that? |
| 17:37 | <annevk> | wanderview: is this about e.g. the image cache? |
| 17:48 | <JakeA> | wanderview: as far as I know, browsers don't have a good answer for this with the http cache either |
| 17:52 | <wanderview> | annevk: JakeA: I don't think we should do it... was just wondering as I'm trying to track down an issue in the gecko implementation (https://bugzilla.mozilla.org/show_bug.cgi?id=1130803) |
| 17:52 | <annevk> | wanderview: it's still a bit unclear to me what the problem is |
| 17:53 | <annevk> | wanderview: if the problem is combining fetches, we should only do that in the network layer |
| 17:53 | <wanderview> | annevk: same here :-) I was just theorizing |
| 17:53 | <annevk> | wanderview: I guess I'll try to clarify that part of Fetch tomorrow by creating a section dedicated to the network part |
| 18:34 | <wanderview> | is it just me, or is this JakeA's twin (based purely on twitter avatar)? https://twitter.com/m_gol vs https://twitter.com/jaffathecake |
| 18:34 | wanderview | keeps getting them confused in his twitter feed. |
| 18:35 | <JakeA> | wanderview: haha there is *some* similarity I think |
| 18:36 | <wanderview> | it could just be all Europeans look alike to dumb Americans |
| 18:36 | <JakeA> | haha |
| 18:37 | wanderview | is slowly going insane from tracing the gecko network stack. |