| 05:34 | <hayato> | smaug____: Thank you for the test case: http://mozilla.pettay.fi/shadow_focus.html |
| 05:35 | <hayato> | smaug____: I've confirmed. At least, it is an unexpected behavior to me. I guess it's Blink's bug. |
| 05:35 | <hayato> | I happens also in open shadow root. |
| 05:36 | <hayato> | Let me file a bug for Blink. |
| 08:58 | <annevk> | JakeA: minor nit: you probably want to say origin of the last URL |
| 08:59 | <annevk> | JakeA: it's an interesting addition to the same-origin policy this |
| 08:59 | <annevk> | JakeA: and I guess it wasn't quite thought out back when we added media elements and partial requests |
| 09:00 | <JakeA> | annevk: I'm worried about origin A redirecting to different resources on origin B |
| 09:01 | <JakeA> | annevk: Another thing we'll have to decide is where the next partial request goes. Does it go back to the original url, or the final url in the previous response |
| 09:01 | <JakeA> | I think Firefox & Chrome do different things here |
| 09:02 | <annevk> | JakeA: oh right, same URL might be correct given it's partial requests, sorry |
| 09:03 | <JakeA> | annevk: https://github.com/whatwg/fetch/issues/145 "denied responses to range requests if their origin is distinct from the origin response for the initial request" - so it sounds like Chrome does what you suggest |
| 09:03 | <JakeA> | annevk: but I don't think Chrome goes back to the src for the next part. |
| 09:06 | <annevk> | JakeA: I vaguely recall mkwst saying that |
| 09:06 | <annevk> | JakeA: that's probably reasonable |
| 09:06 | <JakeA> | annevk: but may become unreasonable with a service worker in the middle |
| 09:07 | <JakeA> | I'll make a note in the issue |
| 09:07 | <annevk> | JakeA: can the service worker make them distinct? |
| 09:07 | <annevk> | JakeA: I thought the response URL would win, or maybe not with synthetic? |
| 09:08 | <JakeA> | annevk: The service worker could respond with resource A from origin B, then on the next range request respond with resource B from origin B. |
| 09:09 | <JakeA> | annevk: This isn't possible in Chrome today, as it goes straight to origin B to request the second part, so origin B gets to decide where the next part is appended from |
| 09:09 | <JakeA> | annevk: but with a service worker, origin A gets a say each time |
| 09:13 | <JakeA> | (it would be difficult to respond using a particular range from origin B, since I can't create the range headers myself, but I might be able to convince a media element to do it, then keep a clone of the response around in the service worker to reuse later) |
| 09:22 | <annevk> | JakeA: but the media element could reject resource B for not being the same URL, no? |
| 09:22 | <annevk> | JakeA: or the Fetch "range request" algorithm, which seems like a better place to enforce such security restrictions |
| 09:23 | <JakeA> | annevk: but it wouldn't reject if it was just checking the origin of the last url |
| 09:24 | <annevk> | JakeA: I was already convinced that same URL would be more reasonable |
| 09:24 | <JakeA> | ah sorry |
| 09:24 | <annevk> | JakeA: or does Chrome currently allow that URL to redirect elsewhere within the same origin? |
| 09:25 | <annevk> | JakeA: or is that a request with redirect mode set to "error"? (that'd make more sense to me) |
| 09:26 | <JakeA> | annevk: I'll test that. But that seems ok if it goes straight to origin B. Origin B can redirect to anywhere else on origin B. But if Chrome does do that, I don't know if it's behaviour we need to preserve. |
| 09:26 | <JakeA> | annevk: I think this stuff needs to sit with the media element. Only it has the concept of a single piece of media. The fetch spec doesn't have the state of previous requests. |
| 09:27 | <annevk> | JakeA: I think we should have a helper in Fetch, perhaps at a higher-level than the fetch call |
| 09:28 | <annevk> | JakeA: there's been talk about using range requests for images to figure out width/height early on |
| 09:28 | <annevk> | JakeA: we might get other contexts that want to do range requests |
| 09:28 | <annevk> | JakeA: seems problematic if they don't reuse the security infrastructure |
| 09:30 | <JakeA> | annevk: agreed. I've already made the privileged headers flag not-exported, so you have to go through the range request helper. I'll add more stuff to that like url history. |
| 10:22 | <kochi> | MikeSmith: what IRC channel should we use for webcomponents F2F? irc.w3.org#webplat ? |
| 10:24 | <MikeSmith> | kochi: yeah that should work |
| 10:25 | <kochi> | MikeSmith: you seem not on the channel... |
| 10:25 | <MikeSmith> | yeah, I didn’t know that channel actually existed :) |
| 10:25 | <MikeSmith> | I have never been on it as far as I can remember |
| 10:26 | <kochi> | MikeSmith: #webapps is superceded by #webplat IIUC, but much fewer participants there |
| 10:26 | <MikeSmith> | oh |
| 10:26 | <kochi> | We used the channel at TPAC last year. |
| 10:26 | <MikeSmith> | maybe #webapps is the better choice, then? |
| 10:26 | <MikeSmith> | ah OK |
| 10:26 | <MikeSmith> | yeah I didn’t attend any of the TPAC meetings of that group |
| 10:27 | kochi | thinks it's weird to chat about the topic in #whatwg channel... |
| 10:27 | <MikeSmith> | heh |
| 10:27 | <annevk> | Well the majority of the features are now defined by WHATWG standards so might as well |
| 10:27 | <kochi> | So WebPlat is the official working group name now, I think #webplat seems better now. |
| 10:28 | <MikeSmith> | kochi: sgtm |
| 10:29 | <kochi> | Added IRC channel info at https://github.com/w3c/WebPlatformWG/blob/gh-pages/meetings/18-03-Web-components.md |
| 10:30 | kochi | referred https://www.w3.org/WebPlatform/WG/ for the working group name. |
| 10:34 | <kochi> | BTW it may be too late to announce, but we are planning to have a group dinner on the first day. |
| 10:35 | <kochi> | Probably we can get together and go to some restaurants, but I'm trying to book for ~20 people. |
| 13:06 | <annevk> | JakeA: I'm looking at createImageBitmap() again |
| 13:07 | <annevk> | JakeA: if we want SVG to resize early on, how does that work together with sourceRectangle? |
| 13:10 | <annevk> | JakeA: I guess we should just try to make it work, even if it results in a bunch of special casing... |
| 13:11 | <JakeA> | annevk: Yeah, the problem is you want the rectangle applied before resizing for bitmap images, but for vector you want a scaled version of the rectangle applied after rasterisation |
| 13:11 | <JakeA> | annevk: for bitmaps it needs to be applied before resizing to avoid pixels outside the rectangle leaking through |
| 13:12 | <annevk> | JakeA: I guess you basically need to scale the sourceRectangle too |
| 13:13 | <annevk> | Although that doesn't quite work either |
| 13:13 | <annevk> | Ugh |
| 13:14 | <JakeA> | annevk: yep. I think, early on, you need to "if vector", then create a bitmap image that's the final-scale of the SVG, and transform the rectangle by the same amount. Then you can go through the same steps as bitmap images |
| 13:14 | <JakeA> | annevk: Implementations should be encouraged to avoid rasterising parts of the SVG that are cropped out, but that can be a note |
| 13:20 | <annevk> | JakeA: the current text has this oddity too |
| 13:20 | <annevk> | JakeA: if sourceRectangle is 0x0x100x100 and resize is 200x200, and input has no dimensions, then first you size input to 200x200, then take out the top left corner, then resize that to 200x200 |
| 13:21 | <annevk> | JakeA: I guess that's reasonable? |
| 13:26 | <annevk> | JakeA: the thing I was talking about is that if input is 100x100, and sourceRectangle is 0x0x50x50, and resize is 200x200, you cannot render at 200x200 and then take 0x0x50x50 from that, you need to render at 800x800 and take 0x0x200x200 from that, right? |
| 13:27 | <JakeA> | annevk: The intrinsic example is weird, but I can't think of a better way |
| 13:28 | <JakeA> | annevk: yeah, that's right. |
| 13:28 | <annevk> | It's a little annoying that the math for SVG is totally different |
| 13:30 | <annevk> | Oh maybe it's not so much |
| 13:30 | <JakeA> | annevk: Like this https://gist.github.com/jakearchibald/6ca3400071631a51e41bc9d10107fa60 |
| 13:31 | <annevk> | JakeA: except that rendering as a bitmap and resizing a bitmap happen at different stages, so it's a little more complicated |
| 13:31 | <annevk> | JakeA: also, you left out all the complicated bits :p |
| 13:31 | <JakeA> | haha yeah |
| 13:32 | <JakeA> | annevk: But now, for vectors, the resize size is the same as the bitmap size, so that doesn't matter. |
| 13:33 | <JakeA> | (or, it will be after cropping) |
| 13:33 | <annevk> | JakeA: except you cannot really reset sourceRectangle in the algorithm that renders image data, but I guess that'll have to leak somehow |
| 13:36 | <JakeA> | annevk: Couldn't you do it just before 1.6.svg.4.1? https://whatpr.org/html/3424/imagebitmap-and-animations.html#dom-createimagebitmap, just before "rendering image data as a bitmap" figure out what the source rectangle should be |
| 13:37 | <JakeA> | annevk: Another problem is figuring out which media queries to apply within the SVG. I'm pretty fond of what Edge does here https://jakearchibald.com/2016/svg-media-queries/ |
| 13:38 | <annevk> | JakeA: then I'd end up duplicating since Blob needs to do the same thing |
| 13:38 | <annevk> | JakeA: at least, I'm assuming we want equal support for SVG in Blob |
| 13:39 | <annevk> | I'm considering just passing it on as image data instead of rendering it at that point |
| 13:39 | <annevk> | And making crop bitmap data to the source rectangle with formatting deal with both vector images and bitmaps |
| 13:40 | <JakeA> | annevk: Yeah, that could work. |
| 13:41 | <annevk> | JakeA: do you know if none vector images without intrinsic dimensions? |
| 13:41 | annevk | doesn't |
| 13:42 | <JakeA> | annevk: nah, I can't think of how that'd be possible |
| 13:43 | <JakeA> | I guess it'd be a format that has n pixels, but no width, but I'm not aware of anything like that |
| 14:02 | <beverloo> | annevk, I was planning to land notifications#127 after your change, but we can flip it around if I send the WPT change now? |
| 14:05 | <annevk> | beverloo: yeah, seems better in that order given it simplifies the setup a bit |
| 14:17 | <beverloo> | annevk, ok, thanks! I'll squash and rebase the spec change, can you help merge the WPT change? |
| 14:19 | <annevk> | beverloo: done |
| 14:40 | <fgasper> | WebSocket question: Has there ever been consideration of allowing browsers to read the HTTP status code from a rejected handshake? I see the LS section that stipulates that clients shouldn’t distinguish such cases other than to see a 1006 status, but I don’t see why this is any different from a normal XHR response, which does give the HTTP status codes. |
| 14:42 | <annevk> | fgasper already left? |
| 15:08 | <fgasper> | WebSocket question (repost): Has there ever been consideration of allowing browsers to read the HTTP status code from a rejected handshake? I see the LS section that stipulates that clients shouldn’t distinguish such cases other than to see a 1006 status, but I don’t see why this is any different from a normal XHR response, which does give the HTTP status codes. |
| 15:18 | <Ms2ger> | annevk, they're back |
| 16:28 | <annevk> | fgasper: https://github.com/whatwg/html/issues/2401 |
| 16:29 | <fgasper> | @annevk Thanks! |
| 17:44 | <devsnek> | what goes in the transferList for StructuredSerializeWithTransfer |
| 17:44 | <annevk> | devsnek: second/third argument of postMessage(), depending on the variant |
| 17:45 | <annevk> | devsnek: if you click on StructuredSerializeWithTransfer you'll find all its callers |
| 17:45 | <devsnek> | ah ok |
| 17:45 | <annevk> | (that generally goes for definitions in WHATWG standards) |
| 17:46 | <devsnek> | i want to propose a standard for something like that api except with a standardized Blob (or something similar) intermediary |
| 17:47 | <devsnek> | sorta like an alternative to the current json api |
| 17:47 | <annevk> | devsnek: you mean standardizing the byte format? |
| 17:47 | <devsnek> | yea |
| 17:47 | <devsnek> | i realize that would probably slow things down |
| 17:47 | <annevk> | devsnek: well, browsers do have such a thing under the hood |
| 17:47 | <devsnek> | from what i can tell they all have their own byte format for the serialized stuff |
| 17:48 | <annevk> | devsnek: yes |
| 17:48 | <annevk> | devsnek: do you want it for network transfer or something else? |
| 17:48 | <devsnek> | whatever you would use json for |
| 17:48 | <devsnek> | json is kinda a lost cause in my mind as we keep getting more and more types and structures etc |
| 17:49 | <annevk> | I've often thought it'd be cool to have it standardized, especially if Node.js were game |
| 17:50 | <devsnek> | node already exposes v8's serdes |
| 17:50 | <devsnek> | i imagine this as a standardized version of that api |
| 17:50 | <annevk> | Not sure transferring makes sense for the byte format though |
| 17:50 | <devsnek> | yea thats why i was trying to figure out what that way |
| 17:50 | <devsnek> | was* |
| 17:50 | <annevk> | Transferring is more of an optimization when you don't have a byte format, to avoid duplicating the memory allocation |
| 17:50 | <devsnek> | yea |
| 17:51 | <gsnedders> | Also impls will likely want their own custom byte format |
| 17:51 | <gsnedders> | because object representations etc. vary |
| 17:51 | <devsnek> | ya thats my current worry |
| 17:51 | <gsnedders> | and the goal is really to make the transfer as low cost as possible |
| 17:52 | <annevk> | devsnek: I guess it's worth filing a whatwg/html issue to discuss it |
| 17:52 | <devsnek> | well i'm ok with it not being the fastest thing ever |
| 17:52 | <devsnek> | json isn't known for speed |
| 17:52 | <devsnek> | my current goals are: all the js types and structures (within reason so no weakmaps, functions, etc) and being cold storage capable |
| 17:52 | <devsnek> | which i think also implies a saved blob of data might be served to any browser |
| 17:52 | <devsnek> | or from any browser |
| 17:53 | <annevk> | devsnek: I think if you go beyond what StructuredSerialize can do you'll find you'll have to figure out how to extend that first |
| 17:53 | <devsnek> | wdym |
| 17:53 | <annevk> | devsnek: that abstract operation is basically the limit of what can be reasonably serialized at the moment |
| 17:53 | <devsnek> | like the types and structures it can currently handle? |
| 17:53 | <jyasskin> | devsnek: So you probably don't care about transfers, just StructuredSerializeForStorage? |
| 17:53 | <devsnek> | yea |
| 17:54 | <devsnek> | transfers are pointless with this |
| 17:54 | <annevk> | Hmm yeah, StructuredSerializeForStorage is the relevant one |
| 17:55 | <jyasskin> | This seems related to some bits of Web Assembly too. |
| 17:55 | <devsnek> | how come structured serialize doesn't handle symbols |
| 18:01 | <annevk> | devsnek: I think we didn't want to decide on the scope of GlobalSymbolRegistry |
| 18:02 | <devsnek> | i guess that does count as a form of scope heh |
| 18:02 | <devsnek> | makes sense |
| 18:08 | <devsnek> | https://github.com/whatwg/html/issues/3517 |
| 18:54 | <railgun> | when I started contributing to whatwg/html I had the goal to decrease the issue count by cleaning up older issues |
| 18:54 | <railgun> | but it seems like every issue I submited a pull request for 3 more popped up in its place haha |
| 18:57 | <railgun> | s/submited/submitted/ |
| 19:02 | <devsnek> | heh |
| 19:18 | <Domenic> | Yeah I made a graph once of issue count and it depressed me. |
| 19:24 | <jyasskin> | But the phenomenon of fixing one issue revealing 3 more, doesn't mean that fixing the one was useless. The other 3 had always been issues even if we didn't know about them, and the one's still fixed. </daily-encouragement> |
| 19:29 | <Domenic> | <3 |
| 19:30 | <railgun> | I haven't maintained a large repository before, so I still can't imagine hundreds of open issues (even though most of them are probably waiting for something else) |
| 19:31 | <railgun> | but if there are any issues that I can do feel free to link me, I feel like I'm missing some of the easier ones that aren't tagged good first issue |
| 19:31 | <Domenic> | We don't have it as bad as some; cf. nodejs/node, npm/npm, angular/angular |
| 19:32 | <railgun> | Domenic: when I look at those repositories I feel like most of the issues are actually questions |
| 19:34 | <Domenic> | Yeah, although a lot are bugs in disguise, albeit probably duplicate ones |
| 19:37 | <railgun> | I suppose that's the cost of trying to maintain a large code base |
| 20:44 | <annevk> | whatwg/html holds a lot of browser technical debt |
| 20:45 | <annevk> | And no browser is serious in paying it off |
| 21:11 | <railgun> | is there any valid reason why multiple browser engines exist? It seems like there would be a lot of duplicate code between them |
| 21:43 | <railgun> | apparently the link https://github.com/issues?q=is%3Aopen+is%3Aissue+label%3A%22good+first+issue%22+user%3Awhatwg does not work if you're not signed into GitHub |
| 21:45 | <railgun> | was going to make a pull request fixing the link but I'm not sure if there's one that works all the time |
| 21:50 | <railgun> | https://github.com/search?utf8=%E2%9C%93&q=is%3Aopen+label%3A%22good+first+issue%22+user%3Awhatwg&type=Issues seems to work but the interface is slightly different (arguably better since it includes an excerpt?) |
| 21:52 | <railgun> | can I make the update here? |