| 00:09 | <domfarolino> | I noticed in HTML spec there is a section dedicated to custom elements, while there is also a full on custom elements spec (https://www.w3.org/TR/custom-elements/). Both seem to contain relatively the same info |
| 00:10 | <domfarolino> | Is there a reason whatwg does not host a separate custom elements spec (written by whatwg member ddenicola) and just reference it via HTML spec? |
| 00:12 | <domfarolino> | Thought it was kinda odd that the entire CE spec sorta existed in HTML spec, without being pulled out in a whatwg repo (though it is pulled out in w3, and written by whatwg member) |
| 00:17 | <MikeSmith> | domfarolino: https://dom.spec.whatwg.org/ also defines parts of the custom-elements requirements |
| 00:19 | <MikeSmith> | the reason for integrating the requirements into the HTML and DOM specs is that they have always been monkey patches and the assumption all along from the people actually working on defining the requirements is that the requirements would eventually be folded back into the HTML and DOM specs and the monkey patching spec would no longer be needed |
| 00:20 | <MikeSmith> | in other words the reason for not pulling the requirements (back) out into a separate spec is that they don’t rightly belong in a separate spec, they belong in the HTML spec and the DOM spec |
| 00:22 | <MikeSmith> | the requirements necessitate, e.g., adding particular steps to particular existing algorithms in the HTML and DOM specs |
| 00:22 | <domfarolino> | MikeSmith ok that makes sense that it is sort of a subset of those two specs |
| 00:23 | <MikeSmith> | yeah |
| 00:23 | <domfarolino> | MikeSmith: is there a reason then that for some reason it has been pulled out into its own spec but just on w3c territory? |
| 00:23 | <domfarolino> | regardless what you said makes sense thanks |
| 00:24 | <MikeSmith> | the reason for what you just asked is .. complicated |
| 00:24 | <MikeSmith> | and I’m not the right person to comment on that |
| 00:24 | <domfarolino> | I see...policial I assume? |
| 00:24 | <domfarolino> | gotcha |
| 00:24 | <domfarolino> | political* |
| 00:27 | <annevk> | domfarolino: yes |
| 01:34 | <domfarolino> | anybody online willing to answer a quick Q I have regarding the algos pertaining to script modules in the HTML spec? |
| 01:41 | <annevk> | domfarolino: best just to ask |
| 01:44 | <domfarolino> | annevk: thanks. I came across the algorithm for determining a script's "uninstantiated inclusive descendant module scripts" (https://html.spec.whatwg.org/multipage/webappapis.html#uninstantiated-inclusive-descendant-module-scripts). it is a basic DFS (as noted in script), however I was wondering if step 4 > 2 is a bit redundant? |
| 01:44 | <domfarolino> | In other words, why are we checking `current`'s existence in BOTH `stack` and `inclusive descendants` as opposed to just `inclusive...`? |
| 01:46 | <domfarolino> | I could be missing something, but wouldn't it work the same by just checking existence in `inclusive descendants`? Just wondering if I'm missing some nuance with how a script's deps work |
| 01:48 | <annevk> | domfarolino: it matters for ordering at least |
| 01:48 | <domfarolino> | Thats what I first thought |
| 01:48 | <annevk> | domfarolino: not sure how stack is determined though |
| 01:48 | <domfarolino> | I then saw the note at the bottom saying something to the effect of "as long as it returns a set, whose order does not matter" |
| 01:50 | <annevk> | Hmm best to wait for Domenic then or maybe raise an issue |
| 01:51 | <domfarolino> | Ok thanks for the insight...just curious :) |
| 18:31 | <smaug> | anyone familiar with WebVR? |
| 18:33 | <KiChjang> | smaug, which aspects of it? |
| 18:33 | <smaug> | when is vrdisplaypresentchange dispatched? |
| 18:33 | <smaug> | (both 1.1 and editor's draft are super high level specs) |
| 18:34 | <KiChjang> | uh, not sure, but i know of someone who implemented this |
| 18:34 | <smaug> | yeah, I know too at Mozilla but he isn't online atm |
| 18:35 | <KiChjang> | are you thinking of mortimer? |
| 18:37 | <smaug> | I'm thinking kip |
| 18:40 | <KiChjang> | smaug, the tests here may shed some light: https://github.com/servo/servo/blob/518ef39cfd429082dd8dc0d5b13e2db637d08a53/tests/html/webvr/vr-presentation.html#L205 |
| 18:41 | <KiChjang> | so, whenever a VR device is in or out of present mode |
| 18:42 | <smaug> | KiChjang: so is that some very often fired event? I don't thinks so |
| 18:45 | <KiChjang> | it depends on how many times you call requestPresent to get your VRDispaly |
| 18:45 | <KiChjang> | here's the polyfill of it |
| 18:45 | <KiChjang> | https://github.com/servo/servo/blob/518ef39cfd429082dd8dc0d5b13e2db637d08a53/tests/html/webvr/js/third-party/webvr-polyfill.js#L263 |
| 22:28 | <bterlson> | Where would I find the spec'd semantics for Object.prototype.toString.call(cross-origin window object)? |
| 22:28 | <bterlson> | If accessing Symbol.toStringTag cross-origin throws (which I think it should) then this call should fail as well with my naive reading |
| 22:29 | <bterlson> | Chrome is giving [object Object] so perhaps there is some spec'd fallback somewhere? |
| 22:29 | <bterlson> | Domenic: ^ :) |
| 22:29 | <Domenic> | Chrome is probably not super-compliant here. But I know exactly where to look for the spec, one minute |
| 22:30 | <Domenic> | bterlson: https://html.spec.whatwg.org/#crossorigingetownpropertyhelper-(-o,-p-) |
| 22:30 | <Domenic> | so crossOriginWindow[Symbol.toStringTag] should always give undefined. |
| 22:31 | <bterlson> | nice this is exactly what I was looking for |
| 22:31 | <bterlson> | therefore Chrome is compliant |
| 22:31 | <Domenic> | Oh yay |
| 22:31 | <Domenic> | The full spec for Window is at https://html.spec.whatwg.org/#the-windowproxy-exotic-object FYI |
| 22:32 | <Domenic> | Although https://github.com/whatwg/html/pull/2400 is in flight I guess |
| 22:32 | <bterlson> | although HTML might consider adding an entry for Window to https://tc39.github.io/ecma262/#sec-object.prototype.tostring so as to preserve legacy [object Window] toString for window detection purposes |
| 22:33 | <Domenic> | So that'll work same-origin I think |
| 22:34 | <Domenic> | CrossOriginGetOwnPropertyHelper only gets invoked for cross-origin windows |
| 22:44 | <bterlson> | right, but prior to toStringTag you could still get object Window as the tostring of a cross-origin window |
| 22:45 | <bterlson> | (I think) |
| 22:45 | <bterlson> | a change to O.p.toString would handle the case when a window object doesn't have a toStringTag (or returns undefined because its cross origin) |
| 22:45 | <bterlson> | Domenic: ^ |
| 22:46 | <Domenic> | I think prior to toStringTag it probably wasn't specified very well |
| 22:46 | <Domenic> | If we wanted to make [object Window] work cross-origin we'd ideally just give its toStringTag a value? |
| 22:46 | <Domenic> | I assume since it's already configurable that isn't some kind of bad information leak |
| 23:13 | <bterlson> | Domenic: you can't access the property cross-origin |
| 23:13 | <bterlson> | or else you'd have to ensure it's not a getter or proxy with a trap that is going to execute code |
| 23:13 | <Domenic> | I mean we can make crossOriginWindow[Symbol.toStringTag] return whatever we want |
| 23:13 | <Domenic> | Right now we make it return undefined |
| 23:13 | <bterlson> | ohhh |
| 23:14 | <bterlson> | sure right |
| 23:14 | <bterlson> | if you have a place for that it'd work too |
| 23:14 | <bterlson> | I bring this up because F12 uses O.p.toString for detecting window objects |
| 23:14 | <bterlson> | maybe it exists in real code too |
| 23:42 | <Domenic> | bterlson: do you know what different browsers do for O.p.toString on cross-origin windows? If there's disagreement then we should maybe change the spec |
| 23:44 | <bterlson> | Domenic: I only know Chrome (returns undefined) and Edge (throws permission denied) |
| 23:45 | <bterlson> | Edge is just wrong per your previous linkage, but neither preserves legacy behavior |
| 23:45 | <Domenic> | I just don't know if "legacy behavior" is the right term here |
| 23:45 | <Domenic> | Cross-origin windows have always been wonky |
| 23:45 | <Domenic> | So I'm not sure such code ever worked |
| 23:51 | <bterlson> | Domenic: me either ;) FF returns undefined per spec as well, can't check safari of course |
| 23:51 | <Domenic> | Yeah spec sounds pretty good to me then :) |