| 03:55 | <annevk> | I still kinda think we should rename DOMString |
| 07:39 | <MikeSmith> | annevk: about Encoding, are you aware of implementations that implement the decoders and encoders per-spec? |
| 07:39 | <annevk> | MikeSmith: Chrome, Firefox, and soon Safari |
| 07:39 | <MikeSmith> | oh |
| 07:39 | <MikeSmith> | OK |
| 07:39 | <annevk> | or at least Safari TP |
| 07:40 | <MikeSmith> | I remain curious where the Firefox code for that lives |
| 07:40 | <annevk> | I want to blog about it when that happens as it's so cool that we're finally there, 11 years after starting to look into it |
| 07:40 | <zcorpan> | MikeSmith: https://github.com/hsivonen/encoding_rs |
| 07:41 | MikeSmith | looks |
| 07:41 | annevk | was about to paste that |
| 07:41 | <MikeSmith> | aha |
| 07:41 | <MikeSmith> | thanks |
| 07:41 | <annevk> | MikeSmith: https://github.com/hsivonen/chardetng might also be of interest |
| 07:43 | MikeSmith | looks |
| 07:44 | <MikeSmith> | ah I now recall Henri mentioning that elsewhere |
| 07:44 | <annevk> | there's posts/articles too, yes :-) |
| 07:47 | <MikeSmith> | the need to implement the decoders and encoders makes implementing a conforming HTML parser signficantly more work |
| 07:48 | <MikeSmith> | I think html5ever and parse5 don’t actually implement decoders/encoders per spec |
| 07:48 | <MikeSmith> | ...but instead just rely on the character encoding support in the runtime |
| 07:56 | <zcorpan> | MikeSmith: I think node has an encoding standard implementation, see https://github.com/nodejs/node/issues/20365 |
| 07:57 | <annevk> | zcorpan: I think that might be around non-compliant encoders/decoders |
| 07:57 | <zcorpan> | oh |
| 08:00 | <zcorpan> | maybe mathiasbynens encoders/decoders are of interest then https://www.npmjs.com/search?q=keywords:legacy-encoding MikeSmith |
| 08:00 | MikeSmith | looks |
| 08:01 | <MikeSmith> | ah cool |
| 10:25 | <zcorpan> | annevk: hmmmm, it seems hard to isolate the effect of encoding scanner in wpt, in particular if the speculative parser also looks for encoding declarations (which gecko does at least) |
| 10:27 | <annevk> | Well, we only need to document what is observable, so... |
| 10:27 | <MikeSmith> | getting 💥 Error: 403 Forbidden 💥 |
| 10:28 | <MikeSmith> | ...for https://github.com/whatwg/html/pull/5916 |
| 10:28 | <MikeSmith> | dunno if that’s the same problem we had recently with another PR, or whether it’s a different problem |
| 10:29 | <annevk> | That seems different |
| 10:29 | <annevk> | Did w3.org start blocking PR Preview? |
| 10:29 | <zcorpan> | annevk: true. it's certainly possible to test things like <script><meta charset=A></script><meta charset=B> |
| 10:33 | <MikeSmith> | annevk: dunno maybe accidentally |
| 11:40 | <croraf> | <annevk> "I still kinda think we should rename DOMString," I already heard this opinion |
| 11:41 | <croraf> | annevk, do you get pinged when I enwrap your name in <>? |
| 11:41 | <annevk> | yes |
| 12:44 | <croraf> | Does `fetch` inspect the Content-Type header? |
| 12:45 | <croraf> | OK. The question is stupid, because it obviously provides Response.headers. |
| 12:47 | <croraf> | OK, once again I'm a bit confused by the MDN https://developer.mozilla.org/en-US/docs/Web/API/Response |
| 12:48 | <croraf> | This is mentioning Response *interface*, and lists the properties below, for example Response.headers. But this should be written as Response.prototype.headers? |
| 12:48 | <MikeSmith> | croraf: yes |
| 12:48 | <MikeSmith> | that’s a common problem with some MDN content, unfortunately |
| 12:49 | <croraf> | MikeSmith, so this *interface* is the WebIDL term, right? |
| 12:49 | <MikeSmith> | yes |
| 12:49 | <MikeSmith> | maybe probably it should instead talk about it object |
| 12:50 | <MikeSmith> | but again that’s kind of a common shortcoming in some MDN articles |
| 12:51 | <MikeSmith> | the articles in the https://developer.mozilla.org/en-US/docs/Web/JavaScript tree are written in a way that’s more correct and familiar |
| 13:13 | <croraf> | MikeSmith, Cool, I might even try to change this Response page these days, to see what happens. |
| 13:14 | <MikeSmith> | croraf: If you can make time to update it, that would be great |
| 13:15 | <croraf> | Becuase I remember reading that several times over the last years, and I remember it confused me so much, although it is kind of intuitive. |
| 13:15 | <MikeSmith> | yeah |
| 13:15 | <croraf> | So I was like: "Ok, lets not bother with the details this time." |
| 13:15 | <MikeSmith> | and in general with MDN, when you run into confusing articles, you can also file issues at https://github.com/mdn/sprints/issues/new/choose with details about changes that should be made |
| 13:16 | <croraf> | oh, cool |
| 13:16 | <MikeSmith> | but it’s better if you can make the edits directly |
| 13:17 | <MikeSmith> | I will be happy post-review any changes you make |
| 13:17 | <MikeSmith> | I get automated notifications for any changes to https://developer.mozilla.org/en-US/docs/Web/API articles, so I’ll see it regardless |
| 13:17 | <croraf> | MikeSmith, regarding this issues link, which category do WHATWG specs fit. |
| 13:17 | <croraf> | Ofc HTML goes into HTML, but the other specs? |
| 13:18 | <MikeSmith> | hmm good point |
| 13:18 | <MikeSmith> | I see now that https://github.com/mdn/sprints/issues/new/choose doesn’t have category for API docs |
| 13:19 | <MikeSmith> | I guess “Content issue template” is the general one |
| 13:19 | <MikeSmith> | but I will suggest that a specific API one be added |
| 13:20 | <MikeSmith> | croraf: actually though, the preferred way is to just follow a link from the MDN article |
| 13:20 | <croraf> | cool |
| 13:20 | <MikeSmith> | if you go to https://developer.mozilla.org/en-US/docs/Web/API/Response, there a Feedback drop-down at the top |
| 13:21 | <croraf> | Yes. |
| 13:21 | <MikeSmith> | yeah, from that you can select Report a content problem |
| 13:22 | <croraf> | One unlinked question. The URL spec from WHATWG does only relate to the URL object available by the browser or also with the web URL concept itself? |
| 13:22 | <MikeSmith> | both |
| 13:22 | <MikeSmith> | both the API/object and general definition of what a URL is |
| 13:23 | <croraf> | This is kind of unfortunate in my opinion. I hoped that WHATWG would only deal with the browser objects (APIs) |
| 13:23 | <croraf> | Would be more clean, so to say. |
| 13:23 | <MikeSmith> | well the problem is that in practice that clean separation is most often not possible |
| 13:24 | <croraf> | It is kind of unclear to me what WEB consists of. Could we say that WHATWG specifies things only strictly within the WEB? |
| 13:24 | <croraf> | (WEB consists of = what WEB actually is) |
| 13:25 | <MikeSmith> | and another specific problem in the case of URL is that the relevant RFCs are out of data and not maintained and in fact peole in IETF land think there is nothing that needs to be updated |
| 13:25 | <MikeSmith> | in fact many assert that the term URL should not be used but instead URI should be |
| 13:25 | <MikeSmith> | and so on and on and on |
| 13:25 | <croraf> | MikeSmith, does this mean that WHATWG specs sometimes conflict with the IETF one? |
| 13:25 | <croraf> | Or they only extend it? |
| 13:25 | <MikeSmith> | yes |
| 13:26 | <MikeSmith> | conflict |
| 13:26 | <croraf> | thanks. |
| 13:26 | <MikeSmith> | yeah, again, that’s because the responsible parties at the IETF usually don’t ever update their specs after they become RFCs |
| 13:27 | <croraf> | MikeSmith, I just read https://softwareengineering.stackexchange.com/questions/109517/how-is-ietf-different-from-w3c |
| 13:27 | <MikeSmith> | ...even in cases where the specs are known to conflict with implememtations |
| 13:27 | <croraf> | I mean should IETF at all dead with such stuff? |
| 13:27 | <croraf> | Or the W3C? |
| 13:27 | <croraf> | Or is W3C a subcomitee of IETF? |
| 13:27 | <MikeSmith> | separate |
| 13:28 | <MikeSmith> | and the answers in that that stack question are not good |
| 13:28 | <croraf> | And the top voted answer? |
| 13:29 | <croraf> | - IETF works on Internet protocols, particularly at OSI layer 3 and 4. |
| 13:29 | <croraf> | - WWW, which is simply an application-layer protocol. The W3C works on WWW specifications |
| 13:29 | <MikeSmith> | that W3C generally does not work on protocols at all |
| 13:30 | <MikeSmith> | with some exceptions |
| 13:30 | <croraf> | Also the first answer conflicts with the second answer: |
| 13:30 | <croraf> | - IETF works on Internet protocols, particularly at OSI layer 3 and 4. |
| 13:30 | <croraf> | - IETF focuses on packet/line/terminal/telnet based protocols |
| 13:31 | <croraf> | telnet is Application layer |
| 13:31 | <MikeSmith> | about “Web”, you’ll notice that we use the term “the Web platform” — which basically means the set of standard technologies that are implemented nativelly in web browsers |
| 13:32 | <croraf> | So Web are basically the application implemented in the browsers? |
| 13:32 | <MikeSmith> | web platform |
| 13:32 | <croraf> | ok |
| 13:32 | <MikeSmith> | that Web is an information system |
| 13:35 | <croraf> | Does W3C also deal with defining the URL for example? |
| 13:41 | <MikeSmith> | W3C specs reference the WHATWG URL standard |
| 13:43 | <croraf> | Hmm, I indeed see that in MDN the entire Web/API section of articles uses WebIDL terminology. So it is not possible to change, because that would be 1 inconsistent out of 50. |
| 14:26 | <Domenic> | MikeSmith: annevk: I'm looking into why CI isn't building... maybe it's not picking up the latest Wattsi somehow. |
| 14:26 | <Domenic> | Well, it is picking up the latest Wattsi, which is preventing most PRs, but I'm unsure why https://github.com/whatwg/html/pull/5916 is failing CI... |
| 14:26 | <annevk> | Domenic: did I break it with my html-build change? |
| 14:27 | annevk | isn't sure about the timeline, but did land something today |
| 14:27 | <Domenic> | No, it's because we merged MikeSmith's change to make data-export + data-dfn-type an error (because they're redundant), which makes the current spec an error. |
| 14:27 | <Domenic> | So master doesn't build anymore |
| 14:27 | <Domenic> | But https://github.com/whatwg/html/pull/5916 should fix that |
| 14:27 | <Domenic> | But it's not passing validation |
| 14:27 | <Domenic> | I'll investigate for a bit, and rollback Wattsi if it's not an easy fix. |
| 14:28 | <annevk> | Domenic: didn't you need to update the Wattsi server manually? |
| 14:28 | <Domenic> | CI shouldn't be using the Wattsi server |
| 14:28 | <Domenic> | But yes I do need to do that soon enough |
| 14:29 | <annevk> | So looking at MikeSmith's PR the problem is that the output doesn't validate |
| 14:30 | <Domenic> | Right. Which indicates incomplete replacements maybe? |
| 14:30 | <annevk> | It seems we don't convert export/attribute back to data-... |
| 14:31 | <Domenic> | https://github.com/whatwg/wattsi/commit/b6a7eea5edacb73af77a457055bab81d6e93387c indicates we should, but maybe we didn't fully test... |
| 14:32 | <MikeSmith> | dang |
| 14:32 | <MikeSmith> | looking now |
| 14:33 | <MikeSmith> | are we sure the build is picking up the latest Wattsi? |
| 14:34 | <Domenic> | I think so, because it's giving the export + dfn-type error |
| 14:34 | <Domenic> | I'm testing locally now |
| 14:35 | <Domenic> | Yeah with latest Wattsi locally the attributes still appear in the source (noexport="", abstract-op="", ...) |
| 14:35 | <annevk> | I wish this was using GitHub CI already, it's much harder for me to retry Travis stuff |
| 14:35 | <Domenic> | It looks like the replacement might indeed be done in the wrong phase |
| 14:35 | <Domenic> | We should probably roll back https://github.com/whatwg/wattsi/commit/7e4d1e8f42b6d9f6a4a355c0213aa91b4f47605d specifically for now |
| 14:35 | <Domenic> | To un-break the build on master and let other PRs land |
| 14:36 | <Domenic> | Then figure out why the conversion code (noexport -> data-noexport, etc.) isn't working. |
| 14:36 | <MikeSmith> | I can reproduce it locally |
| 14:36 | <MikeSmith> | I think it’s not just the noexport -> data-noexport part |
| 14:37 | <MikeSmith> | I see alos “Attribute “element” not allowed on element “h4” at this point.” |
| 14:37 | <Domenic> | Yeah I don't think any of the replacements are working :( |
| 14:38 | <MikeSmith> | I would think most of them are working |
| 14:38 | <MikeSmith> | because I am only getting 35 errors |
| 14:39 | <MikeSmith> | if it were not working at all, I would think it’d be more like hundreds |
| 14:39 | <MikeSmith> | so my first guess is that that Wattsi code is not catching a subset of cases |
| 14:39 | <Domenic> | My output/index.html does not contain any data-dfn-type or data-export |
| 14:39 | <MikeSmith> | but also I see some weird instances of “Attribute “dfn” not allowed on element “h5” at this point.” |
| 14:42 | <MikeSmith> | Domenic: for me: |
| 14:42 | <MikeSmith> | $ rg data-dfn-type output/ | wc -l 720 |
| 14:43 | <Domenic> | Oh shoot my thing used the build server |
| 14:43 | <Domenic> | Forgot to set $PATH |
| 14:43 | <MikeSmith> | ah OK |
| 14:45 | <MikeSmith> | CI errors at https://travis-ci.org/github/whatwg/html/builds/727323337#L618 look like exactly the same set of errors I am getting locally |
| 14:46 | <Domenic> | Maybe <hN>s and <dfn>s are treated specially by Wattsi |
| 14:46 | <MikeSmith> | yeah must be that |
| 14:47 | <MikeSmith> | well now that I say that: Actually the Wattsi code doesn’t do anythign for these in hNs |
| 14:47 | <MikeSmith> | so that is expected |
| 14:48 | <MikeSmith> | the current Wattsi code only makes the translations for dfn elements |
| 14:49 | <MikeSmith> | so I guess the first fix that’s needed is to just duplicate the translation handling for dfn over to the hN-handling code |
| 14:49 | <Domenic> | Oh dang haha |
| 14:50 | <MikeSmith> | yeah, silly oversight :( |
| 14:50 | <MikeSmith> | but then I was not aware that we had this stuff on hNs |
| 14:50 | <MikeSmith> | I should not have just assumed |
| 14:50 | <MikeSmith> | well, I should have also run the HTML checker on the output locally |
| 14:51 | <MikeSmith> | incidentally, maybe we should have the build script be running the HTML checker |
| 14:51 | <MikeSmith> | locally I mean |
| 14:52 | <MikeSmith> | with an opt-out |
| 14:52 | <MikeSmith> | not run it for the -f case for sure |
| 14:53 | <MikeSmith> | anyway, will make the hN fix in Wattsi right now |
| 14:53 | <MikeSmith> | and then re-test |
| 14:59 | <MikeSmith> | OK well did that, and that eliminates all the HTML checker errors |
| 15:00 | <croraf> | Can interface be a mixin? |
| 15:00 | <MikeSmith> | including “Attribute “dfn” not allowed on element “h5” at this point.” |
| 15:00 | <MikeSmith> | Domenic: annevk: so I guess “dfn” is a valid dfn type |
| 15:00 | MikeSmith | checks the code |
| 15:01 | <MikeSmith> | croraf: yes, an interface defined in a spec can be mixin |
| 15:02 | <croraf> | Does this mean an interface can have some methods and/or properties implemented and still be an interface? |
| 15:02 | <zcorpan> | Domenic: annevk: hmmm, what happened here? I don't get that locally, and the PR is based on latest master https://travis-ci.org/github/whatwg/html/builds/727385861 |
| 15:02 | <MikeSmith> | hmm, no, “dfn” is not a valid dfn type, so I don’t know why my change fixed that error |
| 15:02 | <Domenic> | zcorpan: see last hour of chat :) |
| 15:03 | <zcorpan> | Domenic: oh lol |
| 15:03 | <Domenic> | zcorpan: basically, new Wattsi breaks master, and we're working on fixing it |
| 15:03 | <MikeSmith> | croraf: don’t understand your question. For an interface mixin, the members are exposed from other interfaces that use that mixin |
| 15:03 | <zcorpan> | :+1: |
| 15:04 | <Domenic> | MikeSmith: so, upload your fix and we're good to go, no reverts needed? |
| 15:04 | <MikeSmith> | no reverts needed |
| 15:04 | <MikeSmith> | I will raise a PR with the patch shortly |
| 15:04 | <MikeSmith> | but we now have other errors that require updating the spec source |
| 15:05 | <MikeSmith> | the redundant export thing |
| 15:05 | <MikeSmith> | Error: <dfn> found with dfn type name and redundant export attribute; dfn is <h4> element containing "StructuredSerialize ( value )"; previous heading contents are "StructuredSerialize ( value )" |
| 15:05 | <MikeSmith> | Error: <dfn> found with dfn type name and redundant export attribute; dfn is <h4> element containing "StructuredSerializeForStorage ( value )"; previous heading contents are "StructuredSerializeForStorage ( value )" |
| 15:05 | <MikeSmith> | Error: <dfn> found with dfn type name and redundant export attribute; dfn is <h4> element containing "StructuredDeserialize ( serialized, targetRealm [ , memory ] )"; previous heading contents are "StructuredDeserialize ( serialized, targetRealm [ , memory ] )" |
| 15:05 | <MikeSmith> | Error: <dfn> found with dfn type name and redundant export attribute; dfn is <h4> element containing "StructuredSerializeWithTransfer ( value, transferList )"; previous heading contents are "StructuredSerializeWithTransfer ( value, transferList )" |
| 15:05 | <MikeSmith> | Error: <dfn> found with dfn type name and redundant export attribute; dfn is <h4> element containing "StructuredDeserializeWithTransfer ( serializeWithTransferResult, targetRealm )"; previous heading contents are "StructuredDeserializeWithTransfer ( serializeWithTransferResult, targetRealm )" |
| 15:05 | <MikeSmith> | Error count: 5 |
| 15:06 | <MikeSmith> | so I will fix those by pushing a commit to the HTML spec PR |
| 15:08 | <Domenic> | Ah perfect |
| 15:08 | <croraf> | MikeSmith, I'm reading this "A mixin is a class or interface in which some or all of its methods and/or properties are unimplemented, requiring that another class or interface provide the missing implementations." from https://developer.mozilla.org/en-US/docs/Glossary/mixin |
| 15:09 | <croraf> | When it says "is a class or interface", are class and interface WebIDL terms? |
| 15:10 | <croraf> | Because I dont see class defined in WebIDL |
| 15:11 | <MikeSmith> | well it’s a class really |
| 15:12 | <MikeSmith> | arguably we rightly shouldn’t be using the term “interface” at all |
| 15:12 | <MikeSmith> | but the specs are |
| 15:12 | <MikeSmith> | so that MDN glossary entry should not be mentioning “class” I guess |
| 15:13 | <MikeSmith> | Domenic: TranslateShortSyntax() for the function name? |
| 15:13 | <Domenic> | MikeSmith: SGTM, or maybe "TranslateBikeshedSyntax" |
| 15:13 | <MikeSmith> | k |
| 15:15 | <zcorpan> | croraf: they're neither classes or interfaces, https://heycam.github.io/webidl/#idl-interface-mixins is a separate concept. interfaces can include an interface mixin |
| 15:16 | <croraf> | So interface mixin is basically an interface that can be extended by another interface, and that's it? |
| 15:16 | <croraf> | I mean you said it is not an interface, so i guess it technically is not. |
| 15:17 | <zcorpan> | right, it's a specification-level shorthand so you don't need to write the same things twice |
| 15:17 | <zcorpan> | interface A { undefined queueMicrotask(VoidFunction callback); } interface B { undefined queueMicrotask(VoidFunction callback); } |
| 15:17 | <zcorpan> | is equivalent to |
| 15:18 | <croraf> | But is it basically an interface that cannot be used as an interface itself but can be extended by other interfaces? |
| 15:18 | <zcorpan> | interface A {}; interface B {}; interface mixin C { undefined queueMicrotask(VoidFunction callback); }; A includes C; B includes C; |
| 15:19 | <croraf> | I'm not sure why it exists as a separate concept, why is it not just the interface itself zcorpan ? |
| 15:20 | <zcorpan> | croraf: they aren't extended by other interfaces, their members are folded into other interfaces |
| 15:20 | <Domenic> | Maybe the confusion is that "interface mixin" doesn't mean "interface that is a mixin". It means "mixin for use by interfaces" |
| 15:21 | <croraf> | Domenic, I understand. But I'm making a parallel with Java OO concepts. |
| 15:21 | <Domenic> | I don't think that will serve you well. |
| 15:21 | <croraf> | You have interfaces and interfaces can "extend" other interfaces. |
| 15:21 | <Domenic> | Web IDL is not like Java. |
| 15:21 | <Domenic> | Web IDL is a framework for generating code. |
| 15:21 | <Domenic> | And saving typing. |
| 15:21 | <Domenic> | The concepts in it are not OO concepts. |
| 15:21 | <Domenic> | The concepts in it are things that are useful to save typing by spec authors. |
| 15:21 | <croraf> | Well interface is basically an OO concept. |
| 15:22 | <croraf> | interface that applies to objects. |
| 15:22 | <Domenic> | The Web IDL interface is not an OO concept. |
| 15:22 | <andreubotella> | if you're coming from Java, WebIDL "interface" is *kinda like* a class, and a WebIDL "mixin" is *kinda like* an interface |
| 15:22 | <Domenic> | It is a way of generating spec code. |
| 15:22 | <Domenic> | The spec code that it generates mostly corresponds to a JavaScript class, but that's incidental, and as you can see, the names were not chosen to match up. |
| 15:23 | <croraf> | andreubotella, I think that both "interface mixin" and "interface" are like OO Java's interface. |
| 15:23 | <Domenic> | Trying to draw analogies will mostly hurt understanding. |
| 15:23 | <croraf> | interface mixing defines members that are included in interfaces |
| 15:23 | <croraf> | by using A includes Amixin |
| 15:24 | <croraf> | That seeems analoguous as having interface A and interface Amixin in java and doing interface A extends Amixin {} |
| 15:24 | <MikeSmith> | Domenic: https://github.com/whatwg/wattsi/pull/136 (and I’ll do the HTML commit in about 90 minutes from now) |
| 15:24 | <croraf> | None have an implementation, so none are considered as class. |
| 15:26 | <Domenic> | MikeSmith: excellent, thank you. I can try to finish things off; if local testing works then I'll push and merge. |
| 15:29 | <croraf> | To ilustrate I dont know why you couldnt do: interface A {}; interface C { undefined queueMicrotask(VoidFunction callback); }; A includes C; |
| 15:37 | <andreubotella> | to see how a WebIDL interface is more like a class in OOP languages, consider that you can do `new URL()` or `var instanceof URL`, but you can't do that with a mixin |
| 15:38 | <andreubotella> | the fact that interfaces aren't implemented in WebIDL doesn't matter because WebIDL meant to describe APIs, not their behavior |
| 15:38 | <andreubotella> | *is meant |
| 15:39 | <Domenic> | MikeSmith: still some issues sadly :( https://github.com/whatwg/html/pull/5916#issuecomment-692797393 |
| 15:39 | <Domenic> | I'll revert the conflict-checking commit for now |
| 15:39 | <zcorpan> | croraf: all webidl interface names are exposed as properties on the global. that's not desired for mixins |
| 15:40 | <andreubotella> | isn't there any intro documents for beginners to the web specs? |
| 15:40 | <croraf> | andreubotella, you can do new URL() because someone implemented the URL interface. |
| 15:41 | <zcorpan> | andreubotella: there's https://wpc.guide/ but it doesn't go into depth of details like these :) |
| 15:41 | <annevk> | croraf: an IDL interface really is a description of a class |
| 15:41 | <annevk> | Web IDL interface that is |
| 15:41 | <croraf> | And (by convention it seems) the interface mixins itself cannot be implemented but must be included in an interface. |
| 15:42 | <annevk> | andreubotella: I don't think so, sometimes specifications have introductions and maybe Web IDL should have a better one |
| 15:42 | <Domenic> | It's amazing to me how much confusion we're seeing caused just because Web IDL used the incorrect word "interface" |
| 15:42 | <Domenic> | I wish it'd used "flargle" instead, then nobody would have these questions. |
| 15:42 | <croraf> | An IDL interface doesnt specifiy the implementation, but an API |
| 15:42 | <Domenic> | They'd say "what's a flargle" and we could explain from scratch |
| 15:42 | <Domenic> | Instead of them bringing pre-concieved incorrect notions from Java or similar. |
| 15:42 | <annevk> | croraf: no it does specify an implementation |
| 15:43 | <andreubotella> | croraf: even in Java, you can't construct an interface with `new URL()`, URL would have to be a class |
| 15:43 | <annevk> | Domenic: I mean, "class" would work and we can still rename |
| 15:43 | <annevk> | and one day I hope we will |
| 15:43 | <Domenic> | annevk: quick LGTM on https://github.com/whatwg/wattsi/pull/137 would be good |
| 15:44 | <annevk> | I rubberstamped it |
| 15:46 | <croraf> | annevk, you see interface Headers here https://fetch.spec.whatwg.org/#headers-class this is not an implementation it is just a specification |
| 15:47 | <annevk> | croraf: ok |
| 15:47 | <croraf> | It has the class of the same name which implements this interface. |
| 15:47 | <croraf> | And that class is available in the browser. |
| 15:47 | <annevk> | And what defines that? |
| 15:48 | <andreubotella> | I'm starting to agree with annevk that it'd be worth renaming the concept |
| 15:48 | <croraf> | You mean the class? |
| 15:48 | <croraf> | annevk, |
| 15:48 | <croraf> | what defines the class? |
| 15:49 | <croraf> | The class' API is defined by the Class interface. |
| 15:50 | <andreubotella> | the point we're trying to explain is that, even by your model, there'd be one single class that implements the Headers interface, and the spec defines it with reference to the Headers interface, not as a separate class |
| 15:51 | <andreubotella> | but it'd be more productive to just see "WebIDL interface" and think of "class" |
| 15:51 | <annevk> | and also, part of your implementation is generated from the IDL construct, such as how to do argument coercion, etc. |
| 15:51 | <Domenic> | OK, master is back to building |
| 15:51 | <annevk> | \o/ |
| 15:55 | <croraf> | andreubotella, I don't see your point. Not sure what you mean "there had to be one single class". |
| 15:55 | <croraf> | annevk, Haven't went into details but this is more like specifying how the implementation should behave. |
| 15:56 | <annevk> | croraf: the way this works, you cannot have multiple classes implementing the same interface |
| 15:56 | <annevk> | croraf: sure, but it's a lot more than just a shape |
| 15:57 | <croraf> | Well it is shape and behavior. |
| 15:57 | <croraf> | You cannot use the interface before someone implements it as a Class. |
| 15:58 | <croraf> | You can have several implementations of the interface. |
| 15:58 | <croraf> | Class1 implements Class, Class2 implements Class, etc. |
| 15:58 | <annevk> | You are making a bunch of assertions here, but I don't think these are backed up by any web standard |
| 15:59 | <annevk> | Which makes it hard to have a conversation; when we say "interface", we mean what Web IDL defines that to be |
| 15:59 | <Domenic> | +1, it is getting a bit frustrating. |
| 16:00 | <Domenic> | It seems like you see the word "interface" and assume it means what you want it to mean, instead of what the spec defines it to mean. |
| 16:02 | <andreubotella> | I think I'm going to file an issue about adding an intro for newcomers |
| 16:02 | <andreubotella> | they we could point everyone there |
| 16:02 | <andreubotella> | *then |
| 16:03 | <croraf> | Domenic, you said the concepts in WebIDL are not OO concepts. The first sentence in https://heycam.github.io/webidl/#idl-interfaces says "IDL fragments are used to describe object oriented systems." |
| 16:03 | <Domenic> | Then we should fix that sentence. |
| 16:08 | <andreubotella> | https://github.com/heycam/webidl/issues/918 |
| 16:10 | <andreubotella> | btw, can anyone review https://github.com/whatwg/html/pull/5874? |
| 16:10 | <andreubotella> | I'd much appreciate the comments of parser folks |
| 16:10 | <croraf> | I think I understnad now what you trying to say. In Java the interface only specifies members and methods, it doesnt specify behavior. |
| 17:13 | <MikeSmith> | Domenic: thanks for the fixes. The remaining stuff will take me longer than what I have time left for I need to step away again. But can get back to it in the morning my time (~5 hours from now) |
| 17:13 | <Domenic> | MikeSmith: I think I've got it all working; running the final build now. |
| 17:18 | <TabAtkins> | Importantly, "object oriented systems" is not a synonym for "Java-like"; OO is a far wider and weirder set of concepts than most people who've been taught about OO typically understand. |
| 17:18 | <TabAtkins> | CLOS is OO, despite not having anything like a class or methods, just free functions which can have multiple implementations keyed by the types of their arguments. |
| 18:14 | <croraf> | TabAtkins, I don't know what CLOS is, but from wikipedia: "The basic building blocks of CLOS are classes and their methods, instances of those classes, and generic functions" |
| 18:15 | <croraf> | Although I agree that OO is not only Java-like OO. JS is OO, but radically different from Java's OO. |
| 18:16 | <TabAtkins> | CLOS doesn't have methods. If you specialize more than one argument, they call it a "multi-method", but it's literally the exact opposite of what a "method" is in JS/Java/etc, since it's explicitly *not* owned by a single class. |
| 18:19 | <croraf> | The important sentence in the WebIDL spec is: "Objects that implement the GraphicalWindow interface will expose these attributes and operations in a manner appropriate to the particular language being used." |
| 18:19 | <croraf> | That is more generic: "Objects that implement an interface will expose its attributes and operations in a manner appropriate to the particular language being used." |
| 18:20 | <croraf> | And they continue with: "In ECMAScript, the attributes on the IDL interfaces will be exposed as accessor properties and the operations as data properties whose value is a built-in function object on a prototype object for all GraphicalWindow objects; each ECMAScript object that implements GraphicalWindow will have that prototype object in its prototype chain." |
| 18:20 | <andreubotella> | notice that it talks about *objects* implementing an interface, not classes |
| 18:20 | <andreubotella> | WebIDL's "objects that implement an interface" is equivalent to Java's "objects that are instances of a class" |
| 18:20 | <croraf> | andreubotella, yes |
| 18:20 | <croraf> | I see. |
| 18:22 | <croraf> | Although the analogy is only partially valid. As class in JS also holds the implementation. While the WebIDL interface is just a "signature" |
| 18:22 | <croraf> | In pure Ecmascript you cannot just define the signature I guess (maybe in typescript), you have to define an implementation with it. |
| 18:23 | <Domenic> | No, it is not just a signature. We have told you this many times. |
| 18:23 | <andreubotella> | WebIDL isn't in the business of defining an interface's behavior, that's for the prose in the spec |
| 18:23 | <Domenic> | It defines the behavior for argument handling and various other pieces. |
| 18:23 | <andreubotella> | although the types come with transforms to/from JS |
| 18:24 | <croraf> | By signature I mean the list of attributes and operations. And as per the following the Interface defines just this: "Objects that implement the GraphicalWindow interface will expose these attributes and operations in a manner appropriate to the particular language being used." |
| 18:26 | <Webb> | Are there any artifacts supporting the XML syntax for HTML? I'd like to find anything that would help validate instances: Schemas, DTDs, RNG, Schematron, etc? I'd also like to find XML examples. |
| 18:29 | <Domenic> | Webb: https://validator.nu/ can validate. |
| 18:44 | <Webb> | Is there anything else? Anything normative or machine-readable? |
| 18:50 | <croraf> | andreubotella, we also have the term class like: https://fetch.spec.whatwg.org/#headers-class . Is the Headers interface just the IDL card on the top (the interface Headers {...}) or is part of the interface something from the prose? |
| 18:51 | <croraf> | The term class hear is meant the JS class I suppose. |
| 18:51 | <andreubotella> | it's part of the prose |
| 18:52 | <croraf> | andreubotella, is maybe the entire section 5.1 the description of the Headers interface? |
| 18:53 | <croraf> | (this section is the one linked above) |
| 18:53 | <andreubotella> | yeah |
| 18:54 | <croraf> | thanks. I'm clear now. |
| 20:52 | <isd> | What is the appropriate venue to talk about webrtc? from poking around I haven't found anything to do with it in the whatwg specs. The standards are IETF and w3c, but they look "done;" no updates on the mailing lists in over a year. |
| 20:53 | <Domenic> | isd: maybe their GitHub repositories? |
| 21:02 | isd | looks |
| 21:24 | <isd> | Hm. It doesn't look like the webrtc github org is very active/in good condition either. They have some pinned repos with test data & samples, but nothing that looks like a viable forum for discussion, and issues like this one don't give me a lot of confidence: https://github.com/webrtc/samples/issues/1350 |
| 21:35 | <isd> | Is there a reason whatwg doesn't have anything in the specs about webrtc APIs? It seems odd to have an API that's essential to widely used applications just not be referenced at all. |
| 21:37 | <Domenic> | Well, specs are different from applications, and need different things. |
| 21:38 | <isd> | I'm not entirely sure I follow. |
| 21:39 | <Domenic> | Why would specs reference WebRTC APIs? Just because applications do, doesn't mean specs should. |
| 21:43 | <isd> | Perhaps I misunderstand the scope of whatwg: it seems like if applications in the wild are heavily using an API that is not in the standard, then that is an incompleteness in the standard? It seems like a goal is to specify the web platform, and this seems like it ought to be a part of that? |
| 21:46 | <Domenic> | The goal is not to specify the whole web platform. Each specification has a specific scope that it covers. There are many specifications, from many different organizations (to name a few: WHATWG, W3C, Ecma, IETF, Khronos, CABF, ...) which come together to form the web platform. |
| 21:49 | <isd> | I see. |
| 22:34 | <MikeSmith> | Domenic: I see you made all the fixes needed to the HTML patch |
| 22:34 | <MikeSmith> | and merged |
| 22:35 | <MikeSmith> | thanks much for taking care of that (and the Wattsi fixes that were needed too) |
| 22:39 | <MikeSmith> | isd: https://github.com/w3c?q=webrtc |
| 22:40 | <MikeSmith> | > 24 results for repositories matching webrtc |
| 22:40 | <MikeSmith> | isd: I think the WebRTC working group is quite actively still working on spec updates |
| 22:41 | <MikeSmith> | > Updated 16 hours ago |
| 22:41 | <MikeSmith> | etc |
| 22:41 | <croraf> | I'm checking the consume body https://fetch.spec.whatwg.org/#concept-body-consume-body when used with text(). Step 4 has two things suspicious to me. |
| 22:42 | <croraf> | A) it says "with the first argument given", what does that mean? |
| 22:43 | <croraf> | B) it says "and object's MIME type" with the link on MIME type saying that objects implementing Body gain MIME type. It is not clear to me how they get MIME type? |
| 22:47 | <croraf> | (MDN for example doesnt mention the MIME type property, and I couldn't find it in the response object gotten after fetch) |
| 22:48 | <croraf> | https://developer.mozilla.org/en-US/docs/Web/API/Body |
| 22:48 | <andreubotella> | "MIME type" there is a (browser-internal) variable |
| 22:48 | <andreubotella> | or field, rather |
| 23:01 | <croraf> | How would I know that? And the associated body is also an internal body field and not the one exposed by the IDL? |
| 23:01 | <croraf> | andreubotella, |
| 23:04 | <andreubotella> | interfaces and mixins can have associated fields, and they're usually marked as such, "a Response object has an associated response", "objects implementing the Body mixin have an associated body" |
| 23:04 | <andreubotella> | they're understood not to be exposed through the WebIDL API by default, but they can be |
| 23:16 | <croraf> | andreubotella, thanks once again. And the last thing if you can address my question A) above |
| 23:17 | <andreubotella> | that also wasn't obvious to me at first sight |
| 23:17 | <andreubotella> | `upon fulfillment` there takes some caller-specific code -- a closure, if you will |
| 23:17 | <andreubotella> | that closure should call package data with the first argument passed to it |
| 23:19 | <croraf> | OK, makes sense. Ty |
| 23:19 | <croraf> | Perhaps this "given" might be worded better. |
| 23:20 | <andreubotella> | yeah |
| 23:20 | <croraf> | The bullet 5. also has some strange wording. |
| 23:21 | <croraf> | "Return the result of upon fulfillment of promise given steps." |
| 23:21 | <isd> | MikeSmith: aha, thanks |
| 23:21 | <andreubotella> | croraf: see https://github.com/whatwg/infra/issues/320 for that |
| 23:21 | <croraf> | While WebIDL says: "To perform some steps upon fulfillment of a Promise<T> promise given some steps steps taking a value of type T, perform the following steps:" |
| 23:25 | <croraf> | andreubotella, my small objection is that you cannot "have the result of upon fulfillment" but you can "perform some steps upon fulfillment". Perhaps the outcome is equivalent and obvious to the experienced reader. |
| 23:27 | <andreubotella> | yeah, well, fetch here is using "upon fulfillment" as the name of the algorithm when it maybe should use "return the result of performing `steps` upon fulfillment" |
| 23:27 | <andreubotella> | feel free to open a pull request if that bothers you |
| 23:34 | <croraf> | https://heycam.github.io/webidl/#dfn-perform-steps-once-promise-is-settled this is the sentence that confused me the most |
| 23:34 | <croraf> | Like which "2 sets of steps... promise that is fullfilled, rejected, or BOTH". But I understand it now. |
| 23:35 | <andreubotella> | it's basically an equivalent of Promise.prototype.then, which can take one or two functions |
| 23:35 | <croraf> | They meant one set of steps when promise is fulfilled, one set when rejected, or provide 2 sets of step for both cases. |
| 23:39 | <croraf> | andreubotella, what if reading all bytes rejects its promise https://fetch.spec.whatwg.org/#concept-body-consume-body |
| 23:39 | <croraf> | This case seems not to be covered. |
| 23:40 | <croraf> | The promise in bullet 5 is defined in bullet 3. If it fails the upon fulfillment does nothing. And what is returned then? |
| 23:44 | <andreubotella> | I'm not too familiar with the promise operations in WebIDL, but from a first glance, it looks like the rejection would be ignored and the returned promise would succeed with undefined |
| 23:47 | <croraf> | thanks. It boils down to the return of upon fulfillment when the promise is rejected. |
| 23:49 | <croraf> | That is this: Return ! PerformPromiseThen(promise.[[Promise]], onFulfilled, onRejected, newCapability) |
| 23:49 | <croraf> | when rejected happens |
| 23:49 | <croraf> | (last bullet in React to promise in WebIDL) |
| 23:51 | <croraf> | PerformPromiseThen kind of leads me to the broken link in the ECMAScript spec. |
| 23:52 | <croraf> | (oh actually it takes some time to jump, so something crashes kind of) |
| 23:53 | <croraf> | Yes, I think the .text() in this specific case just returns a promise that gets rejected when the error in reading happens. |
| 23:54 | <andreubotella> | I'm not sure it does, since the rejection steps return undefined |
| 23:54 | <andreubotella> | that strikes me as a WebIDL bug, but I'll have to look deeper into it |
| 23:57 | <croraf> | Aha, I see. It says to return undefined as onRejectedSteps. |
| 23:58 | <croraf> | And then this "undefined" will be called. |