- From: CSS Meeting Bot via GitHub <noreply@w3.org>
- Date: Wed, 14 Jan 2026 18:03:13 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-borders] Add a 'hairline' border-width value`.
<details><summary>The full IRC log of that discussion</summary>
<kbabbitt> emilio: long discussion about different use cases<br>
<kbabbitt> ... and what it implies<br>
<kbabbitt> ... fantasai put current status at end of issue<br>
<kbabbitt> ... good use cases like drawing a hairline border<br>
<kbabbitt> ... could use keyword or border width<br>
<kbabbitt> ... insetting outlines I filed a separate issue for<br>
<kbabbitt> ... box sizes for border widths<br>
<kbabbitt> ... e.g. make margin match border<br>
<kbabbitt> .. right now it needs to be manually snapped<br>
<kbabbitt> ... so use cases are at end of issue<br>
<fantasai> https://github.com/w3c/csswg-drafts/issues/3720#issuecomment-3637873605<br>
<kbabbitt> ... ways to do it are:<br>
<TabAtkins> yeah, my agenda+ was just to add env(hairline), based on issue discussion<br>
<kbabbitt> ... add an env(hairline), or border-round()<br>
<kbabbitt> ... that snaps things to pixels<br>
<kbabbitt> ... when you want something to snap to pixel grid, hairline env variable seems pretty useful<br>
<kbabbitt> ... would be a bit weirder to do it with border-round()<br>
<kbabbitt> ... so I have a slight preference for env var<br>
<kbabbitt> fantasai: hairline could be more than 1dppx depending on resolution<br>
<kbabbitt> ... I think being able to round to dppx is what you really want<br>
<kbabbitt> ... rounding to dppx and making sure it's at least 1 is slightly different<br>
<kbabbitt> ... what you want here is minimal width for a visible border width<br>
<kbabbitt> ... keyword might be more reasonable<br>
<emilio> I wonder if we can just extend the `round()` function with a couple keywords?<br>
<kbabbitt> TabAtkins: these reasons are why in the proposal I asked for new hairline value<br>
<kbabbitt> ... that solves the use case we're most concerned about, thin borders<br>
<emilio> q+<br>
<kbabbitt> ... does so without having to worry about current or future device resolutikons<br>
<kbabbitt> ... other use cases are capable of using this or can be solved in the future since they're more theoretical<br>
<kbabbitt> ... current use case of a minimal border is a real use case we should solve now<br>
<Rossen6> ack emilio<br>
<kbabbitt> emilio: agree that's the simplest thing<br>
<smfr> q+<br>
<kbabbitt> ... main concern is that now hairlies will always be 1dppx<br>
<kbabbitt> ... will people rely on that assumption somehow?<br>
<kbabbitt> ... another alternative might be extending round function to round to pixel grid<br>
<smfr> q-<br>
<kbabbitt> ... but that also seems kind of annoying<br>
<kbabbitt> ... agree env(hairline) is simplest and solves real issues<br>
<kbabbitt> +1 to env(hairline)<br>
<kbabbitt> fantasai: wanted to repeat emilio's concerns<br>
<kbabbitt> ... as a result I'd prefer hairline be a border-width keyword and added a pixel rounding function<br>
<kbabbitt> ... for use cases outside border-width<br>
<Rossen6> ack fantasai<br>
<kbabbitt> smfr: was going to ask about zooming but it was discussed in the issue, it's fine<br>
<kbabbitt> TabAtkins: there are other reasons to want to match the size of a box that's using env(hairline)<br>
<emilio> q+<br>
<kbabbitt> ... shouldn't require hacking things around e.g. transparent hairline border to match geometry<br>
<kbabbitt> ... we have several props that want to use it<br>
<kbabbitt> fantasai: those all take keywords, we'd just add to that set<br>
<kbabbitt> TabAtkins: it's still a width, a bit of geometry, that adds to size<br>
<kbabbitt> ... weird if that's the only way to access it<br>
<kbabbitt> ... env() flexibly lets us handle hairlines as width they are in other use cases<br>
<kbabbitt> fantasai: but that gets into, did you mean hairline or did you want to snap to border width?<br>
<kbabbitt> ... if they need to do matching they can do that in border and in other property<br>
<kbabbitt> ... hairline is applying some amount of judgment about ???<br>
<kbabbitt> ... good shorthand for various line props<br>
<kbabbitt> ... but for geometry, pixel rounding function would give more control<br>
<emilio> What if we do both `env(hairline)` vs `env(dpx)`?<br>
<kbabbitt> ... and won't have people using env(hairline) as env(1dppx)<br>
<kbabbitt> ... if goal is, round to dppx, give them that function and let them use it<br>
<kbabbitt> ... if they want box to be same size including border, that's what box-sizing is for<br>
<kbabbitt> TabAtkins: don't understand, cant use box-sizing to match one box to another<br>
<kbabbitt> fantasai: make them both box-sizing border-box and match them<br>
<kbabbitt> TabAtkins: might not be what they want<br>
<iank_> i'm concerned this restricts usage in box-shadow properties which people use for border type things<br>
<emilio> +1 to iank_<br>
<kbabbitt> TabAtkins: how do you animate from hairline to a fixed value, represent intermediates?<br>
<kbabbitt> fantasai: same as any other value<br>
<fantasai> if you're getting that funky, use the pixel-rounding function with an appropriate length<br>
<fantasai> s/other/other keyword/<br>
<kbabbitt> emilio: we have a rounding function, that rounding function can take lengths<br>
<kbabbitt> ... env(hairline) also allows rounding to hairline<br>
<kbabbitt> ... if concern is people using this for dppx, can we expose env(dppx)?<br>
<kbabbitt> ... then if folks want to round to that, use that as parameter for round()<br>
<kbabbitt> ... otherwise people are going to do that with hairline<br>
<kbabbitt> ... if you want to replicate what border rounding does, it's complicated<br>
<kbabbitt> TabAtkins: would love if we could solve these concerns in another issue and not block hairline on it<br>
<Rossen6> ack emilio<br>
<kbabbitt> emilio: agree<br>
<fantasai> round(<length>, dpx) or round(<length>, line-width)<br>
<kbabbitt> TabAtkins: as iank_ said in chat, other things not borders used in border like circumstances<br>
<kbabbitt> ... maybe we can solve those in other ways<br>
<kbabbitt> ... being restricted from those sorts of lengths over there is also sort of artificial<br>
<emilio> but you might wan to round to a multiple of dpx<br>
<kbabbitt> fantasai: by adding this you're encouraging authors to do things that isn't what they intend<br>
<kbabbitt> ... they'll use env(hairline) as dppx<br>
<kbabbitt> ... which is not what they intend<br>
<kbabbitt> ... on higher res displays it might be 2dppx<br>
<kbabbitt> ... box-shadow being hacked for border purposes is not a problem we need to solve with env() that could mistakenly be used elsewhere<br>
<kbabbitt> ... I think we should add a rounding function for this<br>
<florian> q+<br>
<kbabbitt> ... would solve a lot of the problems described here<br>
<emilio> q+<br>
<kbabbitt> ... for border width, hairline keyword solves that problem without encouraging authors to do things that could cause problems later<br>
<kbabbitt> TabAtkins: people using this for dppx and getting 2 inthe future is probably a good things<br>
<florian> q-<br>
<kbabbitt> ... people almost never mean actual dppx, they mean something small<br>
<kbabbitt> ... if there are issues in the future we can fix them in the future<br>
<kbabbitt> florian: concerned people will abuse this to get dppx<br>
<kbabbitt> ... people who think they want to use dppx and try to use e.g. 700dppx but it's not what they actually wanted<br>
<kbabbitt> ... seems risky to sneakily introduce a unit that looks like dppx but isn't that<br>
<emilio> FWIW I have used it to mean device pixels: https://searchfox.org/firefox-main/rev/5917a9f2af3294b27a325371c5c499e7dd9554fd/browser/themes/windows/browser.css#112, and someone else wants to round to a multiple of device pixels: https://searchfox.org/firefox-main/rev/5917a9f2af3294b27a325371c5c499e7dd9554fd/browser/themes/linux/browser.css#189<br>
<TabAtkins> big multiples of hairline are going to be *wildly* unpredictable.<br>
<kbabbitt> ... so I think I'm with fantasai<br>
<kbabbitt> emilio: agree people will use it to mean dppx<br>
<TabAtkins> anyone using that is footgunning themselves in the first place, they'll figure that tout immediately<br>
<kbabbitt> ... prototyped this in Firefox and ran into cases where you really want dppx<br>
<kbabbitt> ... but outcome if it being 2dppx is, maybe your font is slightly blurry, not the end of the world<br>
<kbabbitt> ... there are uses for rounding to multiples of 2dppx<br>
<dbaron> s/dppx/device pixels/<br>
<kbabbitt> ... as soon as you do that you have the same problem<br>
<kbabbitt> ... round min width 100dppx and you effectively have this value<br>
<kbabbitt> ... pragmatic thing to do is add hairline<br>
<kbabbitt> ... explicit dppx length is also useful<br>
<kbabbitt> ... fine also adding a keyword if you want<br>
<kbabbitt> ... hairline env var is maximially useful thing<br>
<dholbert> s/add hairline/add env(hairline)/<br>
<TabAtkins> round(Xpx, env(hairline)) is reasonable. It's not necessarily exact device pixels, but it's a multiple of device pixels and <= 1px, so that's still useful.<br>
<kbabbitt> ... don't think in future, it might mean 2dppx is a huge deal<br>
<TabAtkins> it'll do *just fine*<br>
<kbabbitt> fantasai: usability of this is not amazing<br>
<djmarland> I can definitely see calc(700 * env(hairline)) appearing in the wild. Massive footgun, but at least the presence of `env` is essentially saying "you don't know what this number is"<br>
<kbabbitt> ... if I want a border width that's this thick. need to know there's an env var and use it<br>
<kbabbitt> .. would make more sense to have thin | thick | medium | hairline as border width values directly<br>
<TabAtkins> totally fine with having a 'hairline' border-width keyword that resolves to env(hairline)<br>
<kbabbitt> ... if having added that and adding dppx rounding function, people still want env var, we can consider it<br>
<kbabbitt> ... these allow authors to directly express actual intention<br>
<emilio> q+<br>
<kbabbitt> ... env var is hacky<br>
<Rossen6> ack emilio<br>
<kbabbitt> emilio: agree, there may be use cases that are not representable with just those<br>
<kbabbitt> ... e.g. you have an abspos box, you need multiple of hairline to account for width<br>
<kbabbitt> fantasai: why?<br>
<kbabbitt> emilio: I found some use cases in Firefox codebase, can post to issue<br>
<kbabbitt> ... they're in IRC<br>
<djmarland> q+<br>
<kbabbitt> ... as soon as you want, let's round to even multiple of dppx<br>
<kbabbitt> ... you effectively need to provide some way of multiplying by that dppx or hairline value<br>
<kbabbitt> ... at that point you're just adding length with extra steps<br>
<kbabbitt> ... I think doing the simple thing that gets the thing done ... totally coool with keyword that resolves to pixel value<br>
<kbabbitt> ... same as writing border-width: 0.01px<br>
<kbabbitt> florian: different when you print, or on very high resolution device<br>
<kbabbitt> ... could be something thinner than hairline<br>
<kbabbitt> emilio: we want that to round to a hairline<br>
<kbabbitt> fantasai: I'm looking at what you linked, emilio, in Mozilla codebase<br>
<kbabbitt> ... talks about snapping to device pixels, not hairline<br>
<kbabbitt> emilio: agree<br>
<kbabbitt> fantasai: that's not a use case for env(hairline)<br>
<kbabbitt> djmarland: have a use case where you might want a margin<br>
<kbabbitt> ... you have filled in panels and a background and want background to show through<br>
<kbabbitt> ... use a margin to separate panels instead of border<br>
<kbabbitt> ... might want that to be hairline<br>
<kbabbitt> fantasai: won't be able to see background in that case, won't show through<br>
<kbabbitt> Rossen6: let's not discount use case just because you wouldn't do<br>
<TabAtkins> q+<br>
<kbabbitt> florian: is this theoretical or seen in the wild?<br>
<kbabbitt> Rossen6: i'm sure there are use case with tiny margins used similarly<br>
<kbabbitt> ... for hairline they don't exist because hairline doesn't exist<br>
<kbabbitt> florian: where this value will be used changes how we have it<br>
<kbabbitt> ... if there are use cases for extremely thin margins, we need it, if not we don't<br>
<emilio> Usage on padding: https://searchfox.org/firefox-main/source/browser/themes/shared/urlbar-searchbar.css#12<br>
<emilio> q+<br>
<Rossen6> ack djmarland<br>
<Rossen6> ack TabAtkins<br>
<kbabbitt> TabAtkins: I understand florian's point but I think it's supported<br>
<kbabbitt> ... people do non border things like box-shadow<br>
<kbabbitt> ... people use padding to show a little border behind something<br>
<kbabbitt> ... let existing background show in border like fashion<br>
<romain> I've worked on a site that needed the thinnest possible margins between grid items, this is definitely something that designers want<br>
<kbabbitt> ... we should not assume these use cases always want to be in pixels<br>
<emilio> So far I found: `background-size` / `font-size` / etc (for snapping), `padding` (to match borders)<br>
<kbabbitt> ... same sort of desire that leads to a hairline, just as much leads to thin but visible box-shadow, margin, padding, etc.<br>
<kbabbitt> ... let's not overgeneralize this and solve varying use cases in ways that continues to delay hairline use case<br>
<fantasai> emilio: Those first several shouldn't be using env(hairline)<br>
<kbabbitt> ... happy to add a border size keyword hairline to make it as easy as possible in border-width<br>
<fantasai> s/emilio:/emilio,<br>
<fantasai> emilio, they should use a rounding function<br>
<kbabbitt> ... and have that resolve to env(hairline) keyword<br>
<djmarland> +1 for the margin shorthand<br>
<kbabbitt> ... so you can use it in other properties<br>
<emilio> fantasai, agreed, they should use `env(dpx)` or so.<br>
<kbabbitt> ... so other cases that want matching size can be resolved on in the future separately<br>
<kbabbitt> ... this issue has been sitting around for a long time<br>
<emilio> fantasai, but hairline is still very useful and does the trick in the meantime :)<br>
<kbabbitt> ... proposal is env(hairline) value and hairline border size keyword<br>
<romain> q+<br>
<Rossen6> ack emilio<br>
<kbabbitt> emilio: did a quick look over Firefox codebase<br>
<kbabbitt> ... a lot of use cases I introduced myself<br>
<romain> q-<br>
<kbabbitt> ... they rely on hairline being dppx<br>
<kbabbitt> ... for padding and such to match borders<br>
<kbabbitt> ... agree with TabAtkins we should do the pragmatic thing<br>
<kbabbitt> ... found a need to round to dppx but agree it shouldn't block hairline<br>
<kbabbitt> ... we should file issues to figre out the snapping use case etc.<br>
<TabAtkins> happy to file the dppx/snapping issue after this call<br>
<florian> q+<br>
<djmarland> +1 on that<br>
<Rossen6> ack fantasai<br>
<kbabbitt> fantasai: fine with hairline keyword for border-width<br>
<emilio> q+<br>
<kbabbitt> ... would find it problematic to add env(hairline) without also giving people a way to do pixel snapping<br>
<kbabbitt> ... don't want to build bad habits around misusing hairline<br>
<kbabbitt> ... emilio demonstrated there are multiple places where it was wanted and had to hack around it<br>
<romain> +1 to shipping both around the same time<br>
<Rossen6> ack florian<br>
<kbabbitt> florian: would it be possible, instead of an env var, introduce it as a keyword anywhere that takes a length<br>
<emilio> Addition to the proposal would be `env(dpx)`, rounding to dev px is just `round(foo, env(dpx))` / `round(foo, 2 * env(dpx))`<br>
<kbabbitt> ... but can't do math with it<br>
<kbabbitt> ... is that a thing we can do?<br>
<kbabbitt> TabAtkins: not realistically<br>
<kbabbitt> ... every place that takes a length needs to worry about this keyword being a syntax clash somewhere<br>
<kbabbitt> ... probably not an issue now but could be in the future<br>
<kbabbitt> ... making it not calc() able would be weird restriction in grammar<br>
<kbabbitt> florian: concerned about introducing it as an env() when we haven't solved the things like it that aren't<br>
<Rossen6> ack emilio<br>
<kbabbitt> emilio: +1 on we probably need to make it calc()able<br>
<kbabbitt> ... wanting to match the size of something and multiplying hairline by 2 seems common<br>
<kbabbitt> ... different proposal to mitigate concerns<br>
<kbabbitt> ... what if we add env(hairline). hairline keyword, and env(dppx)<br>
<kbabbitt> florian: env(dppx) doesn't give snapping, need to snap position, not just size<br>
<kbabbitt> emilio: you cannot snap to screen space by definition, but use cases I showed don't need that<br>
<kbabbitt> ... need to snap size, browser can take care of that<br>
<kbabbitt> ... if you add env(dppx), you can snap to device pixels, which seems reasonable to me<br>
<fantasai> s/dppx/dpx/g<br>
<kbabbitt> florian: does not seem reasonable to me, even though there might be use cases, I've seen far more cases where people think they want it but don't<br>
<TabAtkins> +1 to florian, this is *the exact reason* I want to solve the dppx snapping separately, because it's problematic<br>
<kbabbitt> ... let's find out what people who want that unit are trying to solve and solve that<br>
<kbabbitt> emilio: env() is less likely to be misused than a unit<br>
<kbabbitt> florian: don't think it makes much difference<br>
<kbabbitt> fantasai: it does make some difference<br>
<TabAtkins> once again, the dppx use-cases that *arne't* reasonable to use hairlines for are far beyond the border use-case i'm trying to solve<br>
<kbabbitt> florian: a little, not enough<br>
<kbabbitt> fantasai: we all agree on adding hairline keyword to border-width<br>
<kbabbitt> ... we have some discussion on adding env(hairline) and/or env(dppx) and/or rounding function<br>
<kbabbitt> ... I suggest we resolve on hairline keyword for border-width now<br>
<kbabbitt> ... and open issue to investigate remaining bits of device pixel snapping<br>
<kbabbitt> ... and we can come back to env(hairline) once we have snapping worked out<br>
<kbabbitt> TabAtkins: are you opposed to env(hairline) ahead of us solving the dppx mapping case?<br>
<kbabbitt> fantasai: yes<br>
<kbabbitt> TabAtkins: annoying that I can't apply to padding but ok<br>
<kbabbitt> fantasai: if we can solve together I think it's okay as long as people are going to hack around it<br>
<kbabbitt> TabAtkins: not confident we can solve reasonably or in short amount of time<br>
<kbabbitt> ... there will be a gap between using hairline in border and elsewhere without script hacks<br>
<kbabbitt> ... don't like holding hairlines hostage on separate thing that won't obviate it<br>
<kbabbitt> fantasai: we're not holding it hostage, adding keyword<br>
<kbabbitt> TabAtkins: env(hairline) will not be replaced by dppx thing<br>
<kbabbitt> florian: I don't think we're proposing to reject env(hairline)<br>
<kbabbitt> ... there's a subset on which everyone agrees which is hairline keyword<br>
<kbabbitt> ... let's punt on the rest while agreeing on the hairline keyword<br>
<kbabbitt> ... see what's left after we have that<br>
<emilio> border-width hairline doesn't provide any real value over `0.01px` other than being easier to read the intent<br>
<emilio> q+<br>
<kbabbitt> ... agree we shouldn't decide to never do env(hairline), but doing other part seems reasonable<br>
<kbabbitt> TabAtkins: solving dppx rounding problem is hard<br>
<Rossen6> ack fantasai<br>
<Rossen6> ack emilio<br>
<kbabbitt> emilio: agree with TabAtkins<br>
<kbabbitt> ... concern of people hacking around pixel snapping using hairline doesnt seem enough of a practical concern to me<br>
<kbabbitt> ... worst case if you have massively high res display it will be blurry<br>
<TabAtkins> TabAtkins: This is killing env(hairline) by committee, I'm reasonably certain we *won't* solve dppx-rounding in any reasonable time-frame, maybe never, because it's hard and we've thought about it in the past<br>
<kbabbitt> ... we don't get locked into forcing hairline to being more than 1dppx<br>
<kbabbitt> ... if you specify border-width 0.01px that gets you a hairline<br>
<kbabbitt> fantasai: on computer screens<br>
<kbabbitt> florian: what if you print, line too thin to see?<br>
<kbabbitt> emilio: it does the same thing hairline would do<br>
<kbabbitt> fantasai: if the resolution of a printer is 600dpi, and you specify 0.01px, you should get an extremely thin line, per spec<br>
<kbabbitt> fantasai: maybe impls are flooring, but per spec you should get exactly that on high res device<br>
<kbabbitt> emilio: it basically kills the idea because ... ignoring printing, I don't think there's a problem with tiny width there<br>
<kbabbitt> ... but per spec there would be an issue<br>
<kbabbitt> ... use cases you cannot do now are those like, I want to match hairline width, valuable use cases<br>
<kbabbitt> ... not opposed to adding hairline, but env(hairline) realistically is useful, snapping pixels is hard<br>
<kbabbitt> ... even now, people use harder stuff to hack around it, read device pixel ratio and put it on a var in the root<br>
<kbabbitt> ... that's objectively worse<br>
<kbabbitt> ... would rather add env(hairline) and file another issue for dppx stuff<br>
<kbabbitt> ... woulde rather not block hairline on that<br>
<kbabbitt> fantasai: my position is same as before<br>
<Rossen6> ack fantasai<br>
<kbabbitt> ... we should try to solve problem correctly and avoid hacks<br>
<kbabbitt> ... if we agree on border hairline let's add that now<br>
<kbabbitt> ... and also look at adding device pixel rounding<br>
<kbabbitt> ... cases from emilio are device pixel rounding, not 2 dppx rounding<br>
<kbabbitt> emilio: there are some<br>
<kbabbitt> fantasai: most cases were not dppx rounding, let's enable what was intended<br>
<fantasai> s/were not dppx/were about dpx/<br>
<kbabbitt> florian: proposal is for the part we agree on<br>
<kbabbitt> ... can we make progress on that?<br>
<kbabbitt> TabAtkins: this is going to effectively kill any other possibility of grabbing length<br>
<kbabbitt> florian: why?<br>
<kbabbitt> TabAtkins: I don't think it's solvable in any reasonable time<br>
<kbabbitt> florian: not asking conditional, just delay<br>
<djmarland> Is the concern that the keyword can't be added without also exposing env(hairline) since it is an alias?<br>
<kbabbitt> TabAtkins: that's what fantasai was asking for, pair env(hairline) with solving dppx issue<br>
<kbabbitt> florian: don't think that's what was intended<br>
<fantasai> djmarland, no it's fine to add a keyword. It'll resolve to length.<br>
<kbabbitt> TabAtkins: next time we bring up env(hairline) we'll get an objection because we haven't solved dppx issue<br>
<kbabbitt> ... not willing to deal with things being cut that finely<br>
<kbabbitt> Rossen6: TabAtkins, you feel strongly about resolving both border value as well as env(), right?<br>
<kbabbitt> TabAtkins: yes<br>
<kbabbitt> Rossen6: that's perfectly fine<br>
<kbabbitt> ... I can see use cases for grid gutters to have hairline value as well<br>
<kbabbitt> ... we're at time, not hearing consensus<br>
<kbabbitt> ... hearing very strong desire to solve the border use case<br>
<kbabbitt> ... hear reasonable concerns and points about having it as an env() value as well<br>
<kbabbitt> florian; Rossen6, you also see use cases in grid gutters, that would be solved by fantasai's proposal<br>
<TabAtkins> what we hear is lots of use-cases for env(hairline) that are not borders<br>
<kbabbitt> florian: it would be a line width keyword<br>
<emilio> FWIW printing `data:text/html,<!doctype html><style>div { border: 0.01px solid black; width: 100px; height: 100px; }</style><div></div>` looks pretty fine here when printing<br>
<kbabbitt> ... usable in grid gap though not in shadow<br>
<kbabbitt> Rossen6: still what I'm hearing is TabAtkins is objecting to moving forward without having solved the env() case<br>
<kbabbitt> ... that is enough not to call a resolution just yet<br>
<kbabbitt> ... this was a very spirited discussion, will be captured in issue<br>
<dholbert> grid-gap is potentially bad, since I think its position is not pixel-snapped, so you might end up with a hairline-sized grid gutter that spans a pixel boundary (and looks like two light-gray pixels rather than a single white pixel)<br>
<kbabbitt> ... my proposal is to start with this issue next week<br>
<kbabbitt> ... try to pre-resolve in issue itself while it's still fresh and we'll go from there<br>
</details>
--
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/3720#issuecomment-3750909397 using your GitHub account
--
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 14 January 2026 18:03:15 UTC