Ehsan Karamad

@marian-r and @clelland FYI.

> > This change makes modifications to the focus processing model such that for a new > > focus target that the policy is disabled (i.e., in its node document...

> OK, this looks good to me spec-text wise. What remains before we can merge this is multi-implementer interest, and web platform tests. Thanks! I will be adding tests for...

> ames :(. Uh very sorry! I still need to find my way around github.

> Also, @ehsan-karamad, you work for Google, which is in the field of web technologies, so it's not appropriate to sign the Participant Agreement as an individual. Instead you need...

> If the default is not blocking for third-party contexts, Yes, for now, we are thinking about making this blocking by default in sandboxed subframes. But that said, it should...

> No worries! Could you push an additional commit which ensures that all instances say `allowed to use the "x" feature`, instead of sometimes `allowed to use the "x"` or...

> That doesn't match the behavior of the `autofocus` attribute. Shouldn't the default allowlist be 'self'? If not, there is no web compat concern, so I suspect this is an...

I think even if the server would run and set the header to something like `vertical-scroll 'none'` we'd still have some issues to properly explain what the feature demos. `vertical-scroll`...

I would have to pass that question to @bengreenstein since IMO this is more of a `loading` attribute question. The policy, when disabled, should (almost always) treat unset or `auto`...