| 04:02 | <annevk> | Yeah, maybe “local” is our best pick. I also thought of “pressure-based”, but… |
| 04:03 | <annevk> | I’m not sure I want this term to show up in APIs though. Prolly rather not. |
| 06:32 | <annevk> | Domenic: you might want to follow https://github.com/unicode-org/icu4x/issues/73 as well as I think that's something you care about |
| 09:04 | gsnedders | wonders if we can make document.evaluate static by default |
| 09:09 | <gsnedders> | or am I misunderstanding the iterator/snapshot difference? |
| 11:36 | <tobie> | annevk: changes to pr-preview deployed. LMK if they work for you or if you're having issues. |
| 12:35 | <annevk> | tobie: oh cool, let me try push another commit to a PR |
| 12:36 | <annevk> | tobie: seems to work great: https://whatpr.org/storage/86.html |
| 12:36 | <annevk> | thanks |
| 12:47 | <zcorpan> | domfarolino: do you have thoughts on the element scroll container case here? https://github.com/whatwg/html/issues/5408#issuecomment-623981827 |
| 13:48 | <tobie> | annevk: Great! I have fixed my notification settings, so I think I will be prompted more quickly in the future. :) |
| 14:39 | <domfarolino> | seems zcorpan is gone now :( |
| 16:14 | <treora> | Hi all; I wonder if there are any IDL specs that narrow down attribute types for subclasses. |
| 16:14 | <treora> | For example, in <https://dom.spec.whatwg.org/#interface-node>;, the Node interface contains: “readonly attribute Document? ownerDocument;” |
| 16:14 | <treora> | This attribute’s behaviour is then defined as: “The ownerDocument attribute’s getter must return null, if this is a document, and this’s node document otherwise.” |
| 16:14 | <treora> | I’d think one could then create an IDL for the Document interface that says “readonly attribute null ownerDocument;” |
| 16:14 | <treora> | But the spec does not contain this, and accordingly neither do (e.g.) Typescript’s dom type declarations, and as a result people’s code contains needless type errors. |
| 16:14 | <treora> | Any opinions here on whether/where/how this could (or might already) be addressed somehow? |
| 16:18 | <Domenic> | treora: specs do not do that because doing so would change JS observable behavior and require extra C++ implementation, by causing the overridden property to no longer inherit from the prototype. |
| 16:18 | <Domenic> | treora: TypeScript and IDL are not isomorphic, so it is unfortunate that people try to derive TypeScript types from IDL. |
| 16:18 | <Domenic> | I.e. TypeScript is for catching type errors, so lots of little subtypes maybe is useful. IDL is for generating C++ code, so lots of little subtypes would be actively bad. |
| 16:25 | <treora> | Thanks for explaining. I assumed such narrowing down would indeed be kept outside of the interface definitions, but could perhaps be listed somewhere as ‘corrolaries’, a sort of appendix with some machine-readable implications of the spec. |
| 16:25 | <treora> | *corollaries :) |
| 16:28 | <treora> | Of course it could be done in projects like Typescript, but it seems more easily maintained and more reusable when kept ‘closer to the spec’. |
| 16:29 | <treora> | As you say it is unfortunate that IDL is used to derive types at all, perhaps this would need a more thorough approach.. |
| 16:31 | <Domenic> | I don't think that's something that would make sense in the spec, since it's not useful for implementing. |
| 16:31 | <Domenic> | It would make sense for it to exist in TypeScript if TypeScript is going to use it. |
| 16:32 | <treora> | ok, clear. |
| 16:48 | <annevk> | I wonder if that case could fall out of formalized slots |
| 16:50 | <annevk> | Maybe, but prolly not worth the complexity |
| 17:17 | <treora> | There are better examples than the above by the way, e.g. I suppose a ChildNode could be guaranteed to always have a parentNode. |
| 17:18 | <treora> | I found a place for typescript where I guess these things might go: https://github.com/microsoft/TSJS-lib-generator/blob/master/inputfiles/overridingTypes.json |
| 17:48 | <saber1> | Domenic: this test https://github.com/web-platform-tests/wpt/blob/master/html/semantics/interactive-elements/the-dialog-element/abspos-dialog-layout.html#L200-L210, I guess I understand what it means. The containing block is the `absoluteContainer`, and the test expects the dialog element used this containing block to calculate it's position. Please feel free to correct if I am wrong. My question is, I don't see this is how |
| 17:48 | <saber1> | the spec is defined? I'd still expect the dialog element to use the viewport |
| 18:03 | <Domenic> | saber1: I'm sorry, I'm really not a dialog expert... it's best to post these questions on some public forum and gather input from those that are. |
| 18:03 | <saber1> | gotcha, thanks! |
| 18:05 | <annevk> | Domenic: do you know who to contact at Chrome? |
| 18:05 | <annevk> | Domenic: perhaps you could introduce them to saber1 to move things along a bit more quickly? We're trying to ship it in Fx as I understand |
| 18:05 | <Domenic> | annevk: @mfreed7 is my go-to DOM team contact |
| 18:05 | <annevk> | it* |
| 18:06 | <annevk> | k |
| 18:06 | <Domenic> | I'm happy to do an intro email if that'd be appreciated; just let me know what email address to use. |
| 18:26 | <annevk> | TabAtkins: heh, I might even supply a PR to Bikeshed 🙂 |
| 18:26 | <TabAtkins> | yessssssss |
| 18:27 | <annevk> | TabAtkins: just need to figure out a bit more what exactly we need; but perhaps the easiest fix would be a similar thing to MDN annotations, a switch to allow us to use our own styles and scripts |
| 18:59 | <Domenic> | annevk: Should we maybe require filing bugs on Node.js when the URL Standard changes? Since they have a spec-complaint implementation and are actually going to pay attention to the kinds of minor changes that have happened recently. |
| 19:00 | <Domenic> | I will file one for the recent changes |
| 19:47 | <annevk> | Domenic: thanks, I like that |
| 19:49 | <annevk> | Domenic: the host parser restrictions contributor is from Node’s team, but I should prolly have double checked |
| 19:54 | <Domenic> | Ah yeah true |
| 19:59 | <annevk> | Domenic: I’ve been idly wondering if we should have more process around URL as it gets more stable, but not entirely clear we’re there yet |
| 20:00 | <Domenic> | Yeah, I did notice that the last PR got merged with several boxes left unchecked |
| 20:00 | <Domenic> | Maybe starting with Safari and Node.js bugs, since they've demonstrated care, would be good. |
| 20:00 | <annevk> | Would be nice to have two browsers fully comply |
| 20:00 | <annevk> | Oh a non-editorial PR? |
| 20:06 | <Domenic> | Yeah https://github.com/whatwg/url/pull/497 |
| 20:09 | <annevk> | Maybe one thing to do is confirm each browser has a URL tracking bug remaining |
| 20:11 | <annevk> | I figures for that one I could decide for Fx and we have bugs on file, but a bit sloppy indeed |
| 20:13 | <annevk> | Figured* |
| 20:50 | <saber1> | creating a PR to whatwg/html, how do I add <!-- ACKS, I don't see it anywhere |
| 21:31 | <Domenic> | saber1: in the `source` file it's around line 120803 |