WHATWG on 2024-07-25

07:52	<sideshowbarker>	Domenic: I have a calendar entry for an “HTML spec triage” meeting starting 10 minutes from now. I guess that’s some ghost entry leftover?
07:52	<Domenic>	Domenic: I have a calendar entry for an “HTML spec triage” meeting starting 10 minutes from now. I guess that’s some ghost entry leftover? Hmm I think so, I don't have one myself.
16:03	<smaug>	keithamus: related to the hint/tooltip discussion, I wonder if github would have used context menu if it had been supported everywhere (It was removed in https://github.com/whatwg/html/pull/2742)
16:06	<keithamus>	I can’t say for sure but we’ve definitely tried to provide our own context menus in places before but due to the missing expected experience we saw user pushback. It would be helpful to have a similar concept or revive that spec 😛
19:23	<Ira Kaundal>	Hey folks! I have a basic question for my understanding. Can someone help me understand why don't <img> tags have the ability to support request headers for urls that have such requirements for e.g. authorization token?
19:24	<easrng>	You can use javascript for that.
19:25	<easrng>	try setting src to `URL.createObjectURL(await(await fetch(/* whatever */)).blob())`
20:30	<Ira Kaundal>	Yes, that is the option I am implementing but it comes with its own set of challenges like creating in-memory blobs that need to be released from memory. Current recommendation is to release the memory when component unmounts but when the application is huge and performance is crucial, the intention is to have this more centralized as we don't cannot rely on all components doing this.
20:31	<easrng>	try adding the headers in a service worker perhaps
20:38	<Ira Kaundal>	There are concerns with this approach as well since service works are not expected to always be available. For now blob url is still the most favorable option only.
20:38	<easrng>	could feature detect and switch to whichever is available
20:41	<Ira Kaundal>	Possibly, but right now we are trying to figure out ways to handle the memory problem. It would be preferable to just have one path without adding too much complexity.
20:43	<Ira Kaundal>	I was majorly curious why <img> tag cannot support this. It seems like a common enough concern which would make things a lot easier.
20:43	<easrng>	because img tags are significantly older than the ability to make any kind of request with custom headers on the web
20:44	<Ira Kaundal>	Okay I see.
20:46	<Ira Kaundal>	Thanks for the information and the help! Appreciate it!
23:00	<Colin Alworth>	Some other unsolicited thoughts: you could make a web component for this, so that at least the fetch is papered over and you just make a etc. The fetch itself will potentially be cached (if crafted correctly, right headers from the server), can use a map from original urls to object urls to provide your own caching, and web component lifecycle to revoke the object urls (so that as long as at least one image is attached to the dom, the object url won’t be revoked and can be loaded without hitting fetch at all). img tags can, by dint of being as old as html (…ish), send cookies already, and have some protection against the app loading it being able to see contents. Additionally, cookies can be set to not permit being sent when a different site tries to load an image from the domain that originally set the cookie. On the other hand, authorization (sic) headers are not sent for image resources. Changing either rule could make it possible for an external site (evil.com) to craft img tags and load urls (that might not even be images) from servers that were previously secure from such attacks