| 00:05 | <littledan> | ryzokuken (back friday): https://github.com/tc39/tc39.github.io/pull/303 |
| 00:07 | <ryzokuken (back friday)> | Oh, nice |
| 00:07 | <ryzokuken (back friday)> | nicolo-ribaudo: thanks, will merge asap after the prettier fix |
| 00:08 | <littledan> | re Date.parse, that was already attempted, and was blocked (by the chrome team as i recall) |
| 00:09 | <littledan> | I think browsers would be willing to make changes if it resolved this ongoing compatibility issue; that proposal required browsers to make changes while giving up on solving that problem. |
| 00:10 | <littledan> | (At least, this is what Domenic said at the time while he was agreeing with me on the block, IIRC) |
| 00:12 | <littledan> | Lots of other poorly-specified formats with significant compatibility issues had their parsing standardized at some much later point, e.g., HTML itself. Date.parse would be doable, but it's also understandable if an individual person doesn't want to take on such a challenge. |
| 00:29 | <ljharb> | ah yes, you're right |
| 00:29 | <ljharb> | altho i think blocking on a partial iterative approach is effectively blocking the whole thing, given how demotivating it is |
| 00:31 | <littledan> | Yeah, I really regret how demotivating the process was there |
| 00:31 | <littledan> | but I don't think we should add more features to Date.parse, which is something that proposal did. Standardizing it should be about building compatibility, not improving behavior to be more useful. |
| 00:35 | <ljharb> | (same thing happened with stack traces, in the same meeting) |
| 00:35 | <ljharb> | yeah i think it would have been a fine outcome if the objection was "no new stuff" |
| 00:36 | <ljharb> | that wasn't the takeaway for me tho |
| 00:36 | <littledan> | Yeah I guess the outcome could be confusing and lead to misunderstandings; I'm not sure what to do to address that. |
| 00:37 | <littledan> | I think the issue with stack traces was a bit different but I don't remember what exactly was being proposed |
| 00:40 | <littledan> | I guess we should figure this history of stack traces out a bit, since they are coming up this meeting too... |
| 01:05 | <ljharb> | it felt the same to me; i was specifying the structure but not the contents, and i was told that i'd be blocked if i did anything less then specify 100% of the existing behavior, including contents |
| 01:06 | <ljharb> | whereas i see it as valuable to lock down the structure asap, and leave it to a followon proposal to lock down the contents |
| 01:08 | <littledan> | I think there are different challenges inherent in standardizing the stack vs standardizing Date.parse. For example, web reality agrees what the entrypoint is for Date.parse, but not the stack introspection APIs. And the nature of compatibility differs as well (e.g., Firefox's crazy experience that it would be web-incompatible of them to ship Chrome's API!) |
| 01:09 | <littledan> | they also differ in that changes to Date.parse are changing what an existing function does, but the stack proposal was a new one (with unclear implications for what happens to the existing APIs) |
| 01:10 | <littledan> | they are both important areas of work, but the differences in the problems call for somewhat different approaches |
| 01:13 | <littledan> | when the standard says, "Do this [implicitly: plus something else which you have to figure out yourself]", this is a mess for implementers. ES6 implicitly did a bunch of this, and it took us more than a year to untangle it after it was already "standard". I prefer our post-ES6 habit of making each feature well-defined and complete, by the time it is standardized. |
| 01:21 | <littledan> | whereas i see it as valuable to lock down the structure asap, and leave it to a followon proposal to lock down the contents |
| 05:29 | <ljharb> | that only works if the same champions want to drive all stages of the change. |
| 15:52 | <Richard Gibson> | but I don't think we should add more features to Date.parse, which is something that proposal did. Standardizing it should be about building compatibility, not improving behavior to be more useful. |