| 02:11 | <mounir> | smaug: re: the media remoting intent to implement? |
| 02:12 | <mounir> | smaug: it's not a spec, it's more an intervention from the browser to force a video to be remoted when a tab is mirrored |
| 02:12 | <mounir> | smaug: hopefully, it answers your question :) |
| 02:14 | <smaug> | mounir: how is https://w3c.github.io/remote-playback API related to this all? |
| 05:26 | <MikeSmith> | nox: I see Safari fails http://w3c-test.org/dom/lists/DOMTokenList-iteration.html with “assert_array_equals: lengths differ, expected 3 got 2” (which is different than the “assert_equals: expected function "function keys() { [native code] }" but got function "function keys() { [native code] }"” failure in Chrome) |
| 08:26 | <nox> | MikeSmith: Yes, what do you say about that Safari failure? |
| 08:26 | <nox> | MikeSmith: Legit or not? The test is wrong or Safari is wrong? |
| 08:34 | <annevk> | jgraham: https://github.com/w3c/web-platform-tests/pull/4090 |
| 08:35 | <annevk> | jgraham: I'm going to merge that today unless you tell me not to |
| 08:43 | <annevk> | tobie: POPO is very reminiscent of GOP |
| 08:43 | <annevk> | tobie: kinda like it though |
| 08:44 | <tobie> | tobie: it's a wink at Java, though, which has Pojo. |
| 08:48 | <annevk> | tobie: hah, that makes it even better |
| 08:56 | <tobie> | annevk: you're evil |
| 08:56 | <tobie> | :) |
| 09:06 | <annevk> | tobie: btw, we should try to remember to file syntax changes at https://github.com/plinss/widlparser/issues/18 |
| 09:06 | <annevk> | tobie: though as long as enough specifications use bikeshed I guess that happens automatically... |
| 09:07 | <tobie> | annevk: I think I'm going to add a guide as to when and where we should file what. |
| 09:07 | <tobie> | annevk: Is the README a good place for that? |
| 09:08 | <annevk> | tobie: yeah |
| 09:08 | <tobie> | Good |
| 09:28 | <MikeSmith> | nox: bz wrote that test :) so if I had to bet my own money I’d bet for bz’s test being right rather than Safari |
| 09:29 | <nox> | MikeSmith: Then the spec is wrong too. |
| 09:29 | <Ms2ger> | That's a first |
| 09:30 | <nox> | Nah it's not, but if only Firefox and bz are correct, maybe they should be considered wrong. |
| 09:30 | <annevk> | Wait hold on, there's an open issue on this |
| 09:30 | <nox> | annevk: Hah, nice. |
| 09:30 | <MikeSmith> | hmm I see the test got changed after bz wrote it https://github.com/w3c/web-platform-tests/commit/f521cb4c87e964e32ebdf4b648da013e3c05e957 |
| 09:31 | <annevk> | nox: https://github.com/whatwg/dom/issues?utf8=%E2%9C%93&q=is%3Aissue%20is%3Aopen%20domtokenlist |
| 09:31 | <nox> | annevk: Not seeing an issue about this. |
| 09:32 | <nox> | Oh the second one. |
| 09:34 | <nox> | Such a mess. |
| 09:41 | <nox> | annevk: So no decision has been made yet, right? |
| 09:44 | <annevk> | nox: nothing conclusive, only that we prefer Safari's behavior |
| 09:44 | <nox> | annevk: So we prefer removing dupes, right? |
| 09:44 | <annevk> | nox: yeah |
| 09:45 | <annevk> | nox: ideally it's a set |
| 09:45 | <annevk> | because that's what it is... |
| 09:45 | <nox> | Yeah. |
| 11:08 | <mkwst> | annevk: QQ: Is Encoding or HTML the canonical reference for things like "ASCII case-insensitive"? |
| 11:10 | <nox> | mkwst: Isn't it DOM? https://dom.spec.whatwg.org/#ascii-case-insensitive |
| 11:11 | <mkwst> | nox: Ok, so that's three documents that look like they define the same term in the same way. |
| 11:11 | <nox> | mkwst: https://html.spec.whatwg.org/#ascii-case-insensitive Oh nevermind. :) |
| 11:11 | <nox> | mkwst: Yeah I had forgotten they also define it. |
| 11:11 | <mkwst> | nox: https://encoding.spec.whatwg.org/#ascii-case-insensitive :) |
| 11:11 | <nox> | mkwst: At least it's the same definition! :D |
| 11:12 | <nox> | Could be 3 different ones. :D |
| 11:13 | <mkwst> | Not exactly the same. HTML is missing "inclusive", which appears in both Encoding and DOM. |
| 11:13 | <mkwst> | *shrug* Not a huge deal, I just want to make sure I'm pointing to the one folks want to keep. :) |
| 11:17 | <Ms2ger> | mkwst, I think I'd use Encoding |
| 11:29 | <mkwst> | Ms2ger: Ok. Going with that for the moment. If there's a plan for merging these duplicate definitions, I can probably make some time to help out. |
| 11:30 | <Ms2ger> | I think that'd probably be a good idea, but annevk gets to make that call, I think |
| 11:30 | <Ms2ger> | Arguably it should live in some kind of a "core definitions" spec |
| 11:32 | <annevk> | mkwst: Ms2ger: I'm working with Domenic on that |
| 11:32 | <annevk> | mkwst: Ms2ger: not quite ready to publish just yet |
| 11:33 | <mkwst> | annevk: Ok. Great! |
| 11:37 | <mkwst> | So, Encoding today, Core Whatever tomorrow? |
| 11:37 | <nox> | annevk, Ms2ger: Inb4 "The Miscellaneous Standard" |
| 11:40 | <MikeSmith> | so, given https://github.com/w3c/webauthn/issues/created_by/bzbarsky it seems like the Web Authentication spec is maybe an excellent example to use for why we need to have better guidelines for spec editors on how to write good specsーespecially how to write APIs and importance of understanding WebIDL |
| 11:41 | <MikeSmith> | (bz raised 49 issues against it in one day) |
| 11:42 | <annevk> | mkwst: basically |
| 11:42 | <annevk> | nox: heh |
| 11:49 | <nox> | annevk: Or just util, hah. |
| 11:50 | <Ms2ger> | MikeSmith, ouch |
| 11:53 | <MikeSmith> | Ms2ger: bravo bz on taking time to review it in detail and raise the issues |
| 11:53 | <MikeSmith> | seems like it was not exactly a labor of love |
| 11:53 | <MikeSmith> | and must have taken hours |
| 11:54 | <Ms2ger> | I wish we had more people who would take the time to carefully review random specs |
| 12:03 | <MikeSmith> | sure but at the same time we should ideally really not have people writing specs for the platform that end up being that far off the mark |
| 12:03 | <MikeSmith> | and it’s not because they aren’t smart and extremely capable people |
| 12:04 | <MikeSmith> | it seems instead that there is just a lot of prior knowledge required to do it right |
| 12:06 | <MikeSmith> | though I have to say one red flag with the Web Auth spec is that it has 9 editors listed https://w3c.github.io/webauthn/ |
| 12:11 | <MikeSmith> | and see also https://github.com/w3c/webauthn/issues/276#issuecomment-258736759 and https://github.com/w3c/webauthn/issues/262#issuecomment-258724693 where bz has to explain why editors should not read and reference TR drafts but should instead work from EDs (in a specific case where the Web Crypto TR draft does something wrong that the ED has corrected) |
| 12:12 | <Ms2ger> | Well, that could easily be solved by the w3c |
| 12:14 | <annevk> | Yeah, groups need to be pre-approved by MikeSmith before they get more than 2 editors for a document |
| 12:15 | <MikeSmith> | done! |
| 12:15 | MikeSmith | edits the Process document in place to add that requirement |
| 12:18 | <Ms2ger> | Easily solved, we'll just publish each section as a separate document, and assign "editors" at random |
| 12:19 | <MikeSmith> | good brainstorming |
| 12:21 | MikeSmith | in-place edits the Process doc to add that too |
| 12:24 | <MikeSmith> | seriously though I think we have a real problem when a key implementor/code-reviewer from a browser-engine project has to burn up hours documenting fairly fundamental errors in a major spec |
| 12:24 | <MikeSmith> | kinda significant opportunity cost there |
| 12:31 | <annevk> | Well, there's not that many people with the number of years of experience |
| 13:07 | <MikeSmith> | annevk: sure but we also could have better guidelines with more detail and examples |
| 13:07 | <MikeSmith> | including examples of anti-patterns to avoid |
| 13:08 | <MikeSmith> | the problem is that the people capable of writing the guidelines at the ones already very busy writing/refining specs |
| 13:09 | <annevk> | Domenic has done a lot in that area |
| 13:09 | <annevk> | But we also lack solid examples |
| 13:10 | <annevk> | Most standards are not in a great state |
| 13:11 | <annevk> | And typically new editors do some combination of copy-and-pasting and adjusting to their scenario, without truly understanding |
| 13:11 | <annevk> | And you won't really get true understanding from day one, that takes practice |
| 13:12 | <tobie> | heycam|away: would be awesome if you could have a look at https://github.com/heycam/webidl/pull/221 |
| 13:15 | <tobie> | MikeSmith: I'm certainly hoping to improve the WebIDL spec to make it easier for people to consume and do the right thing. |
| 13:22 | <MikeSmith> | tobie: yes please |
| 13:22 | <MikeSmith> | extremely glad you are on that |
| 13:23 | <MikeSmith> | I think it can help a lot |
| 13:23 | <tobie> | MikeSmith: ideas welcome. I'm trying to add more notes to explain the reasoning behind things |
| 13:24 | <tobie> | MikeSmith: feel like "note for spec editors" could be useful as well as more examples. |
| 13:24 | <tobie> | MikeSmith: the intro needs fixing |
| 13:24 | <MikeSmith> | more examples would absolutely help |
| 13:24 | <tobie> | MikeSmith: marking legacy stuff as such more clearly would also be a good thing |
| 13:26 | <annevk> | Yeah, once we have the legacy platform object split sorted, actually marking getters/setters as legacy would be great |
| 13:30 | <annevk> | JakeA: where did you want Response or undefined again? |
| 13:39 | <annevk> | littledan__: https://github.com/heycam/webidl/issues/226 |
| 13:39 | <annevk> | littledan__: might be interest |
| 13:45 | <JakeA> | annevk: caches.match, but also fetchEvent.preloadResponse |
| 13:46 | <annevk> | JakeA: pinged you in an issue |
| 13:46 | <annevk> | JakeA: about undefined and IDL |
| 13:49 | <JakeA> | annevk: cheers, added to it |
| 15:57 | <littledan__> | Annevk, interesting, don't see a great solution |
| 16:53 | <tobie> | annevk, Domenic: Is the object implementing an interface with Global or PrimaryGlobal extended attribute: |
| 16:53 | <tobie> | 1) a platform object |
| 16:53 | <tobie> | 2) a legacy platform objct |
| 16:53 | <tobie> | 3) something else |
| 16:54 | <tobie> | 4) a legacy platform object if it has indexed props, a platform object otherwise |
| 16:54 | <tobie> | 5) ... ? |
| 16:57 | <Domenic> | annevk: they will never have indexed/named props in practice; we should probably make that a normative requirement |
| 16:57 | <Domenic> | er, tobie: ^ |
| 16:57 | <Domenic> | tobie: I think it is an immutable prototype exotic object |
| 16:57 | <Domenic> | but also a platform object |
| 16:57 | <Domenic> | similar to how legacy platform objects are also platform objects |
| 16:57 | <tobie> | Domenic: so they're platform object with a special prototype, right? |
| 16:58 | <Domenic> | not a special prototype |
| 16:58 | <Domenic> | a special [[SetPrototypeOf]] |
| 16:58 | <tobie> | oh |
| 16:58 | tobie | tries to grasp the nuance. |
| 16:58 | <Domenic> | [[SetPrototypeOf]]() is an internal method that, normally, sets this.[[Prototype]] |
| 16:58 | <tobie> | yes. |
| 16:59 | <Domenic> | But for immutable prototype exotic objects, they have an overridden [[SetPrototypeOf]]() that throws an error |
| 16:59 | <Domenic> | https://tc39.github.io/ecma262/#sec-immutable-prototype-exotic-objects |
| 16:59 | <Domenic> | I think we end up with three categories of platform objects: "non-exotic platform objects", "immutable prototype exotic objects", and "legacy platform objects" |
| 17:00 | <Domenic> | I guess "immutable prototype exotic platform objects" |
| 17:01 | <Domenic> | since Object.prototype is not an immutable prototype exotic **platform** object, just an immutable prototype exotic object |
| 17:01 | <Domenic> | s/throws an error/returns false, which causes various callers, like Object.setPrototypeOf, to throw an error/ |
| 17:04 | <tobie> | Domenic: the spec says: "For every interface declared with the [Global] or [PrimaryGlobal] extended attribute that supports named properties," (https://heycam.github.io/webidl/#dfn-named-properties-object) |
| 17:04 | <Domenic> | tobie: ah I see |
| 17:04 | <tobie> | Domenic: I think I understand what this means, but the language needs to be fixed |
| 17:05 | <Domenic> | tobie: I think that language is correct. What's incorrect is that all the other definitions don't say "except not for globals" |
| 17:05 | <Domenic> | tobie: e.g. https://heycam.github.io/webidl/#getownproperty should not apply to globals |
| 17:06 | <Domenic> | tobie: so if a global supports named properties, nothing about it becomes exotic (besides the unrelated exoticness of [[SetPrototypeOf]]) |
| 17:06 | <Domenic> | tobie: instead, it just gets a special [[Prototype]] which is the named properties object |
| 17:08 | <tobie> | Domenic: So can I get away with defining all legacy platform objects as have named/index props but are not Global or Primary Global? |
| 17:08 | <Domenic> | tobie: correct |
| 17:09 | <tobie> | Domenic: alright, right now the spec disallows named props on Globals or PrimaryGlobals, but not indexed props. |
| 17:10 | <Ms2ger> | Though there's no indexed props on any globals |
| 17:10 | <tobie> | Domenic: so for the above definition to hold, I need to disallow that too as part of the same PR, agreed? |
| 17:10 | <Ms2ger> | There are on WindowProxy, but that's fine |
| 17:10 | <Domenic> | tobie: that seems good yes. |
| 17:10 | <Domenic> | tobie: the spec shouldn't disallow named props on globals, but it should give them a different meaning. |
| 17:11 | <tobie> | named props on globals are for the globals vars, right? |
| 17:11 | <Domenic> | they're for id="" and name="" |
| 17:11 | <Domenic> | https://html.spec.whatwg.org/multipage/browsers.html#named-access-on-the-window-object |
| 17:18 | <tobie> | Domenic: OK. I think I got it. |
| 17:18 | <tobie> | Domenic: Thanks |
| 17:18 | <Domenic> | \o/ |
| 17:18 | <Domenic> | This is gonna be pretty nice |
| 17:27 | <Ms2ger> | https://twitter.com/mikewest/status/795660581823016961 |
| 17:31 | <tobie> | Is [LegacyUnenumerableNamedProperties] appearing anywhere else than on globals, and are there globals with named props that don't have that extended attribute? |
| 17:32 | <tobie> | It sort of feels redundant, but maybe I'm missing out on more fun. |
| 17:40 | <Domenic> | I don't quite remember... nox added it. |
| 17:40 | <Domenic> | tobie: oh it's used several times in DOM |
| 17:41 | <tobie> | Domenic: so yeah, was clearly missing out on the fun |
| 17:45 | <annevk> | Ms2ger: sounds like mkwst has figured out the web |
| 17:46 | <annevk> | tobie: [LegacyUnenumerableNamedProperties] is used for non-globals |
| 17:46 | <annevk> | tobie: only Window has named properties |
| 17:47 | <annevk> | (and frankly, I don't think we should allow any new global to have named properties) |
| 17:47 | <tobie> | annevk: yeah--Domenic mentioned it was used in Dom |
| 17:47 | <annevk> | tobie: it's used in HTML too for several things |
| 17:47 | <annevk> | tobie: <form> for instance |
| 17:48 | <tobie> | annevk: oh, form |
| 17:48 | <tobie> | annevk: yeah, I can see how that would be needed |
| 17:57 | <tobie> | Wish I could write: LegacyPlatformObjectGetOwnProperty(|O|, |P|, false) instead of: |
| 17:58 | <tobie> | Return the result of invoking the [=The LegacyPlatformObjectGetOwnProperty abstract operation|PlatformObjectGetOwnProperty=] |
| 17:58 | <tobie> | abstract operation with |O|, |P|, and <emu-val>false</emu-val> as arguments. |
| 18:01 | <annevk> | tobie: why can't you? |
| 18:01 | <tobie> | annevk: can I? |
| 18:01 | <annevk> | tobie: if you're going to do abstract operations you should go all the way |
| 18:02 | <annevk> | tobie: HTML does this too for defining WindowProxy and Location |
| 18:02 | <annevk> | And StructuredClone, come to think of it |
| 18:02 | <tobie> | That sounds much better |
| 18:04 | <annevk> | tobie: for IDL I'd basically draw a lot of inspiration from ECMAScript as you rewrite and fix things |
| 18:05 | <tobie> | annevk: sgtm |
| 18:09 | <Domenic> | tobie: yeah definitely write it that way |
| 18:53 | <nox> | tobie, Domenic: Yeah made LegacyWhatsItsName to replace some prose with unenumerable properties. |
| 18:53 | <nox> | I still have trouble writing that word, unenumerable. |
| 19:52 | <TabAtkins> | MikeSmith: You should reject the change, it's just Bert being cranky/wrong. |
| 20:36 | <smaug> | oh, Chrome throws when accessing cross-domain iframe.contentDocument |
| 20:38 | <smaug> | looks like per spec it should be just null |
| 21:09 | <jarek> | Is there any particular reason why HTML elements are using "open" boolean attribute rather than "opened"? |
| 21:09 | <jarek> | E.g. <dialog open> or <details open> |
| 21:10 | <jarek> | I'm not native English speaker, but I thought both "open" and "opened" would be grammatically correct in this scenario |
| 21:10 | <jarek> | However, "open" is more ambiguous as it could be a method name as well |
| 21:16 | <KiChjang> | jarek, what is a "method name" in the context of HTML? |
| 21:16 | <jarek> | KiChjang: window.open() for example |
| 21:17 | <KiChjang> | that is javascript |
| 21:17 | <KiChjang> | or rather, WebIDL |
| 21:17 | <jarek> | yeah, or DOM |
| 21:17 | <jarek> | but keep in mind that the "open" attribute is reflected as WebIDL property |
| 21:17 | <TabAtkins> | jarek: Yes, either is correctly. "open" is more of a state term; "opened" is somewhat ambiguous, as it can refer to the current state *or* a past state. |
| 21:18 | <TabAtkins> | Like, if it was opened at any point, it might match "opened" (see: email read indicators), but it won't match "open" unless it is *currently* open. |
| 21:19 | <jarek> | TabAtkins: you could say the same about "disabled" |
| 21:19 | <TabAtkins> | Yes, but we don't have a corresponding "only current state" term for being disabled. |
| 21:19 | <TabAtkins> | So we work with what we've got. |
| 21:20 | <jarek> | Polymer seems to be using "opened": https://elements.polymer-project.org/elements/paper-dialog#property-opened |
| 21:20 | <jarek> | I think this is the case with more libraries too |
| 21:20 | <jsbell> | Heh - https://html.spec.whatwg.org/multipage/forms.html#anchor-points refers to the "open() method" which links to the open attribute |
| 21:21 | <KiChjang> | i... don't think this is a good change |
| 21:21 | <KiChjang> | to the HTML spec |
| 21:21 | <KiChjang> | very backwards-incompatible for little gain(?) |
| 21:21 | <jarek> | KiChjang: so do I, it's way to late. I'm just trying to understand the rationale |
| 21:22 | <TabAtkins> | jsbell: That looks like a bug. Report it? |
| 21:22 | <jsbell> | TabAtkins: doing so |
| 21:24 | <annevk> | jarek: might be as simple as something that was not fully considered |
| 21:25 | <KiChjang> | it's also interesting to note that it only has an open boolean attribute, but not close/closed |
| 21:26 | <KiChjang> | i think it's just because the default state is closed |
| 21:26 | <KiChjang> | so no need to specify |
| 21:26 | <KiChjang> | it can just use close instead of open |
| 21:33 | <jarek> | BTW, why boolean attributes are serialized to e.g. `<dialog open="">` rather than `<dialog open>`, is this a standard behavior? |
| 21:33 | <jarek> | This looks confusing to me because the spec is using `<dialog open>` format in all examples |
| 21:34 | <jarek> | by serialized, I mean e.g. element.outerHTML |
| 21:36 | <jarek> | I found this: https://www.w3.org/TR/html5/single-page.html#html-fragment-serialization-algorithm |
| 21:36 | <jarek> | but it doesn't seem to mention how boolean attributes should be serialized |
| 21:37 | <jarek> | No, wait... it does: For each attribute that the element has, append a U+0020 SPACE character, the attribute's serialized name as described below, a "=" (U+003D) character, a U+0022 QUOTATION MARK character ("), the attribute's value, escaped as described below in attribute mode, and a second U+0022 QUOTATION MARK character ("). |
| 21:41 | <jarek> | this seems unnecessarily verbose and inconsistent to me |
| 21:42 | <KiChjang> | "Please leave your sense of logic at the door, thanks!" |
| 21:43 | <KiChjang> | sometimes specs are written that way just because decisions were made, then propagated to all existing webpages you see nowadays |
| 21:44 | <KiChjang> | jarek, this is relevant |
| 21:44 | <KiChjang> | https://html.spec.whatwg.org/multipage/introduction.html#design-notes |
| 21:45 | <KiChjang> | also, the equivalent WHATWG section of your linked spec is https://html.spec.whatwg.org/multipage/syntax.html#serialising-html-fragments |
| 21:51 | <jarek> | KiChjang: I guess it was defined this way to make it compatible with XML somehow? |
| 21:52 | <KiChjang> | it may have been the case where boolean attributes did not exist in the first few versions of HTML |
| 21:52 | <KiChjang> | and the serializers were never patched or fixed for the case of encountering a boolean attribute |
| 21:53 | <jarek> | on the bright side, it could be much worse, e.g. `<dialog open="open">` |
| 21:54 | <jarek> | or even <DIALOG OPEN="OPEN"> |