| 11:57 | <MikeSmith> | annevk: about the color-scheme thing, I will make a workaround for it right now |
| 11:58 | <MikeSmith> | but it’s unclear to me whether color-scheme is actually supported at all in any engine other than Blink |
| 11:59 | <MikeSmith> | and color-scheme is not documented at all in MDN, and there is zero data about it in BCD |
| 11:59 | <annevk> | MikeSmith: I'm not advocating for validator support btw, it seems fine to block on all that becoming more clear |
| 12:00 | <MikeSmith> | yeah I will just special-case it for now until we can otherwise get something better figured out |
| 12:01 | <andreubotella> | or we could switch off the bikeshed style-colors boilerplate |
| 12:01 | <MikeSmith> | andreubotella: that might be a better solution, if that is doable |
| 12:01 | <MikeSmith> | I don’t know which would be quicker to propogate |
| 12:16 | <MikeSmith> | annevk: I think you may have already pointed this out in another issue comment, but rightly I would hope Bikeshed would not be embedding any CSS styles into WHATWG specs at all |
| 12:16 | <MikeSmith> | any styles should be in external stylesheets |
| 12:17 | <MikeSmith> | or at least we should have an option for not having them embedded in the HTML source in style elements |
| 12:17 | <annevk> | MikeSmith: it already does (including JavaScript) for dfn |
| 12:18 | <annevk> | MikeSmith: I guess this new thing adds more |
| 12:18 | <andreubotella> | I'm not very familiar with the bikeshed code, but from a quick look it seems it wouldn't be hard to add a `Boilerplate: styles no` option |
| 12:18 | <annevk> | MikeSmith: it even seems to emit style attributes |
| 12:18 | <MikeSmith> | oh style attributes too |
| 12:19 | <MikeSmith> | well the HTML spec requires the content of style elements and attributes to be conforming |
| 12:19 | <MikeSmith> | but the HTML spec does not require content of external stylesheets to be conforming |
| 12:22 | <andreubotella> | but an unknown property wouldn't make a stylesheet non-conforming |
| 12:22 | <MikeSmith> | in fact it does |
| 12:23 | <MikeSmith> | an unknown property is indistinguisable from a misspelled property |
| 12:23 | <MikeSmith> | so asserting that unknown properties should be ignored is the same as saying that misspelled properties should be ignored |
| 12:24 | <annevk> | One problem with moving the dfn style sheets is that HTML has its own dfn styles, as per https://github.com/whatwg/whatwg.org/commit/3374e69f013e5939abc5f3fffaae50bb6eaf0bd3 |
| 12:24 | <andreubotella> | HTML links to the css-syntax definition of conformant style sheet, and it talks about the syntax and the individual grammars of each feature |
| 12:24 | <annevk> | And I don't know if what Bikeshed does is completely unique |
| 12:24 | <MikeSmith> | I would hope that the value to developers of reporting font-colro as an error is clear |
| 12:25 | <andreubotella> | yeah, for reporting, sure |
| 12:25 | <annevk> | If what Bikeshed does is completely unique, it's probably easy-ish to just put it in standard.css and HTML will just ignore it |
| 12:25 | <MikeSmith> | annevk: yeah I know we have an opne issue about that |
| 12:25 | <annevk> | (until we solve HTML) |
| 12:25 | <annevk> | I'm not sure if this color-space stuff does anything beyond modifying the dfn stuff |
| 12:29 | <annevk> | Looking at the output this seems to be a lot of additional styles unrelated to dfn |
| 12:30 | <andreubotella> | We can probably switch off style-colors and style-darkmode now, and then see about moving the rest of styles |
| 12:37 | <annevk> | So "Boilerplate: style-colors off" seems to work, but "Boilerplate: style-darkmode off" does nothing? |
| 12:37 | <annevk> | andreubotella: yeah that seems good, but I'm not getting it to work (https://tabatkins.github.io/bikeshed/ also doesn't document all of this) |
| 13:00 | <andreubotella> | annevk, TabAtkins: that sounds like a bug |
| 13:53 | <MikeSmith> | annevk: https://github.com/whatwg/encoding/pull/230 is all green |
| 13:54 | <MikeSmith> | re-run any other pending CI builds for other repos/branches, and they should all turn green too |
| 13:55 | <annevk> | MikeSmith: thanks, though hopefully we can sort out the other thing soon too, since I realize I now approved a somewhat-large increase in file size too |
| 14:29 | <andreubotella> | annevk: https://github.com/tabatkins/bikeshed/blob/master/bikeshed/boilerplate.py#L236 |
| 14:29 | <andreubotella> | it looks like style-darkmode is special-cased because it has to be output after the rest of style blocks |
| 14:29 | <TabAtkins> | Yeah I think I messed that up, apologies. Will fix in a bit, making breakfast now |
| 14:29 | <andreubotella> | and it doesn't seem to be checking the boilerplate maetadata |
| 14:29 | <andreubotella> | ok |
| 14:57 | <MikeSmith> | annevk: increatst in file size? |
| 15:44 | <TabAtkins> | All right, fix pushed for `Boilerplate: darkmode no` to work again |
| 15:50 | <Domenic> | annevk: is request's current URL = response URL for all HTTP(S) fetches? |
| 16:00 | <annevk> | Domenic: can a HTTP(S) fetch involve a service worker? |
| 16:00 | <Domenic> | annevk: yes, I guess so. |
| 16:01 | <Domenic> | annevk: the context here is https://github.com/WICG/portals/pull/247, in particular whether https://github.com/WICG/portals/pull/247/commits/bde960589245799aa4fa18d2d5e38d052bd9efe8 is the right change |
| 16:02 | <annevk> | Domenic: I think in that case there can be a difference as the response's URL list would be non-empty |
| 16:02 | <annevk> | Domenic: though note that navigation deals with this differently from subresources |
| 16:02 | <Domenic> | Yeah this is navigation, hmm. |
| 16:03 | <Domenic> | I've been staring at Fetch/navigation but not staring at service workers |
| 16:04 | <annevk> | Domenic: for navigation we use the request URL for authority but we also have a same origin limitation on service workers (or some such) |
| 16:05 | <Domenic> | That makes sense. Indeed, Jeremy noticed that all of navigation was using request URL so urged me to switch |
| 16:05 | <Domenic> | It seems like the service worker won't be able to change what we care about here, which is the HTTP(S)-scheme-ness of the URL in question. |