Stop exposing Sensor state. #180
Conversation
References w3c#160.
| @@ -592,7 +592,6 @@ A [=sensor=] has an associated <dfn>current polling frequency</dfn> which is ini | |||
| <pre class="idl"> | |||
| [SecureContext] | |||
| interface Sensor : EventTarget { | |||
| readonly attribute SensorState state; | |||
There was a problem hiding this comment.
Will it be modified into boolean activated, like you and @rwaldron discussed at #160 (comment) or we'll leave it not exposed for now?
There was a problem hiding this comment.
I think we should just avoid exposing it for now. That's the kind of precise feedback I'd like to see from origin trials, though (maybe we could even expose both there and see which ones devs end up using?)
There was a problem hiding this comment.
In origin trials the API call statistics is collected, so IMO it is preferable to leave something and see whether it is called or not. I would personally leave the activated attribute: it is minimalistic and perfectly aligned with the rest of API. Exposing both is also possible, so I'm fine with any decision regarding this :)
There was a problem hiding this comment.
Yeah, my worry about basing this on stats is that actual usage will depend highly on what documentation we release before we go to origin trial. @kenchris any thoughts?
There was a problem hiding this comment.
I am fine with exposing the activated attribute. Then we can also see whether people use it or not or need something more powerful
tobie
force-pushed
the
rm-sensorstate-enum
branch
from
378888f
to
04ebcfb
Compare
index.bs
Outdated
| The getter of the {{Sensor/activated!!attribute}} attribute must run these steps | ||
| or their [=equivalent=]: | ||
|
|
||
| 1. If <emu-val>this</emu-val>.{{[[state]]}} is "activating", |
There was a problem hiding this comment.
Heh. Wednesday is the day I take care of the kids. It shows. :D
|
lgtm! |
References #160.
Preview | Diff