02:17
<sideshowbarker>
jarhar: The http://wpt.live/html/semantics/forms/the-button-element/button-submit-remove-children.html test times out in WebKit because (as far as I can see) the load event never fires at the iframe that’s the target of the form action in that test. Any clue as to why the event never fires?
02:24
<jarhar>
hmm, the fact that im not seeing a 404 page in the iframe makes me wonder if webkit legitimately fails this test
02:25
<jarhar>
i wrote this test in response to one of many regression bugs that were filed when i did a refactor to form submission
02:26
<jarhar>
i wrote it here: https://chromium-review.googlesource.com/c/chromium/src/+/1983547
02:26
<sideshowbarker>
I see
02:27
<jarhar>
lol this was really complicated, but i suppose you could try implementing this patch in webkit to see if it makes the test pass
02:29
<sideshowbarker>
Yeah I'll try it I guess
02:32
<sideshowbarker>
This is the only complete fail in WebKit in https://wpt.fyi/results/html/semantics/forms/the-button-element — so, would be nice to make it all go green
02:33
<sideshowbarker>
that said, there is also https://wpt.fyi/results/html/semantics/forms/the-button-element/button-click-submits.html, which has a test that fails both in Blink and WebKit (but not in Gecko)
03:29
<sideshowbarker>
OK, ported that patch but in WebKit, still timing out anyway.
03:30
<sideshowbarker>
so I guess for now I’ll put this test on the back burner and look at it more again some time later
06:53
<annevk>
Domenic: can you review the encoding-parse a URL refactor?
06:53
<annevk>
Would be nice to unblock some of the follow-up work
07:35
<Noam Rosenthal>
zcorpan: regarding the media/supports thing, I felt it was a bit inconsistent that in CSS those are separate @ rules and in the link element they are both folded into the media attribute. perhaps there's a more elegant solution?
07:36
<zcorpan>
Noam Rosenthal: perhaps. We want it to fail closed, so that the stylesheet isn't applied in legacy browsers. (But maybe the importance of this property is debatable, since it's temporary and we have faster update cycles now compared to, say, a decade ago)
07:37
<Noam Rosenthal>
... I would expect it to be in a separate cssSupports attribute, and deal with legacy in a way that's a bit more consistent with the meaning of the attributes
07:39
<zcorpan>
Ways to fail closed other than stuffing it in media (and still work in head): change rel to something else (seems not so elegant long term), use type attribute (should ideally be possible to not have to write text/css since we made that optional)
07:41
<zcorpan>
Maybe we can use a new attribute and in the transition period people can use media="not all" and change that with script (or use other rel/type to avoid the download)
07:41
<Noam Rosenthal>

For now there is a convenient way to do this:

<style>
   @import url("...") supports(...);
</style>

I wonder if making the media attribute inconsistent is worth it

07:42
<zcorpan>
good point
07:42
<Noam Rosenthal>
I didn't quite get if adding this as a link provides anything material
07:42
<zcorpan>
It might be loaded earlier by the speculative parser. Not sure if all browsers speculatively load @imports
07:43
<Noam Rosenthal>
they don't in chrome AFAIK
07:45
<Noam Rosenthal>
I think adding a rel=css or rel=style which can take layer and cssSupports attributes is not that bad, and when everyone supports layers we can make them aliases of each other
07:46
<Noam Rosenthal>
I mean it's not that pretty but it's at least straightforward in a way
07:47
<zcorpan>
I don't like adding alias rels, but I'm warming up to just adding supports attribute and let it fail open in legacy. Use style element or script hack if you need to fail closed
07:48
<zcorpan>
The linked stylesheet can repeat the @supports too if you can control what it contains
07:49
<Noam Rosenthal>
yea that's probably safer, you use the supports attribute as an optimization to avoid loading the link at all rather than as a way to not apply the CSS
07:55
<sideshowbarker>

At https://html.spec.whatwg.org/multipage/semantics.html#standard-metadata-names:meta-color-scheme, the spec normatively states this:

There must not be more than one meta element with its name attribute value set to an ASCII case-insensitive match for color-scheme per document.

But then later has this non-normative note that says this:

Because these rules check successive elements until they find a match, an author can provide multiple such values to handle fallback for legacy user agents. Opposite to how CSS fallback works for properties, the multiple meta elements needs to be arranged with the legacy values after the newer values.

So, that note seems to conflict with the normative requirements — by implying that using multiple <meta name=color-scheme> elements is OK (or even sort of a best practice).

(There’s also a grammar error in the note.)

08:01
<sideshowbarker>
The HTML spec text doesn’t explicitly state that the color-scheme value can be an ordered list of keywords — instead it just says, “The value must be a string that matches the syntax for the CSS 'color-scheme' property value” — where color-scheme is a link/reference to the normative CSS definition for the property value (which says the value is “the keyword normal, or an ordered list of specified color scheme keywords”)
08:02
<sideshowbarker>

So, maybe that note about using using multiple elements was written without an understanding that the value could be a list of keywords rather than a single keyword?

Regardless, the note seems wrong.

08:09
<zcorpan>
Noam Rosenthal: commented in https://github.com/whatwg/html/issues/7540#issuecomment-1725024079
08:10
<zcorpan>
sideshowbarker: if you use a list and you use an unsupported keyword, isn't the whole list ignored?
08:12
<sideshowbarker>
sideshowbarker: if you use a list and you use an unsupported keyword, isn't the whole list ignored?
Not sure. I think it depends on what the CSS parser does and what the CSS spec requires UAs to do
08:12
<zcorpan>
oh no, the grammar allows custom-ident
08:17
<zcorpan>
so parsing would only fail if you use e.g. a function. which seems unlikely to be added, so I think we can just remove the note
08:18
<sideshowbarker>
so parsing would only fail if you use e.g. a function. which seems unlikely to be added, so I think we can just remove the note
OK, I reckon I’ll open a PR
08:19
<zcorpan>
maybe even the processing could stop after the first meta element even if it fails, but also, if the current processing is implemented already, not worth it to shake
08:23
<sideshowbarker>
yeah
08:43
<Noam Rosenthal>
zcorpan: another option for backwards compat if we really want the link element, is to have a new attribute like cssConditions or so that can accept a @media ... @supports style syntax and overrides media. So you use media="not all" like you suggested before, and in browsers that supports this attribute you'd get the media+supports check (plus whatever check we allow in the future)
08:46
<zcorpan>
Noam Rosenthal: interesting idea. personally I prefer the html attribute syntax
08:47
<zcorpan>

also would be surprising that media is ignored here:

<link rel=stylesheet cssconditions="supports(at-rule(@scope))" media="print">
08:47
<Noam Rosenthal>
we can choose ignore it only if cssconditions contains media
08:48
<zcorpan>
seems more convoluted to explain than supports=""
08:49
<zcorpan>
plus more typing
08:50
<zcorpan>
(didn't know starting a line with + made a bullet list)
08:50
<Noam Rosenthal>
sure, but also has some pros as it lets us use the link element earlier
08:50
<Noam Rosenthal>
not sure if it's worth it but thought I'd try to bring an alternative
08:52
<zcorpan>
Maybe we can solve that socially. have a comment in the spec for import conditions to also change the link element
08:56
<Noam Rosenthal>
I don't follow :)
09:10
<zcorpan>
Noam Rosenthal: you said " it lets us use the link element earlier", but that's only true if @import gains a new feature first, instead of the link element gaining that feature first, or they gain it at the same time
09:11
<Noam Rosenthal>
zcorpan: gotcha, yes
10:05
<Domenic>
Domenic: can you review the encoding-parse a URL refactor?
I'm on vacation through 2023-09-26
11:33
<annevk>
Domenic: ah, thanks for letting me know, I'll ask another editor as I addressed all your feedback
11:34
<annevk>
Domenic: and I guess you already let me know, hope the cities are enjoyable :-)
11:36
<annevk>
zcorpan: foolip: interested in reviewing https://github.com/whatwg/html/pull/9719?
11:40
<foolip>
annevk: I can
12:04
<annevk>
miketaylr: curious rename
12:19
<jarhar>
after porting the patch, did the iframe show anything at all like a 404 page?
13:05
<sideshowbarker>
I did not
13:06
<sideshowbarker>
It’s possible that I didn’t fully port it correctly — but it’s a relatively simple change, so I feel like I got it right
13:06
<sideshowbarker>
if I had muffed it in some, I’d expect that it’d probably cause a crash
13:06
<sideshowbarker>
well, or not compile at all to begin with
13:08
<miketaylr>
lol yeah, TIL that /nick changes are global, but there's a /myroomnick for per-name shenanigans 🙈
13:49
<karlcow>
I'm pretty sure he was impersonating the visual effects technician, Mitchell Baker from Kraken: Tentacles of the Deep from 2006.
21:16
<Dominic Farolino>
When ORB blocks a response, you can't even reach for the internal response and get at it, right? Is the response blocked from even reaching that stage annevk ?