| 00:13 | <TabAtkins> | sideshowbarker: It looks like the MDN-spec-links project moved to html-now? But the SPECMAP.json file is still present at the old location, and apparently out of date. |
| 00:13 | <TabAtkins> | (Bikeshed is pulling down some 404 pages for mdn data right now.) |
| 01:12 | <sideshowbarker> | sideshowbarker: It looks like the MDN-spec-links project moved to html-now? But the SPECMAP.json file is still present at the old location, and apparently out of date. |
| 01:14 | <TabAtkins> | Kk. I should respond to 404s better too |
| 01:14 | <sideshowbarker> | yeah |
| 01:15 | <sideshowbarker> | can you give me one that you are getting a 404 on right now? |
| 01:15 | <sideshowbarker> | ah nevermind |
| 01:15 | <sideshowbarker> | I see now |
| 01:16 | <sideshowbarker> | lord, what did I do |
| 01:17 | <sideshowbarker> | w3c.github.io/mdn-spec-links is just entirely redirecting to https://html-now.github.io/ |
| 01:17 | <sideshowbarker> | that’s completely unintentional and I don’t yet have any idea how I caused that, nor when (how long ago) |
| 01:23 | <sideshowbarker> | …and unfortunately, used a 301 rather than a 302 |
| 01:27 | <sideshowbarker> | TabAtkins: should be un-borked now — at least from non-browser requests without some network cache in between |
| 01:27 | <sideshowbarker> | for browsers, may need to do some fiddling in devtools |
| 20:01 | <bakkot> | The web platform and JS are inconsistent wrt each other in the handling of Historically in JS, missing arguments are treated the same way as explicit In the web platform, missing arguments are an error, in contrast to JS. Like in JS, an explicit TC39 just came to consensus that we'd like to be stricter here, for new APIs. In fact we'd like to be stricter even than the web platform currently is - we'll adopt the "missing arguments are an error" thing from the web platform, but in addition we'll start treating explicit I'm hoping the web platform can make the same change: treat missing arguments and explicit Assuming people are open to this, what's the best way to go about making such a change? I was thinking a new [LegacyCoerceUndefined] Web IDL attribute, which would be attached to ~every existing API specified with Web IDL, and then change the default definition for argument handling without that attribute so that explicit |
| 20:01 | <bakkot> | cc Domenic since we were talking about this over in the tc39 channel |
| 21:11 | <annevk> | bakkot: in principle I think that could work, modulo the amount of work; but presumably it only applies to a subset of arguments, strings and nullables? |
| 21:12 | <bakkot> | we don't want to coerce undefined to 0 either? and for nullables accepting undefined is fine |
| 21:12 | <bakkot> | for booleans the default value is generally false so coercing is fine, as long as you can also just omit the argument and get false |
| 21:12 | <bakkot> | you can't coerce undefined to object types, of course. I think that covers everything? |
| 21:14 | <bakkot> | that is, when passing an explicit
|
| 21:15 | <bakkot> | in the boolean/number cases where you want a default value, missing arguments should be accepted and treated the same way as an explicit undefined, rather than getting an error |
| 21:19 | <annevk> | Makes sense, I forgot that undefined works for numbers/booleans |
| 21:21 | <Jeffrey Yasskin> | Nit: passing undefined to a WebIDL dictionary should probably stay equivalent to passing {}. There's a recommendation (https://webidl.spec.whatwg.org/#dfn-optional-argument-default-value) to make that the default value for trailing dictionaries, but there might be interior ones for which it matters. |
| 21:22 | <Jeffrey Yasskin> | Well, I guess I don't actually have a preference that people be able to pass undefined instead of {}. It's just not quite true that it's already an error for all object types. |
| 21:23 | <bakkot> | ah, I only mean for this to apply when there are no default values specified |
| 21:24 | <bakkot> | in the case of default values, I would want explicit undefined, like an entirely missing argument, to give you the default value |
| 21:24 | <bakkot> | ... also is the default for dictionaries really {} instead of { __proto__: null }? seems bad... |
| 21:26 | <bakkot> | for non-trailing dictionaries, which do not have default values specified (i.e. the argument is required), it seems like it ought not accept undefined, to me? |
| 21:28 | <Andreu Botella> | ... also is the default for dictionaries really |
| 21:28 | <annevk> | bakkot: {} is a Web IDL literal, it's not a JS object |
| 21:28 | <bakkot> | ah, ok |
| 21:29 | <annevk> | Dictionaries are returned by some APIs btw. |
| 21:32 | <Andreu Botella> | Oh, it says it can't be a value of constants or attributes, but that's because then there's the issue of what happens when JS code updates them |
| 21:32 | <Jeffrey Yasskin> | But in the case of a returned dictionary, the empty one is OrdinaryObjectCreate(%Object.prototype%) |
| 21:32 | <Jeffrey Yasskin> | (https://webidl.spec.whatwg.org/#es-dictionary) |
| 21:37 | <bakkot> | I'm not so worried about returned dictionaries. I just want to ensure that when using an empty dictionary as a default value, you don't risk inheriting missing properties from Object.prototype. |
| 21:38 | <bakkot> | I guess if you're returning a dictionary for which some property is conditionally present that would be a concern. |
| 21:44 | <Jeffrey Yasskin> | It might actually be ambiguous in WebIDL. The spec is "Optional argument default values can also be specified using the two token value {}, which represents a default-initialized (as if from ES null or an object with no properties) dictionary value.", but as you say, null and "an object with no properties" could be interpreted as producing different dictionaries. |