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
This is an official statement from Mozilla regarding the proposed env() feature in css-env-1.
We think this ís a good feature in general, but we object to the following part:
user agents may define additional undocumented environment variables
Allowing vendors to introduce arbitrary new features into the web platform like this has exactly the same problems as vendor-prefixed properties and values have, which as we all know, is the one of the biggest mistakes in CSS's history.
Our opinion is that all env() <custom-ident>s MUST be decided by CSSWG consensus using the same process that is used for introducing other CSS features. That process has the following benefits:
there is a comprehensible specification for each <custom-ident> so that anyone can implement it without having to reverse-engineer specific UAs
each feature gets proper privacy, security, a11y and i18n review
the W3C rules regarding patents apply
etc
UA vendors MUST NOT expose built-in env() features to the web without going through that process. This process requirement should be written into the env() spec itself as a normative requirement on all built-in <custom-ident>s that are exposed to web content.
The text was updated successfully, but these errors were encountered:
The Working Group just discussed process for adding env() variables, and agreed to the following:
RESOLVED: Accept proposal in the issue.
The full IRC log of that discussion
<fantasai> Topic: process for adding env() variables
<fantasai> github: https://github.com//issues/2820
<fantasai> TabAtkins: I agree.
<fantasai> astearns: Currently spec says “
<fantasai> user agents may define additional undocumented environment variables
<fantasai> ”
<fantasai> TabAtkins: I think Apple agrees with proposal, too
<fantasai> dino: When original discussion happened, there was some mumblings that some platforms might want to expose system colors specific to that platform in some way
<fantasai> dino: But I don't know if anyone still believes that
<fantasai> RESOLVED: Accept proposal in the issue.
<fantasai> “UA vendors MUST NOT expose built-in env() features to the web without going through that process”
I believe this issue may be closed, as the spec now reads:
The following UA-defined environment variables are officially defined and must be supported. Additional UA-defined environment variables must not be supported unless/until they are added to this list.
This implies that all new additions need to go through the CSSWG before they can be added to the spec.
Dear CSSWG,
This is an official statement from Mozilla regarding the proposed env() feature in css-env-1.
We think this ís a good feature in general, but we object to the following part:
Allowing vendors to introduce arbitrary new features into the web platform like this has exactly the same problems as vendor-prefixed properties and values have, which as we all know, is the one of the biggest mistakes in CSS's history.
Our opinion is that all env()
<custom-ident>
s MUST be decided by CSSWG consensus using the same process that is used for introducing other CSS features. That process has the following benefits:<custom-ident>
so that anyone can implement it without having to reverse-engineer specific UAsetc
UA vendors MUST NOT expose built-in env() features to the web without going through that process. This process requirement should be written into the env() spec itself as a normative requirement on all built-in
<custom-ident>
s that are exposed to web content.The text was updated successfully, but these errors were encountered: