| 09:32 | <yoav> | annevk: care to take a look at https://github.com/whatwg/fetch/pull/881? Want to get a read of general direction before I rebase the HTML PR on it |
| 10:12 | <yoav> | thx! |
| 12:57 | <lgrahl> | o/ Quick question: In WebIDL, can "readonly attribute"s contain an algorithm with "steps" like methods can? |
| 13:37 | <annevk> | lgrahl: yes, it's a getter |
| 13:38 | <annevk> | lgrahl: however, please ensure obj.attr === obj.attr |
| 13:42 | <lgrahl> | annevk: Do you have an example for such a check? |
| 13:42 | <annevk> | lgrahl: check? |
| 13:43 | <annevk> | lgrahl: it's a design principle: https://w3ctag.github.io/design-principles/#attributes-like-data |
| 13:44 | <annevk> | lgrahl: the way to write the prose is typically something like "The fooBar attribute's getter must run these steps:" |
| 13:45 | <annevk> | lgrahl: and then depending on what it returns you might need [SameObject] in IDL, an internal slot to store some value in, etc. |
| 13:46 | <lgrahl> | annevk: I wonder... do you consider a getter appropriate for a result that depends on whether or not a permission has been granted via the permission API? |
| 13:48 | <annevk> | lgrahl: stuff that's tied to permissions should be a promise |
| 13:48 | <lgrahl> | annevk: When requesting, definitely. But when just fetching the current state? |
| 13:48 | <annevk> | lgrahl: could be returned from a getter, but managing lifetime might be icky |
| 13:49 | <annevk> | lgrahl: what's the current state when you start out? |
| 13:49 | <annevk> | lgrahl: if it requires accessing the permission store, you introduced synchronous IPC |
| 13:49 | <lgrahl> | annevk: It might require accessing the permission store. |
| 13:49 | <annevk> | lgrahl: then you use a promise |
| 13:50 | <lgrahl> | annevk: Then I'm confused by the spec. https://www.w3.org/TR/permissions/#reading-current-states looks sync to me. |
| 13:50 | <annevk> | please no new synchronous IPC APIs 😊 |
| 13:50 | <annevk> | lgrahl: that might need patching in some way |
| 13:51 | <lgrahl> | The spec? |
| 13:51 | <annevk> | lgrahl: yeah, it's definitely somewhat wrong |
| 13:51 | <lgrahl> | I'm happy to use a Promise, don't get me wrong. :) |
| 13:51 | <lgrahl> | Then I'll just change that to a promise. |
| 13:52 | <annevk> | 👍🏻 |
| 15:27 | <lgrahl> | annevk: Can you tell me what the "current realm" in the Permission API refers to? What is the scope of that realm? The domain name? |
| 15:33 | <annevk> | lgrahl: a realm is 1:1 with a JavaScript global |
| 15:34 | <annevk> | lgrahl: and it's effectively a container of sorts for one |
| 15:38 | <lgrahl> | annevk: So, in my head, can I map that to the "page"? :) |
| 15:39 | <lgrahl> | annevk: Or does it also affect other pages on the same domain? For example, when a permission storage entry has been made. |
| 15:40 | <annevk> | lgrahl: I guess you can consider it roughly analogous to document (which I guess means page, that's not really a term we use) |
| 15:40 | <annevk> | (except for printing) |
| 15:40 | <lgrahl> | Heh, document is alright. |
| 15:44 | <lgrahl> | annevk: Let me rephrase that question then: If a permission storage entry has been made, will that be effective immediately to other documents? Furthermore, will it affect any other documents but those shipped from hat precise domain (such as subdomains)? |
| 15:45 | <annevk> | lgrahl: I think that depends on the implementation and the permission |
| 15:46 | <lgrahl> | annevk: Hrm, I haven't seen any spec defining that (or I missed something). |
| 15:51 | <annevk> | lgrahl: I mean, ISSUE 1 under https://www.w3.org/TR/permissions/#reading-current-states hints at it and that algorithm basically doesn't describe any scoping or keying |
| 15:55 | <lgrahl> | annevk: I see. Thanks for your help so far! I'm working on a use case neutral permission request for WebRTC. |