10:18
<Peter Jeschke>
Hey, just randomly dropping by because I'm looking at the URL standard and have some questions; is it fine to ask here or should I open an issue on the repo? :)
10:20
<annevk>
It's fine to ask here
10:31
<Peter Jeschke>

Alright!

  • The first thing I'm asking myself is how much I should focus on the WHATWG definition of a URL if I'm not a web developer. I just had some discussion about URIs in a completely different context and only learned today that the WHATWG standard kind of deprecates the term URI. Is this "deprecation" only meant in the context of web browsers or do you consider this to be for other environments as well?

  • The URL standard defines validation errors, but the implementations don't seem to expose them. Some of them also don't affect the parsed result, so it seems impossible to notice this. Should I, as a user, care about validation errors in any way?

  • The invalid-credentials validation error is raised when any credentials are included in the URL. I assume this is because credentials in URLs are just a bad idea, but is there any documented reasoning for having a validation error for credentials?

10:46
<annevk>
Peter Jeschke: 1) It impacts other environments as well as many environments want to consume web content and (broken) URLs are found in many places, including the Location header for instance. 2) They could be exposed in theory and I think some implementations might, but you're right that in general there's not much focus on them. They are there to warn people about inputs that might create interoperability issues. 3) That's the reason. There might be something in IETF-land about this, but absent that the validation error might be the only official documentation.
11:26
<Peter Jeschke>
Alright, thanks for your help :)
11:26
<Peter Jeschke>
And for all of your work in general!
12:20
<smaug>
annevk: I wonder if having 2 different kinds of agenda+ labels could work. This naming is obviously wrong, but agenda-minor-thing-or-pr+ and agenda-larger-topic-to-discuss+, and those large ones would be discussed earliest after a week since the label was set. That way the previous meeting could have already a list of larger topics for the next meeting.
12:23
<annevk>
I think that would help with certain scheduling issues, but I'm not sure it would help with the case I'm facing. Said wants to attend to discuss <img>.decode() but he can only attend at an American-friendly time. (This would suggest a nomination label for a particular time slot.)
13:11
<Noam Rosenthal>
annevk: I wonder if CSS method can help here, where the agenda+ list is bigger, and the chair curates a list for the meeting 2-3 days before, allowing people to say if they want issues to be bumped up or postponed if they can't attend that week etc. (* haven't discussed this with cwilso so I don't know if this creates a lot more work or if this would be of help)
13:15
<Noam Rosenthal>
I think it would help if agenda+ is added to topics by mon/tue latest... I often look at the list and it's usually empty on wednesday and gets filled shortly before the meeting, not leaving any time to review the issues prior to the call. using a call with ~20 people to say "people please look at this and that issue" is OK but not the most effective use of a weekly time slot
13:17
<Luke Warlow>
The CSS method I find to be almost broken though. Long standing issues just get bumped off anyway because something else comes up.
13:19
<dbaron>
Some of that is the chairs responding to statements about how urgent different issues are.
13:20
<dbaron>
Sometimes the longstanding issues don't have any particular urgency but other things come up where we have to decide soon or we'll be stuck with a behavior that's shipping.
13:21
<Noam Rosenthal>
I think the chairs try to balance between long standing and urgent issues. but IMO what's actually broken in CSS is that it's a giant WG covering too many issues
13:25
<Stephen Chenney>
What Noam said.
14:15
<Noam Rosenthal>
... and anyway, I'm not proposing to take the CSSWG process as is, but just the part where there is some talk about the agenda a few days before the meeting
20:27
<smaug>
hmm, there are no tests for !origin.isSameSite(anotherOriginObject) when origins are taken from platform objects, like window and (looks like WindowProxy doesn't have the algorithm to get origin) MessageEvent. Adding.