2023-08-02 [17:31:19.0890] Do you know that you can earn $5,000 or more weekly from crypto Trading? With Just $500… 100% Inbox Admin on Telegram for more details 👇👇👇👇👇👇 https://t.me/PROFITSWITHSTEVE 2023-08-05 [18:48:47.0643] i'm looking at the wpt test data for URLs, and i'm a little confused by https://github.com/web-platform-tests/wpt/blob/master/url/resources/urltestdata.json#L4725 [18:49:15.0481] \uD800 \uD801 isn't a valid surrogate pair, so what exactly is meant by this particular input? [18:49:28.0165] my json parser chokes on it, understandably [23:41:23.0977] What is meant is to test what the URL parser does on invalid surrogate pairs [23:41:48.0691] The algorithm handles them just fine (since it operates on strings, which are sequences of 16-bit code units, including invalid surrogates) [00:23:59.0027] I'm sure the URL parser handles it fine, but I think this is invalid JSON [00:25:32.0474] will need to dig up a parser that I can tell to ignore invalid surrogate pairs [00:25:51.0781] * will need to dig up a JSON parser that I can tell to ignore invalid surrogate pairs [01:34:50.0074] JSON.parse() works fine on it [07:34:08.0851] `"\uD800\uD801"` is valid JSON but not guaranteed to be interoperable (especially if the decoder is in a language that internally uses UTF-8 for strings), cf. https://www.rfc-editor.org/rfc/rfc8259#section-8.2 > However, the ABNF in this specification allows member names and string values to contain bit sequences that cannot encode Unicode characters; for example, "\uDEAD" (a single unpaired UTF-16 surrogate)… The behavior of software that receives JSON texts containing such values is unpredictable; for example, implementations might return different values for the length of a string value or even suffer fatal runtime exceptions. 2023-08-07 [22:54:02.0956] KBar, Ms2ger , Sam Sneddon [:gsnedders] , jgraham , emilio : I'm not aware of about:blank quirkiness constraints beyond: a) It's that way, because it has always been (and its logical given the lack of doctype) and b) the cases where the difference would be detectable are motivations both for and against changing it (folks who want the standards mode have a reason to change but existing content that puts stuff there could be adversely affected by a change). 2023-08-08 [02:59:18.0413] Let's say Origin A contains an iframe to Origin B. Is it possible for Origin A to create another Origin B iframe without requiring another main fetch to Origin B? I was hoping I could use a blob url passed back from the Origin B iframe, but that doesn't seem to work https://static-misc-2.glitch.me/iframe-host/ 2023-08-09 [15:50:24.0836] Hey 2023-08-10 [01:24:12.0288] @allstarschh: In general pinging someone less than 24 hours after you've already done so is not necessary. Especially for such a non-urgent PR. I'll try to make time for the PR next week, but it's 17:30 and tomorrow's a holiday, so please have some patience. [01:26:05.0870] <@allstarschh> Domenic: oh, thanks, I saw the reviewer is not set and I don't know if I should set that or someone will set it, the issue is not urgent, [01:46:56.0336] Jake Archibald: there's an (early stage) proposal for websites to mark a blob as crossOrigin accessible. https://github.com/w3c/FileAPI/issues/192. In your case, this would require Origin B to opt in. [02:05:14.0048] freddy: isn't that the opposite of what I'm looking for? It seems like the resulting resource would be different-origin to Origin B. [02:07:54.0309] Right. 🤦‍♂️ [02:10:54.0475] I guess that confirms annevk's worry about the property name. It does initially look like it means the opposite. [02:29:48.0230] The spec describes both classic async scripts and module async scripts as executing as soon as they are available. In reality, classic async scripts may execute a tiny bit later, but since the exact moment of network response finishing isn't exposed, the tiny bit later looks as if it was part of the network timing. However, for inline async scripts that have no external dependencies, "as soon as they are available" in principle has a well-defined point in time relative to the HTML parse. However, it seems bad to grant special guarantees to that case. Do I understand correctly that the spec doesn't mean to grant guarantees about that special case and it's OK for the parse to progress a bit before an inline async module script without external dependencies executes? [02:30:12.0235] ^ @allstarschh [02:30:48.0126] * The spec describes both classic async scripts and module async scripts as executing as soon as they are available. In reality, classic async scripts may execute a tiny bit later, but since the exact moment of network response finishing isn't exposed, the tiny bit later looks as if it was part of the network timing. However, for inline async module scripts that have no external dependencies, "as soon as they are available" in principle has a well-defined point in time relative to the HTML parse. However, it seems bad to grant special guarantees to that case. Do I understand correctly that the spec doesn't mean to grant guarantees about that special case and it's OK for the parse to progress a bit before an inline async module script without external dependencies executes? [02:32:02.0728] It would be unfortunate to have to use the `document.write` accommodating execution path in Gecko for inline async module scripts just because the spec granted that special case a special guarantee that goes away as soon as the module has an external dependency. [02:32:38.0061] (I gather that in any case, module scripts are prohibited from using `document.write`, so the guarantee would be only about the specific observable DOM shape.) [02:43:56.0922] Well, at least Chrome doesn't grant that guarantee. I guess I need to file a spec issue to avoid suggesting a specific execution time. [02:46:12.0059] Demo: https://hsivonen.com/test/moz/inline-async-module-script-without-deps.html [03:05:59.0860] Filed as https://github.com/whatwg/html/issues/9597 [10:35:03.0534] Noam Rosenthal: Re: https://github.com/whatwg/html/issues/9332#issuecomment-1673580721, do you have any sense of what % of sites currently render before all of the ~final/stable above-the-fold DOM nodes are in the DOM? I guess 100% of client side rendered sites -- is that the main (only?) use case here? [10:43:14.0323] > <@etportis:matrix.org> Noam Rosenthal: Re: https://github.com/whatwg/html/issues/9332#issuecomment-1673580721, do you have any sense of what % of sites currently render before all of the ~final/stable above-the-fold DOM nodes are in the DOM? I guess 100% of client side rendered sites -- is that the main (only?) use case here? I don’t think we can have that info, stable is subjective and dependent on content [10:50:28.0143] Noam Rosenthal: That makes sense. I'm just trying to get a sense of the need, here -- what's driving this. Paving a bad cowpath (anti-flicker snippets, used for all kinds of reasons) is a cost. [10:52:26.0446] * Noam Rosenthal: That makes sense. I'm just trying to get a sense of the need, here -- what's driving this. Paving a bad cowpath (anti-flicker snippets, used for all kinds of reasons) is a cost.( [10:52:29.0508] (And hunt around for a more-scoped solution for the subset of problematic cases) [10:52:58.0828] * Noam Rosenthal: That makes sense. I'm just trying to get a sense of the need, here -- what's driving this. Paving a bad cowpath (anti-flicker snippets, used for all kinds of reasons) is a cost. [10:55:41.0378] > <@etportis:matrix.org> (And hunt around for a more-scoped solution for the subset of problematic cases) What’s driving this is view transitions. But the use case has been around way before that, to avoid ugly layout shifts and flashes due to important elements not being parsed yet [10:58:51.0996] Right. Something slowly animating out and then popping back in, in the same spot, late is much, much worse than something just popping in late -- I get the extra need for it for View Transitions. But is there a subset of sites that this affects? It's pages that are fetching content in JS, right? I could put a view-transition-name on something at the bottom of HTML spec single-page and it won't matter that the parser has already yielded to the renderer, because that element is a mile outside of the viewport...? [11:05:03.0360] > <@etportis:matrix.org> Right. Something slowly animating out and then popping back in, in the same spot, late is much, much worse than something just popping in late -- I get the extra need for it for View Transitions. But is there a subset of sites that this affects? It's pages that are fetching content in JS, right? I could put a view-transition-name on something at the bottom of HTML spec single-page and it won't matter that the parser has already yielded to the renderer, because that element is a mile outside of the viewport...? It would be relevant for any page that has cross-document view transitions and its elements are chunked in slowly. It’s actually less relevant to SPA where you can do this with a render-blocking script [11:07:19.0388] > and its elements are chunked in slowly ...and those elements have view-transition-names, right? Hypothetically, would this problem be solved if everyone ensured that everything they put a view-transition-name on was in the HTML response. (I know we can't ask authors to do that... just trying to build a mental model of the problem) [11:07:27.0994] * > and its elements are chunked in slowly ...and those elements have view-transition-names, right? Hypothetically, would this problem be solved if everyone ensured that everything they put a view-transition-name on was in the HTML response. (I know we can't ask authors to do that... just trying to build a mental model of the problem) [11:08:41.0089] > <@etportis:matrix.org> > and its elements are chunked in slowly > > ...and those elements have view-transition-names, right? > > Hypothetically, would this problem be solved if everyone ensured that everything they put a view-transition-name on was in the HTML response. (I know we can't ask authors to do that... just trying to build a mental model of the problem) HTML responses are chunked though [11:09:27.0349] I don’t think you and I are talking about the same issue [11:11:24.0813] The issue is starting a transition from the old doc before the new one has the elements to transition to. This can happen with zero JS, given chunked HTML responses [11:14:27.0469] That makes sense, and yeah seems like a significant case I hadn't thought of. So you can't limit this to JS-fetched cases. (Out of curiosity, if you have any data on how often Chrome paints before the last chunk is through, that seems... more attainable that understanding what DOM is "final") [11:14:53.0779] * That makes sense, and yeah seems like a significant case I hadn't thought of. So you can't limit this to JS-fetched cases. (Out of curiosity, if you have any data on how often Chrome paints before the last chunk is through, that seems... more attainable than understanding what DOM is "final") [11:15:04.0327] Oh that happens super often [11:16:07.0961] FCP < domContentLoaded is very common. Not sure those numbers would tell us an important story [11:16:48.0134] Yeah, ok [11:17:39.0584] Do you think it makes any kind of sense to tie this to View Transitions? So only block rendering when there's an incoming Transition? [11:18:06.0658] No, given that this also helps simpler CLS cases [11:18:42.0989] As in, what people do today by changing the body’s display css [11:21:13.0504] Also we want to have less vt-specific things whenever possible [11:24:17.0660] I don't think that's a pattern we want to make more ergonomic = common, but that's just an opinion and I should back it up with something... [11:24:34.0810] Thanks for the help understanding the issue and where you're coming from on it! [11:25:21.0739] Sure! Hope we can reach a resolution 2023-08-12 [22:46:40.0131] Hello. I guess this is the new USENET/IRC. [22:48:10.0985] I recently discovered that there is no default value for the @scope attribute of the TH element. I always thought it was `row` for children of TBODY and `col` otherwise. Is that not how browsers behave anyway? [22:51:29.0515] If confirmed, would it be wise to codify that behaviour in the standard? (and, is Ian Hickson still the editor?) [23:18:09.0686] Hmm, the current developer presentation of the WHATWG edition of the standard differs from waht is published on MDN: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/th#scope says "browsers automatically select the set of cells to which the header cell applies" but does not mention the `auto` state, leaving me to think it was up to browsers to create some heuristic of their own. This page https://html.spec.whatwg.org/dev/tables.html#attr-th-scope gives quite a verbose description of the expected behaviour, along with diagrams, but does not specify that succinctly in the description of the `auto` state. [23:23:16.0008] The description explicity says both `auto` and `rowgroup` do not apply to cells preceding the TH with that scope in the current row (for TH children of TBODY) or rowgroup. It says nothing about if/how the `auto`, `col` and `colgroup` states apply headers to preceding cells. [23:29:59.0761] Also, the described behaviour of an explicit `rowgroup` value, to not apply to cells in preceding columns, differs from what I would intuitivly have expected. In the diagram, ` Cats` does not apply to ` 93`. Is that really how browsers and accessibility agents behave? In other words, `rowgroup` does not mean "rowgroup", it means "cells in this and following columns within this rowgroup" [23:38:39.0951] More discrepencies: >The row group state means the header cell applies to all the remaining cells in the row group. This wording is incorrect according to the Cats/Legs diagram. The behaviour illustrated would correspond to: "The row group state means the header cell applies to all cells in the current and subsequent columns, within the row group." [23:44:03.0151] If "remaining cells" was defined to mean cells in remaining columns, would that include cells that span across from a preceding column? [00:19:47.0407] `scope` was added between September and November 1997: https://www.w3.org/TR/PR-html40-971107/struct/tables.html#adef-scope > `row`: The current cell provides header information for the rest of the row that contains it. etc. So, "the rest of" is clear for row. `rowgroup` is similarly defined, so it is not clear if it includes preceding columns in subsequent rows (as might be interpreted) [00:24:57.0957] Also the WHATWG text "The remaining headers apply just to the cells to the right of them." should be amended to use logical directionality for RTL tables. [00:32:12.0367] So, my findings are that the definition of `row` and `col` is consistent with the behaviour of `auto` when the TH is a child of a TBODY, or not, respectivly, though this behaviour is not explicitly defined for auto. [00:36:22.0968] In other words, the definition of `auto` could be changed from > The _auto_ state makes the header cell apply to a set of cells selected based on context. to e.g. "The _auto_ state behaves as if it were set to _row_ if `tbody > tr > th:not([scope])`, and `col` otherwise." I think this would be a more useful definition. 2023-08-15 [10:20:03.0866] Dominic Farolino: https://github.com/web-platform-tests/wpt/blob/master/html/semantics/scripting-1/the-script-element/moving-between-documents/move-back-iframe-fetch-error-external-module.html assumes that a slow stylesheet blocks module scripts from running. AFAICT, in Gecko, only the execution of a parser-blocking script can be deferred by a stylesheet. Where in the spec does it say that non-async (i.e. defer) module scripts wait on style? [11:46:00.0695] I didn't write that tests, so I'll try and reach out to the Googler that did and see if he can explain. [11:47:25.0257] * I didn't write that test, so I'll try and reach out to the Googler that did and see if he can explain. 2023-08-16 [20:12:50.0341] QQ - WHATWG is listed on the TPAC agenda -- is there an agenda? Is it likely to be well-attended? [05:24:59.0568] smaug: question re. https://github.com/whatwg/html/issues/9315#issuecomment-1680504091 In Gecko, when there is a rAF pending, would that block the first paint when coming back from bfcache? [05:25:41.0780] there shouldn't be rAF pending when coming out of bfcache [05:26:02.0736] can't you call `requestAnimationFrame` in pagehide? [05:26:43.0905] sure, but the current rendering might be cached [05:27:03.0826] and shown to the user and then rAF called [05:27:23.0302] ok, so it's sort of the same as what we're proposing with reveal [05:28:05.0595] expect that reveal would force waiting for handling of reveal event before showing anything to the user [05:28:06.0633] it's guaranteed to be called before the next rAF, and in the case of an actual view transition also guaranteed to be before the first paint - but that's because VT holds painting of the new document, not because of the reveal event itself [05:28:22.0948] what forces waiting is the fact that there is a view transition, not the reveal event. [05:29:05.0943] if there is a reveal event without a VT - show the cached image, fire the reveal event, fire the rAF callback if it exists, and continue your life [05:30:26.0849] Isn't that quite confusing semantics? In some case reveal would fire when the page has been already revealed to the user and in some case before [05:31:00.0023] we could also make it wait when there is a reveal event handler, to prevent a flashing effect, if e.g. you're showing a clock [05:32:07.0961] how does pageshow work in that regard btw? doesn't it have the same confusing aspect? [05:32:27.0500] Right. I'm just worried about the misuse of the event. Right now bfcache can be really fast, no need to wait for anything. [05:32:33.0896] pageshow doesn't have [05:32:52.0188] it has nothing to do with rendering [05:36:06.0233] if reveal does not have anything to do with rendering (in case when view transitions aren't around), then it would be just a duplicate of pageshow. Which would be a bit weird. [05:37:17.0594] Could we possible have an event specific to view transitions? [05:37:44.0786] Since those anyhow slow down the process of coming out of bfcache or animate that. [05:37:54.0770] * Could we possible have an event specific to view transitions? (just a thought) [05:37:59.0915] The problem with an event specific to view transitions, is that it can be error prone in the sense that you might be expect a VT, but perhaps something in the old document prevented a VT from happening [05:40:18.0547] don't you want then some notification that VT didn't happen? [05:40:39.0590] what would that look like? wouldn't that be the same as a reveal event with a null VT? [05:41:14.0335] maybe, but it would fire only if the page was trying to use vt or something [05:43:08.0678] yea perhaps we could fire it only when the page has opted-in to view transitions and find a VT-specific name. let me think this over [06:07:31.0517] smaug: though I still think that `pageshow` already has this same inconsistent aspect (can be before or after first frame), and having an additional event there wouldn't make it more confusing. I don't exactly get what it means that `pageshow` has nothing to do with rendering. In the BFCache-restore case it has as much to do with rendering as `reveal`. What we were proposing is something that matches `pageshow` exactly, except it's not gated on `load`, and instead gated on document no longer being render-blocked. [06:08:00.0354] pageshow has nothing to do with rendering [06:08:33.0544] it is just to tell that page came out of bfcache, or in case of initial page load, it replicated load event [06:08:40.0184] * it is just to tell that page came out of bfcache, or in case of initial page load, it replicatea load event [06:08:45.0945] * it is just to tell that page came out of bfcache, or in case of initial page load, it replicates load event [06:18:07.0398] pageshow predates anything like rAF for quite a few years. [06:19:23.0890] regardless of their purpose, in the case of VT both pageshow and rAF callback would have a different behavior based on whether there is an actual VT or not, and unlike pageshow, rAF is very related to rendering [06:21:29.0874] why would the behavior of pageshow change in case there is vt around? [06:21:42.0098] as in, if you call rAF on pagehide, and then restore from BFCache, you might or might not see the previous frame again, based on whether you have a VT [06:22:20.0071] same with pageshow. When there is a VT, the first frame always waits for the main thread, and the first task in the main thread is to fire pageshow [06:23:12.0424] so VT: pageshow is before first frame, no VT: pageshow is potentially after cached first frame [06:23:16.0578] reveal is not different [06:23:27.0828] (or it could be, but then we risk misuse as you say) [06:24:56.0130] > <@domfarolino:matrix.org> I didn't write that test, so I'll try and reach out to the Googler that did and see if he can explain. Thanks. And sorry for not checking blame. I saw your name in a comment that suggested perhaps even removing the test that my patch failed. [06:28:57.0219] smaug: So I get why it's confusing, but it's also consistent with the existing rendering-related callback when restoring from BFCache, which is the first rAF. btw I believe this would be also consistent with `ResizeObserver `and `IntersectionObserver` callbacks (at least per spec), and they would also currently have this confusing behavior of sometimes being called after the previous frame, and they're rendering related. [06:52:12.0749] Those just run when rendering updates happen. reveal on the other hand sounds like something which is bound to the first paint, and if it sometimes fires before and sometimes after paint, that is confusing. [07:01:21.0924] you can say it's bound to the first paint of the new state of the document [07:13:33.0152] @smaug we can call it `beforerenderingupdate`, maybe that would be less confusing? it would be guaranteed to be before we update the rendering, but perhaps not before first paint [07:14:21.0839] * smaug: we can call it `beforerenderingupdate`, maybe that would be less confusing? it would be guaranteed to be before we update the rendering, but perhaps not before first paint [08:30:33.0823] that sounds like something which would happen before any rendering update [08:43:49.0655] smaug: `firstrender`? `firstanimationframe`? `firstrenderingupdate`? Also I believe that the word `reveal` does kind of mean this in a way. You show an old state and you're about to reveal the new one. In the documentation we can be explicit that it means "before the rendering update after a navigation". [10:04:31.0207] ... or `readytorender`, `canrender`. [13:59:21.0050] Np. So it looks like module scripts are appended to the "list of scripts that will execute when the document has finished parsing" here: https://html.spec.whatwg.org/multipage/scripting.html#script-processing-model:list-of-scripts-that-will-execute-when-the-document-has-finished-parsing, and that the blocking of executing scripts from that list based on style sheets is done here: https://html.spec.whatwg.org/multipage/parsing.html#stop-parsing:~:text=Spin%20the%20event%20loop%20until%20the%20first%20script%20in%20the%20list%20of%20scripts%20that%20will%20execute%20when%20the%20document%20has%20finished%20parsing%20has%20its%20ready%20to%20be%20parser%2Dexecuted%20set%20to%20true%20and%20the%20parser%27s%20Document%20has%20no%20style%20sheet%20that%20is%20blocking%20scripts [13:59:55.0634] hsivonen: Also relevant: https://bugzilla.mozilla.org/show_bug.cgi?id=1622235 2023-08-17 [20:06:00.0429] sideshowbarker: BTW if you get sick of the Wattsi stuff and would rather we just merge your changes and not have long discussions about them, please let me know. They're clearly an improvement over the status quo so if you want to limit the time we spend on this I'm happy to do that. [21:45:49.0841] > <@domenicdenicola:matrix.org> sideshowbarker: BTW if you get sick of the Wattsi stuff and would rather we just merge your changes and not have long discussions about them, please let me know. They're clearly an improvement over the status quo so if you want to limit the time we spend on this I'm happy to do that. As long as you remain interested in figuring it out, I’m happy to keep making time. [21:47:57.0037] While I guess it’s not absolutely _necessary_ that we understand well what all the code is doing, _not_ understanding it is less than ideal [21:48:42.0189] And to me personally at least, not understanding it all well enough that I could explain it well to any new contributors we might have show up, that feels a bit… unsettling [21:52:48.0478] However, I’ve been attempting to write a WebKit patch for https://github.com/whatwg/html/issues/8892 and am hoping I can get that further along before I go back to looking at the Wattsi stuff [21:53:23.0630] for https://github.com/whatwg/html/pull/8893 that is (the related PR) [21:59:54.0173] I already have a working implementation of the spec requirements in the patch in that PR — but per the comments, it seems like the patch needs to be updated to do the same coalescing behavior that’s specified for `popover` in https://html.spec.whatwg.org/multipage/popover.html#queue-a-popover-toggle-event-task. WebKit has a conforming implementation of that for `popover` — but I’ve been looking at that code, but have so been finding that reimplementing an equivalent to that for `details` is… pretty challenging [22:03:38.0731] I’m hoping that @ntim might be able to give me some guidance, if he’s got time and patience to answer what are some relatively basic questions [23:35:44.0474] > <@mnot:matrix.im> QQ - WHATWG is listed on the TPAC agenda -- is there an agenda? Is it likely to be well-attended? There’s no agenda yet (not that I’m aware of at least), but as far as the attendance, there’s a list at https://www.w3.org/register/tpac2023/registrants#meeting-248 — which is visible to Members only — and it currently shows 66 people registered, mostly as “observers”. It’s likely that a lot of those people may not actually attend, but even if roughly half of them do, that’s 30+ people. [23:56:53.0275] Thanks! [05:40:48.0109] mnot: sideshowbarker: there's a tentative agenda at https://github.com/whatwg/meta/issues/284 [05:51:31.0647] fwiw: Would love to see that "Potential joint session with the OpenUI CG" is recorded. or at least transcribed and minutes published. 2023-08-21 [07:03:36.0090] do we have any machine-readable description that gives HTML element name -> IDL interface? so, like, `{"link": "HTMLLinkElement"}` etc? [07:24:40.0587] Depending on how much massaging you're willing to do, https://github.com/web-platform-tests/wpt/blob/efde03a7b7434136cda336ff0b1ffcd51639dc12/dom/nodes/Node-cloneNode.html#L119 or https://github.com/web-platform-tests/wpt/blob/efde03a7b7434136cda336ff0b1ffcd51639dc12/custom-elements/builtin-coverage.html#L68 might be a good place to start [07:33:02.0510] you can probably have an XPath or so that reads it from HTML's `source` file, it has a table with all that [08:41:48.0865] Or https://github.com/web-platform-tests/wpt/blob/efde03a7b7434136cda336ff0b1ffcd51639dc12/html/semantics/interfaces.js#L131 [10:42:54.0462] this seems to have not been updated in 6 years [10:43:09.0060] but I guess it can be updated 2023-08-23 [12:47:12.0834] Is there a CSSWG type channel on Matrix? Someone here might know in any case. Has there ever been a discussion for allowing "display: contents" to appear invisible to CSS descendant combinators? I know that kind of goes against hierarchical way CSS works. I was thinking either a style on the element like display-contents: ignore. Or an optional descendant like .foo > :display-contents > .bar that descends through any number of display: contents. Does the fact that display is computed make this impossible/difficult? [15:50:59.0054] sirisian: No, CSSWG still works on IRC (the W3C irc server, #css room). [15:51:24.0723] Where [15:51:26.0213] But directly for your question, no, it's impossible to have a selector depend on properties. [15:54:02.0946] Thanks [16:15:21.0805] https://matrix.to/#/#w3c_css:matrix.org 2023-08-24 [17:00:08.0771] To be clear, the W3C CSS room that aja pointed out is the same as the CSS IRC channel (the two places are two-way bridged) [17:02:49.0343] …in other words, you can post messages to whichever place you want, and all your messages will also be seen by everybody in the other place too [17:03:09.0825] Yes public the better [10:52:22.0151] annevk (or others): thoughts on the template vs. template contents question for setUnsafeHTML? https://github.com/whatwg/html/pull/9538#pullrequestreview-1581819151 2023-08-25 [22:31:04.0111] Domenic: I think special cased is the way to go, though it makes me wonder how the other positional methods should end up working there, `beforeUnsafeHTML` and such [22:31:41.0949] Domenic: and yeah, it should be available on `ShadowRoot` too [10:19:41.0717] I'm looking at the URL object protocol setter: https://url.spec.whatwg.org/#dom-url-protocol [10:19:54.0230] it runs https://url.spec.whatwg.org/#concept-basic-url-parser [10:20:08.0390] the latter has > If state override is given, then: > If url’s scheme is a special scheme and buffer is not a special scheme, then return. [10:20:24.0537] "special scheme" meaning http, https, etc [10:20:59.0965] does that mean that `x = new URL('http:bar'); x.protocol = 'notspecial'; x.protocol` should give me `http`? [10:21:02.0581] because it does not [10:21:08.0067] in any browser [10:21:16.0539] * does that mean that `x = new URL('http:bar'); x.protocol = 'notspecial'; x.protocol` should give me `http:`? [10:22:10.0463] it does in Node though, possibly because they were following the spec [11:36:41.0331] Web-platform tests show that all browsers are behind in URL tests - https://wpt.fyi/results/url?label=experimental&label=master&aligned [11:40:58.0552] Here is a relevant test for non-special scheme to special scheme setter: https://github.com/web-platform-tests/wpt/blob/da479d7ffdf4231062582eb84f1a0309e1e8d7fd/url/resources/setters_tests.json#L205 [11:58:15.0956] https://infosec.zeyu2001.com/2023/from-xs-leaks-to-ss-leaks I wonder if the behavior for a samesite leak could be fixed across browsers? [11:58:30.0948] bakkot: yeah, that's the idea [11:59:12.0804] bakkot: there's an open issue on this and we might change it, but it would require a reparse of the entire URL, which is rather ugly, so I hope browsers can get this fixed [12:01:08.0286] > The element differs from iframes in a major way. If the status code of the requested resource is 404, the object is not at all rendered in the DOM. While the object element exists in the DOM tree, none of the page contents are actually rendered in the DOM. [12:04:40.0102] freddy: there's a number of issues on loading against whatwg/html; someone would have to try I suppose [12:13:08.0785] > <@annevk:matrix.org> bakkot: there's an open issue on this and we might change it, but it would require a reparse of the entire URL, which is rather ugly, so I hope browsers can get this fixed it's *really* useful to be able to assign whatever properties i want on an URL instance, because there's no function i'm aware of that can take an object of properties and turn it into a URL instance, so to do that i need to make a blank one and populate it. the restriction about specialness transitions seems weird to me. 2023-08-26 [22:19:54.0718] Is the spec definition of “interactive content” https://html.spec.whatwg.org/multipage/dom.html#interactive-content intended to include the SVG `a` element, or instead only intended to include the HTML `a` element? [22:23:53.0864] I realize the definition _links_ only to the HTML element, but I wonder whether any implementations have assumed the SVG `a` element should be included. [22:26:29.0565] Regardless, _should_ we explicitly include “the `a` element in the SVG namespace” in that definition of “interactive content”? [23:38:44.0703] ljharb: you can't create a blank one [23:41:28.0554] sideshowbarker: where does that definition have an impact on implementations? But yeah, generally I think and should be treated the same. [00:22:41.0860] > <@annevk:matrix.org> sideshowbarker: where does that definition have an impact on implementations? But yeah, generally I think and should be treated the same. For the `summary` element, when deciding whether an activation event somewhere inside the `summary` should toggle its `details` [00:29:42.0705] And https://searchfox.org/wubkat/source/Source/WebCore/html/HTMLLabelElement.cpp#124 is one other existing place I could find in the WebKit sources at least [00:33:36.0348] It seems like that rightly should be considering the SVG `a` element too — but that `if (is(it) && downcast(*it).isInteractiveContent())` won't catch it. [00:38:47.0493] Yeah, hmm. Is svg:a the only interactive element outside of HTML? [00:40:12.0414] > <@annevk:matrix.org> Yeah, hmm. Is svg:a the only interactive element outside of HTML? Yes, from code inspection at least, I believe it is [00:41:33.0607] Nothing else interactive in SVG, as far as I can see, and nothing at all in MathML that's interactive [00:58:49.0733] sideshowbarker: cool, I think we should just change that in the HTML Standard then, just like we already treat SVGImageElement special in a couple of places [00:59:28.0170] > <@annevk:matrix.org> sideshowbarker: cool, I think we should just change that in the HTML Standard then, just like we already treat SVGImageElement special in a couple of places Hai. I'll open a PR [08:17:49.0200] 1 << 31 + unsigned long = positive integer? The final bit of https://webidl.spec.whatwg.org/#abstract-opdef-converttoint is tricky. [15:40:25.0790] > <@annevk:matrix.org> ljharb: you can't create a blank one i mean a conceptually blank one :-p `about:blank` works great in theory. but you're right, which is why maybe the better solution for my use cases is some kind of `URL.from(object)` API 2023-08-28 [05:36:02.0736] annevk: is someone working on implementing ORB in webkit? [07:35:15.0422] zcorpan: I don't think so [07:38:53.0030] annevk: ok. We're doing a staged rollout currently, with some exceptions (mp3 and aac I think). I think Chromium shipped an incomplete version some time ago and are now working on updating it to match the spec more closely. [07:55:56.0633] zcorpan: that's great, does Fx have the JS parser aspects implemented? [07:56:53.0858] annevk: I believe so. farre? [07:57:05.0037] yes [08:35:27.0964] Pretty exciting, that means we should consider making it an official standard soon. [10:53:24.0188] What's ORB? Without any context to guide the search, googling that word is obviously unhelpful. ^_^ [11:05:12.0661] TabAtkins: Opaque Response Blocking https://github.com/annevk/orb [11:07:02.0611] danke [11:08:31.0073] bakkot ljharb I pinged y'all in the issue too, but I went ahead and raised an issue for URL.from() https://github.com/whatwg/url/issues/782 [11:09:01.0085] oh awesome, thanks [12:27:36.0020] Do we have enough to resolve https://github.com/whatwg/html/issues/9491 ? [13:56:14.0478] is there a url that is like the single page edition of the developer version of the html spec? 2023-08-29 [18:24:14.0685] No, developer edition is always multipage [18:26:03.0550] > <@zcorpan:mozilla.org> Do we have enough to resolve https://github.com/whatwg/html/issues/9491 ? I'd be happy to have it closed. But we also just leave a lot of issues open forever in https://github.com/whatwg/html/labels/needs%20implementer%20interest state. [23:57:50.0075] sideshowbarker: https://github.com/whatwg/html/issues/9643 [13:40:10.0858] hmm, what does "top-level" mean in this context https://html.spec.whatwg.org/multipage/webappapis.html#concept-environment-top-level-creation-url ? [13:40:42.0817] I can guess what it might mean, but it is not really defined [13:41:35.0035] > <@smaug:mozilla.org> hmm, what does "top-level" mean in this context https://html.spec.whatwg.org/multipage/webappapis.html#concept-environment-top-level-creation-url ? I'm pretty sure it's the top-level frame. Same as https://html.spec.whatwg.org/multipage/document-sequences.html#top-level-traversables. There's a bug about removing that field entirely... [13:41:50.0176] that is what I'd guess yes [13:42:00.0524] but not defined [13:44:06.0027] https://github.com/whatwg/html/issues/8014 suggests to replace top-level origin with top-level site, but that's not the same as removing or defining the term. 2023-08-30 [23:47:32.0058] I don't understand what you mean smaug? What you're linking to is just defining the layout of the struct. Initializing the struct happens elsewhere. [00:03:46.0826] Hi there! I’m Chrissy, a lover of baking, open source, and the Oxford Comma! :) I learned about this project while making a pull request for MDN Web Docs, and decided to join. I’m interested in technical writing, so does the repo have any docs-related good first issue that you can recommend? [00:15:31.0277] How does one start a proposal without using Microsoft GitHub? Is there an independent forum or mailing list? [01:17:01.0241] > <@annevk:matrix.org> sideshowbarker: https://github.com/whatwg/html/issues/9643 Thanks for the heads-up — fixed now [01:24:27.0069] toastal: there is not, but you could write something on your own website [01:26:30.0315] > <@annevk:matrix.org> toastal: there is not, but you could write something on your own website That’s a bummer with the proprietary lock-in. I wrote a [half-proposal as a blog](https://toast.al/posts/softwarecraft/2023-08-29_semantic-markup-for-callouts) yesterday, but I wanted to get some general feedback before trying something like a more official proposal. [01:27:23.0680] If anyone would be interested in try to clean up & make a more substantial proposal for a `` (and maybe ``) element, please reach out to me! [01:28:43.0846] I would however prefer to keep as much data as possible away from Microsoft-owned platforms. [01:57:12.0139] annevk: aha [05:56:23.0830] Hey Christine Belzie, I'm not aware of any docs-related issue, but you could scan through https://github.com/search?q=org%3Awhatwg+label%3A%22good+first+issue%22+is%3Aopen&type=issues to see if any of those seems doable; happy to help [08:00:40.0439] > <@toastal:mozilla.org> How does one start a proposal without using Microsoft GitHub? Is there an independent forum or mailing list? Hiiii [08:01:32.0295] I'm new here [08:02:55.0945] I find this chat from dark web [09:27:26.0254] Domenic: https://github.com/web-platform-tests/wpt/pull/41693 might be of interest [09:27:53.0969] * Domenic: https://github.com/web-platform-tests/wpt/pull/41693 might be of interest (mainly the meta) [09:45:52.0059] mfreed: jarhar: do either of you know who would own MIME Sniffing these days within Chromium? Would appreciate some input in https://github.com/whatwg/mimesniff/issues/173 [09:50:56.0072] im not sure, but ill @mention some people [12:58:38.0488] > <@domenicdenicola:matrix.org> No, developer edition is always multipage thats a bummer [12:58:43.0430] but thanks 2023-08-31 [19:20:48.0419] How should issue sections be marked in bikeshed? There is [one in Web IDL](https://webidl.spec.whatwg.org/#idl-callback-functions) with just `class="issue"` that isn't styled appropriately and thus reads as a (weird) normative section. [19:50:38.0652] IIRC there's been some discussion in the past of having a method on `AbortSignal` that's like "register this handler if the signal is not already aborted, otherwise immediately call it", which is a pretty common use case (some discussion https://github.com/domfarolino/observable/issues/19#issuecomment-1698201158). anyone recall a discussion along those lines and where it could be found? [19:50:44.0497] I might just be thinking of `throwIfAborted` though. [19:57:37.0340] (note that this is basically how promise `then` works: "register this callback if the promise is not already settled, otherwise call it", modulo details about what "immediately" means) [20:04:07.0085] ah, node has `util.aborted` also, which is this but plus a weakref and in a promise form instead of registering a callback https://nodejs.org/api/util.html#utilabortedsignal-resource [20:08:59.0503] aha, which ultimately led me to https://github.com/whatwg/dom/issues/946 [20:25:31.0157] > <@kaiido:matrix.org> How should issue sections be marked in bikeshed? There is [one in Web IDL](https://webidl.spec.whatwg.org/#idl-callback-functions) with just `class="issue"` that isn't styled appropriately and thus reads as a (weird) normative section. Huh, that suggests that the WHATWG styling doesn't have styles for class=issue. (WebIDL was previously a W3C spec, which does have styling for that.) [20:32:30.0500] Filed https://github.com/whatwg/meta/issues/289 [23:52:52.0575] Kaiido: we use class=XXX [01:11:39.0842] zcorpan: freddy: https://github.com/whatwg/html/issues/2249#issuecomment-1700567077 [01:28:45.0478] I think we should do something once our URL parser is aligning on interop. What anne suggests sgtm.... zcorpan? [01:29:18.0376] freddy: yeah I was just writing a comment [01:37:52.0939] thanks! [02:18:40.0563] annevk: thanks for the heads up! [06:01:46.0264] zcorpan: it's an interesting question whether data: URLs count as cross-origin there; Fetch doesn't consider them as such, but HTML prolly does the quirks check and gets to decide and I doubt it special cases data: URLs [06:02:04.0503] zcorpan: and it prolly shouldn't, so I guess I'd be inclined to treat it as a thing to fix in Chromium [06:05:16.0350] annevk: "If the document has been set to quirks mode, has the same origin as the URL of the external resource" - the origin of the data: *URL* is an opaque origin, so is not same origin with the document [06:07:03.0010] I can file a bug [06:18:48.0766] Looks like Firefox also loads the stylesheet (but then doesn't hang because data: base urls are not allowed). So we need to fix this too [06:27:41.0924] zcorpan: thanks, we should add this test too (perhaps the one that hangs Chromium with a -crash suffix?) [06:29:13.0723] Isn't hang and crash different? [06:29:51.0375] zcorpan: yeah, not sure how to test that in a useful way for Chromium then, maybe just have a short timeout or some such [06:32:04.0862] annevk: I'd expect the result to be TIMEOUT, and the default timeout is probably short enough to not cause issues. It's slightly annoying when someones opens the test [06:32:58.0545] annevk: we can also test the quirk origin check without hanging chromium, by checking computed style or so [06:44:09.0169] https://bugs.chromium.org/p/chromium/issues/detail?id=1477672 [06:44:44.0650] zcorpan: makes sense, since it just hangs the tab I'd create two tests, but it would be nice to cover that scenario so other browsers don't run into it accidentally [06:57:53.0669] annevk: curious that firefox passes the test Parsing: <#x> against . I thought data: wasn't allowed as base [06:59:24.0740] is hash-only always allowed? [07:02:39.0259] https://bugzilla.mozilla.org/show_bug.cgi?id=1850965 [07:03:09.0489] fyi freddy [07:03:43.0729] zcorpan: yeah