-
Notifications
You must be signed in to change notification settings - Fork 709
[css-ui] Hide proprietary appearance values #3968 #3985
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
base: main
Are you sure you want to change the base?
Conversation
Sounds good by me, but I would phrase this a bit more explicitly in the tabl:
|
You can serialize CSS values without going through Another approach, if we want expose |
But you cannot set those as an author, and you cannot access UA stylesheets via CSSOM, right? At least the way I plan to go about non-standard values in Gecko is "removing as much as possible, leave the rest only exposed to UA stylesheets". |
Right, but that setup requires that the non-standard keywords aren't parsed in author-origin CSS (what about user origin?), which would be a separate requirement. |
@zcorpan I assumed that was a requirement (above, "That doesn't seem like what's desired here."). Is it acceptable to allow authors to set |
I suppose UAs aren't allowed to support values that aren't listed in the Value grammar, but this isn't particularly clear (to me, at least). From the spec change here, a possible interpretation is that non-standard values should continue to work in author CSS but getting their value from I don't think authors should be able to set |
This is an attempt to implement the following suggestion from gh-3968:
However, in gh-3980, the motivating use case is under discussion. Depending on how that is resolved (e.g. by disabling access to non-standard pseudo-elements), this change may not be necessary. Even in that case, standardizing this behavior could improve consistency in a more immediate timeframe.
The text I've written feels primitive to me, but I can't think of a better way to normatively handle a disallowed situation. For instance, it would be cleaner to allow UAs to extend the set of valid values, but that would also allow authors to use apply those proprietary values in their own code. That doesn't seem like what's desired here.
An alternative to the property's computed value may be CSSOM's definition of "resolved value". That's a little more indirect, but indirection may be warranted for an edge case like this.
/cc @FremyCompany @zcorpan