| 00:53 | <GPHemsley> | MikeSmith: thanks :) |
| 00:54 | <GPHemsley> | I don't generally have an established setup for wpt tests like I suspect a lot of people do, so having submissions available on the web makes it easier for me to do drive-by testing |
| 00:55 | <GPHemsley> | and for url stuff in particular, it's very convenient to be able to point my code at a JSON URL to run the tests against it |
| 00:55 | <GPHemsley> | which then makes it easy for me to review |
| 01:56 | <MikeSmith> | GPHemsley: yup, understood |
| 01:59 | <MikeSmith> | annevk: please review the paragraphs about default request mode https://developer.mozilla.org/en-US/docs/Web/API/Request/mode#Default_mode and let me know if any of it’s inaccurate |
| 02:12 | <domfarolino> | MikeSmith: fwiw it checks out to me |
| 02:14 | <Domenic> | MikeSmith: I think not all those markup cases are always no-cors |
| 02:15 | <Domenic> | E.g. <script type=module> and <link rel=modulepreload> are cors. Also I think <track> is cors, although you didn't list that and I'm only 60% sure. |
| 02:25 | <MikeSmith> | domfarolino: thanks! |
| 02:26 | <MikeSmith> | Domenic: ah OK, as far a script and link, maybe if I qualify it by adding “except when used with modules”? |
| 02:26 | <domfarolino> | ^ good distinction |
| 02:26 | <Domenic> | Yeah. Oh and also all the others if you use the crossorigin="" attribute, I think? |
| 02:28 | <domfarolino> | ^ true, however since the para is under the "Default" section wonder if its worth enumerating all of the possibilities |
| 02:29 | <MikeSmith> | yeah it starts to be a bit of a case of pulling at at thread |
| 02:29 | <MikeSmith> | but it should at least also mention crossorigin="" |
| 02:29 | <MikeSmith> | so I’ll at dd that |
| 02:33 | <Domenic> | Yeah I dunno, or just soften to "usually" or "by default" or similar |
| 02:46 | <MikeSmith> | OK |
| 02:47 | <MikeSmith> | Domenic: as far a <track> I can’t find anything in https://html.spec.whatwg.org/multipage/media.html#the-track-element nor in the WebVTT about fetches for text tracks being made with cors mode |
| 02:47 | MikeSmith | looks further |
| 02:49 | <Domenic> | Hmm yeah I think they are fetched in https://html.spec.whatwg.org/multipage/media.html#start-the-track-processing-model and I am wrong |
| 02:49 | <MikeSmith> | Domenic: yeah actually in there I find https://html.spec.whatwg.org/multipage/media.html#sourcing-out-of-band-text-tracks:attr-media-crossorigin |
| 02:50 | <Domenic> | Although https://html.spec.whatwg.org/multipage/media.html#security-and-privacy-considerations is something |
| 02:50 | <MikeSmith> | > If the track element's parent is a media element then let corsAttributeState be the state of the parent media element's crossorigin content attribute. Otherwise, let corsAttributeState be No CORS. |
| 02:50 | MikeSmith | reads https://html.spec.whatwg.org/multipage/media.html#security-and-privacy-considerations |
| 02:51 | <Domenic> | So no impact on your docs, just slightly more interesting processing model if you do opt in to cors mode with crossorigin="", is my reading |
| 02:51 | <MikeSmith> | yup |
| 03:06 | <domfarolino> | 'tis also what I gather |
| 03:19 | <annevk> | I think track is same-origin restricted, so could have defaulted to CORS |
| 03:57 | <MikeSmith> | annevk: thanks I added some language to https://developer.mozilla.org/en-US/docs/Web/HTML/Element/track to indicate it’s same-origin-restricted unless the parent has the crossorigin attribute |
| 06:50 | <MikeSmith> | mkwst: For CSP is there any guidance somewhere which states that nonces should be used when possible, rather than hashes? And if so, which explains what the rationale is for preferring the use of nonces? |
| 06:50 | <MikeSmith> | I vaguely recall reading an explanation somewhere, but can’t find it now |
| 06:51 | <MikeSmith> | neither https://csp.withgoogle.com/docs/strict-csp.html nor https://csp.withgoogle.com/docs/faq.html says it explicitly at least |
| 06:54 | <MikeSmith> | and I’ve read the “CSP Is Dead, Long Live CSP! On the Insecurity of Whitelists and the Future of Content Security Policy” paper too ー which recommends nonces ー but nowhere in it does it directly state what properties of nonces make them a better solution than hashes |
| 08:20 | <zcorpan> | MikeSmith: as for submissions/ I'm thinking if it would be a good idea to spin up a subdomain and separate wptserve instance for each PR |
| 08:22 | <zcorpan> | and maybe only provide the syncing on request in a github comment |
| 08:23 | <MikeSmith> | zcorpan: please talk to jugglinmike :) |
| 08:24 | <MikeSmith> | he wrote down some ideas about it already somewhere |
| 08:24 | <zcorpan> | aha |
| 08:24 | <MikeSmith> | I think it was in a github issue but I can’t remember |
| 08:27 | <zcorpan> | Domenic: TabAtkins: two reasons. it's not implemented using shadow DOM anywhere today (AFAIK), and the ::before issue. |
| 08:28 | <zcorpan> | and I guess that the rendering is so special that it needs CSS magic anyway |
| 08:42 | <MikeSmith> | when uses <details> and <summary>, there’s no way to control the spacing after the disclosure triangle and before the summary text, right? |
| 08:46 | <MikeSmith> | nm figure out a way |
| 08:46 | <MikeSmith> | *figured |
| 13:59 | <annevk> | MikeSmith: I’d think hashes are better? |
| 14:02 | <TabAtkins> | zcorpan: Yeah, afaict fieldset doesn't *need* to use Shadow Dom for anything, it's just a messy CSS layout thing. |
| 14:03 | <TabAtkins> | But also: what ::before issue? |
| 14:06 | <MikeSmith> | annevk: I would think so too, but https://csp.withgoogle.com/docs/strict-csp.html seems to imply otherwise |
| 17:34 | <zcorpan> | TabAtkins: if it used shadow dom, i think ::before would appear before the legend |
| 17:34 | <TabAtkins> | HOw? |
| 17:34 | <TabAtkins> | Or in other words: if you're thinking of fieldset's *entire functionality* being implemented via shadow DOM... how? |
| 17:35 | <TabAtkins> | (The "render in the border of another element" seem to clearly point to this being a CSSish thing, not a DOMish thing.) |
| 17:35 | <zcorpan> | I don't really know, I thought that was a thing for details/summary? |
| 17:36 | <TabAtkins> | Yes, because you can actually implement details/summary purely with shadow dom (and existing CSS). And then the result is that details::before is before the summary. Shadow DOM is a non-sequitur with fieldset, tho; you can't reproduce its functionality by just rearranging children. |
| 17:37 | <zcorpan> | Yeah |
| 17:39 | <TabAtkins> | If fieldset's rendering was *just* "first legend gets pulled up to be first child", then yeah, we could do it with shadow dom, and ::before would go before the legend. But the functionality as it exists works on a totally different level, with no meaningful interaction with ::before. |
| 17:41 | <zcorpan> | So I guess the main reason it doesn't use shadow dom is just that it doesn't help with anything 🙂 |
| 17:43 | <zcorpan> | My flight is about to takeoff. See you in A Coruña |
| 17:44 | <zcorpan> | (You being whoever is also there) |
| 19:19 | <MikeSmith> | botie: inform zcorpan https://github.com/bocoup/web-platform-tests.live/issues/2 is the issue about a /submissions replacement |
| 19:19 | <botie> | will do |
| 19:21 | <MikeSmith> | GPHemsley: see https://github.com/bocoup/web-platform-tests.live/issues/2 for discussion about a /submissions equivalent for web-platform-tests.live |