2018-11-01 [02:01:20.0000] TimothyGu: I think ffi et al don't happen because they're marked F, which isn't touched for a simple case folding [02:01:37.0000] TimothyGu: ECMAScript is rather vague about the exact algorithm involved though [02:03:31.0000] Nah, I guess it's fine [15:24:32.0000] hmm, https://www.google.co.jp/search?q=foo&oq=foo&aqs=chrome..69i57j69i61j69i60l2j0l2.2320j0j7&sourceid=chrome&ie=UTF-8 [15:24:44.0000] Well, well, well. What do we have here? An Origin Policy violation. [15:24:44.0000] And what do we not have? A page! [15:25:22.0000] mkwst: ↑ [16:07:54.0000] Is there any reason why I shouldn't write something like as instead? [16:15:43.0000] innovati: That's valid, it's a custom element then. (As long as it has a dash in it.) [16:37:20.0000] Thanks :) If I intend to enhance these elements only with CSS to style it how I like, would there be any browser support issues if I used these in IE11 (and newer)? 2018-11-02 [17:52:46.0000] innovati: you’re not going to have any issues with CSS styling. That video-container element will be parsed into that DOM and be styleable just like any other standard element [18:26:17.0000] thanks :D [06:22:22.0000] Oh fun, we have loads of tests with pointing at http://www.w3.org/TR/2013/WD-html-templates-20130214/. Metadata in tests is great, because it's never outdated. [08:19:09.0000] gsnedders: hmm, I can PR that I suppose [08:19:33.0000] I mean, it's not really worth anyone's time IMO [08:19:49.0000] it's just further evidence that adding loads of metadata is pointless because nobody maintains it [08:21:38.0000] it would be useful if we used other systems that consumed that data and did something valuable with it [08:21:57.0000] which we don’t [08:22:40.0000] and in fact the trend seems to be toward doing the opposite thing and linking from the specs to the test cases instead [08:22:57.0000] e.g., using in Bikeshed [08:23:09.0000] but even having other systems doesn't matter, given we see enough cases in CSS where nobody bothers to update stuff [08:24:19.0000] I didn’t actually know that was the case for CSS ー that even they weren’t keeping that metadata up to date [08:25:11.0000] I mean, people basically care at the time when preparing an IR to advance to PR, and never otherwise. [08:25:16.0000] Which is my experience in general. [08:25:32.0000] anyway, not surprised that nobody keeps something up to date ー same old thing of, if not keeping it up to date doesn’t break anything, then nobody is ever going to get alerted that it’s gone out of date [08:25:40.0000] Almost all the cases I've seen of metadata in tests around the W3C it's only ever been properly maintained for PR advancement, and never otherwise, even if the tests are. [08:26:03.0000] Because the vast majority of metadata only has much value for PR [08:26:17.0000] well seems like the tests get neglected after that too [08:26:34.0000] Mission Accomplished 2018-11-04 [04:18:04.0000] What is used to parse and validate WebIDL interfaces in wpt? [04:36:15.0000] nox: webidl2.js [04:37:02.0000] nox: https://github.com/w3c/webidl2.js [04:59:54.0000] gsnedders: Thanks. [05:00:09.0000] gsnedders: But that only parses, right? [05:03:46.0000] nox: yes; depending on what you mean by validate, maybe /resources/idlharness.js? [05:05:30.0000] I mean for example failing if you try to have overloads for an operation in both the interface definition and one of the mixins. [05:05:56.0000] I think that's still done in webidl2.js? [05:06:05.0000] I'm not really too knowledgable about this, really. [05:07:32.0000] Ok! [05:12:19.0000] nox: It has to be in one of the two, though [05:12:26.0000] :) [06:02:50.0000] gsnedders: Context is https://twitter.com/nokusu/status/1058716551543775233 btw :) 2018-11-05 [02:45:15.0000] annevk: regarding https://github.com/w3c/resource-timing/pull/177#discussion_r230353907, I need to get from a request to the relevant global object. Is there a pre-defined way to do that? (from the discussion between you and Boris I understand that there isn't currently) [02:45:24.0000] (but want to make sure) [05:07:43.0000] yoav: a request doesn't really have a relevant global, there's a client [05:09:47.0000] yeah, which is not what we need in case of an iframe... [05:10:15.0000] so maybe it makes sense to special case iframes here? [05:18:17.0000] yoav: perhaps I was wrong about iframe [05:19:50.0000] annevk: ok, I'll put something together and ping you for your opinion [07:05:47.0000] yoav: annevk: does the request "associated window" help here? https://fetch.spec.whatwg.org/#concept-request-window [07:08:25.0000] wanderview: not familiar with it, so not sure how [07:09:18.0000] ok, maybe I just don't understand what you are trying to do... sorry for the confusion [08:06:17.0000] wanderview: don't be sorry :) It seems like the request's client might be the way to go after all [08:06:34.0000] (potentially with some conditions around it) [08:34:11.0000] Getting pretty close to defining response Content-Type... 2018-11-06 [20:00:38.0000] for “trailing commas” in JavaScript syntax, is there any specific fragment ID in the EcmaScript spec I can point to? [20:00:47.0000] see https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Trailing_commas for the context [20:15:19.0000] is that what Elision_opt indicates? [20:44:27.0000] when I look at a proposal in https://github.com/tc39/proposal-* space, how can I tell if it’s already been adopted into the current https://tc39.github.io/ecma262/ standard? (short of actually checking the current spec text) [20:45:11.0000] e.g., looking at https://github.com/tc39/proposal-trailing-function-commas I cannot tell if it’s been adopted or not from just looking at that [20:45:34.0000] I think it has been, but there’s no statement there to indicate that [20:50:44.0000] OK looking at https://github.com/tc39/proposals I see it’s not listed there, so I guess the process is that I see a proposal in https://github.com/tc39/proposal-*, I need to check https://github.com/tc39/proposals and see if it’s listed there ー but if it’s not, then I need to assume it’s already been adopted [20:52:03.0000] ah [20:52:11.0000] now I find https://github.com/tc39/proposals/blob/master/finished-proposals.md [21:08:51.0000] filed https://github.com/tc39/proposals/issues/162 [06:16:26.0000] so per spec HTMLAllCollection shouldn't have a @@iterator, right? [06:16:54.0000] because it does in FF/Ch, at least [06:17:03.0000] But I can't see any justification for that in the spec. [06:25:49.0000] ‘allo ‘allo [06:26:08.0000] I heard there was a discussion about document.all[Symbol.iterator]. [06:26:30.0000] Is that a thing that only exists in Gecko? [06:26:54.0000] 14:16 < gsnedders> so per spec HTMLAllCollection shouldn't have a @@iterator, right? [06:26:57.0000] 14:16 < gsnedders> because it does in FF/Ch, at least [06:26:59.0000] 14:17 < gsnedders> But I can't see any justification for that in the spec. [06:28:56.0000] Oh interesting find. [06:29:54.0000] I'm wondering if I've misread the spec here [06:31:49.0000] I've misread WebIDL, I think. [06:32:24.0000] "an indexed property getter and an integer-typed length attribute" [06:32:31.0000] which they do, hence they have a @@iterator [06:32:34.0000] okay, ignore me [06:50:10.0000] stupid question about DOM. If we have a document element the assumption is that it includes all the mixins that come with document? [06:51:57.0000] the document has them, the document elmenet is the root element [06:52:02.0000] AutomatedTester: I don't really understand the question [06:52:10.0000] unless you're not asking what I think you are? [06:52:27.0000] I might not be asking it properly... [06:54:00.0000] so my question is do I need to explicitly call out document or shadowRoot for knowing where items should start from. E.g. in webdriver we have the start node for finding elements as the document element but if I want to search a shadow dom I need to use the shadowRoot [06:54:40.0000] so is having it as the document fine or do I need to explicitly say document or shadowRoot [06:56:35.0000] AutomatedTester: what are you using to find things? I presume you just do it by reference to Selectors or XPath? [06:56:47.0000] https://w3c.github.io/webdriver/#find-element step 7 to be exact [06:56:54.0000] gsnedders: yes [06:58:16.0000] since there is no way to pierce a shadow dom otherwise we break encapsulation we need to set the start node to the shadowRoot and then search which is the equivalent of shadowRoot.querySelector(...) [07:03:55.0000] AutomatedTester: hmm, doesn't WebDriver have super powers anyway? Why not break encapsulation? [07:04:41.0000] annevk: we could but then we need to build our own selectors for starting at the top level and descending into a shadow dom [07:05:10.0000] AutomatedTester: anyway, if you want to go through shadow trees, you need to say so, and define how [07:05:17.0000] AutomatedTester: there's no freebies [07:05:27.0000] and I am not sure we can guarantee a view into closed shadow dom's [07:05:47.0000] annevk: thats what I thought and just wanted to check [07:06:40.0000] AutomatedTester: WebDriver should be able to do that I think, but it might require the browser to provide ways [07:10:24.0000] annevk: what was the plan for testing this for end users or was this "webdriver will solve this... probably" [07:16:05.0000] AutomatedTester: end users being? [07:16:26.0000] annevk: website QA folk [07:16:55.0000] AutomatedTester: I think the idea there was that WebDriver would indeed provide hooks [07:17:07.0000] gsnedders: I think [...collection] does some magic because for-of doesn’t work. [07:17:09.0000] AutomatedTester: but there wasn't a lot of discussion about that, for sure [07:17:22.0000] gsnedders: I think reading ECMAScript might reveal some clues. [07:18:44.0000] ato: both should just call the iterator, no? [07:19:04.0000] annevk: my worry is that since deep selectors were dropped its going to be non-trivial to allow people to call from the document down into a shadow dom [07:19:14.0000] feels like there are a lot of dragons down there [07:21:10.0000] ato: for (let x of document.all) console.log(x); [07:21:13.0000] ato: that wfm? [07:21:30.0000] gsnedders: OK, maybe HTMLAllCollection is not the problematic one here. [07:21:53.0000] https://searchfox.org/mozilla-central/source/testing/web-platform/tests/webdriver/tests/execute_script/collections.py for reference. [07:23:03.0000] HTMLFormControlsCollection works with for-of. [07:23:36.0000] And HTMLOptionsCollection. [07:23:53.0000] AutomatedTester: I don't really know what folks are looking for, but you could offer things that basically iterate over the document and all its shadow roots and and match the selectors given [07:24:06.0000] And NodeList. [07:24:17.0000] AutomatedTester: it's just that we don't want to expose those kind of things directly to web pages [07:24:40.0000] And HTMLCollection. [07:24:47.0000] annevk: I think people want /deep/ [07:25:33.0000] AutomatedTester: I guess I'm saying is that if they say that, we need to dig a little deeper since a) it doesn't work for closed trees and b) we don't want a different selector parser for WebDriver [07:25:52.0000] agreed! [07:26:23.0000] if I can offload to the webapi's then I can somewhat guarantee interop [07:26:36.0000] AutomatedTester: we can offer utilities that do some kind of query on all shadow roots associated with a document and return nodes in some manner, but if we can't move the conversation past /deep/ I'd just let it slide for now... [07:26:56.0000] (note that this APIs would have to be WebDriver only) [07:27:03.0000] these* [07:27:15.0000] As does Arguments. [07:27:26.0000] at the moment I can get around most cases (excluding closed shadow doms) using document or shadowRoot [07:27:33.0000] and then base things off that [07:28:31.0000] annevk: if I were to start a conversation about the searchability where is the best place to do that? [07:28:56.0000] AutomatedTester: the WebDriver repo? [07:29:13.0000] AutomatedTester: as I said, we don't want these to be web-exposed APIs [07:29:17.0000] ok [07:29:36.0000] I will just @ the relevant people like you to discuss things further [07:29:45.0000] we have a thread there at the moment [07:29:49.0000] AutomatedTester: it's reasonable to start a WebDriver-specific thread on w3c/webcomponents though to point folks at that [07:29:56.0000] gsnedders: What. Even FileList works with for-of. [07:30:11.0000] annevk: thats what more what I was after :) [07:30:25.0000] AutomatedTester: okay, yeah, please do that [07:30:30.0000] will do [07:30:37.0000] gsnedders: OK, so am I right reading that the conclusion here is that it’s OK for the spec to rely on the collection implementing the Iterable interface? [07:30:57.0000] gsnedders: I mean the language I used is clearly wrong, but that we can use the normal iterator protocol? [07:31:01.0000] ato: it's a feature of IDL [07:31:27.0000] ato: IDL added it to reduce the amount of specifying we'd have to do to support it all over the place [07:32:11.0000] annevk: Let me point you to the actual bit of spec we’re discussing. [07:33:13.0000] annevk: In https://w3c.github.io/webdriver/#dfn-internal-json-clone-algorithm, under the “a collection” variant we say “For each item of value, …”. [07:33:38.0000] And collection is not quite the same as in DOM/HTML: https://w3c.github.io/webdriver/#dfn-collection [07:33:49.0000] (Here “type” should be “interface” I think.) [07:34:16.0000] But the effect we want to achieve is to rely on the each of these objects’ iterator protocols to run some JSON serialisation steps and add them to a JSON Array. [07:34:22.0000] ato: no, we want something like "instance of" except we need it to work cross-origin [07:34:31.0000] and I can't remember what the right way to define that [07:34:32.0000] gsnedders: Yes, I meant that actually! [07:34:49.0000] the right way today is what you did [07:35:03.0000] "is X" is the way to do that until we have [[PlatformBrand]] or equiv [07:35:40.0000] now actually invoking the iterator protocol I don't know, that has all kinds of potential side effects that I'm not sure you want here? [07:36:03.0000] in any event, simply saying "for of" doesn't cut it if you want to call JS operations [07:39:06.0000] We don’t particularly care how implementations do it, as long as the result of the algorithm is that you end up with a JSON Array with the objects passed through a serialisation step. [07:39:38.0000] So when you talk about side effects of invoking the iterator protocol and JS operations, I have a hard time understanding exactly what you mean. [07:40:02.0000] iterators can execute arbitrary code [07:40:07.0000] and throw exceptions, etc. [07:40:36.0000] Right, because they are custom? [07:40:42.0000] Or can be if the prototype has been replaced? [07:41:00.0000] Various things, once you run JavaScript stuff can throw [07:41:15.0000] OK, so I don’t think the intention here is to run JS. [07:41:18.0000] (and you'll also have to define other things, like what globals are in use and such) [07:41:35.0000] Right, and we do this for the actual script execution. [07:41:53.0000] (Where you receive a script string and inject it into the runtime.) [07:42:28.0000] ato: e.g., if I set document.all[Symbol.iterator], the iterator is no longer the default [07:42:47.0000] gsnedders: Got it. [07:43:07.0000] Words are hard (-: [07:44:02.0000] So when we say “for item of value” here, that doesn’t invoke the JS Symbol.iterator or the iterator protocol. What does it do? [07:44:38.0000] Is it inferred as an exercise for the reader to understand that you want to achieve the effect of looking at a DOM/HTML collections items in sequence without going down the same path as JS? [07:45:25.0000] Not trying to be nitpicky here by the way. Just trying to understand how this works. [07:45:27.0000] ato: it's not clear what it does since it's not defined [07:46:18.0000] In the Gecko implementation, what we do specifically is call what I guess is the initial value of the iterator protocol by doing [...collection] in XPCOM. [07:46:33.0000] ato: it does invoke the iterator protocol? [07:46:48.0000] Doesn’t the JS spread operator do that? [07:47:11.0000] https://searchfox.org/mozilla-central/rev/b096dcf0ea226af628fe03f7e7acb56a25853533/testing/marionette/evaluate.js#250-253 [07:47:11.0000] yes [07:47:15.0000] both do that [08:12:06.0000] ato: I think you want to convert from JS into Infra or Web IDL data structures as soon as possible. Then you can operate without running JS side effects. [08:13:00.0000] Although, I guess that conversion will itself have JS side effects [08:13:07.0000] So you need to go deeper -_- [08:13:11.0000] Domenic: so nobody working on Chrome's service worker implementation was considering this or they actively ruled out preloading one already somehow? [08:13:44.0000] annevk: from what they've told me there are engineering challenges with first-run service worker that they have no plans on solving [08:14:07.0000] For Firefox it's only the former as far as I know, the latter is to be seen [08:14:13.0000] Domenic: are those documented somewhere? [08:14:29.0000] Not that I know of [08:14:40.0000] Domenic: who would I ask? [08:14:41.0000] Domenic: Other implemenations are in Rust and C++, so we don’t want to tie the spec to JS if we can avoid it. [08:14:42.0000] But their vibe was that it was kind of common knowledge, so I dunno, maybe? [08:15:01.0000] Domenic: But I don’t really understand what you’re proposing… [08:16:08.0000] ato: My best guess so far is something like "for each supported property index (https://heycam.github.io/webidl/#dfn-supported-property-indices), run the algorithm specified for the collection's indexed property getter (https://heycam.github.io/webidl/#dfn-indexed-property-getter)" and collect all those into a list (https://infra.spec.whatwg.org/#lists) [08:16:37.0000] annevk: kinuko and matto [08:17:11.0000] Domenic: thanks [08:17:51.0000] ato: for Arrays you're totally screwed though, you'll have to run JS with side effects. E.g if someone does `new Array(3); Object.defineProperty(Array.prototype, "1", { get () { throw new Error("foo"); } })` there's no way to avoid hitting that exception [08:19:38.0000] ato: It appears you're also screwed for Arguments objects in a very similar way [08:20:33.0000] By "screwed" I mean "you'll run JS", not "unimplementable in Rust and C++" [08:20:41.0000] Rust and C++ implementations just need to use the JS API [08:21:08.0000] s/JS API/JS engine API [08:30:07.0000] Domenic: Thanks for explaining that, very useful! [08:30:39.0000] Domenic: So we are aware of the pitfalls that we can’t trust the input data to the algorithm, and I don’t think we particularly care that we fail in this case. [08:31:21.0000] Domenic: If a website makes an array throw an error on iteration and you try to return that array using an injected script, you would expect that behaviour. [08:31:28.0000] ato: but we do need to define well the failure case [08:31:39.0000] Yes, that sounds like what is missing here. [08:31:49.0000] Or, I mean, generally throughout the spec. [08:31:53.0000] +1. Ideally with tests ;) [08:32:25.0000] For the other commands in the specification, we expect them to work irregardless of prototype overrides. [08:32:46.0000] So it would be funny to see what happens if you inject a script replacing querySelectorAll or whatever and then you try using the Find Elements WebDriver command. [08:32:59.0000] My guess is that hillarity would ensue depending on the implementation. [08:33:12.0000] Domenic: How does jsdom cope with such Array.prototype shenanigans btw? [08:33:30.0000] It’s not entirely clear to me how to define these error scenarios, but I’ll file a bug and we can take it from there. [08:34:14.0000] It sounds like “define error scenarios” is orthogonal from s/type/instance of/ and indeed how to say “for item of value”. [08:34:27.0000] nox: it doesn't, yet. We haven't tried to harden it. But it could via the various techniques discussed here: https://github.com/domenic/get-originals/blob/master/Sample%20conversion.md#array-manipulation-analysis . (That doc uses a hypothetical "get originals" API, but jsdom has access to the originals via other means, so that part isn't necessary.) [08:34:49.0000] Domenic: Thanks for the link. [08:34:50.0000] ato: I think "define error semantics" is not orthogonal to "for item of value" because how you iterate is what generates or hides errors. [08:35:14.0000] You’re right. But maybe we can do it in steps. [08:35:24.0000] Would you say “for item of value” is the right terminology here? [08:36:13.0000] No [08:36:28.0000] Because it's not defined [08:47:59.0000] https://github.com/w3c/webdriver/issues/1349 [12:08:47.0000] Domenic: For Array, could we wrap them in a Proxy that uses the original Object.defineProperty in its set method? [12:09:08.0000] To be able to still do a[i] = x [12:16:56.0000] nox: hmm yeah that seems pretty good, +1 [12:20:59.0000] Domenic: And is there any way to use Array.values and Array.of to copy an array avoiding holes and stuff like that? [12:21:14.0000] nox: not sure what you mean [12:21:29.0000] Is this for the input, i.e. implementing the sequence<> -> list conversion? [12:21:38.0000] In that case the per-spec thing is to just use the iterator protocol, for-of [12:21:38.0000] Yeah. [12:21:49.0000] Oh right. [13:19:03.0000] Domenic: With such an Array proxy, couldn't we also allow array method calls with the certainty that we are calling the original ones from Array.prototype? [13:19:43.0000] nox: I'm not sure exactly how to write it, but it's definitely true that with a proxy you could make myProxy.map() always do the right thing. [13:20:23.0000] Domenic: I was thinking something way more generic than that, like makeAProxyHandlerThatWillCallExactlyTheCurrentMethodsOfThatGivenPrototype(Array.prototype). [13:20:40.0000] Yeah, I mean, that seems doable. Writing proxies is such an art though. [13:21:07.0000] Also you'd need to save each method you're interested in, to avoid people deleting Array.prototype.map at runtime and thus messing you up [13:22:06.0000] Array methods are not a real big deal though. If you're saving them anyway, you can just do arrayMap(myProxy, mapper) which is almost as nice. [13:22:11.0000] Domenic: Hence why a proxy handler constructed from the prototype. [15:03:29.0000] I wonder if anybody has any clue why every time I now try to do a Google search in Canary, I only instead get a generated error page from Canary about an Origin Policy violation [15:03:42.0000] Well, well, well. What do we have here? An Origin Policy violation. [15:03:42.0000] And what do we not have? A page! [15:03:42.0000] You're trying to go to: https://www.google.co.jp/search?q=foo&oq=foo&aqs=chrome..69i57j69i60j69i61j69i60j0l2.776j0j9&sourceid=chrome&ie=UTF-8 [15:03:45.0000] The policy applies to: https://www.google.co.jp [15:25:05.0000] You must be in some experiment group [15:25:17.0000] Or with a flag flipped [15:25:24.0000] And google.co.jp implemented something wrong 2018-11-07 [16:21:09.0000] Domenic: OK [16:32:27.0000] /me pictures MikeSmith as an experiment [16:42:06.0000] heh [16:42:44.0000] maybe it’s an experiment in increasing Firefox search revenue [03:58:58.0000] MikeSmith: If you can reproduce the error, please hop on https://bugs.chromium.org/p/chromium/issues/detail?id=901477. [03:59:49.0000] It's a mostly-finished implementation of https://github.com/WICG/origin-policy that's apparently going haywire for you, and two other people. :) [04:06:03.0000] mkwst: thanks will do [04:06:15.0000] I can reproduce it 100%.. [04:06:24.0000] That is both excellent and terrible to hear! [04:07:09.0000] haha [04:07:15.0000] It would be helpful if you could grab a net log. [04:07:44.0000] https://www.chromium.org/for-testers/providing-network-details [04:08:55.0000] /me looks [07:20:15.0000] I keep finding more Content-Type parsers in browsers [07:20:17.0000] This cannot be good [07:26:02.0000] This does not surprise me. [07:39:41.0000] gsnedders: yeah, slowly getting there though in having the answers to how HTTP parses; not sure when we last talked about defining this, been a while [07:41:19.0000] annevk: I don't think anyone has much since I played around a bit with it in about 2008/9. [08:06:01.0000] hello folks :) [08:06:41.0000] annevk: Is there anything like floor(), max(), min() defined in WHATWG infra? [08:14:11.0000] ato: we don’t even have numbers 😊 [08:14:32.0000] ato: hopefully soonish though once BigNum is a thing [08:15:04.0000] What's a number? ;P [08:15:15.0000] I wasn’t able to find any good uses in any CSS specs either. [08:15:22.0000] Very much so gsnedders [08:15:41.0000] Primitives are fun [08:16:10.0000] For the moment we have borrowed some of the one-line definitions of things like floor() from TC39. [08:16:22.0000] Basically copy-paste. [08:16:54.0000] ato: seems fine, Encoding has some of this too btw [08:17:35.0000] /me looks [08:18:03.0000] Ah yes, we actually borrowed the logical grouping part from Encoding! [09:19:46.0000] Where is the Symbol.iterator property of HTMLCollection specified? [09:20:06.0000] WebIDL [09:20:11.0000] jugglinmike: https://heycam.github.io/webidl/#es-iterator [09:20:34.0000] jugglinmike: https://heycam.github.io/webidl/#es-iterator [09:20:36.0000] so fast, TimothyGu! Thank you! [09:20:39.0000] oh, TimothyGu beat me [09:20:55.0000] gsnedders I'll give you partial credit [09:21:13.0000] Taking it on your word that you didn't just copy and paste TimothyGu's message [09:21:43.0000] Promise I didn't! [09:21:47.0000] Resolve(I didn't) [09:22:18.0000] Do you know why it's done this way? [09:22:48.0000] More specifically [09:22:59.0000] I presume it was the easiest way to make it apply to everything? [09:23:04.0000] Do you know why it's specified externally rather than in the interface definitions themselves [09:23:11.0000] And minimises the amount of work per interface? [09:23:28.0000] That would be my initial guess, but an optimization like that seems like an implementor's concern [09:24:23.0000] From a specification authoring standpoint, it seems too indirect [09:24:55.0000] no more indirect than many other things in WebIDL? [09:25:50.0000] I don't know anything about that, but I'm wondering if maybe it shouldn't be in webIDL in the first place [09:26:41.0000] but that's a little ignorant [09:27:55.0000] It avoids any inconsistency [09:27:56.0000] I'll need to figure out the WebIDL/DOM boundary before suggesting improvements like this [09:28:16.0000] Remember that things like Array.prototype.* are spec'd to work based on .length and [n] alone [09:29:04.0000] That's actually why I'm here :) [09:29:29.0000] (others probably know more about this than me, though!) [09:33:37.0000] Speaking of collections, I wish there was a single list of all of them. [09:33:44.0000] Some are defined in DOM and some in HTML. [09:34:02.0000] I would like to get away from having to list Array-ish things in WebDriver [09:34:16.0000] That’s why I’m saying. [09:36:54.0000] ato: my silly ideas incoming :) [09:38:48.0000] jugglinmike: it was done this way to easily migrate existing collections and ensure they all share the same behavior [09:39:39.0000] jugglinmike: letting IDL do as much heavy lifting as possible is def preferred for consistency and quality [09:41:12.0000] annevk: got it [09:43:09.0000] annevk: does that mean that the multi-inheritance supported by DOM interface definitions is out of style? Or are there cases where it still makes sense to be specifying shared behavior with that mechanism? [09:43:42.0000] jugglinmike: multi-inheritance? [09:44:24.0000] That's how I think of "[Exposed=Window, LegacyUnenumerableNamedProperties]" in https://dom.spec.whatwg.org/#interface-htmlcollection [09:45:45.0000] jugglinmike: that’s not inheriting from multiple interfaces though, that just affects enumeration of properties [09:48:10.0000] ahah [09:48:33.0000] Sorry for using “just”, it’s indeed all rather weird [09:55:27.0000] No worries, I took "just" to mean "exclusively" [10:00:04.0000] jugglinmike: I read that and thankfully I’m going for a drink soon. 2018-11-08 [22:08:13.0000] botie, inform mkwst about the Origin Policy bug, added comment at https://bugs.chromium.org/p/chromium/issues/detail?id=901477#c14 with NetLog dump attached [22:08:13.0000] will do [04:18:02.0000] Domenic: your comment at https://github.com/whatwg/html/issues/3035#issuecomment-329003087 last year resulted in some controversial discussions on my end... [04:18:12.0000] .. until we realized we weren't actually sure what you _actually_ meant here: "custom elements are not meant to be arbitrarily powerful; they're meant to give you the same power as the platform has" - is it worth asking for clarification? [04:20:41.0000] in particular, someone argued that strict interpretation would mean Polymer, for example, is non-idiomatic as per your statement [07:00:11.0000] is there a simple way to "tee" a Response Object [07:06:43.0000] nm.... missed the .clone() [07:25:15.0000] FND: my comment is about the standard. [08:35:59.0000] Domenic: I could prolly be persuaded that it's still early enough to break early adopters btw, but we can't keep doing that [08:36:12.0000] annevk: I just don't think it counts as "break" [08:36:14.0000] Domenic: so at some point we do have to consider them and work with them in mind [08:36:34.0000] I see, I guess we disagree then [08:36:43.0000] What code is broken? [08:37:02.0000] A page author decides to do something a component author didn't expect. Now, their page behaves as desired. [08:37:07.0000] Nothing is broken, just weird. [08:37:36.0000] I think there are plenty of custom elements out there that don't proactively do `attachShadow({ mode: 'closed' })` to "protect" themselves against breakage [08:37:48.0000] They just accept the consequences if page authors want to do something unexpected [08:38:26.0000] We've certainly never recommended that every custom element attach a closed shadow root to protect itself. Should we start doing so? [08:48:49.0000] Domenic: I guess it depends [08:49:30.0000] Domenic: thanks, I'm not sure that'll suffice to quell concerns here, but that's not your issue :) [08:49:52.0000] Domenic: I’m still not sure attach makes sense btw due to subclassable built-ins [08:50:08.0000] annevk: yes, basically no solution works with subclassing. [08:50:09.0000] Domenic: those have internals already [08:50:38.0000] Oh, are you just talking about the name? [08:50:44.0000] Those have internals already*, so get* makes more sense [08:51:14.0000] Ugh IRCCloud [08:51:21.0000] I don't care about the name. Although I think it's still up in the air whether we want the ElementInternals class to be more like computed style (reading back all internals including ones you set) or more like the style attribute (an overlay on top of any existing internals) [08:51:21.0000] Yup [08:52:20.0000] Hmm yeah, less cascade seems nice, but who knows [08:57:03.0000] hsivonen: foolip & co pointed out https://staging.wpt.fyi/results/encoding?product=firefox%4076c0092916&product=firefox%407f56040b8f&diff which I assume you are aware of, but I wonder what the reason is [09:04:48.0000] jgraham: I think AutomatedTester should have a link to a bug [09:05:20.0000] one sec please caller [09:05:35.0000] jgraham: I think it’s also fixed in Nightly? [09:07:06.0000] annevk: Oh is this that bug [09:07:24.0000] foolip claimed that the regression was still there [09:07:41.0000] jgraham: it was discussed a while back when this was first announced [09:08:23.0000] annevk: Oh you're right https://staging.wpt.fyi/results/encoding?product=firefox%4076c0092916&product=firefox[master]&diff [09:08:35.0000] jgraham: it was meant to “regress” in a way we thought would be acceptable for release, so could be [09:08:35.0000] hsivonen: Sorry to bother you [09:10:40.0000] oh I can't find it [09:11:02.0000] jgraham: iirc, we were falsely passing those tests [09:11:19.0000] and then with the encoding.rs work we started failing properly [09:11:45.0000] AutomatedTester: Doesn't matter :) [09:13:52.0000] ok [09:13:57.0000] it's https://bugzilla.mozilla.org/show_bug.cgi?id=1423877 [09:14:01.0000] if that is the issue [09:18:03.0000] Ta! [09:18:10.0000] Think so 2018-11-09 [00:29:58.0000] jgraham: did annevk land changes to the tests on that day to change the expectation of how unmappables are escaped in URLs? [00:31:23.0000] jgraham: it should be fixed on Nighly. This is a case where defaulting to results from release builds is not useful. [01:29:00.0000] hsivonen: Yeah, foolip happened to be looking at a graph of release builds. I agree it's misleading here [02:22:19.0000] Domenic: I had an idea! [02:23:15.0000] Domenic: For jsdom, [02:24:11.0000] the Node instance exposed to content could be a proxy around a mostly useless object, [02:24:42.0000] where the proxy handler is the actual Node impl object, with a 'get' method that just returns the handler itself if passed const impl = Symbol("impl"). [02:24:51.0000] See what I mean? [02:41:07.0000] Domenic: https://jsfiddle.net/2x0rq31j/ [02:55:45.0000] https://jsfiddle.net/2x0rq31j/1/ Ah, you can break it with an additional proxy. :( [05:03:27.0000] hsivonen: can you look at https://github.com/whatwg/html/issues/3257? [06:06:40.0000] nox: it seems like the straightforward thing is to avoid proxies and just switch from symbols to weakmaps, no? [06:07:28.0000] Domenic: I was trying to find a different way that is easier for JITs. [06:07:47.0000] But yeah the WeakMap solution is correct out of the box. Just slow. [06:07:49.0000] Heh, I've never heard of people saying proxies were easy for JITs... [06:07:56.0000] True. [06:08:10.0000] That was an assumption on my part and SM people told me it was wrong. :D [06:08:22.0000] Well, we're getting proper private state soon in the language. Although it won't support "friend class" use cases which pretty important for DOM. [06:08:35.0000] Oh? [06:08:49.0000] Link please? :) [06:08:58.0000] https://github.com/tc39/proposal-class-fields [06:09:21.0000] Domenic: For my pet project I plan to just use the SM-specific slot API. [06:09:35.0000] Yeah, makes sense [06:09:55.0000] Oh, I remember, there is a hacky way to do friend access [06:11:30.0000] Domenic: Note that I have yet to write a single line of code anyway. :) [06:11:54.0000] Domenic: Oh btw I wanted to suggest a change for webidl2js, for overloads specifically. [06:11:57.0000] Something like `class X { #y; static getY(x) { return x.#y; } static setY(x, val) { x.#y = val; } }; const { getY, setY } = X; delete X.getY; delete X.setY; /* now give getY and setY to any friend classes */` [06:12:20.0000] I could swear we had an open issue on overloads [06:12:34.0000] I really want to switch them to call impl.foo_1(), impl.foo_2()... [06:12:37.0000] Wouldn’t it be better if it dispatched calls to `nameofthemethod{typenameofthedisambiguatingargument}`? [06:12:47.0000] Yeah same but with a better name. [06:12:56.0000] Yeah it would be way better [06:13:03.0000] That project needs a little bit more love than it currently has [06:13:12.0000]