| 16:24 | <devsnek> | Domenic: whats your compulsion behind wanting to use existing url infra |
| 16:26 | <devsnek> | for the std:x|y |
| 16:34 | <annevk> | devsnek: please keep it respectful |
| 16:42 | <devsnek> | annevk: er |
| 16:42 | <devsnek> | what did i do? |
| 16:42 | <devsnek> | i was just asking for his reasoning behind wanting to use existing url stuff |
| 16:43 | <annevk> | Using “compulsion” is not just asking |
| 16:43 | <devsnek> | sorry about the phrasing then |
| 16:43 | <devsnek> | i didn't intend for it to come across in that way |
| 17:13 | <Domenic> | devsnek: it's basically about simplicity. URLs are pretty good for locating resources. One might even say they're a universal way to do so. Why invent a new way to locate resources? Everyone thinks their specific resource type is so special it needs a new way of locating it, but I just don't see any advantage. |
| 17:13 | <devsnek> | Domenic: because its not just one resource |
| 17:14 | <Domenic> | devsnek: it definitely is... |
| 17:14 | <Domenic> | We don't somehow load two modules |
| 17:14 | <devsnek> | its either std:x or some url |
| 17:14 | <Domenic> | Maybe the ?fallback= syntax would make this clearer, interesting., |
| 17:14 | <Domenic> | Here's the analogy |
| 17:15 | <Domenic> | https://example.com/foo?fallback=bar returns the contents of https://example.com/foo if you're using a modern browser, or the contents of https://example.com/bar if you're using an old browser |
| 17:15 | <Domenic> | https://example.com/foo?fallback=bar is a great way of locating the resource |
| 17:15 | <Domenic> | The resource has different representations depending on your user agent |
| 17:15 | <Domenic> | But it's still a single resource |
| 17:15 | <devsnek> | well in the case of example.com |
| 17:15 | <devsnek> | it should just be a query param |
| 17:16 | <Domenic> | There are other identifiers for the same resource, only some of which work, depending on which UA you're using |
| 17:16 | <Domenic> | Yes, that's why I'm saying maybe this would be clearer for people if we did std:x?fallback=y |
| 17:16 | <Domenic> | But there's nothing magical about query params, besides convention |
| 17:16 | <devsnek> | std:x?fallback=y makes sense |
| 17:16 | <Domenic> | Maybe I should take my own advice and not invent something new and special though |
| 17:17 | <Domenic> | I think | as an abbreviate for ?fallback= is nice, but maybe it's too confusing |
| 17:17 | <Domenic> | URLs are supposed to be opaque in terms of how they map to resources, but some people really like attaching meanings to sigils like ?, and maybe I should just go along with that |
| 17:17 | <devsnek> | std:x?fallback=y feels good to me because uh |
| 17:18 | <devsnek> | std:x is just another thing you load |
| 17:18 | <devsnek> | and it could theoretically be handling import.meta.url however it wants |
| 17:18 | <devsnek> | even if that isn't what happens behind the scenes |
| 17:18 | <Domenic> | You understand though that this is just the decision of the server |
| 17:18 | <Domenic> | You could have example.com do https://example.com/foo|bar and do the exact same behavior |
| 17:18 | <devsnek> | wdym |
| 17:18 | <Domenic> | You can set up your server so that https://example.com/foo|bar returns the contents of https://example.com/foo if you're using a modern browser, or the contents of https://example.com/bar if you're using an old browser |
| 17:19 | <devsnek> | oh yeah |
| 17:19 | <Domenic> | It's just a random convention that sometimes people use ? instead of other sigils |
| 17:19 | <devsnek> | i see what you're saying now |
| 17:19 | <Domenic> | Yeah. But it does seem using the sigils people are used to would help. |
| 17:20 | <devsnek> | maybe i was also misunderstanding the proposal a bit |
| 17:20 | <devsnek> | i took it as a generic way to fallback between resources |
| 17:20 | <wanderview> | Domenic: have you considered being able to specify multiple std: URLs, or a some kind of matching function, and then only falling back if they all fail? |
| 17:20 | <Domenic> | wanderview: yeah that's definitely an important open issue. |
| 17:20 | <Domenic> | https://github.com/drufball/layered-apis/issues/5 |
| 17:21 | <wanderview> | I'm just thinking if the URLs end up containing things like "-v1", "-v2", etc... then people may want to call out specific versions or match any version, etc |
| 17:21 | <Domenic> | But overall I'm starting to feel like maybe we should remove this URL syntax and use package name maps instead... |
| 17:21 | <wanderview> | thanks |
| 17:21 | <devsnek> | package name maps as fallbacks |
| 17:21 | <devsnek> | or specifying the fallbacks |
| 17:21 | <devsnek> | sounds nice |
| 17:22 | <wanderview> | Domenic: oh, that issue is about multiple fallbacks... I was talking about multiple standard things in the browser |
| 17:22 | <Domenic> | wanderview: oh interesting! |
| 17:22 | <Domenic> | Well I guess it would still work? |
| 17:22 | <devsnek> | with a package name map |
| 17:22 | <Domenic> | std:x-v1|std:x-v2 |
| 17:22 | <devsnek> | could you do like src="https://mypollyfill"; |
| 17:22 | <devsnek> | and then in a package name map |
| 17:22 | <devsnek> | intercept that |
| 17:22 | <Domenic> | Yes!! |
| 17:23 | <wanderview> | Domenic: can you chain beyond that? std:x-v1|std:x-v2|https://fallback.com |
| 17:23 | <devsnek> | so older browsers get the polyfill |
| 17:23 | <Domenic> | wanderview: well basically issue #5 is suggesting that |
| 17:23 | <wanderview> | ok |
| 17:23 | <Domenic> | devsnek: yeah that's one of the two big problems a package name map would solve |
| 17:23 | <Domenic> | The std:x|y syntax only gives you fallbacks in browsers that support std:x|y |
| 17:23 | <Domenic> | Which is great in the future but hurts when trying to bootstrap the ecosystem |
| 17:23 | <devsnek> | tfw package name maps are lowkey the solution to every problem |
| 17:23 | <Domenic> | ( The other big problem is https://github.com/drufball/layered-apis/issues/10 ) |
| 17:25 | <devsnek> | hmm about number 10 |
| 17:25 | <devsnek> | lets say BigInt was behind std:bigint |
| 17:25 | <devsnek> | wouldn't it be wiser to do `import BigInt from 'std:bigint|x'` instead of `import 'std:bigint|x';` with attaching to global |
| 17:27 | <Domenic> | That's a whole separate issue |
| 17:27 | <Domenic> | But even if you did |
| 17:27 | <Domenic> | Imagine you then had two separate bigint polyfill instances floating around your pap |
| 17:27 | <Domenic> | instanceof wouldn't work, semantics might be slightly different, not good |
| 17:27 | <devsnek> | true |
| 17:28 | <Domenic> | Even without global side effects it's still not great |
| 17:29 | <devsnek> | i guess in that case enforcing fallbacks would make sense |
| 17:54 | <wanderview> | Domenic: wouldn't ?fallback= require URL encoding the fallback URL in the search param? |
| 17:54 | <Domenic> | Hmm, yeah, maybe :-/ |
| 17:54 | <wanderview> | whereas it was not clear to me that the URL would need to be encoded if it had special syntax like "|" |
| 17:55 | <wanderview> | Domenic: I'll add the question to the issue I guess |
| 18:34 | <domfarolino> | annevk: I’ve got something started for console’s formal warning reporting, I’ll get something up for review soon just heads up. |
| 18:34 | <domfarolino> | (I know it was mentioned on that DOM PR by jungkees ) |
| 18:51 | <annevk> | coool |
| 21:09 | <Domenic> | TabAtkins: status of https://github.com/tabatkins/highlighter/issues/5 ? |
| 21:12 | <TabAtkins> | Looking into it now. I can reproduce the issue. |
| 21:27 | <zewt> | download attribute still doesn't work properly? :| |
| 21:28 | <zewt> | (seems like browsers still only use it as the default filename if a link is downloaded, but don't actually cause the link to be downloaded by default) |