Generic Proximity sensor or UserProximity sensor

[tobie]

This follows up on my initial comment about whether the sensor should include distances or just a near/far data point.

Are we targeting proximity sensors in general, here, or are we really looking at proximity sensors used to infer whether a device is close to the user's ear or not?

It is my understanding that different sensor types can be used to achieve the latter, while the number of sensors types able to achieve the former are more limited.

Note that we could very well have both a UserProximitySensor and a ProximitySensor talking to the same underlying hardware sensor. We could even imagine a case where the UserProximitySensor wouldn't require user permission (and would have a matching CSS mediaquery, much like for light-level) and the latter would.

Whatever you decide to go with, I think it's important that you document it and explain the tradeoffs in the spec.

[riju]

We should be targeting proximity sensors in general, and inferring whether a device is close to the user's ear or not should be one of the one use cases.
I am in thinking of removing the near/far attribute.
distance & max should have default value as +Infinity as discussed in #3

near can be inferred as distance != +Infinity or distance != max
Since distance's default value is +Infinity, near can be inferred to be false by default.

In platforms, which can only report near/far,
we can use distance as a proxy -1 / ( +Infinity or max) to represent near/far
distance = 0, is a valid value from a sensor which can report distance, hence using -1, But we leak information that platform cannot give you actual distance, so must be Mac.

If to represent near , we use distance = 0, then we do not leak platform information, but confuse the programmer, if the value is actually 0, or if it represents near.

Since the spec says that we should not use it as a reliable source of accurate distance between sensor and an object, I think using distance = 0 to represent near is a better trade-off.

wdyt ?

[dontcallmedom]

I think a negative distance is confusing; I personally feel that using near/far when that's the best we know (while leaving distance to +Infinity) is less confusing.

Note that the distinction between UserProximity and Proximity that @tobie was suggesting is the one the original Proximity spec used.

[tobie]

But we leak information that platform cannot give you actual distance, so must be Mac.

Is leaking platform issue something we specifically want to avoid here?

[riju]

[Constructor(ProximitySensorReadingInit proximitySensorReadingInit)]
interface ProximitySensorReading : SensorReading {
    readonly attribute unrestricted double distance;
    readonly attribute unrestricted double max;
    readonly attribute boolean? near;
};

dictionary ProximitySensorReadingInit {
  unrestricted double distance = Infinity;
  unrestricted double max = Infinity;
  boolean? near;
};

As a note to implementors, in cases where near is not available, we can use
the value of distance to infer near, meaning distance not equal to max,
can imply there is an object in the sensing range.

wdyt ?