Skip to content
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

[mediaqueries-5] Clarify definition and use cases for light-level feature #1727

Closed
alexshalamov opened this issue Aug 16, 2017 · 6 comments
Closed
Assignees

Comments

@alexshalamov
Copy link

Spec: https://drafts.csswg.org/mediaqueries-5/#descdef-media-light-level

We had a discussion about ambient light sensor use cases, security and privacy, in particular how light-level is mapped to ambient light sensor measurements.

From the MQ5 spec, it looks like the main use case is web content contrast adjustment / accessibility.

The spec defines the light-level as:

"The light-level media feature is used to query about the ambient light-level in which the device is used"

then later:

"this specification intentionally refrains from defining the three levels in terms of a measurement in lux"

That sounds like light-level values are not directly mapped to ambient light (lux) values in which device is used.

Would it be better to define light-level as a hint, whose values would be derived from ambient light measurements, screen brightness, screen technology, etc. Based on the hint, web page could adjust contrast ratio.

@tabatkins
Copy link
Member

From the MQ5 spec, it looks like the main use case is web content contrast adjustment / accessibility.

No, that's one of the use-cases. The other is what it's named after - adjusting content to the ambient light level.

Would it be better to define light-level as a hint, whose values would be derived from ambient light measurements, screen brightness, screen technology, etc.

Isn't that precisely what the spec already says? The note is pretty explicit that lux is one component of the value, and that screen tech/etc are also important.

@alexshalamov
Copy link
Author

Isn't that precisely what the spec already says? The note is pretty explicit that lux is one component of the value, and that screen tech/etc are also important.

True, informative note has very good points, however, normative prose is bit misleading.
For example, e-book reader during sunny day might return 'normal' while mobile device with TFT may report 'washed', yet, ambient light level would be exactly the same for two cases.

Thus, following statement "The light-level media feature is used to query about the ambient light-level in which the device is used," is misleading, since ambient light level is the same.

I think it would be good to redefine 'ambient light level' term (similar to CSS pixels vs pixels) or create new term to avoid confusion.

For example:

For the purpose of this specification, the <dfn>CSS ambient light level</dfn> represents conditions in which device is used, such as illuminance level of the environment, screen brightness, screen technology and other factors affecting the contrast of the device's screen.

Or:

The information about <dfn>condition</dfn> in which the device is used may be derived from the factors such as: illuminance level of the environment, screen brightness, screen technology and other factors affecting the contrast of the device's screen.

The light-level media feature is used to query information about the <a>condition</a> in which the device is used, to allow the author to adjust style of the document in response. The following values are valid:

/CC @anssiko the current ALS spec editor.

@anssiko
Copy link
Member

anssiko commented Aug 17, 2017

I agree with @alexshalamov's reasoning that there's confusion due to the terminology used.

In addition, I'd propose you consider renaming the light-level media feature into something else to better communicate the fact it is a composite, and to ensure it is not confused with the Ambient Light Sensor API and its current light level definition.

I believe the CSS WG is in the best position to pick a better name for this media feature considering consistency across various CSS features, so I leave the naming issue to the group.

The Device and Sensors WG responsible for the Ambient Light Sensor API has bi-weekly calls, so should this topic need further discussion, we'd be happy to invite interested people from the CSS WG to join our call, or alternatively, we could join one of the CSS WG calls.

@frivoal frivoal self-assigned this Aug 17, 2017
@tabatkins
Copy link
Member

The name light-level accurately and clearly communicates what it's about; I suspect anything more nuanced will just make the feature harder to understand. Names don't have to be a perfect reflection of every aspect of a feature, they need to be a short, easy to spell, evocative label for the feature, and I think light-level works well for that.

The values are also accurately described according to their function; they very vaguely refer to light levels, but more importantly dictate what is happening to the page in each case, which the author should respond to.

I think y'all are overthinking this and confusing yourselves. ^_^

@anssiko
Copy link
Member

anssiko commented Aug 18, 2017

As said, I leave the light-level media feature naming to the group. Just wanted to make sure you have all the information needed to make an informed decision.

That said, I think you should incorporate @alexshalamov's informative (i.e. not web-facing) clarifications into the spec prose, but then again, I will not oppose if you prefer not to do so.

@frivoal
Copy link
Collaborator

frivoal commented Jul 31, 2020

The light-level feature has been removed altogether, as it had become redundant with other media features. See #5359 for how the decision was made, and https://drafts.csswg.org/mediaqueries-5/#auto-pref (and in particular example 54) for how scenarios previously covered by light-level can be covered by other media features.

@frivoal frivoal added Closed Accepted by CSSWG Resolution Testing Unnecessary Memory aid - issue doesn't require tests labels Jul 31, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants