| 10:23 | <bkardell (holidays until july 5)> | Yeah, i said in the whatnot meeting (the context was the time proposals) that i disagree with that as stated but i do believe that speculative polyfilling definitely needs to take more care than i think we've given it. It was a topic thats been discussed a long time and i still don't think its often done carefully. |
| 13:16 | <Noam Rosenthal> | Ah the reservation from minutes were about "creating enablers for polyfills should not be a standards goal". This is different from "polyfilling is undesirable" |
| 13:19 | <Noam Rosenthal> | I do resonate with that - adding some lower level knob to support polyfilling can lead to some quirky corners in the web platform that have a poor maintenance cost/usefulness benefit balance. |
| 13:22 | <bkardell (holidays until july 5)> | I don't think its a simple binary do or don't |
| 13:23 | <Noam Rosenthal> | Agreed. As usual, it's a trade off. |
| 13:27 | <annevk> | jmdyck: I'm not sure I like that better. https://annevankesteren.nl/temp/url-components.html (Please ignore some of the obvious errors with the lines being drawn on top.) |
| 13:30 | <annevk> | But maybe it's also because 1/2 remind me of railroad games / tube maps. |
| 13:36 | <Stephen> | Putting my old web developer metrics hat on, my take on this is the possibility of polyfills only comes up when considering adoption of features because polyfills can reduce the need for all browsers to implement something in a timely fashion. I agree with Noam's assessment that making it easier to polyfill is a non-goal. I guess another use case is demonstrating need for some feature if the polyfill version is very popular. |
| 13:42 | <jmdyck> | I'd make the 'path' column wide enough so that 'isbn:etc' doesn't overlap the 'port' and 'query' columns (or at least doesn't overlap the 'port' vertical line), but yeah, 3+4 are close to what I had in mind. |
| 13:42 | <Stephen> | Inserting space into the URLs tells my brain the various pieces are independent and not a single string. Maybe you could add something to tie them together, but then the diagram is more confusing. So I too like the slightly Art Deco curved line version. |
| 13:42 | <annevk> | I would much rather people write a library that demonstrates the need for something as opposed to something that attempts to mimic the exact API shape of a proposal while simultaneously trampling all over our design flexibility. You want to enable people using the |
| 13:42 | <jmdyck> | Would the URLs be first presented in non-spaced-out text form? |
| 13:43 | <annevk> | The idea would be for these to be standalone figures. Location TBD. To address https://github.com/whatwg/url/issues/337 |
| 13:44 | <Stephen> | I see "library that implements some feature" and "polyfill" as synonymous, but I can also see that fails to capture everything. |
| 13:44 | <jmdyck> | (The curved corners in 1+2 are an improvement over the version posted above, though.) |
| 13:46 | <annevk> | When I hear polyfill I think specifically of things that attempt to occupy the exact same API space and tend to cause issues, such as we had recently with Scoped Custom Element Registries. We ended up with a much worse standardized API because of that. |
| 13:48 | <Stephen> | That I agree is a rather serious problem. |
| 14:28 | <bkardell (holidays until july 5)> |
|
| 15:56 | <Noam Rosenthal> | Yea I usually prefer the ponyfill approach for this reason |