2025-06-02 [21:43:16.0915] In https://html.spec.whatwg.org/#steps-to-expose-a-media-resource-specific-text-track, under MPEG-4, there are a couple occurrences of roughly "the concatenation of A, B, and C, or D if condition". It's unclear what the 'scope' of the "or" is. Is it (A+B+C) or (D)? Or is it A+B+(C or D)? [06:26:21.0725] Domenic: fyi https://www.debugbear.com/blog/google-blocked-website [09:27:17.0733] I looked for how browsers implemented that paragraph, but haven't yet found one that does. [09:27:55.0418] * I looked for how browsers implemented that MPEG-4 paragraph, but haven't yet found one that does. [10:21:26.0113] Looks like Hixie added it in 2012 (d485159e) and it hasn't been touched much since then. [10:41:03.0251] I have an open PR that I need to get back to to clean up that algorithm a bit, but I don't touch that part [11:13:15.0951] Testing would be good to verify, but I'm 95% certain that "or" is tightly bound, so it's just "C or D". The C is always "the first FOO field" and the D condition is"if there is no FOO field", so it's extremely likely that the D (always an empty string) is providing a default for the missing C case. [12:33:45.0518] Testing implementations? You'd first have to find one that implements that chunk of the spec, and I'm doubtful there is one. (I don't think anything in WPT calls inBandMetadataTrackDispatchType, so you can't find implementations that way.) And then you'd need to find or create an MPEG-4 file that triggered the condition in question. [12:39:23.0399] The A+B+(C or D) interpretation is 'better' in that it distinguishes more cases. But it seems odd to me that a dispatch type could have a trailing space. [12:47:37.0644] Oh, you know what, you're right, I misread. This is absolutely `(A + B + C) or D`, I was being silly. So you get either `"metx FOO"` or `""` (or whatever, for the other field names). [12:48:00.0809] Anyway, 100% needs a rewrite [14:37:27.0217] Wouldn't have to be a rewrite to disambiguate: you can establish the left edge of the or's scope just by inserting an "either". But a bigger rewrite could improve the readability. (It's interesting that the source, with its judicious linebreaks, is more readable than the rendered spec.) OTOH, if nobody is implementing it, maybe it's not worth the bother. [14:59:21.0244] I've committed the same sins when writing before, precisely because my source linebreaks make it clearer, and it's more ambiguous when rendered inline instead :/ [14:59:34.0151] But anyway, it's the work of like a minute to fix. 2025-06-03 [04:09:42.0503] The `` looks really fugly in https://w3c.github.io/webappsec-subresource-integrity/#example-2319c0a9 (Source at https://github.com/w3c/webappsec-subresource-integrity/blob/2089aeb95782970d35f96283d1f3da89beaa8802/index.bs#L721). Looking at the bikeshed docs for `<xmp>` didn't really help me, anyone got a better idea? [06:15:52.0378] <Ms2ger (🇪🇸)> That highlighting sure didn't work for json [06:42:45.0070] <Noam Rosenthal> Anyone from Gecko/WebKit cares to respond to a standard position on navigation API precommit handlers? The spec PR is pretty much ready (https://github.com/whatwg/html/pull/10919) and the standard position requests are pending.. It's a minor/medium sized addition to the navigation API that was requested by multiple early adopters and frameworks. /cc zcorpan annevk [14:51:07.0012] <TabAtkins> Lol woah, what the fuck happened with that highlighting. [14:56:16.0957] <TabAtkins> Ah, that's not actually valid JSON (JSON uses double quotes), so it's making the lexer just do some nonsense behavior. [14:57:00.0591] <TabAtkins> (Aside from webidl, highlighting is done by Pygments, btw) [15:17:48.0294] <TabAtkins> https://github.com/w3c/webappsec-subresource-integrity/pull/139 2025-06-04 [19:46:43.0441] <Domenic> It's interesting that popular syntax highlighters have generally chosen to be kind of loose and produce nonsense output in the face of nonsense input. For some cases, like writing specs, having them be strict would be quite useful---bonus syntax checking in your build process. But for cases like writing GitHub comments, I guess you want loose. [00:24:08.0336] <freddy> thanks TabAtkins [00:29:52.0146] <TabAtkins> > <@domenicdenicola:matrix.org> It's interesting that popular syntax highlighters have generally chosen to be kind of loose and produce nonsense output in the face of nonsense input. For some cases, like writing specs, having them be strict would be quite useful---bonus syntax checking in your build process. But for cases like writing GitHub comments, I guess you want loose. An issue is handling new syntaxes. Strict parsing means you'll break if there's an update to the language, or someone uses it on a proposal for something new, or someone is highlighting a fragment of syntax that you didn't expect them to start on, etc. Strict also requires a Real Parser, whereas I know the Pygments model is a pile of regexes, at least by default. That's simpler for most people to author. [00:30:09.0999] <TabAtkins> That says, the failure mode here was *weird* [00:30:19.0859] <TabAtkins> * That said, the failure mode here was *weird* [07:40:29.0172] <Luke Warlow (🇪🇸)> jarhar: regarding ToggleEvent.source tests, The spec PR is merged but the tests still seem to be tentative to me, is there a PR to update them? [09:06:21.0481] <jarhar> https://chromium-review.googlesource.com/c/chromium/src/+/6621684 2025-06-05 [19:49:12.0746] <Domenic> annevk: do you know if request's URL list is used for anything "after fetch"? Or would it be an unobservable change for the ecosystem, if we were to truncate it to just « the final URL » at the end of the fetch algorithm? (Context: some gnarly prefetch algorithm stuff.) [23:23:47.0966] <annevk> Request’s `url` has to return the first URL. But in general something like that could probably work. I wonder if we can move the construct to the controller to clarify. [09:17:15.0233] <Eric Portis (he/him)> Noam Rosenthal: Why is there a blocking attribute on <style>? Aren't <style>s in the <head> already render-blocking? https://html.spec.whatwg.org/multipage/semantics.html#dom-style-blocking [09:21:20.0716] <zcorpan> Eric Portis (he/him): https://html.spec.whatwg.org/multipage/semantics.html#the-style-element:implicitly-potentially-render-blocking:~:text=A%20style%20element%20is%20implicitly%20potentially%20render%2Dblocking%20if%20the%20element%20was%20created%20by%20its%20node%20document%27s%20parser [09:23:36.0542] <Eric Portis (he/him)> zcorpan: What can create an element besides the node-document's parser? Script? [09:24:22.0895] <zcorpan> Eric Portis (he/him): yes. or you can move a parser-created element from one document to another document [09:25:37.0908] <Eric Portis (he/him)> Ok. And in those scenarios, the <style> is not render-blocking. Even if the script that's moving or creating the <style> is synchronous/in-the-head? [09:25:50.0093] <zcorpan> I don't know what happens in an XSLT transform [09:26:19.0370] <zcorpan> Right [09:26:53.0112] <Eric Portis (he/him)> But if a <script> creates a <script blocking=render> in the head, it *is* render blocking. [09:28:58.0955] <zcorpan> I assume you mean it creates `<style blocking=render>`, then yes [09:53:50.0040] <Eric Portis (he/him)> @zcorpan: here's my current understanding based on our conversation, and earlier conversations with Noam Rosenthal . https://gist.github.com/eeeps/318812c9d4471136363a6aaa4a448251 Happy to wait until June 16th to understand where I'm wrong btw (: [09:54:05.0149] <Eric Portis (he/him)> * @zcorpan : here's my current understanding based on our conversation, and earlier conversations with Noam Rosenthal . https://gist.github.com/eeeps/318812c9d4471136363a6aaa4a448251 Happy to wait until June 16th to understand where I'm wrong btw (: [09:54:56.0758] <Eric Portis (he/him)> * zcorpan (OOO until June 16): here's my current understanding based on our conversation, and earlier conversations with Noam Rosenthal . https://gist.github.com/eeeps/318812c9d4471136363a6aaa4a448251 Happy to wait until June 16th to understand where I'm wrong btw (: [09:57:45.0593] <Noam Rosenthal> What's on June 16th? This gist seems right to me [09:57:58.0022] <Noam Rosenthal> I believe the "no idea" bit is not render-blocking [09:58:10.0229] <Eric Portis (he/him)> (when Simon's OOO ends) [09:59:17.0073] <Eric Portis (he/him)> Noam Rosenthal: Thanks! [11:39:59.0370] <Eric Portis (he/him)> Noam Rosenthal: a review would be appreciated https://github.com/mdn/content/pull/39809 [11:55:52.0809] <zcorpan (OOO until June 16)> Eric Portis (he/him): I think that's correct [11:57:42.0733] <zcorpan (OOO until June 16)> There are tests here https://wpt.fyi/results/html/dom/render-blocking?label=master&label=experimental&aligned&q=%2Fhtml%2Fdom%2Frender-blocking%2F [12:00:20.0242] <Noam Rosenthal> Nice work! Added a few comments. [15:42:30.0322] <Eric Portis (he/him)> Noam Rosenthal: Comments are super helpful, thank you! Hope to make some time to address them tomorrow. 2025-06-07 [17:48:14.0744] <Sam Sneddon [:gsnedders]> What's the intention of things like fingerprinting warnings? I _guess_ these aren't intended to be complete, but e.g. if you read https://html.spec.whatwg.org/multipage/interaction.html#interaction-with-details-and-hidden=until-found you might think "hmm maybe we should suppress the toggle event" if you were trying to mitigate this, not realising that the beforematch event also provides a similar threat. [02:18:27.0856] <annevk> I think the main aim is to catalogue them, see also https://infra.spec.whatwg.org/#privacy 2025-06-09 [04:47:44.0652] <Andreu Botella> I've found a case where `<wbr>` renders differently in different browsers, and once again I'm wondering why `<br>` and `<wbr>` are still specified in terms of `display-outside`, which is not part of CSS currently, and which I doubt was ever in a published CSS standard [04:48:21.0108] <Andreu Botella> * I've found a case where `<wbr>` renders differently in different browsers, and once again I'm wondering why the rendering of `<br>` and `<wbr>` is still specified in terms of `display-outside`, which is not part of CSS currently, and which I doubt was ever in a published CSS standard [05:06:26.0453] <akaster> > <@abotella:igalia.com> I've found a case where `<wbr>` renders differently in different browsers, and once again I'm wondering why the rendering of `<br>` and `<wbr>` is still specified in terms of `display-outside`, which is not part of CSS currently, and which I doubt was ever in a published CSS standard Isn't that <https://github.com/whatwg/html/issues/2291> ? I don't know that anyone actually knows how to spec those elements properly [05:09:03.0323] <Andreu Botella> Surely we can do better than using non-existent CSS property [05:09:38.0132] <akaster> Oh I guess Domenic: has this old PR that specifies them as "UA magic 🪄" https://github.com/whatwg/html/pull/2298 [05:10:31.0809] <Domenic> It might be good if someone resurrects that to just add a bunch of XXX boxes, instead of using CSS. [05:10:41.0767] <Domenic> I guess the main open question is what CSS properties apply to those elements [05:12:02.0517] <Domenic> Hmm I feel like that PR is somewhat mergeable as-is, reviewing its contents. Maybe just change one `<p>` to `<p class="XXX">`. I think I just wasn't confident enough in my new editorship in 2017 to feel comfortable merging it. [05:12:23.0137] <Domenic> If someone resurrects it I can review and merge. [05:14:48.0715] <nicolo-ribaudo> Lol, Element is not escaping the br in that link preview title [05:25:52.0554] <Andreu Botella> The rendering difference I found is that, with inherited `white-space: nowrap`, `<wbr>` in Chromium allows line breaking, but it doesn't in Firefox or Webkit [05:25:55.0035] <Andreu Botella> there's a parallel to `nobr wbr { white-space: normal }` [05:26:26.0117] <Andreu Botella> but we can figure this out after the magic PR is merged [06:51:34.0956] <Domenic> That may be https://github.com/whatwg/html/issues/6227 2025-06-10 [18:29:18.0417] <james7474> Join BlackHat_Nexus – Trusted by Over 23,000 Subscribers Your reliable hub for Cybersecurity, Digital Recovery, and Tech Support Services. We provide fast, secure, and confidential solutions for a wide range of digital challenges—trusted by individuals and businesses worldwide Our Expert Services Include: 🔐 Account Recovery – Email, Social Media, Crypto Wallets 💼 Digital Investigations & Fund Recovery – Lost funds, scam cases 📱 Lost Device Tracking – Phones, Laptops, Vehicles 🧠 Password Recovery & Access Support – Secure, consent-based assistance 🛡️ Cybersecurity Consultations – Protect your digital identity 🧰 System Troubleshooting – Windows, Android, iOS 🌐 Website Security Audits – Vulnerability detection & protection 🎓 Academic Access Support – Authorized educational record recovery 📡 Network Security Testing – Wi-Fi & CCTV configuration & checks 👁️‍🗨️ Ethical Monitoring Solutions – Discreet and compliant digital oversight --- Why Choose Us? ✅ Fast, Professional Response ✅ 24/7 Availability ✅ Confidential & Secure Handling ✅ Experienced Digital Experts --- Join us today and secure your digital world. https://t.me/BlackHat_Nexus [07:58:44.0953] <gogo> Hello. I want to document the latest version of the w3c parser for finding client side vulnerabilities. I started with a DOM XSS using the RFC of the parser with element.innerHTML = "XSS";. My goal is to have the syntax possible for each XSS possible. I started with: https://html.spec.whatwg.org/multipage/parsing.html#overview-of-the-parsing-model according to the schema, the loop starts at the HTML tree builder at https://github.com/WebKit/WebKit/blob/main/Source/WebCore/html/parser/HTMLTreeBuilder.cpp#L816 and then I am wondering if according to the code at https://github.com/WebKit/WebKit/blob/2246a2aa28d527e129ebec66183569db035fdc8a/Source/WebCore/dom/Element.cpp#L4347 , the policy of innerHTML could deny to execute a script even if not sanitized. I need to find the parser location to see the grammar syntax for potential XSS as mentrionned there: https://html.spec.whatwg.org/multipage/dynamic-markup-insertion.html#dom-element-innerhtml . Is Elements::replaceChildrenWithMarkup the parser please? [08:28:30.0863] <akaster> if you're looking for the HTML parser, have you tried looking in the directory called "html/parser" ? https://github.com/WebKit/WebKit/tree/main/Source/WebCore/html/parser [08:32:34.0216] <akaster> also your definition of XSS doesn't seem to make much sense. in what way is javascript code that calls the innerHTML setter of an arbitrary element a cross-site scripting vulnerability? [08:38:10.0577] <gogo> Yes I did. I mentionned it for parser/element webkit folder. [08:44:47.0669] <gogo> To clarify technically: Element.innerHTML = "<script>alert(1);</script>"; Will not execute contrary to: Element.innerHTML = "<img src='error' onerror='alert(1);'>"; That will print the 1. [08:45:22.0849] <gogo> In this contextvi need the parser code of policy/ parser of innerHTML output [09:00:10.0316] <Luke Warlow> you're setting JavaScript code to a HTML sink, if you wrap it in a script element it will execute (I think) [13:37:37.0953] <gogo> no. It will not. Sanitization is *one* of the securing methodologies. Check out at https://portswigger.net/web-security/cross-site-scripting/dom-based/lab-innerhtml-sink to see what you must do with the syntax to make it run. [13:37:44.0954] <gogo> * wrong. It will not. Sanitization is _one_ of the securing methodologies. Check out at https://portswigger.net/web-security/cross-site-scripting/dom-based/lab-innerhtml-sink to see what you must do with the syntax to make it run. [14:16:21.0368] <TabAtkins> Domenic or annevk : Would be really useful to have one of y'all comment on https://github.com/tc39/proposal-idl/issues/8 about the history of getting W3C to be able to refer to WHATWG specs (so ECMA can do the same). [14:28:19.0526] <gogo> element.innerHTML = "XXX"; calls setInnerHTML at [14:28:28.0500] <gogo> https://github.com/WebKit/WebKit/blob/main/Source/WebCore/dom/Element.cpp#L4347 [16:30:19.0023] <Domenic> There isn't much to say. One day W3C decided to stop self-inflicting problems on themselves. SDOs can set their own policies. Ecma can decide at any time what it wants, and TC39 has a lot of power over Ecma since it's the main spec Ecma produces. 2025-06-11 [00:16:27.0253] <gogo> > <@gogo2464:matrix.org> Hello. I want to document the latest version of the w3c parser for finding client side vulnerabilities. > > I started with a DOM XSS using the RFC of the parser with element.innerHTML = "XSS";. My goal is to have the syntax possible for each XSS possible. > > I started with: > > https://html.spec.whatwg.org/multipage/parsing.html#overview-of-the-parsing-model > > according to the schema, the loop starts at the HTML tree builder at https://github.com/WebKit/WebKit/blob/main/Source/WebCore/html/parser/HTMLTreeBuilder.cpp#L816 and then > > > I am wondering if according to the code at https://github.com/WebKit/WebKit/blob/2246a2aa28d527e129ebec66183569db035fdc8a/Source/WebCore/dom/Element.cpp#L4347 , the policy of innerHTML could deny to execute a script even if not sanitized. I need to find the parser location to see the grammar syntax for potential XSS as mentrionned there: https://html.spec.whatwg.org/multipage/dynamic-markup-insertion.html#dom-element-innerhtml . > > Is Elements::replaceChildrenWithMarkup the parser please? Could I ask again for the setinnerhtml parser please? [00:17:02.0473] <gogo> > <@gogo2464:matrix.org> Could I ask again for the setinnerhtml parser please? I need the policy parser [06:42:28.0205] <annevk> If anyone wanted to review https://github.com/whatwg/html/pull/10548 before it lands, now would be a very good time. [06:59:36.0635] <jmdyck> gogo: Re "the setinnerhtml parser": You linked to https://html.spec.whatwg.org/multipage/dynamic-markup-insertion.html#dom-element-innerhtml . So 2 lines down from that is "Element's innerHTML setter steps" (which refer to "the fragment parsing algorithm steps", which refer to "the HTML fragment parsing algorithm", etc). Does that answer your question? If not, could you be more specific? [07:00:12.0369] <annevk> Luca Casonato: https://github.com/whatwg/webidl/pull/1489 [07:10:53.0670] <gogo> yes. I showed you a link of my previous work. In 1000 pages, I showed you the link I finally found. I need: - to know if the policy parser could ignore not sanitized scripts - if responsible, I need the policy parser [07:51:32.0428] <annevk> Luke Warlow keithamus smaug: based on the discussion we had last week, are https://github.com/whatwg/html/pull/11255 and https://github.com/whatwg/html/pull/11345 still accurate or will they need changes? Per my recollection I think they match what we wanted in the end. Which was not composed, retargeted, and no further changes to event dispatch for referencetarget. (Olli was not in the room, but I'd like to make sure he agrees so maybe Keith can chat with Olli or some such.) [07:52:32.0154] <Luke Warlow> > <@annevk:matrix.org> Luke Warlow keithamus smaug: based on the discussion we had last week, are https://github.com/whatwg/html/pull/11255 and https://github.com/whatwg/html/pull/11345 still accurate or will they need changes? Per my recollection I think they match what we wanted in the end. Which was not composed, retargeted, and no further changes to event dispatch for referencetarget. (Olli was not in the room, but I'd like to make sure he agrees so maybe Keith can chat with Olli or some such.) I think that's correct those two things should be enough. [07:53:10.0331] <gogo> I need to understand why are not executed the <script> tag after innerHTML while not sanitized and while <img onerror="alert(1)">* [08:04:16.0653] <akaster> > These properties' setters perform no sanitization to remove potentially-dangerous elements and attributes like script or event handler content attributes. setting an element's innerHTML to untrusted input is a horrible idea in any case. it's almost guaranteed to lead to the problems like the ones outlined in your lab. There are better ways to dynamically add elements to the page than blindly treating a string from the network as html markup. [08:06:29.0923] <gogo> Yes. I stated it. What is the other way to secure with no sanitization please? [08:06:37.0723] <gogo> * Yes. I agree with it. What is the other way to secure with no sanitization please? [08:08:37.0956] <akaster> for that simple example of a search form? you could do something trivial like `document.createTextNode` and then `appendChild` that to the responsible div. or call the textContent setter on something but usage questions like this are out of scope for this forum [08:09:18.0417] <akaster> * for that simple example of a search form? you could do something trivial like `document.createTextNode` and then `appendChild` that to the responsible div. or call the textContent setter on something. But in general usage questions like this are out of scope for this forum [08:15:14.0568] <smaug> Not sure why source needs to retarget if the event isn't composed [08:15:29.0354] <smaug> Feels useless [08:20:44.0860] <annevk> smaug: the rationale is that people might accidentally expose their shadow tree if they fire a synthetic event as composed. (Though this really argues for generically retargeting event fields that hold nodes.) [08:22:03.0908] <smaug> I'd expect similar behavior to events which have .relatedTarget [08:24:19.0601] <smaug> (though, 'command' really should be composed always, somehow, or perhaps composed with some opt-in mechanism. Otherwise it becomes too useless.) [08:26:20.0344] <smaug> One shouldn't need to manually dispatch composed 'command' events, after capturing the trusted, non-composed 'command'. [08:29:51.0355] <Luke Warlow> During our discussion we couldn't really think of an example where using the composed command event really made sense. Because you can't operate on the real event target anyway [08:30:42.0862] <smaug> It is an API. You get command event with command "play" on widget which incorporates video element [08:30:44.0809] <Luke Warlow> In the toggle event case it would also be problematic because you can't actually disambiguate what fired the toggle event [08:30:48.0603] <smaug> and you can call preventDefault [08:30:56.0204] <smaug> stuff like that [08:30:58.0443] <annevk> I don't actually know what happens for a synthetic event with a class that has relatedTarget. Would be good to test. [08:31:32.0074] <smaug> (command event isn't integrated with video or such yet, sure) [08:31:37.0882] <Luke Warlow> > <@smaug:mozilla.org> and you can call preventDefault But is it really the job of the consumer to do that? Surely that's an implementation detail? [08:32:08.0434] <smaug> It would be part of the API [08:32:21.0922] <Luke Warlow> I fire a play command at "<magical-element>" if that element wants to let me prevent that behaviour they should fire their own event? [08:32:28.0372] <smaug> API contract that one can get notified when something happens and possibly cancel it [08:32:34.0905] <Luke Warlow> Whether it uses video under the hood or not isn't really relevant right? [08:32:58.0161] <smaug> Why would one need to first capture the event internally and then dispatch another event [08:33:00.0567] <smaug> feels useless [08:33:33.0870] <Luke Warlow> Because shadow roots are deliberately quite encapsulated [08:33:38.0784] <smaug> the API contract could be that `<magical-video>` exposes commands 'play', 'pause', 'stop' [08:34:15.0522] <Luke Warlow> Yeah and in doing that it would listen to command events on itself? Why does it need to be composed? [08:34:28.0150] <smaug> Right now in many cases one can call preventDefault() on *down/*up/click [08:34:46.0636] <smaug> composed makes it useful to the outside world [08:35:07.0504] <smaug> I might need to be opt-in somehow [08:36:31.0195] <Luke Warlow> I guess my question is why is command special? Do we instead need a way for a shadow root to "forward events" which automatically refires them essentially making them composed? [08:38:04.0066] <smaug> command might not need to be special. But in order to have somewhat useful command (so that it could replace some click usage), it probably needs to propagate outside shadow dom [08:38:33.0674] <Luke Warlow> I'm confused on why command keeps being equated to click? [08:38:45.0693] <Luke Warlow> Command fires on the other end [08:39:01.0037] <smaug> on the other end? [08:39:24.0056] <Luke Warlow> Well command fires on the video not on the button. [08:39:33.0804] <smaug> for now [08:39:42.0225] <smaug> command should fire on video when you click on video [08:40:11.0462] <Luke Warlow> ...that's not what command buttons are though. [08:40:12.0065] <smaug> the whole "limit to button" should be just a temporary thing 🙂 [08:40:36.0747] <Luke Warlow> Firing a command event instead of click in all scenarios doesn't make sense to me [08:44:10.0463] <Luke Warlow> Given it is only on buttons right now, is there a scenario where having it composed is good in practice and not in a hypothetical? I'm happy to be persuaded either way but Jake's made a fairly compelling case that it's not actually desirable to be composed. And when thinking through the source retargeting possibilities none of us could come up with a compelling case even for that. [08:46:05.0988] <smaug> if we keep it very simple and bound to buttons only, then sure, non-composed could work [08:47:09.0948] <smaug> But that is not what I had in mind when this was discussed in Sevilla [08:51:12.0988] <gogo> ok no problem. Do you know a more specific forum please? [08:58:19.0174] <Luke Warlow> Well if we need to add something novel in future we can still add that, but I'm just trying not to block shipping the current stuff on a potential future thing. If there's a counter use case to Jake's then we can discuss it though. [09:01:18.0305] <smaug> we need to always think about future when designing APIs. This is the web, we can't easily remove badly designed APIs 😉 [09:03:04.0105] <Luke Warlow> For sure, and I think what you're describing suggests a new forward event mechanism because this isn't the only event that probably warrants optional forwarding [09:03:49.0555] <Luke Warlow> * For sure, and I think what you're describing suggests a new forward event mechanism because this isn't the only event that probably warrants optional forwarding. Though doing that in JS doesn't feel like a major blocker [09:08:19.0881] <TabAtkins> Sure, but part of "stop self-inflicting problems" was asking for some working mode changes from WHATWG (RDs, at least), and some legal wording on their part presumably. I was just checking if there were more details I wasn't aware of. [09:37:05.0963] <smaug> Luke Warlow: I _think_ we could add opt-in filtering later. (but I don't still understand the retargeting patch. Added a comment there) [09:45:41.0740] <annevk> TabAtkins: RDs came before the W3C MoU and I don't think were motivated by the MoU. They were motivated by not having a compelling enough IPR story. [09:46:56.0074] <cwilso> RDs weren't motivated by the MoU, they were motivated by IPR commitments (and horizontal review at W3C), but that was the point of the MoU... [09:46:59.0379] <annevk> The main thing W3C asked for the MoU was the right to re-issue RDs of specific Workstreams, which we granted. Though then subsequently they stopped investing effort into that. [09:48:31.0570] <cwilso> I think at this point, we need to figure out what to re-work. The biggest problems, to me, are 1) the IPR path from incubation to standard should be unbroken; the current path of incubation in CGs relies on the work "migrating to a W3C WG", which it "kinda" does via HTML WG when feature goes to HTML spec, IFF those RDs are published. [09:48:46.0618] <annevk> * The main thing W3C asked for the MoU was the right to jointly publish RDs of specific Workstreams, which we granted. Though then subsequently they stopped investing effort into that. [09:48:56.0651] <cwilso> 2) horizontal review of HTML and DOM, which I still think is a value W3C could add if they got their act together. [09:48:58.0865] <annevk> * The main thing W3C asked for the MoU was the right to jointly publish some RDs of specific Workstreams, which we granted. Though then subsequently they stopped investing effort into that. [10:54:55.0515] <gogo> can I ask to RD and where? [11:55:11.0086] <jmdyck> I think "RD" stands for "Review Draft", which is briefly described here: https://whatwg.org/faq#patent-policy [11:55:20.0772] <Severin Severin> I'm so sorry if I'm in the wrong place. I just have a random question about a decision made for the HTML spec. Specifically concerning the CanvasImageSource. [11:58:28.0406] <gogo> Hello. Let me clarify previous question. where is the javascript EBNF javascript formal grammar please? I am looking for the doc for element.innerHTML and document.write please. [11:58:58.0371] <jmdyck> Severin Severin: I'm guessing you're in the right place. (or *a* right place, at least). [12:02:01.0258] <Severin Severin> jmdyck: Thanks. Do we just... shout it out and hope some other soul in the void can provide an answer? [12:02:05.0696] <jmdyck> gogo: The javascript language is defined in the ECMAScript specification, which you can find the current draft here: https://tc39.es/ecma262 It contains a grammar for the language, in BNF plus extensions, though probably not the EBNF you have in mind. [12:02:56.0468] <jmdyck> Severin Severin: That seems to be how it works. (Here and chat rooms in general, I think.) [12:04:23.0325] <Severin Severin> jmdyck: It's been a while since being in a "chat room" for me. 20 years or so. Thanks for the tips. [12:04:25.0546] <gogo> great ! thank you!! I want to write my own formal grammar spec for innerHTML xss injection I am going to read the parser of Element::setInnerHTML(...) in order to tell all the possible syntax for such injection. [12:05:32.0266] <jmdyck> Severin Severin: I mean, if you think you've found an error/problem with the spec, you can open an issue in the spec's github repo. But if you just want to ask a question, best to start here, probably. 2025-06-12 [18:11:50.0906] <Domenic> No working mode changes were done. They started citing WHATWG work before RDs existed. RDs were necessary to get them to stop forking DOM and HTML, but they cited Fetch and URL and others before any of that. [18:28:43.0932] <Domenic> Streams too maybe [00:13:21.0447] <annevk> sideshowbarker: could you perhaps review the conformance aspects of https://github.com/whatwg/html/pull/10548? It's not entirely clear to me they are unambiguous. In particular for `selectedcontent` it's a bit weird. It can appear in phrasing content, but only when there's an ancestor button element which has a parent select element, I think? I don't think there's any kind of precedent for that in the specification, so maybe it'll just be weird for a while until we get a better grip on it... [00:35:23.0757] <sideshowbarker> > <@annevk:matrix.org> sideshowbarker: could you perhaps review the conformance aspects of https://github.com/whatwg/html/pull/10548? It's not entirely clear to me they are unambiguous. In particular for `selectedcontent` it's a bit weird. It can appear in phrasing content, but only when there's an ancestor button element which has a parent select element, I think? I don't think there's any kind of precedent for that in the specification, so maybe it'll just be weird for a while until we get a better grip on it... Thanks yeah I'll take a look. But maybe not til early next week. (I have to be at what's basically a local member-recruiting event all day today and tomorrow.) But as far as precedents, I think it's possible we do actually have some — maybe not in HTML itself, but instead in the ARIA specs, which has some particular document/authoring-conformance requirements that are significantly more baroque than anything in HTML (including ones that require looking up the ancestor tree). [00:41:03.0936] <gogo> > <@sideshowbarker:matrix.org> Thanks yeah I'll take a look. But maybe not til early next week. (I have to be at what's basically a local member-recruiting event all day today and tomorrow.) But as far as precedents, I think it's possible we do actually have some — maybe not in HTML itself, but instead in the ARIA specs, which has some particular document/authoring-conformance requirements that are significantly more baroque than anything in HTML (including ones that require looking up the ancestor tree). For me? [00:42:13.0508] <sideshowbarker> Sorry, I don't know what you're asking me [01:00:57.0553] <annevk> sideshowbarker: thank you! I think it's also okay if it happens later and we address it post-landing if you're particularly busy, but waiting until early next week seems fine to me. [01:01:29.0771] <annevk> Hope the event has some decent snacks. 😊 [01:13:58.0460] <sideshowbarker> Hey, I can't join the WHATNOT meeting today, but a topic for those here and also for those who are attending: By the 20th, I need to request room for us (WHATWG) to meet at TPAC. So, I need to specify: - How many days we want to meet (e.g., one day, or two days, or half a day, or 1.5 days, or whatever - Which days we prefer: Monday+Tuesday or Thursday+Friday [01:17:24.0084] <sideshowbarker> And FYI one additional complication for this year is that they're going to have an additional one-hour slot on Monday, Tuesday, and Thursday for breakout sessions: > During TPAC 2024 we scheduled 14 breakouts in parallel in each of 6 slots. Our goal for TPAC 2025 is to schedule only 10 breakouts in parallel. Because we expect receiving 80-90 session proposals, we are organizing 9 1-hour slots during the week as follows (all times Japan): - Monday: 17:00-18:00 - Tuesday: 08:30-09:30 - Wednesday: 6 1-hour slots between 08:30 and 18:30 - Thursday: 17:00-18:00 [01:18:34.0714] <sideshowbarker> And incidentally for the WPT project, I also need to make the same kind of request, by the 20th [01:21:31.0307] <annevk> sideshowbarker: It doesn't seem like WHATNOT is happening today. I think we should ask for two days given the number of topics last year. If an hour is taken away here or there that seems fine. [01:22:20.0244] <annevk> * sideshowbarker: It doesn't seem like WHATNOT is happening today (it had ended by the time I remembered to join, anyway). I think we should ask for two days given the number of topics last year. If an hour is taken away here or there that seems fine. [01:26:07.0695] <Domenic> It ended after 15 minutes, we only had one issue basically and it was me plus three Mozilla people. [01:28:28.0582] <smaug> two days for WHATWG at TPAC sounds good to me. 2025-06-13 [14:56:06.0606] <jmdyck> https://html.spec.whatwg.org/#dom-navigator-appversion asserts that the result starts with "5.0 (", which can only be true if the "default `User-Agent` value" always begins with "Mozilla/5.0 (". That might be the case in practice, but the HTML spec and the Fetch spec don't appear to guarantee it. Does something else? [15:00:22.0886] <jmdyck> Oh, I see HTML has the comment `Fetch doesn't actually require the value to start with "Mozilla/5.0 (".` 2025-06-14 [03:36:46.0626] <filmore> Hi all [03:37:31.0196] <filmore> The spec shows <strong> being used inside of a caption (https://html.spec.whatwg.org/#table-descriptions-techniques). Is that semantically correct? Would <b> be better? [07:57:01.0923] <TabAtkins> Huh, yeah, I don't think that's really strongly emphasizing the first line, it's just giving it a distinctive style to separate it from the following text. `<b>` might indeed be better there. 2025-06-15 [14:37:31.0441] <cyberpunk> H