You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@supports is used in Styles to check support for certain features. However, it is possible to check for the same feature in multiple ways. For example, all of these are valid ways to check for the existence of the dvh unit.
All of these work in StyleX today. However, if the developer is not careful to use the same check in different parts of the codebase, the generated CSS will have unnecessary duplication.
Is there a way we can solve this?
Automatically?
Is it possible to parse the condition in @supports and ascertain the feature being detected with high confidence in most cases?
Perhaps, if we maintain a list of features that are likely to be tested we can detect the feature being detected in the majority of cases.
If so, we can "normalize" the @supports query into a single canonical form and
optimise the generated CSS.
Explicitly?
If it is not possible to simply detect the intention of the developer by parsing @supports queries, we can instead add explicit API to stylex that can be used to detect certain feature?
The first option is preferable because it doesn't bloat the StyleX API any further and doesn't put the responsibility on the developer to ensure they always use the API from StyleX in order to get the most optimised CSS.
The text was updated successfully, but these errors were encountered:
@supports
is used in Styles to check support for certain features. However, it is possible to check for the same feature in multiple ways. For example, all of these are valid ways to check for the existence of thedvh
unit.All of these work in StyleX today. However, if the developer is not careful to use the same check in different parts of the codebase, the generated CSS will have unnecessary duplication.
Is there a way we can solve this?
Automatically?
Is it possible to parse the condition in
@supports
and ascertain the feature being detected with high confidence in most cases?Perhaps, if we maintain a list of features that are likely to be tested we can detect the feature being detected in the majority of cases.
If so, we can "normalize" the
@supports
query into a single canonical form andoptimise the generated CSS.
Explicitly?
If it is not possible to simply detect the intention of the developer by parsing
@supports
queries, we can instead add explicit API to stylex that can be used to detect certain feature?So instead of having to write:
A developer may be able to write:
The first option is preferable because it doesn't bloat the StyleX API any further and doesn't put the responsibility on the developer to ensure they always use the API from StyleX in order to get the most optimised CSS.
The text was updated successfully, but these errors were encountered: