| 00:46 | <smaug____> | jgraham: are the wpt tests for websockets? |
| 00:47 | <smaug____> | websockets in workers |
| 02:55 | <Domenic> | mounir: iis Permissions constructible? Seems bad to have statics if not. |
| 04:24 | <MikeSmith> | if there's somebody around here who's familiar with Apache's HTTPClient stuff and could sanity-check-level review of https://github.com/validator/validator/commit/ce45db603aa77fa5809044e4e1d82c9431fd8b7f#diff-c9f54b9fc478b7db28d3e3443278ac49R122 I'd really appreciate it |
| 04:25 | <MikeSmith> | I think I got it right but I'm not an idiomatic Java programmer and the set up APIs involved there is just baroque |
| 04:28 | <MikeSmith> | in particular despite having read through a ton of their docs, I really don't have a clear idea of how the threading behavior here not what the thread-safety precautions I need to be taking in the rest of my application code as a result of using their pooling connection manager here vs whatever the default connection manager is otherwise |
| 04:29 | <MikeSmith> | in fact from their their docs I can't even tell what connection manageer it uses by default otherwise, or if it even has a name or even if it's using a "connection manager" in the default case at all |
| 06:18 | <annevk> | MikeSmith: awake now |
| 07:44 | <annevk> | So https://twitter.com/brucel/status/577504998256484352 is cool, but unless they figure out how to run Chromium in the cloud for cheap, they're still running abandonware, just a little newer abandonware... |
| 08:05 | <zcorpan> | smaug____: it seems not |
| 08:07 | <MikeSmith> | annevk: so please see https://vnu.herokuapp.com/?showimagereport=yes&doc=http%3A%2F%2Fxkcd.com%2F |
| 08:07 | <MikeSmith> | ...which uses the "Image report" feature of the validator |
| 08:21 | <annevk> | MikeSmith: ah yeah, you'd have to proxy those images or live with the warning |
| 08:22 | <MikeSmith> | annevk: ok |
| 08:23 | <annevk> | MikeSmith: it's a goal of sorts to eventually disallow those kind of images too, so I guess you should try to think about a proxy or blocking insecure images |
| 08:23 | <annevk> | MikeSmith: generating a warning for sites that don't use HTTPS might also be a good idea |
| 08:23 | <annevk> | MikeSmith: some integration with ssllabs perhaps? |
| 08:26 | <MikeSmith> | annevk: maybe down the road |
| 08:27 | <MikeSmith> | short term, I fell like it would just annoy people and make them not want to use the validator |
| 08:27 | <MikeSmith> | if we start giving them warnings I mean |
| 08:28 | <annevk> | or some kind of tip thing |
| 08:28 | <annevk> | perhaps wait for let's encrypt to launch |
| 08:28 | <MikeSmith> | yeah I guess I could add something unobtrusive |
| 08:29 | <MikeSmith> | yeah |
| 08:29 | <MikeSmith> | I wonder if there are any image proxying services |
| 08:29 | <MikeSmith> | hosted image proxying |
| 08:44 | <MikeSmith> | annevk: https://sideshowbarker.net/tests/proxied-image.html |
| 08:46 | <MikeSmith> | using a google image proxying service described at https://carlo.zottmann.org/2013/04/14/google-image-resizer/ |
| 08:46 | <MikeSmith> | the URL for the image is https://images1-focus-opensocial.googleusercontent.com/gadgets/proxy?url=http://imgs.xkcd.com/comics/arbitrage.png&container=focus |
| 08:47 | <MikeSmith> | which if you navigate to it you'll see has a Content-Disposition: attachment;filename=p.txt header |
| 08:47 | <MikeSmith> | but if you put it in a img[src] attribute it works |
| 08:48 | <MikeSmith> | so I could actually have the validator use that |
| 09:45 | <MikeSmith> | actually using some third-party thing is bad; better to just convert the images to base64 and just use data URIs |
| 09:46 | <annevk> | MikeSmith: if you convert them you need to use a proxy, no? |
| 09:47 | <MikeSmith> | why? I serve them as data URIs |
| 09:48 | <MikeSmith> | am I missing something? |
| 09:51 | <annevk> | MikeSmith: isn't your server then fetching them first to convert them into such URLs? |
| 09:51 | <annevk> | MikeSmith: as in, isn't your server then acting as a proxy? |
| 10:00 | <MikeSmith> | annevk: ah yeah on the backend— but it would just be a matter of reading them into a byte array then converting that to base64 to put into a data to URI. it would otherwise not be persisting the images or making them available at some new URL. so, not an open proxy but just a per-session/transection/request proxy. that is, nothing but the response document I return would have access to the converted im |
| 10:00 | <MikeSmith> | age |
| 10:01 | <MikeSmith> | well, except of course as a data URI that anybody could manually copy |
| 10:15 | <zcorpan> | MikeSmith: what would that do to the load on the validator server to have to fetch and send lots of images? |
| 10:19 | <zcorpan> | how often is the image report used? |
| 10:20 | <MikeSmith> | zcorpan: not used much, I think |
| 10:20 | <MikeSmith> | I can imagine it might be a load problem if it were used a lot |
| 10:20 | <MikeSmith> | but in practice, it's not |
| 10:22 | <MikeSmith> | plus, the w3c instances are running on relatively beefy hardware |
| 10:58 | annevk | wonders how far TabAtkins is with converting DOM |
| 10:58 | <Ms2ger> | I thought he was done |
| 10:59 | <Ms2ger> | > Jeezus, I finally reached the end of DOM. All 9k+ lines (WHAT, 9000?!?) converted. Now it's time to fix all the errors. |
| 10:59 | <annevk> | Aah |
| 11:00 | <annevk> | Errors :-) |
| 11:40 | <ondras_> | hmm, text nodes can be event targets? |
| 11:41 | <Ms2ger> | Sure |
| 11:43 | <ondras_> | so inside a "click" event handler, e.target.nodeType can be 3, right? |
| 11:43 | <ondras_> | interesting, I would say I never encountered this |
| 11:44 | <Ms2ger> | I didn't say that |
| 11:44 | <Ms2ger> | You can dispatch events at text nodes, but that doesn't imply the browser actually does that |
| 11:44 | <ondras_> | right |
| 11:44 | <ondras_> | http://jsfiddle.net/ondras/6sa3gm9n/ |
| 11:45 | <ondras_> | clicking on <p> results in p being the target |
| 11:45 | <ondras_> | but I have a different, complex web page |
| 11:45 | <ondras_> | where the e.target is #text |
| 11:48 | <ondras_> | Ms2ger: can you please elaborate on when and why can this happen? |
| 11:48 | <Ms2ger> | I don't know |
| 11:49 | <annevk> | I think it's when you actually click on the text rather than next to it |
| 11:49 | <annevk> | But hey, nobody has defined hit testing |
| 11:49 | <annevk> | Also something about me being a broken record |
| 11:50 | <ondras_> | the situation in question happened to me when clicking inside a "calendar" widget, that is implemented as a <table> |
| 11:50 | <ondras_> | but http://jsfiddle.net/ondras/6sa3gm9n/1/ does not exhibit this behavior |
| 11:51 | <ondras_> | perhaps it is somehow related to the fact that the calendard widget disappears when clicked |
| 11:58 | <zcorpan> | MikeSmith: w3c block is still there btw |
| 12:00 | <zcorpan> | ondras_: do you have a link to the page where it happens? |
| 12:00 | <ondras_> | zcorpan: probably not, let me try to find a publicly accessible version |
| 12:01 | <ondras_> | zcorpan: so yes, I can reproduce it. But I will need to give you a specific guidance :) |
| 12:01 | <ondras_> | zcorpan: first, open http://mapy.cz/zakladni?planovani-trasy&x=16.8616839&y=49.9455682&z=6&rc=9iCMYxXmd-&rl=Nov%C3%A1%20Ves%20I%2C%20okres%20Kol%C3%ADn&rl=&rp={%22criterion%22%3A%22pubt%22%2C%22departure%22%3Atrue%2C%22time%22%3A%22%22%2C%22date%22%3A%2205.03.2015%22} |
| 12:01 | <zcorpan> | (in firefox?) |
| 12:02 | <ondras_> | yes. |
| 12:02 | <zcorpan> | check |
| 12:02 | <ondras_> | zcorpan: then, click the input with 05.03.2015 in it |
| 12:02 | <ondras_> | this opens the calendar widget. |
| 12:02 | <ondras_> | clicking its day cells results in the weird event |
| 12:02 | <ondras_> | BUT |
| 12:02 | <ondras_> | the website has "console" overriden |
| 12:03 | <ondras_> | so console.log does nothing |
| 12:03 | <ondras_> | to enable that, please do console.DEBUG=1 |
| 12:03 | <ondras_> | so something like |
| 12:03 | <ondras_> | console.DEBUG=1; document.addEventListener("click", function(e) { console.log(e.target); }) |
| 12:03 | <ondras_> | does the trick. then just open the calendar, click a day... |
| 12:03 | <ondras_> | #text :) |
| 12:05 | <MikeSmith> | zcorpan: please send a message to sysreq⊙wo asking to be unblocked, and cc me (and mention that the block has persisted over several days) |
| 12:05 | <zcorpan> | ondras_: i get the <td> |
| 12:05 | <MikeSmith> | GPHemsley: can you please install https://www.mediawiki.org/wiki/Extension:ExternalRedirect |
| 12:05 | <zcorpan> | MikeSmith: ok |
| 12:06 | <GPHemsley> | MikeSmith: That seems risky... where are you looking to redirect? |
| 12:06 | <MikeSmith> | write-only pages |
| 12:06 | <MikeSmith> | it works only for write-only pages |
| 12:07 | <GPHemsley> | still, please present your usecases :) |
| 12:07 | <MikeSmith> | GPHemsley: the Validator-related pages, to redirect to equivalents in https://github.com/validator/validator/wiki |
| 12:08 | <MikeSmith> | that reminds me, I need to mark the current ones as write-only now |
| 12:08 | MikeSmith | wonders if I have perms to do that |
| 12:08 | <GPHemsley> | MikeSmith: It seems what you really want is an Interwiki namespace |
| 12:08 | <GPHemsley> | https://www.mediawiki.org/wiki/Extension:Interwiki |
| 12:09 | <ondras_> | zcorpan: I get the <td> when I click the empty space around a number. But when clicking the "5" directly, for instance, I get #text |
| 12:09 | <ondras_> | zcorpan: ff 36.0.1 @ linux |
| 12:09 | <MikeSmith> | GPHemsley: ah ok, will take a look |
| 12:09 | <MikeSmith> | thanks |
| 12:09 | <ondras_> | zcorpan: looks like it happens only on those <td>s where clicking hides the widget |
| 12:10 | <zcorpan> | ondras_: i still get the <td>. have nightly 39.0a1 (2015-03-11) on mac os x 10.10.1 |
| 12:10 | <ondras_> | hm |
| 12:10 | <ondras_> | not sure what to do now. |
| 12:10 | <zcorpan> | don't have 36 to check :-) |
| 12:10 | ondras_ | does not have neither nightly nor macosx |
| 12:11 | <MikeSmith> | GPHemsley: hmm that seems more complicated by a good measure |
| 12:11 | <GPHemsley> | How so? |
| 12:12 | <zcorpan> | ondras_: i had firefox *26*, and can reproduce there |
| 12:12 | <ondras_> | zcorpan: ah, nice! |
| 12:13 | <GPHemsley> | MikeSmith: This extension is a known entity to me, and I think it will solve your usecase. |
| 12:13 | <MikeSmith> | GPHemsley: oh wait I think I was misunderstanding what that does |
| 12:13 | <MikeSmith> | GPHemsley: yeah agreed, after actually taking time to read it |
| 12:13 | <MikeSmith> | this is the right solution |
| 12:14 | <GPHemsley> | MikeSmith: Is this an urgent request? Because I don't have the time to install it right now? |
| 12:14 | <GPHemsley> | -? |
| 12:15 | <zcorpan> | ondras_: the text node's parentNode is null according to devtools |
| 12:15 | <MikeSmith> | GPHemsley: not urgent at allーvery low priority |
| 12:15 | <GPHemsley> | OK, cool |
| 12:15 | <GPHemsley> | I'll include it in my maintenance whenever I get to it |
| 12:16 | <MikeSmith> | GPHemsley: superーthanks! |
| 12:16 | <GPHemsley> | MikeSmith: In the meantime, you might find this template useful: https://wiki.whatwg.org/wiki/Template:Obsolete |
| 12:16 | MikeSmith | looks |
| 12:16 | <MikeSmith> | ah good |
| 12:17 | <MikeSmith> | thanks for that too |
| 12:20 | <ondras_> | zcorpan: ah, okay then |
| 12:20 | <ondras_> | zcorpan: will try adjusting that |
| 12:23 | <mounir> | smaug____: you would prefer window.Permissions or window.permissions? |
| 12:36 | <GPHemsley> | Anyone have any insight into this proposal for a 'font' top-level MIME type? http://dev.w3.org/webfonts/WOFF2/spec/#IMT |
| 12:38 | <GPHemsley> | Editors: |
| 12:38 | <GPHemsley> | Vladimir Levantovsky (Monotype) |
| 12:38 | <GPHemsley> | Raph Levien (Google) |
| 12:45 | <smaug____> | mounir: I don't have preference |
| 12:49 | <smaug____> | mounir: is this all for now about Permissions? |
| 12:49 | <smaug____> | mounir: are we sure we don't want the API to implement or extend some other interface |
| 12:49 | <smaug____> | in such case singleton might work better |
| 12:56 | <zcorpan_> | jgraham: Ms2ger: https://github.com/operasoftware/presto-testo/pull/43 |
| 13:31 | <mounir> | smaug____: how so? I mean, do you have an interface in mind? |
| 13:31 | <smaug____> | mounir: say, you want to handle events for some reason |
| 13:31 | <smaug____> | like, get observed when some permission changes |
| 13:32 | <mounir> | smaug____: yes, in such case, we might want to live in navigator. |
| 13:32 | <smaug____> | why |
| 13:32 | <smaug____> | where did you get navigator here? |
| 13:33 | <mounir> | smaug____: sorry, I thought taht's what you meant |
| 13:33 | <mounir> | what did you mean? |
| 13:33 | <smaug____> | mounir: just thinking about whether to use interface + static methods |
| 13:33 | <smaug____> | or singleton object |
| 13:34 | <mounir> | smaug____: ok, I was just assuming that the singleton would live in navigator |
| 13:34 | <mounir> | there are no plans in having anything else than static methods |
| 13:34 | <smaug____> | right |
| 13:34 | <mounir> | obviously, that could change but for now, the plan is to have that interface state less |
| 13:35 | <mounir> | if things change, it would be forward compatible |
| 13:35 | <smaug____> | singleton would be |
| 13:35 | <mounir> | yes |
| 13:35 | <smaug____> | interface + static methods might not be |
| 13:37 | <zcorpan_> | heh, try{top.opener.rr(result);}catch(e){} is still in my muscle memory |
| 14:26 | <wanderview> | annevk: does it still make sense to expempt HEAD in step 4 here? https://github.com/slightlyoff/ServiceWorker/issues/653#issuecomment-82153813 |
| 14:26 | <wanderview> | since we can only put GET methods into the Cache by default? |
| 14:26 | <wanderview> | or does HEAD normally equate to a GET |
| 14:26 | <wanderview> | ? |
| 14:48 | <annevk> | wanderview: can I get you to comment on my Storage wiki page first? :p |
| 14:49 | annevk | looks |
| 14:49 | <wanderview> | annevk: I did glance at it before... I'll look again before our meeting today |
| 14:51 | <annevk> | wanderview: HEAD usually does the same as GET, except that the server does not return the body |
| 14:51 | <wanderview> | k |
| 14:51 | <annevk> | wanderview: what does the cache API do? |
| 14:51 | <wanderview> | annevk: as far as I know Cache returns the body too |
| 14:51 | <annevk> | wanderview: we might want to change that |
| 14:51 | <wanderview> | at least, we do... and I believe thats what the spec says |
| 14:51 | <annevk> | wanderview: I can file a bug on the spec |
| 14:53 | <annevk> | wanderview: https://github.com/slightlyoff/ServiceWorker/issues/655 |
| 14:57 | <wanderview> | annevk: I'm not sure if Cache should really block them from getting the body in that case... seems like content script could do this themselves |
| 15:00 | <annevk> | wanderview: but why then do we pay attention to method at all? |
| 15:00 | <wanderview> | annevk: because you can only store GETs in a cache right now |
| 15:00 | <annevk> | wanderview: then HEAD should do the same as POST |
| 15:01 | <wanderview> | annevk: I guess I don't feel strongly either way |
| 15:02 | <annevk> | wanderview: the point of doing HEAD is that it can be a whole lot cheaper |
| 15:02 | <annevk> | wanderview: e.g. if the server stores metadata and files separately or some such |
| 15:02 | <annevk> | wanderview: in case of Cache you could imagine setting up a simpler Response object structure... |
| 15:02 | <annevk> | wanderview: seems weird to allow HEAD but then give it identical semantics to GET |
| 15:03 | <wanderview> | annevk: I guess it makes sense if someone is just doing a simple respondWith(cache.match(event.request)); and it ends up intercepting a HEAD request |
| 15:03 | <wanderview> | annevk: its not really a problem for me to implement... I already support Response without a body as you can synthetically create one |
| 15:07 | <annevk> | wanderview: I guess it's up to JakeA if he's still maintaining that specification |
| 15:08 | <annevk> | wanderview: we did discuss moving the Cache API into Fetch at some point, but that hasn't really materialized yet |
| 15:08 | <wanderview> | annevk: he should be? has he said otherwise? |
| 15:08 | <annevk> | wanderview: yeah, I think so |
| 15:43 | <wanderview> | annevk: do you have particular questions for me in relation to the storage wiki? I generally like where we are going, but I'm still nervous about nag popups |
| 15:44 | <annevk> | wanderview: I was wondering whether you had seen https://developer.mozilla.org/en-US/docs/Mozilla/Tech/Places/Frecency_algorithm and to what extent we should consider aligning storage and the HTTP cache in terms of algorithms and quota |
| 15:44 | <annevk> | wanderview: but also any comments/concerns on the API |
| 15:45 | <wanderview> | annevk: my gut feeling is we should try not to couple ourselves tightly to HTTP cache... it seems particularly performance sensitive for the whole browser and they should be free to experiment/change based on real life usage |
| 15:46 | <wanderview> | annevk: so we could borrow ideas from there, but maybe not count on them staying aligned |
| 15:46 | <annevk> | wanderview: it seems weird that we'd drop the HTTP cache but not localStorage if both are best effort |
| 15:46 | <wanderview> | annevk: the Frecency thing strikes me as too detailed and specific to go in a spec (is that an ironic statement?) |
| 15:46 | <annevk> | wanderview: I didn't mean that as being part of a spec necessarily |
| 15:47 | <annevk> | wanderview: just wondering that if "best effort" drops storage, should it drop HTTP cache as well? And vice versa |
| 15:47 | <wanderview> | annevk: http cache makes zero guarantees, though... for example, if you get two responses that match a request based on VARY headers... http cache in gecko only stores the last one you visit |
| 15:47 | <wanderview> | annevk: I would vote no, to start... we could allow it, but not require it |
| 15:48 | <wanderview> | annevk: at least in gecko, the http cache is a carefully tuned thing that is wholely separate from all our other storage implementations |
| 15:48 | <annevk> | wanderview: yeah I'm not really talking about at spec-level |
| 15:48 | <annevk> | wanderview: mostly wondering whether it makes sense for the browser to do such a thing |
| 15:49 | <wanderview> | annevk: the main thing I want in relation to http cache is the ability to de-duplicate a thing in Cache with a file in the http cache... |
| 15:49 | <wanderview> | thats pretty impossible in gecko today, though |
| 15:50 | <annevk> | wanderview: yeah, and it seems you'd want the HTTP cache to have the same scope as other storage |
| 15:51 | <annevk> | wanderview: it doesn't have to have the same reliability but infrastructure-wise it seems a lot could should? be shared |
| 15:55 | <wanderview> | annevk: the reality is I don't think we want them to be shared... http cache has tighter performance constraints that might make it take different design paths than DOM APIs |
| 15:56 | <wanderview> | and it shouldn't be constrained by those mostly unrelated DOM APIs |
| 15:56 | <wanderview> | just my opinion of course |
| 15:56 | <annevk> | wanderview: with service workers it seems HTTP cache and Cache have near identical considerations |
| 15:57 | <wanderview> | annevk: Cache is spec'd as to how it behaves and what it must store... that will always make it slower than HTTP cache that can cut corners based on real-world usage data |
| 15:57 | <wanderview> | annevk: dropping this like the prefixMatch from Cache has made it closer to http cache, though |
| 15:57 | <wanderview> | ^this^things |
| 18:25 | <TabAtkins> | annevk: Yeah, done with the conversion, just got a lot of link failures to address. And it's uncovered a lingering unicode bug in Bikeshed I need to fix. |
| 18:26 | <annevk> | hah yay |
| 18:35 | <TabAtkins> | Thanks for letting me take all this time. This is a big spec, and getting it fixed up properly and into Shepherd will help a lot of people trying to write specs that touch the DOM. |
| 19:40 | <wanderview> | annevk: do you understand vary headers? (or anyone else) |
| 19:40 | <wanderview> | does step 9.5.1 of this look right? https://slightlyoff.github.io/ServiceWorker/spec/service_worker/index.html#query-cache-algorithm |
| 19:41 | <wanderview> | shouldn't a vary header value of * immediately match the response? |
| 19:42 | <wanderview> | JakeA: does it look right to you? ^^^ |
| 21:05 | <annevk> | wanderview: isn't it easier to read the Vary spec? |
| 21:06 | <wanderview> | annevk: I don't think the official VARY spec allowed * to mixed with other values at all |
| 21:06 | <annevk> | wanderview: shouldn't we do the same then? |
| 21:06 | <wanderview> | annevk: I only ask about this because gecko's implementation of vary:*,otherheader does something slightly different than the SW spec |
| 21:06 | <wanderview> | annevk: I have no idea... I'm new here |
| 21:07 | <annevk> | wanderview: I think in principle we should match the semantics of the HTTP specification |
| 21:07 | <wanderview> | annevk: it seems for web compat we have to support * mixed with other values... or maybe it changed at some point and I am looking at something out of date |
| 21:07 | <annevk> | wanderview: whenever we deviate, we should file a GitHub issue |
| 21:07 | <annevk> | wanderview: if that's true, we should point out in the specification why we deviate |
| 21:07 | <wanderview> | annevk: where is the most up-to-date VARY spec? |
| 21:08 | <wanderview> | the internet appears littered with stale specs |
| 21:08 | <annevk> | wanderview: I guess https://tools.ietf.org/html/rfc7231#section-7.1.4 would be it |
| 21:08 | <wanderview> | yea, thats what I read |
| 21:08 | <wanderview> | I'll open a SW spec issue |
| 21:09 | <annevk> | ta |
| 21:09 | <annevk> | I guess I should do a more detailed review of Cache at some point |
| 21:12 | <seth_> | zcorpan: so what's the next step for this issue? https://www.w3.org/Bugs/Public/show_bug.cgi?id=28096 |
| 21:13 | <seth_> | zcorpan: i'm fairly keen to implement loadend for multipart/x-mixed-replace images in gecko, but only if i'm fairly confident this will stick |
| 21:14 | <annevk> | seth_: do all browsers support multipart/x-mixed-replace? |
| 21:15 | <wanderview> | annevk: https://github.com/slightlyoff/ServiceWorker/issues/656 |
| 21:15 | <seth_> | annevk: IE does not support multipart images |
| 21:16 | <seth_> | in general support for multipart/x-mixed-replace images and documents seems to be shrinking everywhere, but i suspect we will end up being stuck with at least the subset necessary to display JPEG webcams |
| 21:16 | <annevk> | seth_: how does IE do those webcams? |
| 21:17 | <seth_> | annevk: people have hacks, like reloading the image in JS on a timer |
| 21:17 | <annevk> | seth_: it seems though that if in general usage is subpar we shouldn't be putting effort into them |
| 21:18 | <seth_> | annevk: i generally agree, yes, but i think this is one specific case where we should specify something that is useful as opposed to something totally non-useful |
| 21:18 | <seth_> | annevk: there's not a huge implementation cost for firing loadend |
| 21:19 | <seth_> | annevk: now if you want to talk about removing them from the spec altogether, i could certainly get behind that =) but whatever we do specify should be useful |
| 21:19 | <annevk> | seth_: yeah, I figured we could maybe try removing unused formats |
| 21:20 | <annevk> | seth_: or land in the same code path as IE |
| 21:20 | <annevk> | if it's a dead end anyway taking a small perf hit doesn't seem too bad |
| 21:20 | <JakeA> | wanderview: the intent in the SW spec is to ignore vary * |
| 21:20 | <JakeA> | (sorry IRC cloud keeps randomly not giving me notifications) |
| 21:20 | <annevk> | JakeA: question is about "Vary: *, x" which is technically illegal |
| 21:20 | <wanderview> | JakeA: uh... it doesn't do that does it? |
| 21:20 | <seth_> | annevk: browser sniffing makes it hard, but in gecko we're moving in the direction of only supporting JPEG parts, and requiring that they all be the same size. that lets us treat them as just another animated image format, which is not so bad |
| 21:21 | <seth_> | annevk: chrome removed support for multipart/x-mixed-replace documents, and i'm pushing to have us follow them on that, so then what we're left with is the webcam subset |
| 21:21 | <annevk> | seth_: as long as we don't expect all browsers to align on something we implement we're potentially shooting ourselves in the (long term) foot |
| 21:22 | <JakeA> | wanderview: hmm, ok, probably needs fixing. Vary: * struck me as pretty uncacheable and likely just to bloat the cache, so I figured avoiding it would be best. Do you think it's useful? |
| 21:22 | <wanderview> | JakeA: I barely understand VARY (raises confidence in the gecko Cache implementation, I know) |
| 21:22 | <annevk> | seth_: and if we add features to features that are not widely supported we risk developers creating more content specifically for Gecko... |
| 21:22 | <zcorpan> | seth_: do you want just the loadend event? |
| 21:23 | <wanderview> | JakeA: it seems VARY:* is treated as a match, right? |
| 21:23 | <JakeA> | wanderview: Vary is pretty crazy. I didn't know too much about it before I did the cache design |
| 21:23 | <seth_> | annevk: yep. we're actually shrinking what we're supporting, and i think that chrome and us will end up in the same place. the one exception is the loadend event, which i really think is worth adding |
| 21:23 | <annevk> | JakeA: famous last words |
| 21:23 | <seth_> | zcorpan: i don't view the progress events as important, really. i'm mostly concerned about the loadend event |
| 21:23 | <annevk> | seth_: mkay, up to you I guess |
| 21:24 | <JakeA> | wanderview: I was intending Vary:* to be matched as if Vary wasn't there, but maybe that got lost in the spec |
| 21:24 | <annevk> | wanderview: JakeA: I recommend asking mnot / jreschke |
| 21:24 | <zcorpan> | seth_: can you check if another browser vendor is interested in implementing it? |
| 21:24 | <annevk> | wanderview: JakeA: mnot / reschke on GitHub |
| 21:25 | <seth_> | zcorpan: yeah, that seems like the next step |
| 21:25 | <JakeA> | annevk: cheers, added to todos |
| 21:25 | <JakeA> | annevk: and appologies for inactivity on tickets of late. Two week holiday and thrown straight into conference (and employee review \o/) |
| 21:26 | <JakeA> | Maybe I'll be fired before I get to it |
| 21:26 | <annevk> | JakeA: you've not contributed to mobile performance? |
| 21:26 | <seth_> | zcorpan: probably if blink would take it, we're ok. i'm not sure if the appropriate engineers follow the whatwg mailing list or bugtracker, though... |
| 21:27 | <JakeA> | annevk: just joking, but it's a lengthy process (if you're trying to go for promotion, which I am) |
| 21:27 | <annevk> | JakeA: I was hoping you'd be drinking beer someplace not worrying much about the web and such |
| 21:27 | <JakeA> | annevk: and I didn't know the deadline was today until today |
| 21:27 | <annevk> | oh boy |
| 21:27 | <annevk> | good luck |
| 21:28 | <JakeA> | I'm going to do beer tomorrow :D |
| 21:28 | <wanderview> | JakeA: I think if a * is encountered in step 9.5.1 we want to exit the step 9 loop and keep the match... if I understand your intention correctly: https://slightlyoff.github.io/ServiceWorker/spec/service_worker/index.html#query-cache-algorithm |
| 21:28 | <annevk> | if you still need an external vote of approval, they know how to find me |
| 21:28 | <wanderview> | JakeA: that is also what gecko does in its http impl |
| 21:28 | <wanderview> | sorry...I have to run... |
| 21:28 | <wanderview> | JakeA: good luck! |
| 21:29 | <JakeA> | Cheers! |
| 21:29 | <JakeA> | annevk: cheers, I'll see if there's a way to do that. It seems awfully internal-centric |
| 21:30 | <zcorpan> | seth_: yeah it's probably better to email the relevant people directly. the cc list of https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/hMNb2utmh_s might contain someone relevant (or yoavweiss) |
| 21:32 | <seth_> | zcorpan: thanks, i'll try that |
| 21:33 | <seth_> | zcorpan: i'm tempted to subscribe to blink-dev so i can contribute to that thread as well =) |
| 21:33 | <zcorpan> | seth_: do it :-) |
| 21:34 | <smaug____> | seth_: plenty of mozillians in that list too |
| 21:35 | <smaug____> | need to watch what crazy ideas blink'ers have ;) |
| 21:35 | <seth_> | smaug____: heh, i guess there's precedent then =) |
| 21:47 | <seth_> | zcorpan: my best guess is that noel gordon is a good starting point. it seems that google groups censors everyone's full email addresses, though. do you have noel's email? |
