| 08:58 | <MikeSmith> | annevk: about the encoding support in the validator.nu parser, I’m remembering now that Henri had been working on a spec-conformant implementation previously |
| 08:58 | <MikeSmith> | ...but it’s in a separate branch and it’s not had any new changes in a long time |
| 09:00 | <MikeSmith> | and there’s a note about it being “unfinished” but not with any details about what’s needed to finish it |
| 09:00 | <MikeSmith> | I kind of vaguely recall now that Henri had been working on Big5 decoder and maybe that’s what never got finished |
| 09:01 | <MikeSmith> | But I’m wondering if you remember any more from past discussions with him |
| 09:01 | <MikeSmith> | I think this would have been maybe 5 years ago |
| 09:48 | <smaug____> | annevk: could you interpret something for me :) https://html.spec.whatwg.org/#own-autocapitalization-hint "The autocapitalize IDL attribute, on getting, must return the string value corresponding to own autocapitalization hint of the element, with the exception that the default state maps to the empty string. On setting, it must set the autocapitalize content attribute to the given new value." |
| 09:48 | <smaug____> | The 'must return the string value corresponding to own autocapitalization hint of the element' part |
| 09:49 | <annevk> | That looks like a typo, but I'll have a look at what it might mean without that too |
| 09:49 | <smaug____> | how does that work when same hint maps to multiple values |
| 09:50 | <annevk> | smaug____: ah yeah, that's buggy |
| 09:53 | <annevk> | smaug____: so judging from the tests there is normalization going on |
| 09:54 | <smaug____> | or some specific mapping |
| 09:54 | <smaug____> | that sentences state maps always back to sentences string |
| 09:54 | <annevk> | smaug____: it seems that the idea is that the state name is also the canonical name |
| 09:55 | <smaug____> | right |
| 09:57 | <annevk> | smaug____: "For the purposes of reflection, the canonical keyword for the Anonymous state is the anonymous keyword." is what we have elsewhere, I guess I can PR a fix for that |
| 10:03 | <annevk> | Except of course it doesn't use reflection so the fix needs to be different |
| 10:09 | <annevk> | smaug____: https://github.com/whatwg/html/pull/5911 |
| 10:09 | <smaug____> | thanks |
| 14:29 | <JakeA> | Is there anything wrong with making an interface that's indexable, iterable, but also an event target? Or is that looked down upon vs having an event target and a sequence? |
| 14:30 | <JakeA> | As in, the sequence and event target being different objects vs being the same object |
| 15:13 | <annevk> | JakeA: indexable is a bit frowned upon I think still |
| 15:17 | <JakeA> | ta |
| 15:19 | <annevk> | JakeA: Domenic came up with some new type specifically for array-like structures |
| 15:19 | <annevk> | JakeA: I think it's https://heycam.github.io/webidl/#idl-observable-array |
| 15:20 | <Domenic> | Not an interface though |
| 15:20 | <Domenic> | EventTarget + a sequence/frozenarray/observablearray would be best I think |
| 15:22 | <JakeA> | The context is https://github.com/webscreens/window-placement/issues/30 fwiw |
| 18:59 | <croraf> | I'm confused about what is the scope of WHATWG. Can I ask and discuss here? |
| 19:00 | <croraf> | I see that it manages a number of standards. |
| 19:10 | <croraf> | I see that its set of standards that are meant to be implemented by the browsers. But it also affects other parts of web infrastructure, like web servers, right? |
| 19:14 | <croraf> | For example the Fetch standard or the Storage standard shouldn't affect any other component of the web except the browser. |
| 19:14 | <croraf> | But the URL standard does affects other components of the web, not just the browser. |
| 19:33 | <annevk> | Sounds about right, though fetch() has been implemented by servers to some extent |
| 19:37 | <croraf> | annevk, yes, although this was not the intention of the standard I guess. |
| 19:38 | <croraf> | Now, my question is, how are WHATWG standards related to "Web IDL" standard? |
| 19:38 | <croraf> | https://heycam.github.io/webidl/ |
| 20:05 | <Domenic> | croraf: almost all specs that define JavaScript APIs, including WHATWG specs and many others, use Web IDL. |
| 20:16 | <croraf> | I'm a bit confused why Javascript APIs are not defined in terms of Javascript but in another language? |
| 20:16 | <croraf> | Does Ecmascript need to conform to this Web IDL also? |
| 20:18 | <croraf> | Domenic, |
| 20:19 | <Domenic> | croraf: they are defined in terms of an abstraction layer, which reduces the boilerplate. For example you can declare your argument types in Web IDL and that abstracts away 3-4 steps per argument of validation code. |
| 20:23 | <zcorpan> | croraf: the ecmascript spec defines the ecmascript language without any dependency on webidl. webidl is on top of ecmascript. The fetch() API and others use webidl to get a consistent and more thought through API fundamentals on details such as argument conversion and validation |
| 20:23 | <croraf> | Domenic, your explaination makes sense, but I'm still a bit suspicious about this Web IDL. For example it defines a DOMString, so when designing an API you can for example say my function accepts one argument of type DOMString? |
| 20:24 | <Domenic> | Yes. And that allows specs to avoid writing the 3 steps in https://heycam.github.io/webidl/#es-DOMString for every argument. |
| 20:24 | <croraf> | If there was no WebIDL you would say my function accepts one argument of type ES String |
| 20:24 | <Domenic> | No, because you'd need to define what happens when the web developer passes a non-String. |
| 20:25 | <croraf> | Domenic, ok I see |
| 20:25 | <andreubotella> | If you look at the function definitions in the ECMAScript spec, you see that kind of checking that the arguments have a certain type all over the place. |
| 20:27 | <croraf> | zcorpan, I see, thanks. Btw using these 2 words next to each other is so confusing :D "more thought through API" for a non native speaker :D |
| 20:27 | <zcorpan> | heh :) |
| 20:28 | <croraf> | andreubotella, you want to say they repeat themselves all over the place. It would be better if they defined the "mnemonics" themselves |
| 20:28 | <croraf> | ? |
| 20:28 | <croraf> | (I mean they have the absctract operations, and shortcuts like ? and !) |
| 20:29 | <croraf> | Hmmm, Ok the abstract operations are internal to ES. |
| 20:31 | <andreubotella> | you can still those abstract operations outside of ES; the Streams standard used them until recently, and some of the operations in WebIDL do |
| 20:31 | <andreubotella> | but the typechecking isn't very conducive to "mnemonics" of that kind unless you add a layer like WebIDL, I think |
| 20:32 | <croraf> | I have 2 more questions. One is who maintains the WebIDL, is it the same group that maintains the WHATWG? |
| 20:34 | <croraf> | The second is, is WebIDL only used in the API specs for Javascript running in the browser, or also to define interface between some other browser components? |
| 20:35 | <croraf> | (or some other systems like Node...) |
| 20:36 | <andreubotella> | WebIDL is maintained by the W3C, which is a different standards body, but it shares many people with the WHATWG |
| 20:36 | <andreubotella> | for example, I believe that our own annevk and Domenic are editors of WebIDL, or at least have merge permissions |
| 20:37 | <croraf> | And WHATWG is W3C+many others? |
| 20:38 | <croraf> | (that is W3C is one of the parties in WHATWG) |
| 20:39 | <andreubotella> | the W3C and the WHATWG are separate organizations, but they share many people because both of them define large chunks of the web platform, and so browser vendors have representation in both of them |
| 20:40 | <croraf> | andreubotella, thanks! |
| 20:41 | <croraf> | Now only one of my questions remains: Is WebIDL only used in the API specs for Javascript running in the browser, or also to define interface between some other browser components? |
| 20:42 | <andreubotella> | so WebIDL was originally meant as a compatibility layer between the browser code (written in C++ or Rust) and the JS APIs |
| 20:42 | <croraf> | Or better: "Is WebIDL only used in the API specs for libraries used by the Javascript running in the browser, or also to define interface between some other browser components?" |
| 20:43 | <andreubotella> | but in the last few years it has shown its use in porting web APIs to Node.js or Deno |
| 20:43 | <andreubotella> | I don't think WebIDL is used per se across browser components that aren't accessible from JS code |
| 20:43 | <croraf> | andreubotella, thanks, you helped me a lot. |
| 20:44 | <croraf> | When you say "...and the JS APIs" you mean the JS API these libraries expose for the browser's Javascript to use? |
| 20:45 | <andreubotella> | no problem |
| 20:45 | <andreubotella> | that's right |
| 20:45 | <croraf> | Thanks, all clear :) |
| 20:45 | <croraf> | You guys are awesome :) |
| 20:45 | <croraf> | Very precise in the answers, I guess the specs people are like that :D |
| 20:46 | <andreubotella> | heh, I just started contributing to the specs a few months ago |
| 20:46 | <andreubotella> | most of this is stuff I've picked up |
| 20:46 | <andreubotella> | *picked up on |
| 20:46 | <andreubotella> | my English is also not the best ever :) |
| 20:47 | <croraf> | Haven't noticed that. |
| 20:48 | <croraf> | I got interested couple of days ago when I explored the "fetch" API in the MDN documents. |
| 20:48 | <croraf> | If you dive thorough it you get to the point where you can read the incoming response using https://developer.mozilla.org/en-US/docs/Web/API/ReadableStream/getReader |
| 20:50 | <andreubotella> | yeah, I also found my way here through MDN |
| 20:50 | <croraf> | Here it mentions that the mode parameter is of type DOMString. |
| 20:51 | <Domenic> | I wish MDN would not use IDL terms :(. They are really for implementations and code-generators. Web developers should never need to worry about what a "DOMString" is. |
| 20:51 | <croraf> | Yes!!! |
| 20:52 | <Domenic> | Similarly MDN says "interface" a lot, which is a confusing IDL term. For web developers they could just say "class" |
| 20:52 | <Domenic> | I have given them this feedback many times but they have not been willing to change. |
| 20:52 | <croraf> | They don't use it often. Rarely you encounter something like that. |
| 20:52 | <croraf> | Domenic, I think MDN is free to edit from anyone. |
| 20:52 | <Domenic> | Yeah, but fighting against the full-time editors is hard. |
| 20:53 | <croraf> | You think they might revert the change back also? |
| 20:53 | <croraf> | Or just that you cannot change on every place and continously? |
| 20:53 | <Domenic> | Mostly the latter. But also, they might revert the change because if I changed it in only one place it would be inconsistent, and they prefer consistency. |
| 20:54 | <croraf> | Domenic, also I checked this: https://developer.mozilla.org/en-US/docs/Web/API/DOMString |
| 20:55 | <croraf> | And it says that it maps directly to String. |
| 20:55 | <croraf> | I mean, in this direction this might be true actually. |
| 20:57 | <Domenic> | Yeah, I mean, it could explain that it will "stringify" whatever you pass in... but I'm not sure how helpful that is. |
| 20:58 | <croraf> | The root of the problem is that they used DOMString at all. |
| 21:01 | <andreubotella> | I suspect that the MDN folks wanted to preserve the distinction between DOMString/USVString/ByteString, since the latter two won't accept every ES string |
| 21:02 | <andreubotella> | but just throwing those terms at a JS developer won't help them very much |
| 21:07 | <croraf> | Is there a reason why mention DOMString here: https://pasteboard.co/Jr608kY.png |
| 21:08 | <croraf> | When it says that mode can have only 2 valid values, the "byob" and undefined. |
| 21:10 | <andreubotella> | I suspect that's a "mistranslation", since the WebIDL here uses very uncommon constructs |
| 21:11 | <andreubotella> | the Stream spec switched to using WebIDL a couple months ago, and some of the APIs weren't very WebIDL-friendly |
| 21:13 | <croraf> | https://streams.spec.whatwg.org/#rs-get-reader |
| 21:13 | <croraf> | this is the link andreubotella |
| 21:13 | <croraf> | I'm thinking of removing the mention of DOMString there :/ |
| 21:14 | <andreubotella> | yeah, I don't think anyone would oppose to that |
| 21:15 | <andreubotella> | the parameter here uses a dictionary with a single non-required element, which is an enum with only one variant |
| 21:16 | <andreubotella> | in practice, the allowed values of mode are the enum variant ("byob") and undefined, but that's not easy to tell |
| 21:17 | <andreubotella> | I had to read through the relevant sections of WebIDL a couple times to figure out why Domenic used that |
| 21:20 | <croraf> | In the streams spec link, first step it checks if options["mode"] does not exist. |
| 21:21 | <croraf> | It links to "exist" definition, but I'm still not clear when is the object["key"] considered to exist. |
| 21:21 | <andreubotella> | if you look at the WebIDL block here: https://streams.spec.whatwg.org/#rs-class-definition |
| 21:22 | <andreubotella> | you see that the parameter to getReader is an optional dictionary |
| 21:22 | <croraf> | If the object itself does not exist or is undefined or is a string, what happens here. |
| 21:22 | <andreubotella> | iirc, WebIDL translates a dictionary into an Infra map, such that if the key is undefined, it "does not exist" by that definition |
| 21:24 | <croraf> | Yes. But if the options itself is undefined what happens at this step: |
| 21:24 | <croraf> | 1. If options["mode"] does not exist, return ? AcquireReadableStreamDefaultReader(this). |
| 21:24 | <andreubotella> | the WebIDL block has: optional ReadableStreamGetReaderOptions options = {} |
| 21:25 | <andreubotella> | a.k.a. when the param is not given, the Infra map will be the same as if it was converted from an empty JS object |
| 21:25 | <andreubotella> | that is, empty |
| 21:25 | <andreubotella> | there's a lot of moving parts |
| 21:26 | <andreubotella> | I'd recommend you to first go through the Infra spec, and then check out some of the webidl conversion algorithms |
| 21:28 | <andreubotella> | for some quick intuition: the WHATWG spec algorithms for the most part don't deal with JS objects directly -- they deal with the WebIDL interfaces |
| 21:29 | <andreubotella> | a.k.a with the C++ objects that back the JS objects |
| 21:29 | <croraf> | Yes. I understand your last comment, yes. I'm missing a lot of basics. But just let make this clear. If the options is not given at all, or is given as undefined it will be set to an "empty object" right? |
| 21:30 | <croraf> | (or empty map) |
| 21:30 | <croraf> | (or empty Infra map :D, whatever) |
| 21:30 | <croraf> | as indicated by "= {}" |
| 21:31 | <andreubotella> | "= {}" means that the default JS value is an empty object (more or less...) |
| 21:31 | <andreubotella> | and WebIDL translates that to an empty Infra map |
| 21:32 | <croraf> | Now, one last question. What if I provide a string or a number as this options argument. How is this resolved from the IDL schema that we look at? |
| 21:32 | <andreubotella> | https://heycam.github.io/webidl/#es-dictionary |
| 21:33 | <andreubotella> | "an ECMAScript value `esDict` is converted into an IDL dictionary type by running the following algorithm" |
| 21:33 | <andreubotella> | in this case: |
| 21:33 | <andreubotella> | If Type(esDict) is not Undefined, Null or Object, then throw a TypeError. |
| 21:35 | <croraf> | Cool. Indeed makes sense. Ty. I'm going to test if it really throws a TypeError :D |
| 21:37 | <Domenic> | That error might not yet be implemented in browsers. It's one of the subtle differences that occurred when we switched the spec to Web IDL, and implementations haven't fully switched yet. |
| 21:37 | <Domenic> | See the full list of subtle differences in https://github.com/whatwg/streams/pull/1035 |
| 21:39 | <croraf> | Yes, chrome doesnt throw an error |
| 21:40 | <croraf> | https://pasteboard.co/Jr6duq5.png Domenic , andreubotella |
| 21:41 | <Domenic> | Yes, the old spec would look up 'the string'.mode, which was usually undefined |
| 21:41 | <croraf> | Cool cool. Ty andreubotella and Domenic and others :) |
| 21:41 | <andreubotella> | from my time lurking in that thread, I thought Chrome had switched to WebIDL for streams |
| 21:42 | <Domenic> | andreubotella: they did, but with a ton of `any` to match the existing semantics as much as possible. |
| 21:42 | <andreubotella> | I see |
| 21:43 | <croraf> | Btw I contributed a bit to a Rust JS engine. Cool project called boa. Primitive support though. |
| 21:44 | <croraf> | There is a much more advanced engine in development Jsparagus Mozilla backed, but dont know if it stopped with mozilla's cuts |
| 21:44 | <croraf> | Actually Jsparagus is maybe only a parser and compiler or something like that. |
| 21:45 | <croraf> | Boa is a parser and runner. |
| 21:45 | <croraf> | Fun stuff, rust is kind of fun. |
