| 08:32 | <annevk> | smaug____: so I wrote a test and Chrome does in fact adjust the slot when the content attribute is removed |
| 09:02 | <annevk> | smaug____: I'll change the spec a bit more I suppose |
| 10:29 | <smaug____> | thanks |
| 16:28 | <jgraham> | Domenic: Your CI failures are a missing : at the end of the list of keys to filter (I tried to comment on the PR, but GitHub 500'd) |
| 16:28 | <Domenic> | jgraham: ah, thank you! |
| 18:40 | <Domenic> | jgraham: https://github.com/web-platform-tests/wpt/pull/21705 should be fixed now |
| 18:54 | <jgraham> | Domenic: Approved, but I think the RFC should land first |
| 18:54 | <Domenic> | jgraham: ah OK. I don't have permissions to do that; what's the process? |
| 18:57 | <jgraham> | I've just done it; I think everything checked out |
| 18:57 | <jgraham> | So feel free to merge the PR now |
| 18:57 | <Domenic> | \o/ Thanks for all your help! |
| 21:22 | <tomasino> | hey all, wondering about the goals of the URL living standard as it applies to specific protocols and this project. On the one hand there's a lot of language on the site that indicates it's meant to replace the RFCs and be the end-all-be-all standard. On the other hand it seems like it is narrowly focused on the needs of web browsers. The relatively recent removal of gopher mapping to port 70 is an |
| 21:22 | <tomasino> | example. Is there a definite goal in one direction vs the other? |
| 21:23 | <tomasino> | special schemes are now limited to just ftp, file, http(s), and ws(s). That limitation really only makes sense in context of projects like Chrome. There's so many other valid URLs that have RFC defined ports. |
| 21:24 | <tomasino> | anyway, don't want to start any arguments. just looking for clarification. "The URL Standard" vs "The URL Standard for modern web browsers" |
| 21:44 | <TabAtkins> | Speaking for Anne & co, so take my words with a grain of salt, but: URL Standard is aimed at browsers. By implication, it's also aimed at anything that wants to interoperate with browsers, which is most URL-consuming things. But it intentionally does not want to complicate its model to deal with things that aren't relevant to browsers. |
| 21:44 | <TabAtkins> | It *does* want to be a replacement for the RFCs *for browsers* (and the things that want to interoperate with browsers). |
| 21:51 | <tomasino> | thanks. That's the way my understanding was leaning as well. I know some other software projects that lean heavily on the work done by whatwg and it'll be good to be able to make that clarification with them when it's not browser related |