| 09:33 | <yoav> | annevk: do you know what destination should an SVG image fetched as a `<use>` use? https://www.w3.org/TR/SVG2/linking.html#processingURL-fetch doesn't seem fetch integrated nor does it mention destinations :/ |
| 09:46 | <annevk> | yoav: table at https://fetch.spec.whatwg.org/#concept-request-destination doesn't mention it either, not sure |
| 09:47 | <yoav> | yeah, that's where I first checked :) |
| 09:47 | <annevk> | yoav: file an issue against each spec I guess? |
| 09:47 | <annevk> | and cross ref them |
| 09:47 | <yoav> | ok |
| 09:47 | <annevk> | I suspect the answer depends a lot on what we'd want CSP to do |
| 09:47 | <yoav> | The immediate issue that brought me to poke at this is https://bugs.chromium.org/p/chromium/issues/detail?id=1065069 |
| 09:48 | <yoav> | In Chromium's implementation, these images are fetched as an SVG document |
| 09:49 | <yoav> | which is very different "ResourceType" from images |
| 09:49 | <annevk> | yoav: what does that mean for CSP? |
| 09:49 | <yoav> | dunno, but I can find out |
| 09:49 | <annevk> | yoav: and yeah, if the result can execute script I don't think we want "image" |
| 09:49 | <annevk> | yoav: maybe "script" would suffice |
| 09:50 | <yoav> | would be very hard to explain to devs that preloading SVG sprites need a "script" `as` value, but that's a second-order issue |
| 09:50 | <annevk> | I do vaguely recall a bunch of issues with SVG as image and SVG as document now that also pertain to CSS linking SVG |
| 09:51 | <annevk> | Not sure those ever got solved properly |
| 10:02 | <yoav> | https://svg-discrimination.glitch.me/csp.html seems to indicate the SVG doc download is guarded by `img-src` |
| 10:03 | <yoav> | in Chrome but not in Firefox... |
| 10:04 | <yoav> | Safari also likes `img-src` here |
| 10:05 | <yoav> | I'll file issues |
| 10:11 | <annevk> | I guess the question is whether it can execute script |
| 10:13 | <yoav> | https://github.com/whatwg/fetch/issues/1012 |
| 10:16 | <yoav> | doesn't seem like it can |
| 10:17 | <yoav> | added a script to the SVG in the test, and it's only running when the SVG is browsed to as the main document |
| 10:46 | <annevk> | Great, in that case image seems fine to me |
| 10:46 | <annevk> | Though we should prolly investigate why Chrome has a different type |
| 15:18 | <annevk> | Domenic: feel free to take over that Bikeshed PR btw to do your work on top and change it to how you like it to be, I don't care too strongly |
| 15:18 | <Domenic> | annevk: OK cool, thanks |
| 16:25 | <TabAtkins> | And just ping me when it's ready to merge |
| 16:58 | <annevk> | TimothyGu: if you're around, is there a way to run specific tests? |
| 16:58 | <annevk> | TimothyGu: and is it correct that the initial value of a DocumentFragment's _host is undefined? |
| 16:59 | <annevk> | TimothyGu: and when does it give more detailed output from a particular test, only at the end? |
| 16:59 | <Domenic> | annevk: https://github.com/jsdom/jsdom/blob/master/Contributing.md#tests `To run specific to-upstream web-platform-tests: yarn test-tuwpt --fgrep domparsing` |
| 16:59 | <Domenic> | And yeah I think it'll save the detailed output to the end |
| 17:00 | <Domenic> | Sorry, I quoted the wrong line: `To run specific web-platform-tests already enabled via to-run.yaml: yarn test-wpt --fgrep dom/events` |
| 17:00 | <TimothyGu> | annevk: yes, looks like the "default" host is undefined |
| 17:01 | <TimothyGu> | but just to be safe I'd assume it could be either undefined or null |
| 17:01 | <TimothyGu> | we haven't been super consistent with that unfortunately |
| 17:13 | <annevk> | I really dislike this issue |
| 17:47 | <annevk> | Found the flaw in my logic, but still some test changes to analyze and not sure I’ll get to it today… Oh well, some progress at least. Thanks for the jsdom help! Works well with test-wpt plus grep |
| 17:56 | <TimothyGu> | Good to hear! |
| 18:09 | <Mek> | TabAtkins: the FileAPI spec doesn't seem to build anymore with the latest bikeshed version, failing with "FATAL ERROR: Couldn't find the MDN data for 'fileapi' nor 'fileapi'." |
| 18:10 | <Mek> | (https://travis-ci.com/github/w3c/FileAPI/builds/155915673) |
| 18:11 | <TabAtkins> | Ah, MikeSmith has been turning MDN annotations on for various groups, one of which includes FileAPI, and there must not be any MDN annotations for FileAPI. |
| 18:13 | <Mek> | not sure what it means for there to "be MDN annotations"? |
| 18:14 | <TabAtkins> | https://w3c.github.io/mdn-spec-links/ |
| 18:14 | <TabAtkins> | Means MDN has some articles that link back to your spec |
| 18:14 | <Mek> | fileapi is definitely listed there |
| 18:15 | <TabAtkins> | ah indeed it is, and it's in bikeshed's data folder. HMM |
| 18:15 | <TabAtkins> | i'll investigate |
| 18:21 | <TabAtkins> | Hm, I should probably also add a value to the metadata that allows "add if present", so it's safer to put into group boilerplates without new specs getting a fatal error. |
| 18:22 | <Mek> | yeah, having it in WICG especially seems problematic, as there are any wicg specs that aren't on mdn yet |
| 18:28 | <TabAtkins> | After I diagnose and fix this issue with fileapi i'll add the metadata value and fix the boilerplates, because otherwise it would hide this issue. ^_^ |
| 18:29 | <Mek> | okay, thanks! |
| 18:30 | <Mek> | I'm curious, where is bikeshed's data folder that is supposed to contain this mdn data? |
| 18:37 | <TabAtkins> | bikeshed/spec-data/mdn |
| 18:37 | <Mek> | nope, no such directory |
| 18:38 | <TabAtkins> | In your bikeshed directory, go to the bikeshed sub-directory? |
| 18:39 | <Mek> | yeah, no mdn subdirectory in the spec-data directory |
| 18:39 | <Mek> | (and I did run bikeshed update) |
| 18:44 | <Mek> | `bikeshed update --skip-manifest` seems to have done the trick? (I imagine `bikeshed update --mdn` would also have worked) |
| 18:48 | <TabAtkins> | Hmmmm, okay I can reproduce the manifest update not picking up the new data, even tho it shows up in github.com/tabatkins/bikeshed-data/ |
| 18:48 | <TabAtkins> | thanks for pointing this out, will fix |
| 18:57 | <TabAtkins> | Mek: And this led me to find I was fucking up the updates a lot worse than I thought ^_^ thanks so much for pointing out the error ^_^ |
| 19:23 | <annevk> | TabAtkins: so api.csswg.org was not updated to Python 3 but the Bikeshed copy was updated? |
| 19:24 | <TabAtkins> | What do you mean by "the Bikeshed copy"? |
| 19:24 | <annevk> | At least, I think that's what https://travis-ci.org/github/whatwg/dom/builds/667847147 indicates |
| 19:24 | <annevk> | TabAtkins: well, the Bikeshed instance that api.csswg.org uses |
| 19:28 | <TabAtkins> | Yeah, something happened that caused the api server to update bikeshed unexpectedly, I'm talking with plinss about it now. |
| 19:30 | <TabAtkins> | annevk: Try it again? plinss just manually set it to the last py2 commit |
| 19:30 | <TabAtkins> | (and will be updating it to py3 and master this weekend) |
| 19:32 | <annevk> | Great! Travis isn't loading for me, but maybe soon I can try again |
| 19:33 | <annevk> | The amount of Python 3 bullshit I've had to deal with in a time of international crisis is too damn high |
| 19:34 | <TabAtkins> | heh, same |
| 19:34 | <TabAtkins> | to be fair, we've all had like a year of warning and chose to procrastinate ^_^ |
| 19:39 | <annevk> | If the changes didn't seem so artificial and pointless I would be less spiteful |
| 19:39 | Domenic | is almost done making agent cluster allocation imperative... |
| 19:41 | <annevk> | o_O |
| 19:42 | <annevk> | I gotta watch some Mando, but tomorrow |
| 19:42 | <annevk> | Travis will also have to wait, completely unresponsive somehow |
| 20:19 | <TimothyGu> | TabAtkins: do you know if any plans to reinstate `SVGUseElement`'s `instanceRoot` in Chrome or elsewhere? |
| 20:21 | <Domenic> | Do I even want to know what that is |
| 20:21 | <Domenic> | Most things about SVGUseElement fill me with fear |
| 20:24 | <TimothyGu> | SVGUseElement is defined in terms of shadow DOM these days, and instanceRoot is supposed to be the `<svg>` element in the shadow root, I think |
| 21:09 | <TabAtkins> | TimothyGu: I doubt it, but I have no special insight into the matter. |
| 21:09 | <TimothyGu> | got it |
| 23:12 | <MikeSmith> | TabAtkins: Mek_: is the issue with the File API spec an MDN annotations fixed? |
| 23:12 | <TabAtkins> | should be, yes |
| 23:12 | <Mek_> | yes |
| 23:12 | <MikeSmith> | Ok cool |
| 23:13 | <Mek_> | I think there is still the problem that most wicg specs won't have mdn annotations, so requiring that in the wicg template probably doesn't make sense |
| 23:13 | <TabAtkins> | MikeSmith: Before adding to more boilerplates, wait for me to add the "add if possible" value to the metadata. |
| 23:13 | <MikeSmith> | TabAtkins: OK |
| 23:13 | <TabAtkins> | too busy with other stuff to do that yet |
| 23:13 | <TabAtkins> | (I'll fix the ones you've already done.) |
| 23:15 | <MikeSmith> | yeah I have been doing a ton of testing but I have to admit now that the only specs I have been testing with are the ones I know to have MDN annotations |
| 23:16 | <MikeSmith> | it seems obvious now that I should have tested randomly with some others too |
| 23:16 | <MikeSmith> | because even hitting on just one that didn’t have annos would have made me realize the problem |
| 23:16 | <TabAtkins> | it's fine, we'll fix in a bit |
| 23:16 | <MikeSmith> | ok |
| 23:16 | <MikeSmith> | thanks |
| 23:16 | <TabAtkins> | i haven't been regenning the tests yet, or else i'd have hit it too |
| 23:17 | <MikeSmith> | ah |