| 10:26 | <zcorpan> | evilpie: https://fetch.spec.whatwg.org/#http-x-content-type-options |
| 10:31 | <zcorpan> | evilpie: what do browsers do with nosniff for document loads? |
| 10:35 | <evilpie> | https://mimesniff.spec.whatwg.org/#mime-type-sniffing-algorithm |
| 10:35 | <evilpie> | evilpie: what do browsers do with nosniff for document loads? */* etc |
| 10:38 | <zcorpan> | evilpie: https://mimesniff.spec.whatwg.org/#no-sniff-flag:~:text=A%20no%2Dsniff%20flag%2C%20which%20defaults%20to%20set%20if%20the%20user%20agent%20does%20not%20wish%20to%20perform%20sniffing%20on%20the%20resource%20and%20unset%20otherwise%2E seems to suggest it's a pref or so, not based on X-Content-Type-Options? |
| 10:47 | <evilpie> | I am not sure how mime sniff is integrated with e.g. HTML, but that is the only thing that makes sense. And how it works in browsers. |
| 10:50 | <zcorpan> | https://github.com/whatwg/mimesniff/issues/98 |
| 13:27 | <annevk> | smaug: can you take another look at https://github.com/whatwg/dom/pull/1268? Doesn't have to happen before TPAC I suppose, but it would be nice to get these Trusted Types integration points landed. cc Luke Warlow |
| 13:27 | <smaug> | sure, tomorrow (when there is a TT meeting anyhow) |
| 13:29 | <annevk> | Is that a Mozilla-specific meeting? If not I might be interested in joining. |
| 13:29 | <Luke Warlow> | Fwiw I've just landed a WebKit PR so we now pass all of the subtests for this PR, likewise so does Firefox, Chromium (experimentally) and even Servo. https://wpt.fyi/results/trusted-types/set-attributes-mutations-in-callback.tentative.html?label=master&label=experimental&product=chrome&product=firefox&product=safari&product=servo&aligned |
| 13:41 | <evilpie> | https://github.com/whatwg/mimesniff/issues/98 |
| 13:42 | <smaug> | annevk: it is Moz, Google, Igalia. It has been about the implementation |
| 13:51 | <smaug> | annevk: btw, I think https://github.com/whatwg/html/issues/11821#issuecomment-3434680157 will need feedback especially from Apple. |
| 13:52 | <smaug> | (not that I see even a webkit s-p for that. Andreu Botella ) |
| 13:55 | <Andreu Botella> | I was going to open one, hadn't gotten around to it though |
| 13:55 | <Andreu Botella> | will do today |
| 13:56 | <annevk> | smaug: the story for how this should work for events keeps changing and it also seems some server-side implementations have already shipped? I kinda lost the plot, but I've the feeling nobody is particularly enthusiastic about the complexity it adds to engines... |
| 13:57 | <smaug> | I haven't heard anything from webkit side. (this is not Shadowrealm 🙂 ) |
| 13:58 | <smaug> | AsyncContext is complicated, and the integration with web APIs seems to be a bit inconsistent |
| 13:58 | <annevk> | It's been discussed a couple times at TPAC (though as a side chat) and at Web Engines Hackfest. |
| 13:59 | <annevk> | The main concern I see is that for web APIs each API designer has to be aware of it and make it work well (at least for one design iteration of AsyncContext), which seems unlikely to happen. People already can't hold their promises and events straight... |
| 14:00 | <nicolo-ribaudo> | (small rant, not directed to anybody in particular) What's difficult about that proposal is that web developers are excited about some more "core" parts of the proposal, and a lot do not care about what we end up doing for a lot of web APIs. It's quite unfortunate that large part of the complexity comes from things that we need to figure out an answer to, but which answer exactly we pick doesn't matter for most people. |
| 14:01 | <nicolo-ribaudo> | async/await and setTimeout&friends would probably make 90% of devs that ask for the proposal satisfied 😅 |
| 14:01 | <nicolo-ribaudo> | Which is btw why the answer to events has changed over time |
| 14:01 | <annevk> | If we can find a solution that solves it just for those and makes extensions possible going forward, I'd expect you'd get support. |
| 14:03 | <Andreu Botella> | Well, I don't see a realistic way to make extensions possible going forward, because those might change existing behavior |
| 14:04 | <nicolo-ribaudo> | Yeah extensions cannot look like "oh this API now will start automatically propagating context" |
| 14:08 | <annevk> | We did discuss having something like event.otherContext(). I could also imagine something like new API({propagateContext: true}). |
| 14:12 | <smaug> | (I am still, as always, worried about memory leaks on web pages) |
| 15:07 | <Brian Cardarella> | Hi I'm implementing WHATWG specs in Zig, I'm separating each spec out into its own library. However, I'm seeing cyclic dependencies between specs. For example, Encoding defined types that depend on API defined in the Streams spec (i.e. TextEncoderStream). This creates a cycle of depencies where the Streams spec depends on the DOM spec and the DOM spec depends on Encoding and apparently Encoding depends on Streams. Are the specs intended to be cycle free? |
| 15:17 | <Luke Warlow> | No, the specs are all very interdependent, especially for concepts (aka types). Some things you can probably create API surfaces to integrate but others such as types you might need a shared library definition for them all? |
| 15:19 | <Brian Cardarella> | That's something I'm considerig, I'm also thinking of just breaking out the speciifc APIs that introduce cycles into their own lib. So for the Encoding <-> Streams issue having an EncodingStreams library. That should solve the issue. |
| 15:42 | <annevk> | I think if there's a clearly better way to organize the types we'd certainly welcome such an improvement, but sometimes it's hard to avoid. Most browser engines are kinda monolithic and you'll find that reflected in specifications. But again, I do think we should try to improve that whenever it's possible. |
| 15:49 | <Brian Cardarella> | annevk: yeah I understand, these have been around for 20+ years. I've been making heavy use of AI to help separate the concerns into isolated libraries and for the most part it does seem to be working. On another note, it would be fantastic if there was a way to get markdown specs instead of the html rendered ones for the purposes of LLM token consumption. I've gone through the effort of doing that for myself here: https://github.com/zig-whatwg/specs/tree/main/whatwg but it would be nice if there was a markdown ACCEPT header or .md extension on the whatwg site |
| 15:52 | <jmdyck> | You could get the .bs file from github? |
| 15:54 | <Brian Cardarella> | jmdyck: aren't those still just in a markup? For certain specs like DOM or HTML that are very large the additional tokens exhausts the context window pretty quickly |
| 15:55 | <Brian Cardarella> | but ultimately I think I'll have to load these into a RAG so maybe it's not really a concern |
| 15:56 | <annevk> | I think if someone did the work of integrating that with the publishing pipeline that we'd be willing to take on the ongoing maintenance burden (we publish PDF for the HTML standard for instance). See https://github.com/whatwg/whatwg.org/tree/main/resources.whatwg.org/build |
| 15:58 | <Brian Cardarella> | I'm happy to contribute my repo but I suspect it isn't that simple as this was multipass: first convert the html to markdown with pandoc then optimize the markdown for token reduction with Claude. I suspect that workflow wouldn't be sufficient for a specification |
| 15:58 | <jmdyck> | Yeah, HTML and (I think) DOM specs have no markdown, but e.g. https://github.com/whatwg/streams/blob/main/index.bs has lots |
| 15:59 | <Brian Cardarella> | I'm going to spend some time investigating if the RAG solution is better. RAGs are designed for the purpose of managing large data sets so if it leads to a better outocome with token usage I'll report back |
| 15:59 | <annevk> | Yeah, I'm not sure we want a dependency on Claude as part of publishing changes. Converting HTML to Markdown seems okay though. |