| 07:36 | <freddy> | Hey, this might be interesting for people who worked on Sanitizer/Trusted Types or other recent HTML parsing changes: I am exploring how to combine the control function of Trusted Types with the safety features of the Sanitizer API to enable implicit sanitization. https://github.com/mozilla/explainers/blob/main/trusted-or-sanitized-html.md. |
| 07:46 | <Noam Rosenthal> | Hey! I think https://github.com/w3c/trusted-types/pull/606 addresses this already in some sense? |
| 07:46 | <Noam Rosenthal> | (and we've discussed it at the sanitizer call a couple of times I think) |
| 07:50 | <Noam Rosenthal> | I would expect to at least mention it... though I think both have a place and what you're suggesting there seems like a good trajectory |
| 07:55 | <freddy> | Clearly an omission on my side not to mention it. Noted! |
| 07:57 | <freddy> | I don't think it addresses the issues I see most important though. |
| 08:00 | <Noam Rosenthal> | I'd love to hear more! Maybe if the explainer could mention what createParserOptions doesn't solve in that regard? It does allow you to implicitly enforce HTML sanitization. I have a feeling there's something this does better but would be good to point it out |
| 08:04 | <freddy> |
(It's all in the explainer. I handwrote it, 100% organic, LLMs were proof-reading, not writing this. ;)) |
| 08:05 | <Luke Warlow> | https://github.com/whatwg/html/issues/12441#issuecomment-4727511027 - meeting link for anyone joining the extraordinary meeting later. |
| 08:13 | <Noam Rosenthal> | For 1 - createParserOptions allows you to inject a sanitizer though. For 2 - sure, trusted types does require JS |
| 08:13 | <Noam Rosenthal> | What's not in the explainer is what this solves on top of createParserOptions. I understand it solves things that TrustedHTML doesn't |
| 08:19 | <freddy> | Yeah, but createParserOptions only works for the unsafe function calls, not any existing/legacy code |
| 08:23 | <Noam Rosenthal> | why not? It does |
| 08:26 | <Noam Rosenthal> | the current blink implementation and spec PR it applies also for innerHTML/outerHTML/insertAdjacentHTML/createContextualFragment. srcdoc/document.write requires also streaming sanitizer but they can work as well |
| 08:28 | <freddy> | wait what. how would you pass the result the TrustedParserOptions into innerHTML? |
| 08:29 | <Noam Rosenthal> | it effectively converts element.innerHTML = x to element.setHTMLUnsafe(x, trusted_types.default_policy.createParserOptions({sanitizer: {})) |
| 08:29 | <Noam Rosenthal> | (with some quirks like enabling XML and disabling declarative shadow DOM) |
| 08:30 | <Noam Rosenthal> | Also element.innerHTML = a_trusted_html_object should be possible. But that's not spec'ed/implemented and I'm not sure it's needed |
| 08:37 | <freddy> | ah... and the conversion happens when you use a default policy? |
| 08:37 | <Noam Rosenthal> | yes |
| 08:43 | <Noam Rosenthal> | I agree that in a world without trusted types where we had sanitizer from the start I'd prefer something totally declarative where the mandatory sanitizer is defined in the header... perhaps also allowing declarative named sanitizer JSON configs. but trusted types do exist so perhaps createParserOptions is a good enough start? |
| 08:50 | <Noam Rosenthal> | also trusted types allow fine grained control with TrustedParserOptions... requiring a sanitizer for everything will not work for a very common use case of injecting unsafe HTML from a trusted source alongside other safe+untrusted sources |
| 08:51 | <Luke Warlow> | How common actually is it to need to be able to insert a <script> element dynamically via the parser? I've personally never seen it done on anything I've worked on. I know it's obviously used I'm just thinking is it so common that a sanitizer-html trusted-types option wouldn't be usable by anyone? I also didn't realise that the new trusted types addition worked for the older parser sinks, that's interesting. |
| 09:05 | <Noam Rosenthal> | It's common to update the document without reloading it, and the new update might include script tags (or on attributes) |
| 09:06 | <Noam Rosenthal> | also unkown custom elements that are not part of the safe baseline |
| 11:52 | <freddy> | sorry, I was completely unaware of the implicitness when using parseroptions in a default policy, this is cool and much closer to what I was thinking, thank you for clarifying. Sounds like we need to talk about it in greater detail for sure :) |
| 11:54 | <Noam Rosenthal> | let's do that! |
| 12:08 | <Noam Rosenthal> | btw I wonder if we could have a header that totally disables the legacy methods and forces people to use setHTML* and parseHTML* |
| 12:08 | <Noam Rosenthal> | (A header or some other affordance) |
| 12:59 | <Noam Rosenthal> | keithamus: I think that something that I failed to communicate at the modules discussion is that the proposal still allows for "fully globally break from encapsulation" |
| 13:00 | <Noam Rosenthal> | <!-- this is encapsulated from accidental collision using unguessable hashes --> <style exportblob="hash:123"> * { color: red}</style> <!-- this overrides it and exports it to a fully global namespace --> <script type=importmap> { "theme": "blob:hash:123" } </script> |
| 13:38 | <Noam Rosenthal> | dandclark: for an activation-behavior type of API, I think it would still be great to have all the "reset button a11y behavior" in there or all those things. It doesn't have to be atoms like click/focus/etc - more like "a set of behavior specifically for buttons/links/etc" |
| 13:45 | <Luca Casonato> | do you all never use TCQ for WHATNOT? it's great! if we want to use it now: https://tcq.tc39.es/meeting/ninety-houses-sort |
| 13:45 | <annevk> | We almost never meet in person, but maybe we should when we do |
| 13:46 | <Luca Casonato> | it's also nice for full remote because it can distinguish between "new topic" and "reply to the current topic". i was really considering us to use it for the breakout for <time> yesterday |
| 14:50 | <annevk> | hsivonen: I added a note for the case we discussed. I think I'll merge tomorrow unless there's further concerns. https://github.com/whatwg/url/pull/914/commits/9b998f7e8003908aa15f34ebdbe60bab04f113fd |
| 15:48 | <zcorpan> | annevk: https://github.com/whatwg/html/issues/12584 - can we create a new repo for incubation under whatwg? |
| 15:52 | <annevk> | zcorpan: yes |
| 15:53 | <annevk> | I created https://github.com/whatwg/proposal-dom-localization and gave eemeli access |
| 15:53 | <annevk> | We should probably create a template for future proposals so they automatically get the correct LICENSE file |
| 18:33 | <annevk> | When people have time, if they could let me know if https://github.com/whatwg/sg/pull/276 is an improvement on the Stages situation I'd appreciate it. |
| 19:38 | <nektro> | re https://github.com/whatwg/html/issues/12333 and https://github.com/whatwg/html/issues/12591 something very similar that i'd really love is a since attribute where you plug in datetime and then it auto updates to 2 days ago etc |
| 19:41 | <nektro> | you could also maybe use the attribute value to force a unit, eg since="days" would do 35 days ago instead of 1 month ago |
| 22:29 | <annevk> | nektro: yeah I agree we should do that. It’s slightly more involved due to dynamic changes but makes a lot of sense. And I think it’s what most people are looking for |
| 22:31 | <nektro> | would also totally be be fine imo if it didnt auto update at first, progressive enhancement and all |
| 22:33 | <nektro> | especially once you get out of the like seconds or minutes range, the chance of there being an update in the lifetime of the page is exceedingly rare |