-
Notifications
You must be signed in to change notification settings - Fork 655
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
[css-variables] User Agent properties and variables #1693
Comments
The CSS Working Group just discussed The full IRC log of that discussion<dauwhe> Topic: dino suggestion on writing modes<astearns> s/writing modes/variables/ <astearns> github: https://github.com//issues/1693 <dauwhe> dino: [approaches podium] <dauwhe> ... I'll explain it backwards <dauwhe> ... we're proposing a new var function <dauwhe> ... instead of exposing user custom properties <dauwhe> ... these are defined by the user agent <dauwhe> ... "contstant" means you can''t change it <dauwhe> ... user wants to control type size on iphone <dauwhe> ... css can't detect that <dauwhe> ... you can query the UA value, and then use calc to respond <dauwhe> ... User agent properties <glazou> s/contstant/constant <dauwhe> ... rest is similar to CSS variables <dauwhe> ... I show lots of examples... font size, foreground/background color... <dauwhe> ... like user pref for black background/white text <dauwhe> ... some dyslexic folks want low contrast <dauwhe> ... so CSS could query UA and then respond <dauwhe> ... or we could use safe areas when projecting to screen of different size <dauwhe> glazou: it's coming from UA and system? <dauwhe> dino: yes <glazou> q+ <dauwhe> iank_: could you draw the safe area on the blackboard <bdc> q+ <dauwhe> dino: this has been a concept in TV <dauwhe> ... some TVs you wouldn't see the whole frame <dauwhe> ... so there was a title safe area, where you know pixels would always be visible <dauwhe> myles: modern TVs fake this, <dauwhe> dino: if you have a circular display, the safe area might be in the middle <astearns> ack myles <astearns> q+ <Florian_> q+ <dauwhe> glazou: I like this <dauwhe> ... open question: could be extended to system colors? <astearns> ack glazou <gregwhitworth> q+ <dauwhe> ... we'd have to find common names for system colors on all platforms <melanierichards> q+ <Florian_> q- <dauwhe> ... 2nd thing: I'd like to see a 2nd part with JS elements to detect system change events <dauwhe> dino: you can't do MQ <Florian_> q+ <dauwhe> glazou: being able to detect theme change, or that you switched to night view.... would be color <astearns> ack bdc <glazou> s/would be color/would be cool <dauwhe> bdc: like underlying idea of prefers-reduced-motion MQ... <dauwhe> ... so why do we want a new thing? <dauwhe> dino: unlike MQ, you want to know a value <dauwhe> ... given one of these values, tell me when it changes <dauwhe> bdc: i don't see a difference <dauwhe> Florian_: i don't think so <dauwhe> ... reduced motion is not about make things slower... it's about doing something else <dauwhe> dino: for reduced motion, sometimes we fade in instead of moving in <dauwhe> ... we're generally not removing animations <glazou> q? <dauwhe> astearns: I want to ask about support <glazou> ack astearns <dauwhe> dino: this raises issue on css var spec <dauwhe> ... but I don't know where the property lists go <dauwhe> astearns: if we don't have access for @supports, how do we author? <dbaron> you could always do @supports (color: constant(foobar)), no? <astearns> ack gregwhitworth <dauwhe> gregwhitworth: these are defined by the UA <dauwhe> ... how are we not going to end up with the -webkit- prefixes unless we agree on everything? <dauwhe> dino: these are new properties <dauwhe> ... just like a normal property <dauwhe> gregwhitworth: they'll be standardized? <dauwhe> dino: yes <fremy> q? <fremy> q+ <dauwhe> ... we want them to be universal <Rossen> q+ <dauwhe> dino: don't know if they should be prefixed with -- <glazou> ack melanierichards <astearns> ack melanierichards <dauwhe> ... so they know they can't set, maybe it's ++ <surma> q+ do we need `constant`? <dauwhe> melanierichards: let's say the ua stores the value <surma> q+ <dauwhe> ... the user hasn't overwritten defeault value of foo <dauwhe> ... would it be undefined? <dauwhe> ... as a user, I'd only want the value when it was overwritten by the user <dauwhe> dino: good question <astearns> ack Florian_ <dauwhe> Florian_: it's a nice hammer we have here, we should be careful with it <dauwhe> ... the examples of things are less comfortable with, as they could be solved in other ways <dauwhe> dino: I'm mostly interested in font size and inset ones <dauwhe> Florian_: for font size, why don't you change REM <dauwhe> TabAtkins: REM is font size on root element, this is initial value <astearns> q? <dauwhe> Florian_: this will be one rem if not overridden? <dauwhe> Florian_: for inset, we've been discussing a similar problem, and were trying to solve some other way? <dauwhe> dino: haven't looked at other solutions <dauwhe> myles: what's the other one <melanierichards> s/as a user, I'd/as an author, I'd/ <dauwhe> Florian_: first, a media query for shape, another is another MQ about 'if I place something there, is it visible?' <dauwhe> ... third is using shape inside: display <Rossen> q? <astearns> ack fremy <dauwhe> ... let's not rush into defining through this, as it might prevent us from exploring other solutions <dauwhe> fremy: I have same concern as surma <dauwhe> ... why don't reuse var function? <dauwhe> ... we could use namespace for var function <surma> q- <dauwhe> ... so we don't need new function <dauwhe> ... just variable under new namespace <dauwhe> dino: i don't mind <dauwhe> ... but we used the name constant to remind user they can't change it <dauwhe> ... under the hood it uses same code as variables <astearns> ack Rossen <dauwhe> fremy: I think it's better to reuse namespace inside var <dauwhe> Rossen: thumbs up on the idea <dauwhe> ... we've had lots of requests <dauwhe> ... in terms of getting font size and background colors <fremy> fremy: e.g. { color: var(user preferred-color) } <dauwhe> ... respond to high contrast, etc <Florian_> var(system safe-area-inset) <dauwhe> ... would be insteresting to see the path forward <dauwhe> ... and to summarize how much stuff you want to expose <Bert> q+ to ask do you need the word "constant"? Isn't 'contant(foo)' easier written as 'foo'? <glazou> q+ <dauwhe> TabAtkins: performance would be better than variables <dauwhe> ... you don't control the values <dauwhe> plinss: what about UA changing while you're animating? <SimonSapin> q+ fallback <dauwhe> dino: we should have current color blink text :) <SimonSapin> q- fallback <SimonSapin> q+ <astearns> ack Bert <Zakim> Bert, you wanted to ask do you need the word "constant"? Isn't 'contant(foo)' easier written as 'foo'? <dauwhe> Bert: constant looks like an identity function. can't you use the ID itself? use "fontsize"? <dauwhe> Florian_: we need comma fallback <dauwhe> fremy: if you have properties like font-family you couldn't use it <dauwhe> TabAtkins: this would add an unlimited set of global keywords to CSS <dauwhe> ... functions prevent that <dauwhe> gregwhitworth: one should be scroll-bar-width <dauwhe> ... arrow color, <astearns> ack glazou <dauwhe> glazou: I want to expand on unlimited sets of global name <gregwhitworth> q+ <dauwhe> ... we want to make sure nothing is shipped until everyone agrees on how it works <astearns> zakim, close queue <Zakim> ok, astearns, the speaker queue is closed <dauwhe> ... let's keep it clean <dauwhe> TabAtkins: you only need a few smart devs with houdini, then everyone can use libraries <dauwhe> glazou: it's like what fremy said, it's a namespace <dauwhe> ... I think we can reach consensus on the names <dauwhe> astearns: two more <astearns> ack SimonSapin <dauwhe> SimonSapin: what about fallback? <dauwhe> dino: you could do comma zero <astearns> ack gregwhitworth <SimonSapin> SimonSapin: fallback same as in var()? <SimonSapin> dino: yes <dauwhe> gregwhitworth: I think our biggest request is high contrast, which we map to system colors <dauwhe> ... it became a problem because not everyone does high contrast theming <dauwhe> ... we may have foreground/background, do we need accent color and accent color2? <dauwhe> ... I foresee problems <dauwhe> ... so fallback is what you get <dauwhe> dino: I hear general agreement <dauwhe> ... concerns about constants vs var with namespace <dauwhe> ... melanierichards wants to know when user explicitly change <dauwhe> ... them, someone else wants to ahve events <dauwhe> myles: unset is same as "i don't know what you're talking about" <dauwhe> astearns: general consensus that this is interesting |
I was just talking to @heycam about this -- and one question he brought up is whether we should pull in most/all of the non-boolean media queries and allow them to be specified as variables. Do people want to write calc expressions based on things like the |
Isn’t this already possible with the |
Would
When you say Cursory experimented with exposing:
Scrollery experimented with exposing the following values:
And then the most fun was exposing values related to HTML elements as CSS variables with Varsity like:
In my experiments I would use JavaScript to supply, and keep updated, the values for these special CSS variables, and then tried to incorporate these variables in my CSS. Many of these techniques aren't things that these 'User Agent Properties' would enable, but I'm sharing some of these here because what they are, and the way they would be used seems so parallel. Perhaps the CSSplus experiments can validate the usefulness of these 'User Agent Properties' and these 'User Agent Properties' being suggested and add some merit to the idea of exposing more of these values from the browser to CSS using CSS Variables as an interface:
So hopefully that helps support the idea with some examples of something kind of similar, and gives an idea of what the CSS might look like when integrating these 'global CSS variables' into designs :D |
It's not a bad idea; I'm down for it. It would just mean we'd have to be a little careful about naming conflicts between MQs and other UA-vars, but I don't think that's a huge issue. (Alternately we could namespace, but I don't think that's necessary.) |
Also: I really want to hook this functionality for custom JS things; the syntax is already super compatible. Just create a map hanging off of document or CSS or something, require the keys to be |
I had a little brainstorm about exposing JS properties of elements to CSS via CSS variables so authors can make use of a little more situational awareness when writing styles. I've been toying around with this idea for a while, but this thread about User Agent properties gave me the motivation I needed to get it published :D There are a few fun code examples in the README and on the demo page: https://github.com/tomhodgins/varius#examples I wonder if a value handoff between JS and CSS like this via an interface of CSS variables could help give CSS more power without needing to extend CSS features 🤔 |
Now that the iPhone X has been announced, the suggestion to add safe-area-insets is more clear. The idea is that a page needs to know how to avoid the rounded corners and notch at the top or side of the screen (depending on orientation). The term "safe area" has been around for a fair while in TV, and we think it makes sense here. Since the value can change depending on orientation, it needs to be exposed directly to the style sheet - hence the proposal for CSS constants. |
I think we had three major things to decide on:
|
Why would Apple deem it OK to place this burden on web developers? |
We're not requiring them to do this. By default we'll avoid the notch by insetting everything. However, if the author wants their page to use the full area, they can opt in but then need to avoid the corners. |
Why don't you just add a property to
And then the UA can just fill up the space as needed with stuff that's normally cut off? This way the developer could just place elements outside the normally available viewport, e.g. render a header element that should extend to the edges of the screen with negative margins. Potentially browsers that support this could add CSS units that are 1/100th's of the safe area (analogous to vw/vh). This could be useful not only for iPhone X, but also for things like circular watch screens, etc. |
I think that is the whole point of the proposal for "Use Agent Variables", the value of the variables we are talking about would be exactly similar to variables containing the size of the safe/unsafe area. I don't want to discourage talking about render-safe-area and other proposals at all, but in a different issue (such that the current issue can stay focused on ironing out the user-agent variables proposal). |
I agree with @grorg reasoning about the default behaviour and the new proposed properties, but still, ideally neither the user, nor the developer should need to bother with this. |
For colors there are already the so called System Colors, that do work in some browsers and OSes (namely IE and Firefox, never tested in Edge). The Background, Highlight and HighlightText colors also work in Windows Phone's IE and one can do a fully adaptive app theme, that mutates with the currently selected background and highlight in the OS - something not possible in iOS/Android. If these constants are going to be implemented in all browsers, I'm all for that. |
Could this help work around the non-tappable area at the bottom of the viewport in iOS Safari? As a designer of web apps I would love a way around that. |
This has obvious parallels to the Round Display stuff; we should make sure these work in compatible ways. But like @FremyCompany said, this is a different issue and the specifics should be discussed in a different thread.
I also strongly prefer
👍 This is easy API-wise - just hang a maplike off of
I'd prefer we make a new spec for this that's intended to be where most of them sit. Like Selectors is for selectors - most of them live there, but a few do live in other specs. |
iOS 11 uses |
We've done that, via a viewport tag. The problem is that we can't just extend objects - because it doesn't always look correct. Also, many objects are snapped to the edges anyway (think of a top or bottom bar), so they need to know how much padding to include in those objects in order to know they are showing content without being clipped. After a lot of experimentation, we concluded that the best thing to do was to give authors the ability to extend to the full viewport and avoid edges if they want to, but we'd do the right thing otherwise. Note that this discussion is orthogonal to the |
/me dons fire retardant suit Note that |
Yep, agreed. As mentioned, we use the |
Minor suggestion: |
For anyone curious about how this works in practice on the iPhone X (both the |
I have got a problem here, and my problem varies ;) More precisely, the values that we are discussing here are not going to be constants. The scrollbar width can be updated on Windows and it is very likely we will end up toggling them off for instance when you detach your keyboard and got to tablet mode. Similarly, when you enable an high-contrast theme, "constant" colors are going to change. Even the proposed notch-safe space will depend on the screen orientation, I assume. All in all, I have not seen any argument to convince me we should invest in adding a new function instead of a namespace for existing value references. |
TLDR: "global variables" != "constants" |
Hi Dean 😃
You had written "a page needs to know how to avoid the rounded corners and notch" - that sure sounded as if each page is required to know how to avoid the rounded corners and the notch.
Thus on/beside each page that doesn't opt in (as the myriads of existing unmaintaned web pages ever created up to now) there will two thick white bars, correct? https://twitter.com/thomasfuchs/status/907764896829452288 Although the white bars are stylable (albeit in a limited way it seems https://twitter.com/thomasfuchs/status/907770902338785280 ), and although though there might be CSS in the future for intentionally-fuller-area pages for dealing with the notch, ideally web developers wouldn't have to bother with Apple's notch or Apple's white bars - at least in my opinion. |
@tobireif, I agree that in addition to giving authors explicit control over how the screen shape is handled, Safari on an iPhone X should by default display pages in a way that takes the notch and rounded corners into account in a reasonable fashion, so that authors are not required to make changes to have their pages properly displayed on the device. You also seem to be making the argument that's Apple's current answer to this problem (letterboxing the page using the background color, to avoid unexpectedly clipping content in pages not designed to take into account the screen shape) is a completely unfit way to handle the problem. Why do you think that is the case, and what alternative do you suggest? To me, clipping content by default—to avoid ungainly, unexpected letterboxing—has far more breaking potential, potentially hiding important areas of content or interactive elements. Without allowing any clipping to occur, it's hard not to end up with blank areas around the page; any ideas as to handle these better is appreciated. |
Perhaps it's too late, but I had a thought regarding the name choice. What about My only issue with it would be that it is almost too similar to |
We're locked and loaded to ship env(), and there was a WG resolution on that, so we'd really prefer that it not change again. |
Ah, very good. Then don't mind me! |
Can anyone give me guidance on how to get at these new constant/env() properties from javascript? |
@jkuss This is actually quite interesting. I believe at this moment WebKit, being the only User Agent shipped with this functionality, offers no JS API to directly obtain Being UA-specific things, it sort of makes sense that I know this problem is right in the middle of a standardization minefield, and probably out-of-scope of CSSWG, but it doesn’t particularly seem in-scope anywhere else. EDIT: Issue 1 of the new spec draft suggests an API should be defined on |
Safari Technology Preview 49 has added support for parsing |
Safari Technology Preview 52 has added two new ones: |
@kiding any documents about |
@zhouqicf I don't think so, but you can infer them from WebKit's bug tracker. |
Since Chrome wants to start working on env(), but no further action has happened in the PR, I've gone ahead and written up a draft spec for the feature: https://drafts.csswg.org/css-env-1/ There are a lot of open issues that need to be addressed. It would be a great help if @grorg could take a crack at answering them here; I'll be happy to edit them into the draft. ^_^ |
Per... https://drafts.csswg.org/mediaqueries/#units
Any idea on how "user’s preferences" will be interpreted, allowing media queries use of something like Also, this reminds me of discussion currently happening in #2430 - font-size: 'medium' value is the user's preferred font size. |
I think this will lead to vendor-specific, or even device-specific, dialects of CSS. |
@tabatkins’ new draft specification mentions:
I want to express that I am glad that this is still being included. There appears to be at least some community demand for this use case, as evidenced by this Stack Overflow question: “CSS native variables not working in media queries”. I myself would find them quite useful as an author. |
Are there still plans to advance the spec, make envs definable by users and usable in media queries? |
Given that css-env-1 exists now, can this issue be closed? |
Here is WebKit's proposal for a new type of property and variable.
User Agent Properties
This specification defines an open-ended set of properties called
User Agent properties
, which, among other things, are used to define the substitutionvalue of
constant()
functions.Name: (various)
Value:
<declaration-value>
Initial: (nothing, see prose)
Applies to: all elements
Inherited: yes
Percentages: n/a
Media: all
Computed value: specified value with variables substituted (but see prose for "invalid variables")
Canonical order: per grammar
Animatable: no
A User Agent property is not specified in a style sheet. User Agent properties
instead define variables, referenced with the
constant()
notation.For example, a page that wants to use the user's requested font sizing, and page
background:
Unlike other CSS properties, User Agent property names are case-sensitive.
User Agent properties are not reset by the all property. If a style rule attempts to
define a value for a User Agent property, it is ignored.
Using Cascading User Agent Variables: the 'constant()' notation
The value of a
User Agent property
can be substituted into the value of anotherproperty with the
constant()
function. The syntax ofconstant()
is:The
constant()
function is used in the same manner, and follows the same rules,as the
var()
function.Defined User Agent Variables
user-font-size
: User's requested font sizeuser-background-color
: User's requested background coloruser-foreground-color
: User's requested foreground colorsafe-area-inset-top
: Inset, as a<length>
from the top of the viewport to the title-safe content area.safe-area-inset-right
: Inset, as a<length>
from the right of the viewport to the title-safe content area.safe-area-inset-left
: Inset, as a<length>
from the left of the viewport to the title-safe content area.safe-area-inset-bottom
: Inset, as a<length>
from the bottom of the viewport to the title-safe content area.The text was updated successfully, but these errors were encountered: