WHATWG on 2024-04-02

09:39	<zcorpan>	Looking for mathml content in httparchive but it's almost entirely this: https://github.com/facebook/react/blob/6e650109999e5f483fcb910ff20fe8148a566cb2/packages/react-dom-bindings/src/server/ReactFizzConfigDOM.js#L3934 (cc bkardell )
09:49	<zcorpan>	https://chromestatus.com/metrics/feature/timeline/popularity/4403 might be better. Maybe mathml on the web usually isn't in markup but generated from script?
11:15	<annevk>	I really only know one website: https://golem.ph.utexas.edu/~distler/blog/
11:16	<annevk>	There used to be a website that collected all of them, but I don't remember that one
12:44	<bkardell>	Looking for mathml content in httparchive but it's almost entirely this: https://github.com/facebook/react/blob/6e650109999e5f483fcb910ff20fe8148a566cb2/packages/react-dom-bindings/src/server/ReactFizzConfigDOM.js#L3934 (cc bkardell ) yeah not surprising since the http archive is mainly getting home pages and even sites dedicated to math and science don't usually put math on the home page :). There are sites like https://ar5iv.labs.arxiv.org/, for example..
12:48	<bkardell>	and wikipedia has many millions but currently (because of core interop issues - that's why we're here) still doesn't use it for rendering, only for a11y -- so like https://en.wikipedia.org/wiki/Mass%E2%80%93energy_equivalence has 30 mathml instances related to images of math - ick
12:51	<bkardell>	zcorpan: we have a few very rich sources - is there something you're trying to answer specifically that I can help with or just generally poking around?
12:53	<zcorpan>	bkardell: trying to get a sense of how much content uses `href` and on which elements
12:56	<bkardell>	bkardell: trying to get a sense of how much content uses `href` and on which elements ah well you can see some discussion in that issue (there are some related emails or issues with more on this same topic, but it's pretty generally aligned with this) https://github.com/w3c/mathml-core/issues/142#issuecomment-1082772082
12:56	<bkardell>	in the full collection there, there are 30 <mrow with href as opposed 97549 <mi and 3226 <mn
12:58	<bkardell>	the thing is most of the corpuses are in XML toolchains that they are open to some transforms on - many things have been adapted for mathml-core already
13:00	<bkardell>	That's why I am saying if the group is like "we should prefer mrow because then links still work" I am like, well, only a tiny tiny fraction and the rest you have to transform anyways - let's just fix it properly
13:03	<zcorpan>	Right
13:58	<bkardell>	Right I do think the a11y tools might be a pretty compelling argument (many are already fine so we'd have to see how difficult the other two are I guess) - I am just trying to make sure `<a>` gets a fair shot is all because i think it is clearly the best answer if possible...But I can also accept if it is not, it's not a hill I want to get seriously injured on
15:00	<bkardell>	zcorpan: do you have all you need or can I help you find more?
15:01	<zcorpan>	bkardell: a separate use counter for every mathml element in a document with an href attribute, maybe? :)
15:02	<zcorpan>	For now my conclusion is that href at all is very rare
15:10	<bkardell>	hmm, idk - in some sets it is not rare at all. In a few almost every token has an href, but in those cases that is to do a toolip about what it represents or something and would be better maybe as a popover :)
15:12	<bkardell>	but yeah I guess there are many many docs with no links too
15:16	<bkardell>	there are also potentially false positives depending on how you count.. like `document.querySelectorAll('math [href]').length` is too naieve because it will give you positives of links that are in foreign content inside the tokens (which is fine, it's just HTML), and also stuff inside `<annotation-xml>` which isn't displayed
15:17	<zcorpan>	I looked at like 50 that match the chromium use counter and not one had `math [href]` on a presentation-math element. There was one with a href attribute inside `annotation-xml` but that was not a rendered element
15:23	<bkardell>	emilio: had some counters in moz, not sure if they are still there or if they're counting this, but you could check? I mean, he is the one that opened the issue we're all pointing at even - so it's possible :)
22:36	<Timo Tijhof>	I'm trying to preload requests for `<script type=module src=…>` via the HTTP Link header. I'm aware of, and have read, the past discussions around why `rel=modulepreload` was introduced separately instead of within rel=preload. As I understand it, module requests are made with a different CORS setting, plus by signalling the module type this way, browsers can do additional optimizations (e.g. look for indirect imports and preload those as well, and honouring import maps). I'm also aware that at this time, there is no way to apply an import map to preloaded resources, which is fine, since the server-side in my case knows the flat and full list of "real" requests that will be made. All that having been said, I can't seem to find in the spec what rel=preload incantation will result in the preloaded result being used by `<script type=module>`. In Chrome, if I use `Link: </static/foo.js>;rel=preload;as=script;crossorigin` it will correctly satisfy the later demand for `<script type=module src=foo.js>` by re-using the preload response (I can tell by the timing, the initiator, the order, and there not being a duplicat req). In Firefox, it doesn't and there's instead a duplicate request made later on.
22:52	<Timo Tijhof>	Hm.. so via Bugzilla search I'm finding a related change https://hg.mozilla.org/mozilla-central/rev/72570ac420f0, where I see in the diff context that Gecko apparently considers an (unspecified?) `type=module` attribute for `preload as=script` and discards those. This was done last year for https://bugzilla.mozilla.org/show_bug.cgi?id=1803744 which implemented support for the (also unspecified) ability for `rel=modulepreload` to be used in a Link header.. this despite the standard still saying at https://html.spec.whatwg.org/multipage/links.html#linkTypes:link-type-preload that `modulepreload` does not have "Link processing".
22:57	<Timo Tijhof>	While that sounds cool (and Firefox-only today, Chrome discards it with a console warning for invalid `rel=modulepreload` in HTTP), it's actually unusable for my use case because if I use `rel=modulepreload` in Firefox for all (or even one) of foo.js?v=1, bar.js?v=1 and baz.js?v=1. It ends up doing its recursive logic, and attempt to preload the unversioned dependency URLs of the discovered imports (since the import map isn't known at this time).