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:
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 @import s |
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 rel s, 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:
But then later has this non-normative note that says this:
So, that note seems to conflict with the normative requirements — by implying that using multiple (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? |
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 |
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
|
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? |
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 ? |