-
Notifications
You must be signed in to change notification settings - Fork 29
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Rewrite privacy considerations section #215
Conversation
ff24d72
to
a057762
Compare
index.html
Outdated
</li> | ||
<li>If the screen orientation changes, not fire the <a data-link-for= | ||
"ScreenOrientation">change</a> event to reveal a change to a | ||
[=secondary=] orientation. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wouldn't this encourage battery-expensive polling instead? If you support rotating in a way that changes width/height of the viewport I think we should require that something changes. But limiting it two values for type and angle each seems reasonable.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wouldn't this encourage battery-expensive polling instead?
Sorry, I might need to word this better. The answer is "no", because the UA wouldn't fire events when switching from "X-primary" to "X-secondary". Only if "X" changes, would the event fire, but it would always report as "X-primary".
The reason the orientation change event does fire, is that the screen width/height would change, which is already observable either polling screen
's attribute or simply by matchMedia("(orientation: landscape)")
.
Thanks for the feedback @annevk. I updated the event recommendation. Is that more clear? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks, that helps! Only nits remain.
Hopefully this is a bit clearer now... |
index.html
Outdated
<li>For any [=natural=] orientation ([=portrait=] or [=landscape=]), | ||
always return `0` for the value of the {{ScreenOrientation/angle}} | ||
attribute. And for any rotated/opposite orientation, always return `90` | ||
for the value of the {{ScreenOrientation/angle}} attribute. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Okay, so this means we will be exposing the natural direction of the device. Or is the natural direction simply the direction the user used when navigating to the site?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh! I quite like the idea of taking the orientation to which the page was navigated and using it to lie (i.e., and not expose the natural orientation).
No browser does the above today, which is why I spec'ed it based on "natural" orientation, but that doesn't mean they couldn't.
Merging as feedback has been addressed. Happy to refine this a bit more as a followup. |
Closes #188
Closes #181
Cc @smfr
This matches what Gecko does.
The following tasks have been completed:
Implementation commitment:
Preview | Diff