| 06:04 | <yhirano__> | annevk: yt? |
| 06:06 | <yhirano__> | annevk: I would appreciate if you could review https://github.com/w3c/web-platform-tests/pull/7671. |
| 06:54 | <annevk> | yhirano__: I suggest asking JakeA; I'm technically on leave and only plan to work on a couple things during that time |
| 06:54 | <annevk> | yhirano__: I'll have more time starting next month and back to full-time December most likely |
| 06:55 | <yhirano__> | annevk: thanks! |
| 07:16 | <JakeA> | annevk: yhirano__: I'm on leave until Wednesday, but will catch up then |
| 07:17 | <yhirano__> | JakeA: thank you. |
| 13:22 | <mounir> | annevk: hey, about user activation delegation, I was wondering if you could have a look about my latest comments |
| 13:23 | <nox> | annevk, Domenic: You both are so patient. |
| 13:24 | <annevk> | mounir: heya, I can have a look |
| 13:25 | <annevk> | nox: I try, it's not worth it to get upset |
| 13:25 | <Domenic> | annevk sets a good example for me |
| 13:26 | <nox> | Domenic: Actually, |
| 13:26 | <nox> | when I'm on whatwg, |
| 13:26 | <nox> | my first thought is "if I get angry, will that make annevk's and Domenic's job harder having to clean up my shit", |
| 13:26 | <nox> | and then I calm myself down. :P |
| 13:28 | <annevk> | keep it up 😊 |
| 13:30 | <nox> | "And it worries me greatly that you apparently haven't even read the RFCs while trying to replace them." Oh my |
| 13:31 | <gsnedders> | nox: where is this? |
| 13:33 | <nox> | gsnedders: https://github.com/whatwg/url/issues/118#issuecomment-338206323 |
| 13:33 | <nox> | gsnedders: Not much value reading it, except for Friday afternoon popcorning. |
| 13:38 | <gsnedders> | nox: oh I got that from the quote ;P |
| 13:39 | <mounir> | annevk: thanks :) |
| 13:39 | <nox> | gsnedders: Here is something more interesting: https://twitter.com/goldengateblond/status/920785613003087872 |
| 13:40 | <mounir> | Domenic, annevk: I'm hoping we can resolve than name problem given that it's one of the two open issues |
| 13:40 | <mounir> | annevk: no update on #8? |
| 13:40 | <mounir> | ie. https://github.com/WICG/gesture-delegation/issues/8 |
| 13:44 | <annevk> | mounir: patience |
| 13:44 | <annevk> | 😃 |
| 13:45 | <mounir> | annevk: just wanted to make sure you have it in your rader :) |
| 13:45 | <mounir> | annevk: thanks for your responsiveness though :) |
| 13:46 | <justJanne> | annevk: to avoid spamming the issue tracker further: it's just hat the RFCs are used basically everywhere, and your claim of obsoleting and replacing them has made huge waves everywhere. |
| 13:47 | <justJanne> | Especially because the WHATWG is known for being — due to its nature — biased towards the web, over other fields of IT |
| 13:47 | <justJanne> | And WHATWG replacing a spec that basically has unlimited scope and is used everywhere and was defined over many years by stakeholders from all fields, |
| 13:48 | <justJanne> | With a spec that has had very little external inout and publicity before it got standardized, |
| 13:48 | <justJanne> | Rubs a lot of people the wrong way, due to the perceived arrogance of that statement |
| 13:48 | <annevk> | justJanne: did you verify that it's actually used everywhere by testing the implementations? E.g., as is clear from that issue curl doesn't conform to it |
| 13:49 | <justJanne> | And it doesn't make working with URLs easier when we now have different standards with different scopes that both claim to be universal |
| 13:49 | <annevk> | justJanne: I don't think most "RFC implementations" actually conform, despite claims to the contrary |
| 13:49 | <justJanne> | annevk: the issue isn't with the leniency of an implementation, but the strictness. |
| 13:49 | <justJanne> | Most "RFC implementations" will be less strict than the RFC |
| 13:50 | <annevk> | justJanne: okay, could you explain to me how those are different? If you're more lenient you're less strict, no? |
| 13:50 | <justJanne> | Exactly, |
| 13:50 | <annevk> | justJanne: so how is it with either leniency or strictness? Aren't they the same? |
| 13:50 | <justJanne> | No, like, |
| 13:51 | <nox> | It's easy to have a RFC that is "used basically everywhere" when that RFC is very underspecified, vague, and special cased by pretty much everyone in different ways. |
| 13:51 | <justJanne> | nox: the RFC defines a very strict form of the URL that is always valid. |
| 13:51 | <annevk> | Well, the RFC is not vague or underspecified, it's just not compatible with deployed content and major implementations |
| 13:51 | <justJanne> | See appendix A |
| 13:51 | <nox> | Yes, from which everyone deviates. |
| 13:51 | <nox> | In different ways. |
| 13:51 | <justJanne> | Not really. |
| 13:52 | <justJanne> | As long as your URL matches the ABNF from appendix A, it will work everywhere |
| 13:52 | <justJanne> | The problem is that the WHATWG spec allows URls that the RFC spec doesn't. |
| 13:52 | <justJanne> | So people start using these URLs |
| 13:52 | <annevk> | justJanne: no we don't, as I already pointed out |
| 13:52 | <justJanne> | And RFC parsers suddenly all interpret them differently |
| 13:52 | <annevk> | justJanne: the URL Standard has a very strict definition of what's a valid URL, which matches that of IRIs |
| 13:53 | <justJanne> | annevk: you don't allow them, but you still define a way how to handle them (and all implementors of whatwg specs handle them without even a warning) |
| 13:53 | <nox> | The URL parser from the URL Standard will accept >2 slashes *BECAUSE* the real world has URLs with >2 slashes, |
| 13:53 | <nox> | let's not reverse causality here. |
| 13:53 | <justJanne> | nox: that's a problem, though |
| 13:53 | <annevk> | justJanne: sure, because that's required from implementations that want to consume arbitrary content |
| 13:53 | <justJanne> | Because in the reality, urls > 2 slashes will break at some place |
| 13:53 | <justJanne> | Because most implementations don't accept them |
| 13:53 | <nox> | The problem is writing a spec-compliant parser and not actually being able to work in real world URLs. |
| 13:53 | <justJanne> | Well, no. |
| 13:54 | <annevk> | justJanne: I think I see where you're coming from, but what you're advocating is anti-competitive |
| 13:54 | <justJanne> | nox: say you type a URL into an IRC client. |
| 13:54 | <nox> | And? |
| 13:54 | <justJanne> | What do you expect will the client of another user interpret? |
| 13:54 | <nox> | Texgt. |
| 13:54 | <annevk> | justJanne: it basically disadvantages new URL software over existing URL software that deals with existing content |
| 13:54 | <justJanne> | Will they use the RFC parser? |
| 13:54 | <justJanne> | Will they use the whatwg parser? |
| 13:54 | <nox> | I have no idea why you are focused on URLs in plain text. |
| 13:55 | <annevk> | justJanne: which is very bad from the perspective of keeping the web a healthy competitive ecosystem |
| 13:55 | <justJanne> | I write IRC clients that support autolinking |
| 13:55 | <justJanne> | And I get frequently bug reports. |
| 13:55 | <nox> | Yes because the RFCs are bad. |
| 13:55 | <justJanne> | Both in the direction of "this link works in other clients, but not in yours" |
| 13:55 | <nox> | Cf. annevk's example of trailing dots. |
| 13:55 | <justJanne> | And in "this link works in your client, but not others" |
| 13:55 | <justJanne> | I get both of these reports. |
| 13:56 | <nox> | So? |
| 13:56 | <justJanne> | And it's getting a lot worse recently |
| 13:56 | <justJanne> | Because web-based clients startvusing the whatwg url parser |
| 13:56 | <justJanne> | And as result, they deviate from all other clients |
| 13:56 | <justJanne> | And other software. |
| 13:56 | <nox> | I had linkify issues in 2000 already, before the WHATWG URL Standard was a thing. |
| 13:57 | <justJanne> | And as result, users copy-paste URLs that are increasingly broken |
| 13:57 | <nox> | Not sure how that's an argument against or for that standard. |
| 13:57 | <nox> | "broken" |
| 13:57 | <annevk> | justJanne: do you have examples? I think it would be nice if there was a decent text-to-URL specification, but nobody has written one yet |
| 13:57 | <annevk> | justJanne: hmm, that can't really happen |
| 13:57 | <nox> | I remember lots of issues with parens in URLs, for example. |
| 13:57 | <annevk> | justJanne: at the point URLs are exposed to users they're already normalized |
| 13:57 | <annevk> | justJanne: so e.g. a space would be converted to %20 at that point |
| 13:58 | <justJanne> | nox: ' is tbe most annoying part |
| 13:58 | <annevk> | justJanne: so maybe that's a different problem |
| 13:58 | <justJanne> | annevk: they're not always normalized the same way |
| 13:58 | <annevk> | justJanne: across browsers? |
| 13:58 | <justJanne> | I've seen browsers normalize ' away, or leave it i. |
| 13:58 | <justJanne> | *in |
| 13:59 | <annevk> | justJanne: sure, that's what we're trying to fix, in part (although again, the address bar is somewhat out of this, but also shouldn't really violate the RFC as far as I know) |
| 13:59 | <justJanne> | Well, the problem is also that URLs aren't always normalized |
| 13:59 | <justJanne> | Users copy-paste URLs from other sources, too. |
| 13:59 | <annevk> | justJanne: if you run into issues like this feel free to file them against whatwg/url and we can figure out how to best solve them |
| 14:00 | <annevk> | justJanne: I'd love concrete feedback like that |
| 14:00 | <justJanne> | And if a browser accepts them, every other software has to accept them, too |
| 14:00 | <annevk> | So what do you think about the example I gave? |
| 14:00 | <annevk> | https://example.com. |
| 14:01 | <annevk> | Is the trailing dot part of the URL or not? |
| 14:01 | <justJanne> | That's the worst example you could pick. |
| 14:01 | <gsnedders> | How much of this is down to what the browser exposes in the address bar or "copy link" or similar UI pieces? Because neither the RFC nor the WHATWG spec define behaviour there. |
| 14:01 | <annevk> | Edge cases is what standards are all about |
| 14:01 | <justJanne> | That's not an edge case. |
| 14:01 | <justJanne> | example.com evaluates to example.com. due to DNS resolution |
| 14:02 | <annevk> | gsnedders: it sounds like copying into the address bar vs copying into IRC client from a random source is also problematic |
| 14:02 | <justJanne> | They are identical domajns |
| 14:02 | <justJanne> | And as result, identical URLs |
| 14:02 | <annevk> | justJanne: that really depends on your local DNS configuration |
| 14:02 | <justJanne> | Nope |
| 14:02 | <annevk> | justJanne: yes it does |
| 14:02 | <justJanne> | That is the very definition of the DNS standard. |
| 14:02 | <justJanne> | nowadays |
| 14:02 | <annevk> | justJanne: example.com might be short for example.com.mycorp.internal |
| 14:02 | <justJanne> | Because every browser does DNS resolution wrong. |
| 14:02 | <justJanne> | annevk: yes, exactly. |
| 14:03 | <justJanne> | Except, browsers ignore that. |
| 14:03 | <annevk> | justJanne: so it's not at all identical to example.com. |
| 14:03 | <justJanne> | And then are surprised that example.com gets a cert for example.com.internal.corp |
| 14:03 | <justJanne> | Browsers today only work if a relative domain resolves to the same as an absolute domain |
| 14:03 | <annevk> | That doesn't relate to DNS resolution though |
| 14:03 | <annevk> | That's how certificates work |
| 14:04 | <justJanne> | Although some webservers, about 2%, refuse to allow relative domains |
| 14:04 | <justJanne> | whatwg.org. is broken, for example |
| 14:04 | <justJanne> | google.com. and my own sites work |
| 14:04 | <annevk> | We could probably fix that |
| 14:04 | <justJanne> | As nginx, haproxy, GCP, AWS, CloudFlare, IIS, Apache implement this correctly, |
| 14:04 | <justJanne> | I assume you are using traefik or caddy |
| 14:05 | <justJanne> | Edge cases. |
| 14:05 | <annevk> | https://github.com/whatwg/whatwg.org/issues/100 |
| 14:05 | <justJanne> | And almost every edge case I find that breaks things is when some web developers suddenly think that reinventing the wheel is a good idea. |
| 14:06 | <justJanne> | Including reinventing URL standards. |
| 14:06 | <annevk> | You haven't really addressed my feedback on that your approach is anti-competitive |
| 14:06 | <justJanne> | That's not a problem. |
| 14:06 | <annevk> | It makes it harder to write a new browser if browsers have to reverse engineer each other |
| 14:06 | <justJanne> | And they don't have to. |
| 14:07 | <justJanne> | The long term goal is increasing strictness. |
| 14:07 | <justJanne> | Over the past decades, we went from ignoring certificate errors to TLS chain validation, to dropping SHA1 certs, to HSTS and HPKP, all increasing strictness. In many other parts, the same happened |
| 14:08 | <gsnedders> | They have to if they want any success of in the market. We've from time to time had browsers that have followed specs more strictly than others and ultimately failed to get marketshare in part becaues of sites not working. |
| 14:08 | <justJanne> | Increasing strictness improves interoperability, and allows new vendors to easier comepte |
| 14:08 | <justJanne> | *compete |
| 14:09 | <justJanne> | gsnedders: and yet increasing strictness in the TLS parts hasn't harmed marketshare at all. |
| 14:09 | <justJanne> | Nor did dropping flash piece by piece. |
| 14:09 | <annevk> | I don't think we managed to deprecate quite as much outside TLS |
| 14:09 | <justJanne> | Nor addons. |
| 14:09 | <annevk> | That's a rather unusual case |
| 14:10 | <justJanne> | Dropping HTML5 apis for pages not loaded via TLS (geolocation, etc) |
| 14:10 | <justJanne> | By now it's more than a dozen APIs that got dropped |
| 14:10 | <justJanne> | Increasing strictness is possible. |
| 14:10 | <justJanne> | And it reduces the complexity of developing a web browser. |
| 14:11 | <justJanne> | Which in turn improves interoperability, and makes it easier to compete |
| 14:11 | <annevk> | Euh, not really |
| 14:11 | <annevk> | Restricting a feature to a secure context doesn't simplify it |
| 14:11 | <gsnedders> | The things that have been dropped are mostly things where security or privacy concerns make it easier to justify to end users breaking sites they currently use, whereas things like parsing where a significant percentage of content doesn't match any strict subset is much harder to justify to users. |
| 14:12 | <Domenic> | Increasing strictness does not inherently improve interoperability. |
| 14:12 | <annevk> | But it's also vastly different from changing the syntax of something |
| 14:12 | <Domenic> | What improves interoperability is coordinated movement toward a goal. |
| 14:12 | <justJanne> | Domenic: but you're not doing that either. |
| 14:12 | <justJanne> | URLs are used everywhere |
| 14:12 | <gsnedders> | Restricting a feature to a secure context increases complexity given you now have more forks in your code that depend on whether the document was loaded over a secure context. |
| 14:12 | <annevk> | Indeed |
| 14:12 | <Domenic> | We definitely are; we've made great strides in URL unification across browsers, Node.js, Rust, Go, etc. |
| 14:12 | <justJanne> | Whatwg isn't coordinating with most stakeholders outside of browsing on that. |
| 14:13 | <Domenic> | I've laid out a path for improving interoperability that also increases strictness at https://github.com/whatwg/url/issues/118#issuecomment-218323801 |
| 14:13 | <justJanne> | Yes, great. Rust and Go are both written by browser vendors. |
| 14:13 | <Domenic> | But nobody has started working on it. |
| 14:13 | <annevk> | justJanne: you still haven't answered my question about who else you need us to reach out to |
| 14:13 | <justJanne> | And node.js literally uses a browser JS engine |
| 14:13 | <justJanne> | That's still at zero external stakeholders. |
| 14:13 | <gsnedders> | The browser JS engine doesn't include any URL parser…? |
| 14:13 | <justJanne> | It does nowadays actually |
| 14:13 | <annevk> | Yeah, pretty sure they wrote their own URL parser |
| 14:14 | <annevk> | justJanne: no it doesn't |
| 14:14 | <justJanne> | The standard specifies a JS URL interface, and parser. |
| 14:14 | <justJanne> | The URL object's API is defined in the standard, |
| 14:14 | <annevk> | justJanne: no browser implements that in the JS engine |
| 14:14 | <gsnedders> | And Go is a very different part of Google to anything web facing. |
| 14:14 | <justJanne> | And how it should parse it. |
| 14:14 | <annevk> | justJanne: different layer of the system, just like it's a different layer in Node.js |
| 14:14 | <gsnedders> | justJanne: It doesn't appear in ECMA-262, and isn't implemented in any browser JS VM. There's a DOM URL object that browsers implement, but that's a host object implemented outwith the JS VM. |
| 14:15 | <gsnedders> | justJanne: JS VMs implement very, very little that isn't in ECMA-262 |
| 14:15 | <justJanne> | so, did you ever check what other RFCs reference the URL RFCs, and discussed with those what the deprecation of the URL RFC would mean? |
| 14:16 | <justJanne> | If you say that replacement of a widely used standard is a goal, I'd expect that you'd have made a study determining the impact of this, and determining who would be affected. |
| 14:16 | <annevk> | justJanne: in most cases there's not much impact as far as I can tell |
| 14:16 | <justJanne> | Or at least some kind of discovery |
| 14:16 | <annevk> | justJanne: RFCs that build upon URLs build upon the data model |
| 14:16 | <justJanne> | Little impact yet, many of these effects ripple down over years. |
| 14:17 | <annevk> | justJanne: there's one RFC that tries to modify the syntax, but that's a very controversial one |
| 14:17 | <justJanne> | annevk: many also build upon the syntax. |
| 14:17 | <justJanne> | For example, by saying "... Shall be a URI as defined in RFC ..." |
| 14:17 | <justJanne> | For these, minor changes in the URL syntax might lead to changes in how their parser works |
| 14:18 | <justJanne> | And if users come to expect more lenient URL parsing due to browsers, that might ripple down. |
| 14:18 | <annevk> | justJanne: sure, I don't see that as a problem |
| 14:18 | <justJanne> | Did you determine which standards, languages and libraries do this, and might be affected by this? |
| 14:19 | <annevk> | justJanne: every library that implements URLs is in some sense affected already |
| 14:19 | <justJanne> | Good. So you know who you'd have to ask before publishing and finishing the spec. |
| 14:19 | <annevk> | justJanne: the moment someone tries to use it to scrape web content that library will find itself in the position where it has to figure out how to deal with U+0020 in a URL |
| 14:20 | <justJanne> | Everyone that ever parses URLs, from any content, anywhere. |
| 14:20 | <annevk> | justJanne: I would expect those people to read uri⊙wo and have seen the various requests for feedback |
| 14:20 | <annevk> | justJanne: and indeed there has been some of that |
| 14:20 | <annevk> | justJanne: more would be great, but I suspect they're all strapped for time too and rather not look at their URL parser too often |
| 14:21 | <justJanne> | Correct. |
| 14:21 | <justJanne> | So did you make an effort to enumerate and contact such projects and standards? |
| 14:21 | <justJanne> | Before standardizing your spec, ideally? |
| 14:21 | <annevk> | This issue was raised repeatedly with the IETF back in 2011 or so or maybe even earlier |
| 14:21 | <annevk> | I'm sure they're all aware |
| 14:22 | <justJanne> | I'll ask again, did you try to enumerate and contact them? |
| 14:22 | <annevk> | It's just that nobody really wanted to work on it within the IETF so it went elsewhere |
| 14:22 | <justJanne> | Because that sounds like a no. |
| 14:23 | <annevk> | For sure it's a no, I'm happy with incremental adoption |
| 14:23 | <annevk> | And I think there's been enough outreach to the various standardization places around URLs that exist |
| 14:23 | <justJanne> | It sounds to me like you tried obsoleting and replacing a stabdard without even determining who would be affected by this, |
| 14:23 | <justJanne> | Or trying to contact them. |
| 14:24 | <annevk> | If that's what you take away from the above, that's your prerogative |
| 14:24 | <Domenic> | One of the wonderful things about standards is that they are used by many people across the community |
| 14:24 | <justJanne> | Because most projects that deal with this never even heard of your spec, and those that did, mostly because of the huge outrage that was on HN when your spec was already finished and people discovered what happened. |
| 14:24 | <Domenic> | Not all of them, indeed the majority of them, are not known to the authors |
| 14:24 | <Domenic> | Certainly when we make a change to, e.g., HTML, we don't contact every site that uses HTML! |
| 14:24 | <justJanne> | Correct. |
| 14:24 | <justJanne> | But in industry standards, this is expected. |
| 14:25 | <justJanne> | If you'd redefine the size of ISO/EN/DIN A4 paper, you certainly would have to first contact every manufacturer of paper, of paper producing machines, cutters, orinters, and co. |
| 14:25 | <annevk> | HTML is not an industry standard? |
| 14:25 | <justJanne> | And that's what you'd do. |
| 14:25 | <justJanne> | *printers |
| 14:25 | <annevk> | Is JavaScript an industry standard? |
| 14:25 | <Domenic> | Hah, we definitely don't contact all users of JavaScript when making changes to the JS spec. |
| 14:25 | <justJanne> | They're standards in an entirely different way. |
| 14:26 | <Domenic> | I don't find this line of reasoning that you need to contact all users of a spec when you change it convincing at all. |
| 14:26 | <justJanne> | They're expected to change frequently, vague, |
| 14:26 | <justJanne> | etc. |
| 14:26 | <annevk> | o_O |
| 14:26 | <Domenic> | Can you cite a vague part of the JS spec? |
| 14:26 | <justJanne> | The URL spec is used in standards that are required by law in some jurisdictions |
| 14:27 | <justJanne> | That's where this really becomes a different situation |
| 14:27 | <Domenic> | So are HTML and JS |
| 14:27 | <justJanne> | There's jurisdictions where the law requires for certain situations a certain standard, which requires some oarts to be serialized using the URL RFC |
| 14:28 | <justJanne> | When a serialization format is defined in laws, and the underlying spec starts to change, that has a lot different implications |
| 14:28 | <annevk> | Yeah that goes for most standards |
| 14:28 | <annevk> | And yet somehow they all get to change and laws adapt |
| 14:28 | <justJanne> | That's your mindset? |
| 14:28 | <justJanne> | Break the world? |
| 14:29 | <justJanne> | We don't want to make URLs strict to avoid breaking some hobbyists blog, but breaking legsl definitions is fine? |
| 14:29 | <annevk> | That seems like hyperbole |
| 14:29 | <justJanne> | Well, that's what I read out of "somehow they all get laws to adapt" |
| 14:30 | <Domenic> | I'd love to hear more about how the WHATWG has broken some country's legal codes. That is an amount of power I never knew we had. |
| 14:30 | <justJanne> | Which sounds like breaking someone's blog was given more consideration with this spec than downstream specs and legal definitions. |
| 14:30 | <Domenic> | What crimes can I commit now, in what jurisdictions? |
| 14:30 | <annevk> | Domenic: I'd hope they file an issue |
| 14:31 | <justJanne> | Probably nothing, but the standardized APIs some banks have to provide might now not work anymore. |
| 14:31 | <annevk> | justJanne: if you could stop it with the straw mans that'd be appreciated |
| 14:31 | <Domenic> | I'd love to hear how changing a document on whatwg.org broke bank APIs |
| 14:31 | <Domenic> | concrete examples are, I think, more helpful than strawpersons. |
| 14:32 | <justJanne> | I haven't yet fully read the HBCI standard yet, it's 800 pages of german text, written in prose, defining a SOAP api |
| 14:32 | <justJanne> | So I can't link it right now |
| 14:32 | <annevk> | justJanne: first you claim we have a failed standard and now you claim we break the world |
| 14:32 | <annevk> | justJanne: it comes across a little nutty |
| 14:33 | <annevk> | justJanne: I'd love to work with you on interoperability issues you hit |
| 14:33 | <justJanne> | annevk: well, I'm saying that maybe your goals are defined wrongly. |
| 14:33 | <annevk> | justJanne: both with respect to your IRC client and with respect to any laws |
| 14:33 | <justJanne> | If you define your goals as replacing a globalky used standard, |
| 14:33 | <justJanne> | Then either you do break the world, |
| 14:33 | <annevk> | justJanne: but I think I'll restrict it to that from now on |
| 14:33 | <justJanne> | Or, if you don't break the world, |
| 14:33 | <justJanne> | You've failed. |
| 14:33 | <annevk> | justJanne: as we're not making progress here |
| 14:33 | <justJanne> | annevk: maybe just make the introduction of the spec a little less universal? |
| 14:34 | <justJanne> | Maybe just write defining URLs in the context of ...? |
| 14:34 | <justJanne> | If you write obsoleting every other URL spec, that has some kind of arrogance that comes across a bit nutty. |
| 14:36 | <annevk> | I don't want to leave any room for systems to think they need two different URL parsers, that way lies madness |
| 14:37 | <Domenic> | Yeah, I agree with annevk, the most productive way forward is to open individual issues on interoperability problems or ways in which we have broken the legal code of specific countries, with details; trying to deal with these strawpersons is not helpful without concrete issues. |
| 14:39 | <justJanne> | Okay, that's an interesting solution, but okay |
| 14:40 | <justJanne> | Domenic: the basic problem, though, is the sheer arrogance of redefining such a widely used standard without even determining whom it might affect. This is the farthest reaching change afaik the WHATWG has ever done. |
| 14:41 | <justJanne> | This is going to get real fun, dealing with broken URLs everywhere. |
| 14:42 | <justJanne> | I hate it already. |
| 14:45 | <justJanne> | annevk: direct, concrete question: could the changed node.js, rust or go URL APIs potentially serialize a URL, that an RFC-compliant parser can not parse? |
| 14:46 | <annevk> | justJanne: yeah, something like http://test/?%test could be serialized as is |
| 14:47 | <justJanne> | That's a potential issue then, isn't it, if one client serializes content with such a library, and another endpoint tries to deserialize it with an RFC parser? |
| 14:48 | <annevk> | justJanne: yeah, it might be worth going through those kind of differences and see what we can accomplish |
| 14:48 | <justJanne> | I'll try and find examples of standards using this. |
| 14:48 | <annevk> | justJanne: I suspect there's a couple like that, but % is definitely the easiest one (and I think long interoperable across browsers unfortunately) |
| 14:49 | <Domenic> | which brings us back to https://github.com/whatwg/url/issues/118#issuecomment-218323801 :) |
| 14:49 | <justJanne> | I know that OpenID Connect defines endpoints by a json at a specified point that contains the endpoints, potentially including queries, as URL |
| 14:49 | <justJanne> | And that there are OIDC clients in Java, and identity providers written in node.js, |
| 14:50 | <justJanne> | Both using the language's URL subsystem for serialization/deserialization |
| 14:50 | <justJanne> | I'll try to build an example that leads to issues |
| 14:51 | <justJanne> | I also know that the FinTS banking API does the same for endpoints, but in XML, but I think all servers there are stil using the RFC serialization |
| 14:52 | <justJanne> | Domenic: the problem is that these things should have happened before publishing the spec |
| 14:52 | <justJanne> | So the people that might be affected could have a voice in defining yhe spec |
| 14:52 | <annevk> | This was already a problem with or without this spec |
| 14:52 | <annevk> | This spec just puts it in the sunlight, making it more visible and maybe possible to fix |
| 14:52 | <justJanne> | By now it might end up either breaking the web, or breaking the rest of tech that relies on URLs, if we have incompatible standards |
| 14:53 | <justJanne> | annevk: the whole point of a spec is to define an interoperable formst that is guaranteed to be supported by anyone and everyone for decades. |
| 14:53 | <annevk> | Lots of straw manning again justJanne |
| 14:53 | <justJanne> | annevk: well, that's the potential worst case scenario |
| 17:14 | <TabAtkins> | jgraham, gsnedders, other people interested in WPT stuff: https://github.com/tabatkins/bikeshed/issues/1116 is my plan for adding inline test annotations to Bikeshed. Review and comments welcome! |
| 17:16 | <nox> | There are a lot of websites out there that don't work anymore if you put a dot after the hostname. |
| 17:16 | <nox> | And that's not really considered a bug AFAIK. |
| 17:20 | <jgraham> | TabAtkins: Oh, interesting idea. It cleanly solves a lot of problems I think. It will be interesting to see if it works :) |
| 17:21 | <jgraham> | Uh, imagine I had a broad enough vocabulary not to use interesting twice in two sentences. |
| 17:23 | gsnedders | will look shortly |
| 17:25 | <jgraham> | Imagine if I could count to three |
| 17:26 | <TabAtkins> | That'd be the day. |
| 17:26 | gsnedders | is having one of those days where he feels motivated to bother reporting minor hate crime |
| 17:27 | <gsnedders> | (I'm totally fine, don't worry!) |
| 18:24 | <justJanne> | nox: less than 2% of the alexa top million |
| 18:24 | <justJanne> | nox: And that’s out of spec |
| 18:24 | <nox> | 2% is a damn lot. |
| 18:25 | <justJanne> | That’s their problem |
| 18:25 | <justJanne> | I use .s at the end by default |
| 18:25 | <justJanne> | if that doesn’t work with sites, users can file bugs with the sites |
| 18:25 | <justJanne> | Or I file bugs with the sites and their webservers |
| 18:25 | <justJanne> | although caddy refuses to support absolute DNS names to this day |
| 18:26 | <justJanne> | generally this should be handled by web browsers, and they should simply always resolve the absolute name and send the relative hostname, |
| 18:26 | <justJanne> | but it’s easier to change laws than to change webbrowsers, as browser devs are the most stubborn people there are |
| 18:29 | <justJanne> | nox: also, 2% is nothing. Google Chrome dropped SHA1 just a year after 19.5% of Alexa top million sites still used it |
| 18:29 | <nox> | Because that was for security reasons. |
| 18:29 | <justJanne> | That changes nothing. |
| 18:29 | <nox> | Chrome doesn't chrome Web features that have no security implications even at 0.01% usage. |
| 18:30 | <justJanne> | It shows it is possible. |
| 18:30 | <nox> | s/chrome/drop/ hah |
| 18:30 | <justJanne> | it doesn’t? That’s interesting, because it has done that previously |
| 18:30 | <justJanne> | and Google does the reverse, Google today runs major products that don’t work at all on up to 30% of browsers. |
| 18:31 | <justJanne> | Including Google Earth and Google Allo Web |
| 18:31 | <nox> | That's unrelated. |
| 18:31 | <justJanne> | And Google dropped other features previously too at far higher usage |
| 18:31 | <justJanne> | such as allowing JS to start audio/video playback |
| 18:31 | <justJanne> | which had no security impact |
| 18:32 | <nox> | How is that related? |
| 18:32 | <justJanne> | It was a functionality dropped from a browser, |
| 18:32 | <justJanne> | which was used by many sites, |
| 18:32 | <justJanne> | without security implications |
| 18:32 | <justJanne> | which broke user experience on many sites |
| 18:32 | <nox> | Yeah and users didn't like that. |
| 18:33 | <justJanne> | And yet it happened |
| 18:33 | <justJanne> | and was forced through, to this date |
| 18:33 | <nox> | On the other hand, users don't like the browser exploding when a redirection to http:///blabla fails. |
| 18:33 | <nox> | What's the benefit for the end user to reject such redirections? |
| 18:33 | <justJanne> | Long-term benefits for the web? |
| 18:34 | <Domenic> | What benefits? |
| 18:34 | <justJanne> | By having less of a clusterf**k? |
| 18:34 | <Domenic> | See topic |
| 18:35 | <justJanne> | I mean, why do many of the recent web standards exist? Many exist to improve reliability of the sites that are written, and to reduce edge cases. |
| 18:35 | <justJanne> | reducing edge cases is often mentioned as goal for specific changes, and it should be reason enough to do non-destructive changes |
| 18:37 | <nox> | You can't reduce edge cases of old features without breaking a lot of websites that will most probably never get fixed. |
| 18:37 | <justJanne> | That was why the W3C back in the day introduced versioning, so that newer sites could have less edge cases to deal with, but compatibility with old sites could be kept. |
| 18:38 | <nox> | That didn't go very well, did it? |
| 18:38 | <justJanne> | It worked everywhere else. |
| 18:39 | <justJanne> | Changing standards to reduce edge cases takes time, but it certainly is possible. |
| 18:40 | <justJanne> | I’m not sure why you think that your standardization effort won’t be able to do so, when even the metric system managed to replace all those tiny different versions over decades. |
| 18:40 | <nox> | Well clearly it wasn't working for the Web, the W3C spec of HTML was mostly useless for vendors. |
| 18:40 | <nox> | I don't see how that's related to the metric system. |
| 18:40 | <Domenic> | Yep, it's certainly possible. See the concrete plan at https://github.com/whatwg/url/issues/118#issuecomment-218323801 and get working on it if you're interested! |
| 18:41 | <justJanne> | The WHATWG specs have the opposite issue, nox |
| 18:41 | <justJanne> | they’re written almost exclusively for implementors of user agents, and not for people trying to generate input |
| 18:41 | <nox> | The WHATWG specs drop things when they can get dropped. |
| 18:41 | <nox> | And they don't change for no reason once something has reached convergence. |
| 18:42 | <justJanne> | They’re descriptivist, yes. |
| 18:42 | <nox> | Authors contribute to the spec too. |
| 18:42 | <justJanne> | But standards should be prescriptivist. |
| 18:43 | <justJanne> | The only descriptivist standards outside of WHATWG that ever got popular are the Office Open XML standards, and they’re just as much of a clusterf**k |
| 18:43 | <nox> | Well, it did get popular, right? |
| 18:43 | <TabAtkins> | (CSS has quite a lot of descriptivist stuff in its specs, recognizing what happens after-the-fact and adjusting the spec to match.) |
| 18:44 | <justJanne> | nox: yes, the .docx formats got popular, but that was before the standard, |
| 18:44 | <nox> | I mean the Web. |
| 18:44 | <justJanne> | Well, the WHATWG standards are closely resembling the MS Office Open XML standard story |
| 18:44 | <nox> | How so? |
| 18:45 | <justJanne> | Well, both got popular before standardization, the standards are just descriptions of the 1-3 largest implementations' behaviour, and they're impossible to implement for a new vendor |
| 18:45 | <nox> | And how does people make a new browser if there is absolutely no document that actually represents the state of art of the real world? |
| 18:45 | <TabAtkins> | (For a big recent one, see the Tables spec.) |
| 18:46 | <justJanne> | Standards aren’t generally written like that, nox |
| 18:46 | <nox> | How is having no spec at all, or a spec that doesn't work for real websites, be able to let anyone make a new browser? |
| 18:46 | <justJanne> | standards are written as a spec that authors adhere to if they want theirs to work everywhere |
| 18:46 | <nox> | So what do we do about existing websites? |
| 18:46 | <justJanne> | Existing websites support the spec, or stop working |
| 18:46 | <justJanne> | my A4 printer also can’t load letter. |
| 18:47 | <justJanne> | even though lots of companies might still use US letter paper. |
| 18:47 | <nox> | Sounds like a great plan. |
| 18:47 | <justJanne> | it’s how most standards are done |
| 18:47 | <justJanne> | When socket standards are changed, you buy new plugs. |
| 18:48 | <justJanne> | Almost every standard is written first, then implemented, and authors write in adherence to the spec – or produce paper in adherence to it, or plugs, or even build monitor holders – and the other side also builds towards that spec |
| 18:48 | <nox> | Sockets are created by a way smaller number of people than web pages. |
| 18:48 | <nox> | That applies to most other standards in existence. |
| 18:48 | <justJanne> | And? |
| 18:48 | <justJanne> | Every standard drops what exists before. |
| 18:49 | <justJanne> | Most standards even drop significant amount of existing technology |
| 18:49 | <nox> | And never has something on that scale be dropped. |
| 18:49 | <justJanne> | Yes it has. |
| 18:49 | <justJanne> | When metric units were introduced |
| 18:49 | <justJanne> | and everything had to be remeasured, or redesigned |
| 18:49 | <nox> | There are way less people making physical rules and whatever than there are people making Web pages. |
| 18:49 | <justJanne> | It’s not about making rulers. |
| 18:50 | <justJanne> | when metric units were introduced, everything had to change – from your grandmas recipes to your shoe sizes |
| 18:50 | <justJanne> | (as often products in the new system were only available in slightly different sizes than before) |
| 18:50 | <justJanne> | and yet, it worked. |
| 18:51 | <nox> | Switching to the metric system doesn't break my old grandma recipe. |
| 18:51 | <nox> | I don't even know my foot size in centimetres. |
| 18:51 | <justJanne> | It doesn’t? Okay, what’s 2 1/3rd cups in metric? |
| 18:51 | <nox> | I can look it up. |
| 18:51 | <justJanne> | Correct. |
| 18:51 | <justJanne> | There is a new standard, and a published system for converting the legacy into the new system. |
| 18:52 | <nox> | End user can't look up that his redirection failed because there were 3 slashes. |
| 18:52 | <justJanne> | No, but that’s not an issue. |
| 18:52 | <nox> | It is. |
| 18:52 | <justJanne> | You can define a new spec, |
| 18:52 | <justJanne> | which all new sites should adhere to, |
| 18:52 | <justJanne> | and a translation for old ones |
| 18:52 | <nox> | What's the definition of the old ones? |
| 18:52 | <nox> | How do you get authors to update, given you know the great majority of them won't? |
| 18:53 | <justJanne> | Well, I have a translation table for metric units that were in my country replaced 2 centuries ago |
| 18:53 | <justJanne> | nox: show a visible error, or worse, in developer mode? |
| 18:53 | <nox> | What? |
| 18:53 | <justJanne> | What what? |
| 18:53 | <nox> | Why would the user use your browser then, instead of staying on the older one where the website continues to work? |
| 18:54 | <justJanne> | nox: the sites continue to work, |
| 18:54 | <nox> | No they don't, they show a visible error. |
| 18:54 | <justJanne> | in developer mode |
| 18:54 | <justJanne> | as I specified |
| 18:54 | <nox> | So when do you actually reject the 3 slashes URL? |
| 18:54 | <justJanne> | which would be for example visible in beta/canary versions, or with dev tools open |
| 18:54 | <justJanne> | You reject 3 slashes whenever you feel like it. |
| 18:54 | <justJanne> | that’s up to implementors. |
| 18:54 | <nox> | So never, right. |
| 18:55 | <justJanne> | That’s your choice to make. |
| 18:55 | <nox> | So what's the point of the strict separate standard? |
| 18:55 | <justJanne> | Some deprecate such things quite quickly |
| 18:55 | <nox> | That sounds like XHTML and nobody cared. |
| 18:55 | <justJanne> | Google’s Android manages to deprecate API changes within of 1 year. |
| 18:55 | <nox> | How is that related? |
| 18:55 | <nox> | There are way fewer people making Android apps than there are people making Web pages. |
| 18:56 | <justJanne> | Yet it’s the closest there is. |
| 18:56 | <justJanne> | In terms of people affected. |
| 18:56 | <nox> | Not even close in terms of who many people need to act upon the deprecation. |
| 18:56 | <justJanne> | And Google doesn’t drop APIs when 2% of people use them on Android |
| 18:56 | <justJanne> | or 5% |
| 18:56 | <justJanne> | Google drops APIs even when 100% of people rely on them on Android. |
| 18:56 | <nox> | And they won't under a way lower percentage for Web features. |
| 18:56 | <justJanne> | And that’s a problem. |
| 18:57 | <justJanne> | Because this way, the web will forever be stuck where it is today. |
| 18:57 | <nox> | We are going in circles so let's just stop, I guess. |
| 18:57 | <justJanne> | The web is going in circles, too. |
| 18:57 | <justJanne> | you need to deprecate things someday, the only question is when. |
| 18:58 | <nox> | When the time is right, that already happened and will continue to happen in the future. |
| 18:58 | <justJanne> | mhm |
| 19:01 | <justJanne> | nox: actually, I found another good example. If there is something like a #whatwg-offtopic, I’d love to continue to discuss it there. |
| 19:06 | <justJanne> | (the example would be changing languages by committee, as is happening all the time) |