Add a sensor interfaces to sensor features

[Elchi3]

See https://developer.mozilla.org/en-US/docs/Web/API/Sensor_APIs

Specific sensors:

• Add Magnetometer API #1848
• Add Ambient light sensor #2245
• accelerometer.yml
• device-orientation-events.yml
• gyroscope.yml
• orientation-sensor.yml

[autonome]

@Elchi3 Is this usable in the absence of a specific sensor? Review feedback on "base class" types of features so far has been to bundle them w/ the first usable implementation.

[Elchi3]

hm, what is the first usable implementation or specific sensor here? Looks like there is varying support and even re-implementations on top of "generic sensors" (this API).

[captainbrosset]

Yeah, I don't think we should create a feature just with those keys, because they don't represent a thing developers can use. This is an interesting case where we'd almost need these BCD keys to be duplicated into each of the features that use Sensor as a base class.

Why don't we allow duplication of BCD keys by the way? @ddbeck?

BCD keys:

• api.Sensor
• api.Sensor.activate_event
• api.Sensor.activated
• api.Sensor.error_event
• api.Sensor.hasReading
• api.Sensor.reading_event
• api.Sensor.start
• api.Sensor.stop
• api.Sensor.timestamp
• api.SensorErrorEvent
• api.SensorErrorEvent.SensorErrorEvent
• api.SensorErrorEvent.error

Classes that inherit from Sensor

• Accelerometer (feature)
• AmbientLightSensor (feature)
• GravitySensor (grouped under the accelerometer feature)
• Gyroscope (feature)
• LinearAccelerationSensor (grouped under the accelerometer feature)
• Magnetometer (no feature yet)
• OrientationSensor (feature)

[captainbrosset]

We just discussed about this PR on the WebDX CG call (minutes).

The options seem to be the following:

• Ignore the generic Sensor BCD keys (at least for now).
• Bundle these keys with whichever feature came first, as suggested by Dietrich.
• Duplicate the keys among all of the features that derive from the generic Sensor class.
• Create a generic Sensor feature.

I don't want to block this PR, but I do want to express my opinion, which is that we should either ignore the keys for now, or fold them under one of the concrete sensor classes (not sure which one). If people feel strongly that we need a Sensor feature, then I won't block the PR either.

I'm having trouble seeing the value of creating a standalone generic Sensor feature in this repo. This repo is used to generate summarized browser support data for features that web developers want to use.
If a dev wants to use the AmbientLightSensor to implement a use case in their app, then we should have a feature for it, which gives them the right browser data.
Can developers use the Sensor class on its own? I don't think so. Do they think about the Sensor class separately from the rest? Maybe, not sure. We should maybe do some customer research here.

Now, during the meeting, the learning argument was brought forward. That a dev would have to learn about the Sensor interface anyway, because that's what gives them at least half of the methods/events that they'll end up using. My counter argument here is that I don't think web-features needs to care about that too much. Web-features cares about "entry points", about the features that are in devs' minds. Web-features answers questions like "Is there a feature to detect light?", "Where is that feature supported?"

[ddbeck]

Why don't we allow duplication of BCD keys by the way? @ddbeck?

This came at MDN's request, when feature authoring was considerably less sophisticated. It was (and is) ambiguous where an MDN page's status ought to come from, if the compat key can be in multiple features. I'm going to ask the MDN folks soon about their current perspective on this.

Duplicate the keys among all of the features that derive from the generic Sensor class

I agree that this is the long-term correct answer. AFAICT, you can't do anything useful with the Sensor API without a concrete physical sensor (or virtual sensor, in the case of webdriver) and its attendant interface additions.

In the mean time…

Bundle these keys with whichever feature came first, as suggested by Dietrich

I think this is the correct way forward, if it's possible. The process would look like this: compare all the concrete sensor implementations and find the least common denominator (i.e., the sensor that is oldest and mostly widely implemented).

I could imagine cases where this wouldn't work very cleanly (e.g., if the most widely implemented sensor is not the oldest). In that case, I'd say we ought to set aside these keys and work to resolve #1173 quickly.

[ddbeck]

I could imagine cases where this wouldn't work very cleanly (e.g., if the most widely implemented sensor is not the oldest). In that case, I'd say we ought to set aside these keys and work to resolve #1173 quickly.

I talked to MDN about #1173 on Thursday. They said they'd be open to us proceeding with keys in multiple features, but not before January. I think the right thing to do here then is:

• In this (or a superseding PR), assign Sensor keys to all the concrete physical sensor features.
• For each key that appears in two or more features, comment out the key from all but the most historical feature(s).
• In a draft PR, uncomment the overlapping keys.

[Elchi3]

Added the generic Sensor interfaces to all specific sensors (except Magnetometer, that's still in a separate PR).
Where should I leave it in and what should be commented out?

[ddbeck]

Based on the dists, it looks like orientation-sensor has the oldest, least complicated support story involving Sensor. I suggest you comment out the keys in all but that one feature. Though it appears that the keys might've been added to a feature erroneously; see line comment. Thank you!