WHATWG on 2023-06-23

13:15	<annevk>	Welcome dveditz 👋
14:18	<annevk>	Well https://twitter.com/WeizmanGal/status/1672206009643970560 is cursed, maybe we should address that
14:21	<Sam Sneddon [:gsnedders]>	Do indexed getters have higher precedence than named getters? But I guess you still need to somehow distinguish them…
14:24	<annevk>	Yeah, I'm not sure what "addressing" might mean here. I've long thought that a complete opt-out would make sense, but that might not be a meaningful enough improvement on its own
14:26	<Sam Sneddon [:gsnedders]>	I mean a CSP policy that totally opted out seems… not silly, at first glance?
14:26	<Sam Sneddon [:gsnedders]>	But also I have thought about this for ~seconds, so, ymmv.
14:49	<bkardell>	annevk: was this issue about the mathml core spec? https://github.com/w3c/mathml-core/issues/195
16:17	<annevk>	bkardell: I was assuming that code was based on something in the spec
16:19	<annevk>	bkardell: I'll try to clarify now that I've seen https://w3c.github.io/mathml-core/#html-and-svg
16:19	<bkardell>	hmm the only thing core says is in a note `The <math> element can be used at position permitted for flow content (e.g. a <foreignObject> element) or phrasing content. Any phrasing content can be used inside mi, mo, mn, ms and mtext elements. The <svg> element can be used inside annotation-xml elements. Any flow content can be used inside annotation-xml elements with encoding application/xhtml+xml or text/html.`
16:19	<bkardell>	ah ok you see that
16:25	<bkardell>	thx annevk
17:26	<dveditz>	I mean a CSP policy that totally opted out seems… not silly, at first glance? I love CSP, and at one point envisioned it being used for all security policy things like this, but that was early on when we (Mozilla folks, at least) naively thought servers would mostly go for a site-wide policy served from a URL referenced in the header. It could expand as needed because it would end up cached like the site's large style sheets or JS framework libraries. But given the reality of today's complex header policies in practice I'd prefer seeing if there's a better delivery mechanism for that.
17:26	<dveditz>	Is "Document Policy" going anywhere?
17:41	<dveditz>	Opt out of what, exactly? Maybe opt IN to actually enforcing the lowercase "must"s in the spec? When specified on HTML elements, the id attribute value must be unique amongst all the IDs in the element's tree and must contain at least one character. The value must not contain any ASCII whitespace.
17:43	<dveditz>	although what would enforcement mean? probably that "invalid" ids are simply ignored (plus a console error) and the web dev has to debug their page
17:43	<dveditz>	oops, misread "character" as "alpha character". that wouldn't solve the problem in the tweet.
17:48	<Sam Sneddon [:gsnedders]>	Opt out of what, exactly? Maybe opt IN to actually enforcing the lowercase "must"s in the spec? When specified on HTML elements, the id attribute value must be unique amongst all the IDs in the element's tree and must contain at least one character. The value must not contain any ASCII whitespace. Presumably opt-out of there being a named getter on Window at all
17:50	<dveditz>	hm, ok. I was trying to go in the direction of only having valid ones. But good point, why should all the elements be stuck willy-nilly on the global in the first place?
17:58	<dveditz>	could use the same switch to turn off `document.all` while we're at it
21:31	<Eric Portis (he/him)>	So with critical client hints the server essentially asks for an additional roundtrip, akin to a redirect or authentication required? Can the server only do this in response to a GET? Yes, I think that's right. "The restart retries the entire navigation (including any prior redirects)." 2. It may make sense to limit it to idempotent requests, although I don't think that's currently spec'd anywhere. Might be worth hashing out in https://github.com/WICG/client-hints-infrastructure/issues/154