| 03:17 | <MikeSmith> | looking at https://fetch.spec.whatwg.org/#ref-for-concept-response-status%E2%91%A0%E2%91%A8 I’m wondering why annevk chose the wording “are to be ignored” rather than “must be ignored” |
| 03:18 | <MikeSmith> | is “are to be ignored” normative language? |
| 03:18 | <MikeSmith> | it seems like rather than “Any responses whose status is in the range 100 to 199, inclusive, and is not 101, are to be ignored. |
| 03:19 | <MikeSmith> | ... it would just be more clear to say: |
| 03:19 | <MikeSmith> | Any responses whose status is in the range 100 to 199, inclusive, and is not 101, are to be ignored. |
| 03:19 | <MikeSmith> | oofs |
| 03:19 | <MikeSmith> | “Ignore any responses whose status is in the range 100 to 199, inclusive, and is not 101.” |
| 03:19 | <MikeSmith> | imperative |
| 07:10 | <annevk> | MikeSmith: Fetch takes PRs 😊 |
| 07:10 | <MikeSmith> | hey annevk |
| 07:10 | <annevk> | MikeSmith: I try to avoid saying must again if an algorithm is already required, but no hard fast rule for that yet |
| 07:10 | <MikeSmith> | I was just curious if there was a specific reason you worded it that way |
| 07:10 | <MikeSmith> | ok |
| 07:11 | <MikeSmith> | I’ll make a PR |
| 07:11 | <annevk> | MikeSmith: I like your imperative version |
| 07:11 | <MikeSmith> | OK |
| 07:11 | <MikeSmith> | well once I make my PR, then we’ll have two problems :p |
| 07:12 | <annevk> | Oooh that hasn’t been resolved? |
| 07:12 | <MikeSmith> | nope :( |
| 07:12 | <annevk> | Ouch best not to then |
| 07:12 | <MikeSmith> | I have been working on it |
| 07:12 | <MikeSmith> | at Keio |
| 07:12 | <MikeSmith> | just had a another discussion about it today |
| 07:12 | <MikeSmith> | but no resolution |
| 07:13 | <MikeSmith> | anybody who thinks it’s not a huge amount of work and time to get an employer to sign off on that, they are fooling themselves |
| 07:14 | <MikeSmith> | pretty disheartened about this situation |
| 10:47 | <nox> | annevk: So my DOM PR will just land as is? |
| 10:53 | <annevk> | nox: well, not literally, but I'm still convinced by that basic setup, yes |
| 10:53 | <nox> | Cool! |
| 10:54 | <annevk> | nox: I think we might need similar hooks for removal, and all the places that used to invoke "child text content change steps" will now invoke "children changed steps" and those might all need to have deferred steps of sorts |
| 13:31 | <ondras> | zcorpan: may I ask why is document.domain bad? and somewhat related, why does the metric name include "CrossOriginAccess"? |
| 13:33 | <zcorpan> | ondras: i think it's bad for several reasons. first, it complicates the origin model in browsers; more complexity leads to more interop problems and more security bugs |
| 13:34 | <ondras> | I might be not familiar enough with its functionality. It does more than reporting location.hostname ? |
| 13:35 | <zcorpan> | ondras: using it for one use case opens up access for all subdomains, which might not be intentional or desirable |
| 13:35 | <zcorpan> | ondras: oh. yes. you can set it to change the origin |
| 13:35 | <ondras> | oops |
| 13:35 | <ondras> | wow. |
| 13:36 | <zcorpan> | ondras: not to anything, but to a parent domain |
| 13:36 | <ondras> | aha, from a.b.com to b.com? |
| 13:36 | <zcorpan> | ondras: so foo.example.com and bar.example.com can access each others DOMs |
| 13:36 | <zcorpan> | right |
| 13:36 | <ondras> | ah. is there any other use case for this, except for cross-document access? |
| 13:37 | <zcorpan> | I don't think so |
| 13:37 | <ondras> | okay, thanks for explanation then! |
| 13:38 | <zcorpan> | np! I think there needs to be a doc that explains this stuff and why it's bad :) |
| 13:39 | <annevk> | mutable global policies/state is/are bad, thank you for coming to my ted talk |
| 13:40 | <ondras> | succintly said. |
| 13:40 | <zcorpan> | that too. and that it enables access between http://foo.test and https://foo.test |
| 13:42 | <annevk> | zcorpan: is that true? |
| 13:43 | <annevk> | zcorpan: I've been meaning to test that, but I was really hoping document.domain would still have scheme protection |
| 13:46 | <zcorpan> | annevk: looks like i misremembered the spec for that case |
| 13:49 | <annevk> | ah, same origin-domain checks the schemes |
| 13:52 | <zcorpan> | yes. though the spec ignores the port |
| 14:02 | <annevk> | yeah, jochen__ looked into that at some point, but it wasn't worth the trouble |
| 14:41 | <ondras> | zcorpan: nicely tweeted |
| 14:41 | <zcorpan> | ondras: ty |
| 23:37 | <Domenic> | Origin policy starting to get together... https://github.com/WICG/origin-policy/pull/60 |