| 00:44 | <foolip> | tobie: where does the code live that maps wpt dirs to labels? like what label for /css/fonts/? |
| 00:56 | <MikeSmith> | annevk: FYI about the problem with the W3C mailing-list search results becoming bad recently, as it turns out the cause was a bunch of broken indexes, the W3C mailing-list guru wrote a script today to catch the problem next time |
| 00:56 | <MikeSmith> | so thanks for reporting it :) |
| 01:35 | <hayato> | annevk: Let me look at https://github.com/whatwg/dom/issues/525#issuecomment-342179455 today. |
| 04:31 | <wanderview_> | JakeA: I filed the Response.url issue here... let me know if I misrepresented anything: https://github.com/whatwg/fetch/issues/629 |
| 04:46 | wanderview | realizes he was logged in from two accounts. |
| 05:56 | <annevk> | hayato: ta |
| 12:06 | <ldexterldesign> | hey all |
| 12:06 | <ldexterldesign> | anyone here, after some help? |
| 12:57 | <ldexterldesign> | well, here goes anyway |
| 12:58 | <ldexterldesign> | can anyone confirm the best places to soak up whatwg information (e.g. forums, mailing lists, websites)? |
| 12:58 | <ldexterldesign> | anything in addition to whatwg@listswhatwg and whatwg@whatwg mailing lists? |
| 12:58 | <KiChjang> | you mean blog.whatwg.org? |
| 12:58 | <ldexterldesign> | hope to hear back |
| 12:59 | <annevk> | ldexterldesign: the various GitHub repositories is where all the action is |
| 12:59 | <ldexterldesign> | KiChjang: hey, yea know about https://blog.whatwg.org/ thanks |
| 12:59 | <ldexterldesign> | annevk: hey, k cool |
| 12:59 | <ldexterldesign> | annevk: got a url? |
| 12:59 | <KiChjang> | indeed, GH is usually the most active |
| 12:59 | <annevk> | ldexterldesign: https://github.com/whatwg |
| 13:00 | <annevk> | ldexterldesign: e.g., https://github.com/whatwg/html for the HTML Standard |
| 13:00 | <ldexterldesign> | annevk: ta |
| 13:00 | <ldexterldesign> | curious, how do y'all manage github info |
| 13:00 | <ldexterldesign> | i gave up on watching repos because of email noise |
| 13:01 | <annevk> | ldexterldesign: I wrote https://annevankesteren.nl/2017/11/using-github earlier today |
| 13:01 | <ldexterldesign> | interestingly i see they use atom feeds on everything so i may use my feed reader |
| 13:01 | <annevk> | ldexterldesign: /notifications is my thing, basically |
| 13:01 | <ldexterldesign> | annevk: ha, glad i'm not the only one |
| 13:01 | <ldexterldesign> | annevk: all my dev' friends have the same issue |
| 13:02 | <annevk> | ldexterldesign: so yeah, you'll need to figure out if you want to monitor all discussions closely, or just see what's up every now and then |
| 13:03 | <annevk> | ldexterldesign: there's quite a few WHATWG repositories that don't have that much traffic though and should be easy to keep up with |
| 13:03 | <annevk> | ldexterldesign: whatwg/html is one of the more active |
| 13:11 | <ldexterldesign> | annevk: cool, thanks |
| 13:11 | <ldexterldesign> | annevk: i read all the chat in help@ before the list closed |
| 13:12 | <ldexterldesign> | annevk: there was a good post about lists having 300+ emails per month and not being able to keep up, now with github people can cherry pick interests and discuss in depth; which is inherently more useful |
| 13:21 | <ldexterldesign> | annevk: ahh, i see you've also written about that https://annevankesteren.nl/2016/10/standards-on-github |
| 13:21 | <ldexterldesign> | annevk: "A couple years ago I wrote Contributing to standards and it is worth noting how everything has gotten so much better since then. Basically all due to GitHub and standards groups such as TC39, WHATWG, and W3C embracing it. You can more easily engage with only those standards you are interested in. You can even subscribe to particular issues that interest you and disregard everything else. If you contrast that with mail |
| 13:21 | <ldexterldesign> | agreed |
| 15:06 | <annevk> | JakeA: do you know why I no longer have write access to the ServiceWorker repository? |
| 15:07 | <annevk> | JakeA: at least I remember being able to close issues and such |
| 15:07 | <JakeA> | annevk: maybe it happened when the repo moved to W3. Will fix |
| 15:10 | <JakeA> | annevk: added you as a collaborator. There are definitely folks there from the old repo, no idea why you disappeared. |
| 15:11 | <annevk> | JakeA: did you all discuss whether to keep dedicated workers as clients? |
| 15:11 | <annevk> | JakeA: I suppose wanderview brought that up |
| 15:15 | <JakeA> | annevk: yeah, briefly as part of https://github.com/whatwg/fetch/issues/629, but we didn't discuss it specifically or come to any conclusions |
| 15:15 | <JakeA> | Sounds like something we could do a call on though. I don't currently recall the pros & cons |
| 15:15 | <JakeA> | But that might be jet leg |
| 17:42 | <wanderview> | JakeA: annevk: we did not discuss it in detail... I guess I was waiting to hear from others that they wanted to make the change rather than explicitly bring it up myself in place of something else on the agenda |
| 17:49 | <annevk> | k |
| 18:30 | <wanderview> | JakeA: annevk: I'm also here all week if people still want to talk about it, of course |
| 18:59 | <TabAtkins> | annevk: Aw dang, /notifications does seem really useful. |
| 19:13 | <smaug____> | annevk: what does notifications do? |
| 19:14 | <smaug____> | is that something one needs to explicitly go and look at |
| 19:14 | <smaug____> | and it tells changes since last time or something? |
| 19:27 | <othermaciej> | annevk, Domenic: I'm making WebKit test cases to test that we *don't* support some nonstandard encodings that we used to. Does it make sense to add tests like that to WPT or should I leave them as WebKit layout tests? These are encodings that I don't think any other browser engine has ever supported. |
| 19:28 | <wanderview> | sounds good to include as WPT to me |
| 19:28 | <Mek> | there are a bunch of "historical" tests in wpt already to test that nonstandard stuff isn't supported |
| 19:28 | <gsnedders> | othermaciej: the expectation is that things not in Encoding are unsupported, AFAIK, so it seems totally appropriate |
| 19:29 | <othermaciej> | All right, I'll make myself a note to make WPT versions of these tests. |
| 19:36 | <wanderview> | annevk: does setting the security tag actually guarantee the security team will respond? my experience is these kind of "throw it over the wall to security" is a way of ignoring the issue |
| 19:50 | <annevk> | wanderview: it’s just a way of categorizing |
| 19:50 | <annevk> | wanderview: and copying the security team is a way of notifying, no guarantees, but also no throwing over walls… |
| 19:51 | <wanderview> | ok |
| 19:51 | <annevk> | smaug____: yup |
| 19:52 | <annevk> | Hmm Maciej left |
| 19:53 | <annevk> | wanderview: FWIW I think our options are make it work or reject |
| 19:54 | <annevk> | wanderview: if we go with reject we might also need to reconsider some other cases |
| 19:54 | <wanderview> | annevk: I don't understand why we can make it the same as the SW script doing `new Response(corsResponse.body)` |
| 19:54 | <wanderview> | as an interop failsafe |
| 19:54 | <wanderview> | while we collect data to see if we can reject |
| 19:56 | <annevk> | wanderview: losing headers is bad |
| 19:57 | <wanderview> | annevk: well `new Response(corsResponse.body, corsResponse)` or whatever it is to copy as much of the REsponse as safely possible... |
| 19:57 | <wanderview> | but sure, unsafe headers would be lost |
| 19:58 | <annevk> | wanderview: it seems it would break relative URLs and such too |
| 19:59 | <wanderview> | annevk: uh... no more than actually implementing the fetch spec change to use Response.url will... I mean using the Request.url is our current shipping behavior |
| 20:00 | <wanderview> | annevk: and chrome has a bug where it always uses Request.url for worker self.location, etc... not sure about stylesheets, but those aren't same-origin requests |
| 20:01 | <annevk> | I mean breaks expectations and breaks expected CORS setup |
| 20:01 | <annevk> | Maybe some early adopters work around this for service workers and would be broken in the way you suggest |
| 20:01 | <wanderview> | annevk: a same origin Request would not have a CORS setup? I guess I am confused about this concern |
| 20:01 | <annevk> | But long term it seems bad |
| 20:02 | <annevk> | If I redirect a same-origin CSS request to a CORS CSS on a CDN that should just work |
| 20:03 | <annevk> | If URLs would be adopted from the request that would not work |
| 20:03 | <wanderview> | annevk: what CSS request has mode="same-origin"... when I say a same-origin Request I mean Request.mode=='same-origin' |
| 20:04 | <wanderview> | maybe that is the confusion here |
| 20:04 | <wanderview> | I don't mean all Requests with same-origin urls |
| 20:04 | <annevk> | Yeah, maybe that is exceptional, but it still seems rather bogus |
| 20:04 | <annevk> | As depending on the request you end with diff very behavior |
| 20:05 | <annevk> | Moves away from response has authority |
| 20:11 | <Domenic> | https://github.com/blog/2460-archiving-repositories I archived javascript and meta-theme-color. xref might also be a candidate. |
| 20:18 | <wanderview> | annevk: yea, I don't want it... but shipping intercepted channels using Request.url for years may require something lame like this for interop... and its not different from what the SW script can do itself anyway |
| 20:25 | <annevk> | Domenic: html-differences still uses it |
| 20:26 | <annevk> | wanderview: yeah understood; I just rather not do that if possible; it would be a rather weird special case |
| 20:28 | <annevk> | Domenic: nifty feature though |
| 20:53 | <smaug____> | annevk: that composedPath issue. Need to tweak your version of algorithm I guess |
| 21:11 | <annevk> | smaug____: yeah, ping me tomorrow? Will try to remember too |
| 21:11 | <smaug____> | k |
| 21:12 | <annevk> | smaug____: if you have suggestions though, let me know, it’s been a while since I had this all fresh in my head |
| 21:12 | <smaug____> | easiest might be if that get parent algo returned the flag too |
| 21:12 | <smaug____> | as I suggested earlier |
| 21:18 | <annevk> | I wonder why that would so much easier, but we could I suppose if we coordinate with IDB |
| 21:20 | <jsbell> | othermaciej: https://github.com/w3c/web-platform-tests/blob/master/encoding/unsupported-encodings.html |