| 05:07 | <Doctor> | Are there any other popular matrix servers worth joining? Being in only one for a platform seems lonely. |
| 09:05 | <janvarga> | Is there any reason why WebIDL allows a return type for setters? https://webidl.spec.whatwg.org/#idl-indexed-properties https://drafts.css-houdini.org/css-typed-om-1/#csstransformvalue |
| 09:06 | <janvarga> | We are discussing this in https://bugzilla.mozilla.org/show_bug.cgi?id=1981764 |
| 09:13 | emilio | filed https://github.com/whatwg/webidl/issues/1516 |
| 09:13 | <annevk> | janvarga: I think emilio is correct and we should either enforce undefined or forbid a type declaration altogether if possible |
| 09:14 | <janvarga> | Sounds good. |
| 09:16 | <janvarga> | Interesting how this started spreading. I mean, allowed in WebIDL, then CSS Typed OM used that, then chrome and webkit copied that :) |
| 09:18 | <emilio> | Well if it wasn't for that compiler warning about unused results we wouldn't have noticed either probably |
| 09:18 | <janvarga> | Yeah :) |
| 09:18 | <emilio> | Sent https://github.com/w3c/css-houdini-drafts/pull/1143 to the typedom spec |
| 09:19 | <janvarga> | Even CSSUnparsedValue was ok, because the generated code used an out param ... |
| 09:19 | <emilio> | Hah, so mostly by chance... |
| 09:20 | <janvarga> | So I guess, the way to go now, should be changing the WebIDL in Gecko to return undefined and maybe also provide a simple patch for WebIDL.py to assert that ? |
| 09:21 | <annevk> | That sounds good to me. That way we hopefully identify other cases as well. |
| 09:22 | <annevk> | I don't think WebKit has shipped CSS Typed OM btw, there were too many issues with that specification. |
| 09:22 | <janvarga> | Hm |
| 09:23 | <emilio> | annevk: epiphany does support it at least, can't check Safari r/n tho... |
| 09:23 | <janvarga> | let t = new CSSTransformValue([new CSSTranslate(CSS.px(10), CSS.px(20))]); t.length returns 1 |
| 09:23 | <janvarga> | in Safari on mac |
| 09:31 | <annevk> | janvarga: emilio: I misremembered. It's only CSSTypedOMColorEnabled that's disabled. |
| 09:32 | <annevk> | I wanted to use that for <input type=color>, but alas. |
| 09:33 | <emilio> | FWIW I only find one instance of named setters in Gecko (Storage.setItem, which does return undefined) |
| 09:37 | <emilio> | Same on WebKit and Blink |
| 09:37 | <annevk> | There's also DOMStringMap, HTMLSelectElement, and HTMLOptionsCollection per HTML, but they're all correct. |
| 09:37 | <emilio> | Right but those are not named right? |
| 09:38 | <emilio> | I was just thinking that, syntax wise, it might make sense to remove the return type for setters/deleters altogether |
| 09:38 | <emilio> | But at that point may as well remove the name |
| 09:39 | <emilio> | It seems only Storage would need to change? |
| 09:39 | <annevk> | I wonder if that creates an ambiguity as then for a named setter it might look like it returns a setter type. |
| 09:39 | <emilio> | (As in, add a undefined setItem(...); on top of the setter) |
| 09:48 | <annevk> | I see, if that's really the only setter we have that might be reasonable, but it will make it inconsistent with getters, where I don't think we'd want to make such a change. So hmm. |
| 09:50 | <emilio> | Right, my point is we'd remove named setters altogether |
| 09:51 | <emilio> | Ok... It was just an idea, I don't have very strong opinions either way. It's just that restricting it in prose tends to not be super effective in my experience :) |
| 09:52 | <emilio> | Yeah I guess named getters are used pretty often |
| 11:22 | <janvarga> | Interesting, Gecko has a WebIDL parser test containing: interface SpecialMethodsCombination { getter deleter boolean (DOMString name); }; |
| 11:24 | <janvarga> | Obviously changing boolean to undefined doesn't work because getters must have non-undefined return type, maybe this was the reason for having return type for setters and deleters |
| 17:50 | <TabAtkins> | Yeah, the fact that setting does return a value, and WebIDL allows it, caused me to add that type to the setter. It made sense, at least to me. |