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

Open
grorg opened this Issue Aug 4, 2017 · 87 comments

Comments

Projects
None yet
@grorg
Contributor

grorg commented Aug 4, 2017

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 substitution
value 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:

:root {
  font-size: constant(user-font-size);
}

body {
  background-color: constant(user-background-color);
}

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 another
property with the constant() function. The syntax of constant() is:

constant() = constant( <user-agent-property-name> [, <declaration-value> ]? )

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 size
  • user-background-color: User's requested background color
  • user-foreground-color: User's requested foreground color
  • safe-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.
@css-meeting-bot

This comment has been minimized.

Show comment
Hide comment
@css-meeting-bot

css-meeting-bot Aug 4, 2017

Member

The CSS Working Group just discussed dino suggestion on writing modes.

The full IRC log of that discussion <dauwhe> Topic: dino suggestion on writing modes
<astearns> s/writing modes/variables/
<astearns> github: https://github.com/w3c/csswg-drafts/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
Member

css-meeting-bot commented Aug 4, 2017

The CSS Working Group just discussed dino suggestion on writing modes.

The full IRC log of that discussion <dauwhe> Topic: dino suggestion on writing modes
<astearns> s/writing modes/variables/
<astearns> github: https://github.com/w3c/csswg-drafts/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
@dbaron

This comment has been minimized.

Show comment
Hide comment
@dbaron

dbaron Aug 8, 2017

Member

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 width media query, etc.?

Member

dbaron commented Aug 8, 2017

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 width media query, etc.?

@ausi

This comment has been minimized.

Show comment
Hide comment
@ausi

ausi Aug 8, 2017

Do people want to write calc expressions based on things like the width media query, etc.?

Isn’t this already possible with the vw and vh CSS units?

ausi commented Aug 8, 2017

Do people want to write calc expressions based on things like the width media query, etc.?

Isn’t this already possible with the vw and vh CSS units?

@tomhodgins

This comment has been minimized.

Show comment
Hide comment
@tomhodgins

tomhodgins Aug 8, 2017

Would constant() work inside calc() so we could do things like this?

* {
  font-size: calc( (constant(user-font-size) * 0) + 12px);
}

Do people want to write calc expressions based on things like the width media query, etc.?

When you say width do you mean the same value as window.innerWidth? I experimented a little big with exposing various values as CSS properties to see what uses I could come up with. Things I experimented with included these global values:

Cursory experimented with exposing:

  • innerWidth
  • innerHeight
  • cursor X and Y position

Scrollery experimented with exposing the following values:

  • scrollWidth
  • scrollHeight
  • scrollTop
  • scrollLeft

And then the most fun was exposing values related to HTML elements as CSS variables with Varsity like:

  • offsetWidth
  • offsetHeight
  • offsetLeft
  • offsetTop
  • element's aspect-ratio
  • number of characters of text
  • number of child elements
  • current value

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

tomhodgins commented Aug 8, 2017

Would constant() work inside calc() so we could do things like this?

* {
  font-size: calc( (constant(user-font-size) * 0) + 12px);
}

Do people want to write calc expressions based on things like the width media query, etc.?

When you say width do you mean the same value as window.innerWidth? I experimented a little big with exposing various values as CSS properties to see what uses I could come up with. Things I experimented with included these global values:

Cursory experimented with exposing:

  • innerWidth
  • innerHeight
  • cursor X and Y position

Scrollery experimented with exposing the following values:

  • scrollWidth
  • scrollHeight
  • scrollTop
  • scrollLeft

And then the most fun was exposing values related to HTML elements as CSS variables with Varsity like:

  • offsetWidth
  • offsetHeight
  • offsetLeft
  • offsetTop
  • element's aspect-ratio
  • number of characters of text
  • number of child elements
  • current value

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

@tabatkins

This comment has been minimized.

Show comment
Hide comment
@tabatkins

tabatkins Aug 8, 2017

Member

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 width media query, etc.?

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.)

Member

tabatkins commented Aug 8, 2017

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 width media query, etc.?

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.)

@tabatkins

This comment has been minimized.

Show comment
Hide comment
@tabatkins

tabatkins Aug 8, 2017

Member

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 --foo form and the values to be TypedOM instances (so you get grammar-checking at parse-time, as intended), and boom, "global variables" that can be used in all locations in a stylesheet, including in MQ conditions, and which don't have unfortunate performance implications due to inheritance from root.

Member

tabatkins commented Aug 8, 2017

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 --foo form and the values to be TypedOM instances (so you get grammar-checking at parse-time, as intended), and boom, "global variables" that can be used in all locations in a stylesheet, including in MQ conditions, and which don't have unfortunate performance implications due to inheritance from root.

@tomhodgins

This comment has been minimized.

Show comment
Hide comment
@tomhodgins

tomhodgins Aug 10, 2017

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 🤔

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 🤔

@grorg

This comment has been minimized.

Show comment
Hide comment
@grorg

grorg Sep 13, 2017

Contributor

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.

Contributor

grorg commented Sep 13, 2017

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.

@grorg

This comment has been minimized.

Show comment
Hide comment
@grorg

grorg Sep 13, 2017

Contributor

I think we had three major things to decide on:

  1. The name: whether to use constant(name), var(name-without-leading-hyphen) or var(user name). I'd prefer constant because it makes it more clear that there is no way for the developer to set these properties.

  2. A JS hook so that they can be easily queried and raise notifications on change.

  3. A place to define the new properties/values. Maybe these just end up in the respective specifications clearly labelled as read-only.

Contributor

grorg commented Sep 13, 2017

I think we had three major things to decide on:

  1. The name: whether to use constant(name), var(name-without-leading-hyphen) or var(user name). I'd prefer constant because it makes it more clear that there is no way for the developer to set these properties.

  2. A JS hook so that they can be easily queried and raise notifications on change.

  3. A place to define the new properties/values. Maybe these just end up in the respective specifications clearly labelled as read-only.

@tobireif

This comment has been minimized.

Show comment
Hide comment
@tobireif

tobireif Sep 13, 2017

a page needs to know how to avoid the rounded corners and notch at the top or side of the screen

Why would Apple deem it OK to place this burden on web developers?

a page needs to know how to avoid the rounded corners and notch at the top or side of the screen

Why would Apple deem it OK to place this burden on web developers?

@grorg

This comment has been minimized.

Show comment
Hide comment
@grorg

grorg Sep 13, 2017

Contributor

@tobireif

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.

Contributor

grorg commented Sep 13, 2017

@tobireif

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.

@madrobby

This comment has been minimized.

Show comment
Hide comment
@madrobby

madrobby Sep 13, 2017

Why don't you just add a property to body or html that tells the browser that it's ok to render stuff that's normally cut off because it's outside the viewport?

render-safe-area: allow;

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.

madrobby commented Sep 13, 2017

Why don't you just add a property to body or html that tells the browser that it's ok to render stuff that's normally cut off because it's outside the viewport?

render-safe-area: allow;

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.

@FremyCompany

This comment has been minimized.

Show comment
Hide comment
@FremyCompany

FremyCompany Sep 13, 2017

Contributor

Potentially browsers that support this could add CSS units that are 1/100th's of the safe area (analogous to vw/vh).

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).

Contributor

FremyCompany commented Sep 13, 2017

Potentially browsers that support this could add CSS units that are 1/100th's of the safe area (analogous to vw/vh).

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).

@alessiomaffeis

This comment has been minimized.

Show comment
Hide comment
@alessiomaffeis

alessiomaffeis Sep 13, 2017

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.

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.

@bundyo

This comment has been minimized.

Show comment
Hide comment
@bundyo

bundyo Sep 13, 2017

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.

bundyo commented Sep 13, 2017

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.

@ry5n

This comment has been minimized.

Show comment
Hide comment
@ry5n

ry5n Sep 13, 2017

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.

ry5n commented Sep 13, 2017

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.

@tabatkins

This comment has been minimized.

Show comment
Hide comment
@tabatkins

tabatkins Sep 13, 2017

Member

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).

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.

The name: whether to use constant(name), var(name-without-leading-hyphen) or var(user name). I'd prefer constant because it makes it more clear that there is no way for the developer to set these properties.

I also strongly prefer constant(). (I discussed in the meeting how this ties into the desire for cheaper "global variables", so authors could use constant(--name) while UA-defined ones are just constant(name))

A JS hook so that they can be easily queried and raise notifications on change.

👍 This is easy API-wise - just hang a maplike off of CSS, and make it an event emitter.

A place to define the new properties/values. Maybe these just end up in the respective specifications clearly labelled as read-only.

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.

Member

tabatkins commented Sep 13, 2017

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).

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.

The name: whether to use constant(name), var(name-without-leading-hyphen) or var(user name). I'd prefer constant because it makes it more clear that there is no way for the developer to set these properties.

I also strongly prefer constant(). (I discussed in the meeting how this ties into the desire for cheaper "global variables", so authors could use constant(--name) while UA-defined ones are just constant(name))

A JS hook so that they can be easily queried and raise notifications on change.

👍 This is easy API-wise - just hang a maplike off of CSS, and make it an event emitter.

A place to define the new properties/values. Maybe these just end up in the respective specifications clearly labelled as read-only.

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.

@dpogue

This comment has been minimized.

Show comment
Hide comment
@dpogue

dpogue Sep 13, 2017

This could be useful not only for iPhone X, but also for things like circular watch screens, etc.

iOS 11 uses viewport-fit in the viewport meta tag to handle this, which is consistent with the CSS Round Displays working draft.

dpogue commented Sep 13, 2017

This could be useful not only for iPhone X, but also for things like circular watch screens, etc.

iOS 11 uses viewport-fit in the viewport meta tag to handle this, which is consistent with the CSS Round Displays working draft.

@grorg

This comment has been minimized.

Show comment
Hide comment
@grorg

grorg Sep 14, 2017

Contributor

Why don't you just add a property to body or html that tells the browser that it's ok to render stuff that's normally cut off because it's outside the viewport?

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.

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 constant proposal. I think there is general support for that without finalizing the safe-area-inset topic.

Contributor

grorg commented Sep 14, 2017

Why don't you just add a property to body or html that tells the browser that it's ok to render stuff that's normally cut off because it's outside the viewport?

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.

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 constant proposal. I think there is general support for that without finalizing the safe-area-inset topic.

@grorg

This comment has been minimized.

Show comment
Hide comment
@grorg

grorg Sep 14, 2017

Contributor

/me dons fire retardant suit

Note that constant is partially supported in iOS 11/High Sierra, but we are very open to changing this ASAP to something everyone agrees on. The good news is that the values are always zero on existing hardware (and parsing errors mean they fallback easily on other engines)

Contributor

grorg commented Sep 14, 2017

/me dons fire retardant suit

Note that constant is partially supported in iOS 11/High Sierra, but we are very open to changing this ASAP to something everyone agrees on. The good news is that the values are always zero on existing hardware (and parsing errors mean they fallback easily on other engines)

@grorg

This comment has been minimized.

Show comment
Hide comment
@grorg

grorg Sep 14, 2017

Contributor

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.

Yep, agreed. As mentioned, we use the viewport-fit meta tag from round displays. One can imagine a display with rounded corners as just a version of a rounded display (or visa versa)… ignoring the notch.

Contributor

grorg commented Sep 14, 2017

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.

Yep, agreed. As mentioned, we use the viewport-fit meta tag from round displays. One can imagine a display with rounded corners as just a version of a rounded display (or visa versa)… ignoring the notch.

@heycam

This comment has been minimized.

Show comment
Hide comment
@heycam

heycam Sep 14, 2017

Contributor

Minor suggestion: const() might be a nicer name to parallel var() (since that didn't get named variable()).

Contributor

heycam commented Sep 14, 2017

Minor suggestion: const() might be a nicer name to parallel var() (since that didn't get named variable()).

@dpogue

This comment has been minimized.

Show comment
Hide comment
@dpogue

dpogue Sep 14, 2017

For anyone curious about how this works in practice on the iPhone X (both the viewport-fit aspects from the CSS Round Displays spec and the proposed constant() values), I've written a blog post about it with screenshots showing some different cases: https://ayogo.com/blog/ios11-viewport/

dpogue commented Sep 14, 2017

For anyone curious about how this works in practice on the iPhone X (both the viewport-fit aspects from the CSS Round Displays spec and the proposed constant() values), I've written a blog post about it with screenshots showing some different cases: https://ayogo.com/blog/ios11-viewport/

@FremyCompany

This comment has been minimized.

Show comment
Hide comment
@FremyCompany

FremyCompany Sep 14, 2017

Contributor

I also strongly prefer constant(). (I discussed in the meeting how this ties into the desire for cheaper "global variables", so authors could use constant(--name) while UA-defined ones are just constant(name))

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.

Contributor

FremyCompany commented Sep 14, 2017

I also strongly prefer constant(). (I discussed in the meeting how this ties into the desire for cheaper "global variables", so authors could use constant(--name) while UA-defined ones are just constant(name))

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.

@FremyCompany

This comment has been minimized.

Show comment
Hide comment
@FremyCompany

FremyCompany Sep 14, 2017

Contributor

TLDR: "global variables" != "constants"

Contributor

FremyCompany commented Sep 14, 2017

TLDR: "global variables" != "constants"

@tobireif

This comment has been minimized.

Show comment
Hide comment
@tobireif

tobireif Sep 14, 2017

Hi Dean 😃

We're not requiring them to do this.

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.

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.

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.

Hi Dean 😃

We're not requiring them to do this.

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.

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.

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.

@Cykelero

This comment has been minimized.

Show comment
Hide comment
@Cykelero

Cykelero Sep 14, 2017

@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.
Another nice point of the letterboxing-by-default approach is how nicely it folds in with the viewport-fit working draft, so that authors can work to target non-rectangle displays in general, not just iPhone X-shaped ones.

@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.
Another nice point of the letterboxing-by-default approach is how nicely it folds in with the viewport-fit working draft, so that authors can work to target non-rectangle displays in general, not just iPhone X-shaped ones.

@basiclines

This comment has been minimized.

Show comment
Hide comment
@basiclines

basiclines Sep 14, 2017

How should behave this UA Properties/Constants when writing direction is RTL instead of LTR?

safe-area-inset-right
safe-area-inset-left

How should behave this UA Properties/Constants when writing direction is RTL instead of LTR?

safe-area-inset-right
safe-area-inset-left

@dpogue

This comment has been minimized.

Show comment
Hide comment
@dpogue

dpogue Sep 14, 2017

How should behave this UA Properties/Constants when writing direction is RTL instead of LTR?

Those refer to the left and right of the physical device screen, regardless of writing direction

dpogue commented Sep 14, 2017

How should behave this UA Properties/Constants when writing direction is RTL instead of LTR?

Those refer to the left and right of the physical device screen, regardless of writing direction

@tobireif

This comment has been minimized.

Show comment
Hide comment
@tobireif

tobireif Sep 14, 2017

@Cykelero

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?

Ideally there wouldn't be a notch. That is my opinion. No notch, no issues 😀

The notch issue is not caused by a force of nature, but it has been added based on a decision by Apple. That is the issue.

Now that they did add the notch, it sure is sensible to limit the default viewport to the safe area (although as default color for the side-bars, black-like-the-notch-etc might be better than glowing bright white), and it also is sensible to also offer an option for using the full area (plus constants for handling the notch etc).

I'm not arguing anything. I'd like to have had a vote (or better a veto 😀 ) regarding whether Apple adds the problematic notch, but alas that decision has been set in stone already.

Now we can only deal with the issues, which I sure will do 😀
I'll probably (normally) stay inside the safe area (the default viewport) but try to style the side-bars/letterboxes in a sensible way.

@Cykelero

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?

Ideally there wouldn't be a notch. That is my opinion. No notch, no issues 😀

The notch issue is not caused by a force of nature, but it has been added based on a decision by Apple. That is the issue.

Now that they did add the notch, it sure is sensible to limit the default viewport to the safe area (although as default color for the side-bars, black-like-the-notch-etc might be better than glowing bright white), and it also is sensible to also offer an option for using the full area (plus constants for handling the notch etc).

I'm not arguing anything. I'd like to have had a vote (or better a veto 😀 ) regarding whether Apple adds the problematic notch, but alas that decision has been set in stone already.

Now we can only deal with the issues, which I sure will do 😀
I'll probably (normally) stay inside the safe area (the default viewport) but try to style the side-bars/letterboxes in a sensible way.

@madrobby

This comment has been minimized.

Show comment
Hide comment
@madrobby

madrobby Sep 14, 2017

For the benefit of anyone finding this looking for actionable advice on how to deal with the iPhone X viewport issues, here’s a great write-up on using viewport-fit: http://stephenradford.me/removing-the-white-bars-in-safari-on-iphone-x/

For the benefit of anyone finding this looking for actionable advice on how to deal with the iPhone X viewport issues, here’s a great write-up on using viewport-fit: http://stephenradford.me/removing-the-white-bars-in-safari-on-iphone-x/

@eeeps

This comment has been minimized.

Show comment
Hide comment
@eeeps

eeeps Sep 14, 2017

What @FremyCompany said. @tabatkins had to explain to me that there are two axes of variablilty: changing over tree context and changing over the lifetime of the document. constant() is about tree context, but “constant” connotes time. global() would be a better name.

eeeps commented Sep 14, 2017

What @FremyCompany said. @tabatkins had to explain to me that there are two axes of variablilty: changing over tree context and changing over the lifetime of the document. constant() is about tree context, but “constant” connotes time. global() would be a better name.

@tabatkins

This comment has been minimized.

Show comment
Hide comment
@tabatkins

tabatkins Sep 14, 2017

Member

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.

Yeah, what eeeps said - they're constant over the page, as opposed to refs that can vary from element to element.

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.

A big difference is that these are usable in places other than properties and animations - you should be able to use these "constants" in MQs and such. (Again, because they're constant across the page, and so don't care about what context they're being used in.) I'm loathe to say "var() is only allowed on elements normally, but you can use it wherever you want if you use this particular type of var name" - much better for everyone if it's a totally distinct name.

Member

tabatkins commented Sep 14, 2017

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.

Yeah, what eeeps said - they're constant over the page, as opposed to refs that can vary from element to element.

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.

A big difference is that these are usable in places other than properties and animations - you should be able to use these "constants" in MQs and such. (Again, because they're constant across the page, and so don't care about what context they're being used in.) I'm loathe to say "var() is only allowed on elements normally, but you can use it wherever you want if you use this particular type of var name" - much better for everyone if it's a totally distinct name.

@jakearchibald

This comment has been minimized.

Show comment
Hide comment
@jakearchibald

jakearchibald Sep 14, 2017

Contributor

From http://stephenradford.me/removing-the-white-bars-in-safari-on-iphone-x/:

I added the following to the main container on the website.

padding: constant(safe-area-inset-right);  

Unless I'm mistaken, this will break when the phone is rotated. It also assumes that the right inset will be the largest, and that padding by the largest value on all sides will look fine.

To avoid this kind of error, should we have safe-area-inset that could be used in shorthand properties like margin, padding, border-width? It would be equivalent of constant(safe-area-inset-top) constant(safe-area-inset-right) constant(safe-area-inset-bottom) constant(safe-area-inset-left).

We might also consider ways to get the max/min inset value, via a generic max and min function.

Contributor

jakearchibald commented Sep 14, 2017

From http://stephenradford.me/removing-the-white-bars-in-safari-on-iphone-x/:

I added the following to the main container on the website.

padding: constant(safe-area-inset-right);  

Unless I'm mistaken, this will break when the phone is rotated. It also assumes that the right inset will be the largest, and that padding by the largest value on all sides will look fine.

To avoid this kind of error, should we have safe-area-inset that could be used in shorthand properties like margin, padding, border-width? It would be equivalent of constant(safe-area-inset-top) constant(safe-area-inset-right) constant(safe-area-inset-bottom) constant(safe-area-inset-left).

We might also consider ways to get the max/min inset value, via a generic max and min function.

@dpogue

This comment has been minimized.

Show comment
Hide comment
@dpogue

dpogue Sep 14, 2017

It's worth pointing out that these do work in calc() expressions, so something like padding-top: calc(20px + constant(safe-area-inset-top)) works like a charm

dpogue commented Sep 14, 2017

It's worth pointing out that these do work in calc() expressions, so something like padding-top: calc(20px + constant(safe-area-inset-top)) works like a charm

@othermaciej

This comment has been minimized.

Show comment
Hide comment
@othermaciej

othermaciej Sep 14, 2017

Member

Unless I'm mistaken, this will break when the phone is rotated. It also assumes that the right inset will be the largest, and that padding by the largest value on all sides will look fine.

The inset values adjust when you rotate, so it probably won't break on rotation, but it is indeed wrong.

To avoid this kind of error, should we have safe-area-inset that could be used in shorthand properties like margin, padding, border-width?

If it's possible to have variables/constants produce multiple values, then yes, it would help avoid wrongly over-applying a single edge's value.

We might also consider ways to get the max/min inset value, via a generic max and min function.

CSS calc(), min() and max() are super useful with this, they are already in the CSS Units and Values Level 4 Editor's Draft. https://drafts.csswg.org/css-values/#funcdef-min

Besides the use you describe, it's often useful to padding or margin to the minimum of the inset or a fixed padding for the case where there's no inset.

Member

othermaciej commented Sep 14, 2017

Unless I'm mistaken, this will break when the phone is rotated. It also assumes that the right inset will be the largest, and that padding by the largest value on all sides will look fine.

The inset values adjust when you rotate, so it probably won't break on rotation, but it is indeed wrong.

To avoid this kind of error, should we have safe-area-inset that could be used in shorthand properties like margin, padding, border-width?

If it's possible to have variables/constants produce multiple values, then yes, it would help avoid wrongly over-applying a single edge's value.

We might also consider ways to get the max/min inset value, via a generic max and min function.

CSS calc(), min() and max() are super useful with this, they are already in the CSS Units and Values Level 4 Editor's Draft. https://drafts.csswg.org/css-values/#funcdef-min

Besides the use you describe, it's often useful to padding or margin to the minimum of the inset or a fixed padding for the case where there's no inset.

@danieltj27

This comment has been minimized.

Show comment
Hide comment
@danieltj27

danieltj27 Sep 14, 2017

To me, this could be easily avoidable by having WebKit support a new meta tag that either 'respects full viewport' (so takes the notch into account) or instead on the WebKit/Safari side, just indent the corners to line up the corners and notch so there's no need to inset. Surely that's the most backwards compatible and on-breaking way forward?

This seems very overkill for supporting one platform by implementing more CSS properties that is only useful for iOS Safari (on iPhone X).

Something to the effect of:

<meta name="safe-viewport" content="render-viewport-spacing=full" />

To me, this could be easily avoidable by having WebKit support a new meta tag that either 'respects full viewport' (so takes the notch into account) or instead on the WebKit/Safari side, just indent the corners to line up the corners and notch so there's no need to inset. Surely that's the most backwards compatible and on-breaking way forward?

This seems very overkill for supporting one platform by implementing more CSS properties that is only useful for iOS Safari (on iPhone X).

Something to the effect of:

<meta name="safe-viewport" content="render-viewport-spacing=full" />
@tomhodgins

This comment has been minimized.

Show comment
Hide comment
@tomhodgins

tomhodgins Sep 17, 2017

To me, the term constant() feels like a misnomer, especially if the rule (and property and value) can be overriden by a more specific selector.

body {
  color: constant(fontColor);
}
body.home {
  color: red;
}

It's not looking "constant" in any sense of the word, plus it's confusing on another level with var and const in JavaScript existing for similar uses, but different to each other and also different to variable() and the proposed constant().

The $() syntax doesn't feel quite like anything else in CSS. The first thing that pops into my mind would be something like global() or ua() standing for user-agent. Consider you had never heard of the functionality of exposing browser settings to CSS before, which of the following syntax examples conjures up the idea that that's what's going on in the code:

body {
  color: constant(fontColor);
  background: constant(backgroundColor);
}

or

body {
  color: $(fontColor);
  background $(backgroundColor);
}

or

body {
  color: browser(fontColor);
  background: browser(backgroundColor);
}

Given these examples, the presence of constant() without any other context makes it sound like an invariable…variable? What's that? It doesn't really make sense, if you wanted it constantly one colour couldn't you just set that in the CSS all the time? It's so wrong it feels nearly self-negating.

The second example, using $() reads to me like a layer on top of CSS - either a preprocessor variable or something that's going to be interpolated before that text becomes CSS. This is closer to what's really going on, but my first thought is not that it's coming from the browser. If I saw that in the wild my first thought would be that somebody accidentally published some kind of Sass/Less/Stylus-like preprocessor dialect without compiling it to CSS first. My initial thought would be to google what preprocessor uses $() as a syntax so I could compile it properly.

But given the third example, browser(), even if you have no idea that the functionality is possible, it's CSS-like enough that it could be a native feature, and the name browser() hints that it's nothing that could be rendered in advance…before the browser. For me at least, I think this is not only elegant enough to use while authoring CSS, but also provides the correct context to help people intuit what is going on in the code, as well as provide something 'googleable' they can look up to find out more.

That's my 2¢. This is a great idea for a feature, getting the naming right (or wrong) could be the difference between empowering authors and bewildering them.

To me, the term constant() feels like a misnomer, especially if the rule (and property and value) can be overriden by a more specific selector.

body {
  color: constant(fontColor);
}
body.home {
  color: red;
}

It's not looking "constant" in any sense of the word, plus it's confusing on another level with var and const in JavaScript existing for similar uses, but different to each other and also different to variable() and the proposed constant().

The $() syntax doesn't feel quite like anything else in CSS. The first thing that pops into my mind would be something like global() or ua() standing for user-agent. Consider you had never heard of the functionality of exposing browser settings to CSS before, which of the following syntax examples conjures up the idea that that's what's going on in the code:

body {
  color: constant(fontColor);
  background: constant(backgroundColor);
}

or

body {
  color: $(fontColor);
  background $(backgroundColor);
}

or

body {
  color: browser(fontColor);
  background: browser(backgroundColor);
}

Given these examples, the presence of constant() without any other context makes it sound like an invariable…variable? What's that? It doesn't really make sense, if you wanted it constantly one colour couldn't you just set that in the CSS all the time? It's so wrong it feels nearly self-negating.

The second example, using $() reads to me like a layer on top of CSS - either a preprocessor variable or something that's going to be interpolated before that text becomes CSS. This is closer to what's really going on, but my first thought is not that it's coming from the browser. If I saw that in the wild my first thought would be that somebody accidentally published some kind of Sass/Less/Stylus-like preprocessor dialect without compiling it to CSS first. My initial thought would be to google what preprocessor uses $() as a syntax so I could compile it properly.

But given the third example, browser(), even if you have no idea that the functionality is possible, it's CSS-like enough that it could be a native feature, and the name browser() hints that it's nothing that could be rendered in advance…before the browser. For me at least, I think this is not only elegant enough to use while authoring CSS, but also provides the correct context to help people intuit what is going on in the code, as well as provide something 'googleable' they can look up to find out more.

That's my 2¢. This is a great idea for a feature, getting the naming right (or wrong) could be the difference between empowering authors and bewildering them.

@devatrox

This comment has been minimized.

Show comment
Hide comment
@devatrox

devatrox Sep 18, 2017

Why not follow the idea of currentColor?

body {
    color: userForegroundColor;
}

Why not follow the idea of currentColor?

body {
    color: userForegroundColor;
}
@jakearchibald

This comment has been minimized.

Show comment
Hide comment
@jakearchibald

jakearchibald Sep 18, 2017

Contributor

currentColor isn't global, so it isn't really the same.

Contributor

jakearchibald commented Sep 18, 2017

currentColor isn't global, so it isn't really the same.

@devatrox

This comment has been minimized.

Show comment
Hide comment
@devatrox

devatrox Sep 18, 2017

I get that, but it is a predefined value that the dev can't directly manipulate (indirectly he can in this case). The values proposed here can also change constantly (no pun intended) depending on device orientation, environment, settings, whatever, so it is merely an alias to some value defined in the UA.

The difference between currentColor and userForegroundColor is just the scope, as one uses this and the other window

EDIT: The newly proposed system-ui "font" or simply sans-serif would be another example that is, in my view, the same thing as we are discussing here. currentColor might have been the wrong example to use here because it's distracting.

devatrox commented Sep 18, 2017

I get that, but it is a predefined value that the dev can't directly manipulate (indirectly he can in this case). The values proposed here can also change constantly (no pun intended) depending on device orientation, environment, settings, whatever, so it is merely an alias to some value defined in the UA.

The difference between currentColor and userForegroundColor is just the scope, as one uses this and the other window

EDIT: The newly proposed system-ui "font" or simply sans-serif would be another example that is, in my view, the same thing as we are discussing here. currentColor might have been the wrong example to use here because it's distracting.

@FremyCompany

This comment has been minimized.

Show comment
Hide comment
@FremyCompany

FremyCompany Sep 18, 2017

Contributor

Why not follow the idea of currentColor/system-ui/...?

Because a browser needs to track all these values one by one, and that is costly in terms of code to write and combinations to test. The advantage of reusing the infrastructure of var(...) is that it is generic and can be detected very easily at parse time.

Contributor

FremyCompany commented Sep 18, 2017

Why not follow the idea of currentColor/system-ui/...?

Because a browser needs to track all these values one by one, and that is costly in terms of code to write and combinations to test. The advantage of reusing the infrastructure of var(...) is that it is generic and can be detected very easily at parse time.

@FremyCompany

This comment has been minimized.

Show comment
Hide comment
@FremyCompany

FremyCompany Sep 18, 2017

Contributor

The second example, using $() reads to me like a layer on top of CSS - either a preprocessor variable or something that's going to be interpolated before that text becomes CSS. This is closer to what's really going on, but my first thought is not that it's coming from the browser.

If I understood @tabatkins properly, while some of these values will come from the browser, some can also come from JavaScript using the proposed $(--my-global) syntax. If I misunderstood that then my point is moot, of course,

If I saw $(...) in the wild my first thought would be that somebody accidentally published some kind of Sass/Less/Stylus-like preprocessor dialect without compiling it to CSS first.

Well, it's because you don't know this is allowed in CSS. That's something you would learn as part of learning CSS in the future even before you start learning about SASS.

Contributor

FremyCompany commented Sep 18, 2017

The second example, using $() reads to me like a layer on top of CSS - either a preprocessor variable or something that's going to be interpolated before that text becomes CSS. This is closer to what's really going on, but my first thought is not that it's coming from the browser.

If I understood @tabatkins properly, while some of these values will come from the browser, some can also come from JavaScript using the proposed $(--my-global) syntax. If I misunderstood that then my point is moot, of course,

If I saw $(...) in the wild my first thought would be that somebody accidentally published some kind of Sass/Less/Stylus-like preprocessor dialect without compiling it to CSS first.

Well, it's because you don't know this is allowed in CSS. That's something you would learn as part of learning CSS in the future even before you start learning about SASS.

@tabatkins

This comment has been minimized.

Show comment
Hide comment
@tabatkins

tabatkins Sep 19, 2017

Member

Should there be a standardized set of constant names with an expected meaning, or is that all up to the UA? I believe @grorg's pull request only defines the mechanism, but not any specific constant names.

Yes, this isn't even a question. Without standardization, this is just vendor-specific, and thus worthless. (And thus should be protected behind whatever your vendor-specific-code mechanism is: prefixes or flags or what-have-you.)


Why not follow the idea of currentColor?

Because keywords need to be tracked and monitored for collisions; there are places where we accept arbitrary keywords (like animation-name) where we explicitly handle the few built-in keywords (and thus implicitly disallow you from using them as animation names/etc). Every time we add a new built-in keyword, we run the risk of breaking author code that is currently using it as a custom keyword.

A function, on the other hand, can be handled globally without collision; we don't and will never allow user-defined functions with arbitrary names (they'll be -- prefixed like other custom things), so there's no worry about breaking author-level code.


I think this proposal matches that description: some value replacement that happens to be globally the same (but could be globally invalidated as a result of a value change). I would therefore propose we rename these variables to "globals" instead of "constants" and use $(...) to refer to them anywhere a css value is allowed.

I'm fine with this; it does indeed match the use-case I was trying to reserve $ for. It means some Syntax changes, tho. ^_^

Member

tabatkins commented Sep 19, 2017

Should there be a standardized set of constant names with an expected meaning, or is that all up to the UA? I believe @grorg's pull request only defines the mechanism, but not any specific constant names.

Yes, this isn't even a question. Without standardization, this is just vendor-specific, and thus worthless. (And thus should be protected behind whatever your vendor-specific-code mechanism is: prefixes or flags or what-have-you.)


Why not follow the idea of currentColor?

Because keywords need to be tracked and monitored for collisions; there are places where we accept arbitrary keywords (like animation-name) where we explicitly handle the few built-in keywords (and thus implicitly disallow you from using them as animation names/etc). Every time we add a new built-in keyword, we run the risk of breaking author code that is currently using it as a custom keyword.

A function, on the other hand, can be handled globally without collision; we don't and will never allow user-defined functions with arbitrary names (they'll be -- prefixed like other custom things), so there's no worry about breaking author-level code.


I think this proposal matches that description: some value replacement that happens to be globally the same (but could be globally invalidated as a result of a value change). I would therefore propose we rename these variables to "globals" instead of "constants" and use $(...) to refer to them anywhere a css value is allowed.

I'm fine with this; it does indeed match the use-case I was trying to reserve $ for. It means some Syntax changes, tho. ^_^

@zhouqicf

This comment has been minimized.

Show comment
Hide comment
@zhouqicf

zhouqicf Sep 20, 2017

Why the constant can't be used in calc? This does not meet expectations.

Yes, we can use height: 44px; padding-top: constant(safe-area-inset-top), but height: calc(constant(safe-area-inset-top)+44px) is conciser, and sometimes we have no choice.

Because i using calc() with no spaces around the +, constant can be used in calc.

zhouqicf commented Sep 20, 2017

Why the constant can't be used in calc? This does not meet expectations.

Yes, we can use height: 44px; padding-top: constant(safe-area-inset-top), but height: calc(constant(safe-area-inset-top)+44px) is conciser, and sometimes we have no choice.

Because i using calc() with no spaces around the +, constant can be used in calc.

@dpogue

This comment has been minimized.

Show comment
Hide comment
@dpogue

dpogue Sep 20, 2017

Why the constant can't be used in calc? This does not meet expectations.

The constants do work in calc(), at least in my testing in Safari on the iPhone X simulator.

header {
  height: calc(44px + constant(safe-area-inset-top));
}

They also work in gradients:

linear-gradient(to bottom, black 0%, black constant(safe-area-inset-top), grey constant(safe-area-inset-top), grey 100%);

dpogue commented Sep 20, 2017

Why the constant can't be used in calc? This does not meet expectations.

The constants do work in calc(), at least in my testing in Safari on the iPhone X simulator.

header {
  height: calc(44px + constant(safe-area-inset-top));
}

They also work in gradients:

linear-gradient(to bottom, black 0%, black constant(safe-area-inset-top), grey constant(safe-area-inset-top), grey 100%);
@css-meeting-bot

This comment has been minimized.

Show comment
Hide comment
@css-meeting-bot

css-meeting-bot Sep 20, 2017

Member

The Working Group just discussed User Agent properties and variables, and agreed to the following resolutions:

  • RESOLVED: rename what was constant variables to environment variables using env()
  • RESOLVED: Add this as an ED of variables L2
  • RESOLVED: Add dino as an editor of variables L2 with TabAtkins
  • RESOLVED: The initial set as safe area top, bottom, left and right
The full IRC log of that discussion <dael> Topic: User Agent properties and variables
<dael> github: https://github.com/w3c/csswg-drafts/issues/1693
<dael> smfr: Apple is proposing constantst which are UA defined variables. They're supplied by the UA and not assignable in CSS. Work everywhere variables work. We intend them for metrics that are of interest to web authors to layout their pages. You can imagine one for things like scrollbar.
<dael> smfr: Ones we're most interested in is iPhone 10 where it tells authors how to avoid rounded corners.
<dael> smfr: Two aspects to this discussion. Is the constant function the right name. Second part is should we have a specific set and list them out?
<dael> TabAtkins: Hitting hte second one. You cannot have this as a feature and have a bunch of UA specific values. It doesn't help authors
<dael> smfr: I agree
<dael> TabAtkins: Values need to be in spec. You can have UA ones behind a flag, but general set of values need to be specified and interop.
<dael> smfr: We agree.
<Rossen_> Bert: please reply back to this email (https://lists.w3.org/Archives/Member/w3c-css-wg/2017JulSep/0160.html) and let us know what help you need from the rest of us
<dael> TabAtkins: I love this and this is great. One bit I think I disagree. This should be usable wider than variables. You should be able to use a global in a MQ or something. It shouldn't be limited to use in properties.
<dael> smfr: I think that's reasonable
<gregwhitworth> florian: you're really quiet
<dael> florian: I'm not sure. 2 reasons. If it's not like variables we need to decide how it works. We'd have to invent a new thing. Also, it's not crazy to imagine that this might have different values per element in the DOM, like what's the default font and that's language dependent so you need a DOM. I'd be careful about expanding it.
<dael> TabAtkins: That sort of thing would not be super compat with how we're thinking about this. BUt if we did something like that I would be fine to say in that case it's an invalid reference. Same as using color in a link MQ.
<dael> florian: Okay.
<dael> smfr: One concern with using this in MQ. WE found authors often want them in conjunction with min and max. So that gives you feature creep where you want min and max in MQ.
<dael> TabAtkins: Calc is allowed per spec, which you and then do min and max
<dael> smfr: Does any browser?
<dael> TabAtkins: Dunno.
<dael> smfr: If it's in spec, it's reasonable.
<dael> TabAtkins: You might as well be able to. It makes sense.
<dael> TabAtkins: Regarding names, I'm fine with constant, but thread had people object to that. They suggested global which was fine to me too.
<dael> TabAtkins: fremy also pointed out this is the use case I was trying to reserve $ for. So that might work.
<dael> smfr: I do'nt like $ b/c if someone doesn't know CSS it looks like magic. I think 'constant' is way easier.
<dael> florian: I think we want the extra param on it so if we have $ and function.
<tantek> "you can't google it" is an interesting critique of any new symbol-based syntax
<dael> TabAtkins: A function names $ so $(stuff)
<tantek> "dollarsign(stuff)?"
<Rossen_> dollar-sign()
<dael> fantasai: These are environment variables so you could use the entity.
<fantasai> env() because these are environment variables
<florian> +1 to env()
<dael> myles: Other programming languages let you use $ for things that do vary.
<dael> Chris: I quite like env option. It's an environment vairable.
<dael> TabAtkins: Expcet we want people be able to set the custom ones.
<dael> Chris: Ah.
<dael> TabAtkins: We recognized a lot of variables are a single global set at the root and the entire enharetence machine for that is a lot. We're working on If a variable is only set on the root we pop it in a seperate storage area. This would let authors declare this sort of thing.
<dael> TabAtkins: So you set it once and you have a global variable across the page.
<dael> smfr: So you want the same syntax for that and these?
<Rossen_> q?
<dael> TabAtkins: Names would have to be -- prefix to distinguish name space
<Bert> q-
<dael> fantasai: How to declare?
<Rossen_> Bert, yes let's take that over mail
<dael> TabAtkins: Options. Suggested JS API so you can monitor in JS and watch for changes so you can respond to them. If we have that structure it will give you read only access to these. We can allow write access too if it's in the right form. That's the basic.
<dael> fantasai: That's not a good answer.
<dael> TabAtkins: That's the basic.
<dael> fantasai: I don't consider that basic.
<dael> TabAtkins: Secondary is an @'function name' rule in your stylesheet. Give it a name and a value. It looks same as property, but as an @ rule. Only problem there is if you want to respond to changes we need to expose it in some JS API. So you either delve into CSSOM or we have to do some mapping between a JS object.
<dael> TabAtkins: I have suggestions to this in a thread from where dino is suggesting edits.
<dael> TabAtkins: Current idea is the big JS API can also be used from JS to demote both user and UA defined ones. @global lets you do it in stylesheets and they grow a similar map-like object that's a proxy. Therefore if you need to watch the values you can do so, but if you want to set up in JS you can do that. Whichever is best for you you have access to.
<dael> smfr: How does that impact the naming?
<dael> TabAtkins: Not at all. Whatever the function name is the @rule is similar.
<dael> smfr: Does it promote any of the options?
<dael> TabAtkins: I don't think so. Any of the ones we've come up with are available and reasonable to read
<bkardell_> lol
<dael> smfr: Can we try and resolve on a name?
<smfr> options: constant(), const(), env(), global()
<dael> Rossen_: I head env and global in the running
<dael> smfr: Let me type them.
<dael> smfr: Those (a few chats before)
<bkardell_> I will go against the grain and say I like const() actually
<dael> Rossen_: So constant and const since they do change can we rule those out?
<florian> prefers env, ok with global
<dael> fremy: global is what I prefer. I quite like the $, but of those global is most clear to authors.
<bkardell_> prefers env
<dael> Rossen_: I see some people saying env, some people global. Which is easier to understand for non-english?
<dael> ??: I voted for env
<dael> Chris: THe problem with env is it doesn't work for everything that TabAtkins does
<bkardell_> author-env variables like bash
<bkardell_> yes, what tab said !
<dael> TabAtkins: It's the same as for what bash uses.
<Chris> I like env
<dael> Rossen_: Let's try and resolve on env. Let's get this one on the books for now.
<dael> Rossen_: Objections to renaming what was constant variables to environment variables using env()?
<Chris> also can we please stop u-turning on names because it really impacts deployment
<dael> smfr: I'm not particularly happy because we have an impl, but I guess we can change.
<Chris> bikeshedding considered harmful
<dael> TabAtkins: Given there is 0 spec text, I think we'd be angry if you pull a we can't change due to impl.
<dael> RESOLVED: rename what was constant variables to environment variables using env()
<dael> Rossen_: Did we resolve on the list of predefined?
<dael> smfr: Well what spec do they go in?
<dael> fantasai: variables
<dael> Rossen_: variables l2?
<dael> TabAtkins: Either own or variables. variables 2 is good.
<dael> Rossen_: Makes most sense given how far variable spec is.
<dael> Rossen_: Obj adding this as ED of variable L2?
<tantek> seems reasonable
<fantasai> sgmt
<Chris> +1 to variables-2
<bkardell_> +1
<fantasai> s/sgmt/sgtm/
<dael> RESOLVED: Add this as an ED of variables L2
<dael> Rossen_: Editor?
<dael> smfr: I think I'd like to say dino will do it.
<dael> TabAtkins: He put text together so he self-volunteered
<dael> Rossen_: Obj?
<dael> RESOLVED: Add dino as an editor of variables L2 with TabAtkins
<dael> Rossen_: Now that we know what we're calling them and where, what will be the initial set of predefined values?
<dael> Rossen_: Should we take this back to github?
<dael> florian: I think so
<dael> smfr: We'd at least like safe area top, botoom, left, right
<dael> TabAtkins: Let's get a list in GH
<dael> fantasai: I think we can resolve on those 4 values.
<dael> s/botoom/bottom
<dael> Rossen_: Objections to adding the initial set as safe area top, bottom, left and right?
<dael> RESOLVED: The initial set as safe area top, bottom, left and right
Member

css-meeting-bot commented Sep 20, 2017

The Working Group just discussed User Agent properties and variables, and agreed to the following resolutions:

  • RESOLVED: rename what was constant variables to environment variables using env()
  • RESOLVED: Add this as an ED of variables L2
  • RESOLVED: Add dino as an editor of variables L2 with TabAtkins
  • RESOLVED: The initial set as safe area top, bottom, left and right
The full IRC log of that discussion <dael> Topic: User Agent properties and variables
<dael> github: https://github.com/w3c/csswg-drafts/issues/1693
<dael> smfr: Apple is proposing constantst which are UA defined variables. They're supplied by the UA and not assignable in CSS. Work everywhere variables work. We intend them for metrics that are of interest to web authors to layout their pages. You can imagine one for things like scrollbar.
<dael> smfr: Ones we're most interested in is iPhone 10 where it tells authors how to avoid rounded corners.
<dael> smfr: Two aspects to this discussion. Is the constant function the right name. Second part is should we have a specific set and list them out?
<dael> TabAtkins: Hitting hte second one. You cannot have this as a feature and have a bunch of UA specific values. It doesn't help authors
<dael> smfr: I agree
<dael> TabAtkins: Values need to be in spec. You can have UA ones behind a flag, but general set of values need to be specified and interop.
<dael> smfr: We agree.
<Rossen_> Bert: please reply back to this email (https://lists.w3.org/Archives/Member/w3c-css-wg/2017JulSep/0160.html) and let us know what help you need from the rest of us
<dael> TabAtkins: I love this and this is great. One bit I think I disagree. This should be usable wider than variables. You should be able to use a global in a MQ or something. It shouldn't be limited to use in properties.
<dael> smfr: I think that's reasonable
<gregwhitworth> florian: you're really quiet
<dael> florian: I'm not sure. 2 reasons. If it's not like variables we need to decide how it works. We'd have to invent a new thing. Also, it's not crazy to imagine that this might have different values per element in the DOM, like what's the default font and that's language dependent so you need a DOM. I'd be careful about expanding it.
<dael> TabAtkins: That sort of thing would not be super compat with how we're thinking about this. BUt if we did something like that I would be fine to say in that case it's an invalid reference. Same as using color in a link MQ.
<dael> florian: Okay.
<dael> smfr: One concern with using this in MQ. WE found authors often want them in conjunction with min and max. So that gives you feature creep where you want min and max in MQ.
<dael> TabAtkins: Calc is allowed per spec, which you and then do min and max
<dael> smfr: Does any browser?
<dael> TabAtkins: Dunno.
<dael> smfr: If it's in spec, it's reasonable.
<dael> TabAtkins: You might as well be able to. It makes sense.
<dael> TabAtkins: Regarding names, I'm fine with constant, but thread had people object to that. They suggested global which was fine to me too.
<dael> TabAtkins: fremy also pointed out this is the use case I was trying to reserve $ for. So that might work.
<dael> smfr: I do'nt like $ b/c if someone doesn't know CSS it looks like magic. I think 'constant' is way easier.
<dael> florian: I think we want the extra param on it so if we have $ and function.
<tantek> "you can't google it" is an interesting critique of any new symbol-based syntax
<dael> TabAtkins: A function names $ so $(stuff)
<tantek> "dollarsign(stuff)?"
<Rossen_> dollar-sign()
<dael> fantasai: These are environment variables so you could use the entity.
<fantasai> env() because these are environment variables
<florian> +1 to env()
<dael> myles: Other programming languages let you use $ for things that do vary.
<dael> Chris: I quite like env option. It's an environment vairable.
<dael> TabAtkins: Expcet we want people be able to set the custom ones.
<dael> Chris: Ah.
<dael> TabAtkins: We recognized a lot of variables are a single global set at the root and the entire enharetence machine for that is a lot. We're working on If a variable is only set on the root we pop it in a seperate storage area. This would let authors declare this sort of thing.
<dael> TabAtkins: So you set it once and you have a global variable across the page.
<dael> smfr: So you want the same syntax for that and these?
<Rossen_> q?
<dael> TabAtkins: Names would have to be -- prefix to distinguish name space
<Bert> q-
<dael> fantasai: How to declare?
<Rossen_> Bert, yes let's take that over mail
<dael> TabAtkins: Options. Suggested JS API so you can monitor in JS and watch for changes so you can respond to them. If we have that structure it will give you read only access to these. We can allow write access too if it's in the right form. That's the basic.
<dael> fantasai: That's not a good answer.
<dael> TabAtkins: That's the basic.
<dael> fantasai: I don't consider that basic.
<dael> TabAtkins: Secondary is an @'function name' rule in your stylesheet. Give it a name and a value. It looks same as property, but as an @ rule. Only problem there is if you want to respond to changes we need to expose it in some JS API. So you either delve into CSSOM or we have to do some mapping between a JS object.
<dael> TabAtkins: I have suggestions to this in a thread from where dino is suggesting edits.
<dael> TabAtkins: Current idea is the big JS API can also be used from JS to demote both user and UA defined ones. @global lets you do it in stylesheets and they grow a similar map-like object that's a proxy. Therefore if you need to watch the values you can do so, but if you want to set up in JS you can do that. Whichever is best for you you have access to.
<dael> smfr: How does that impact the naming?
<dael> TabAtkins: Not at all. Whatever the function name is the @rule is similar.
<dael> smfr: Does it promote any of the options?
<dael> TabAtkins: I don't think so. Any of the ones we've come up with are available and reasonable to read
<bkardell_> lol
<dael> smfr: Can we try and resolve on a name?
<smfr> options: constant(), const(), env(), global()
<dael> Rossen_: I head env and global in the running
<dael> smfr: Let me type them.
<dael> smfr: Those (a few chats before)
<bkardell_> I will go against the grain and say I like const() actually
<dael> Rossen_: So constant and const since they do change can we rule those out?
<florian> prefers env, ok with global
<dael> fremy: global is what I prefer. I quite like the $, but of those global is most clear to authors.
<bkardell_> prefers env
<dael> Rossen_: I see some people saying env, some people global. Which is easier to understand for non-english?
<dael> ??: I voted for env
<dael> Chris: THe problem with env is it doesn't work for everything that TabAtkins does
<bkardell_> author-env variables like bash
<bkardell_> yes, what tab said !
<dael> TabAtkins: It's the same as for what bash uses.
<Chris> I like env
<dael> Rossen_: Let's try and resolve on env. Let's get this one on the books for now.
<dael> Rossen_: Objections to renaming what was constant variables to environment variables using env()?
<Chris> also can we please stop u-turning on names because it really impacts deployment
<dael> smfr: I'm not particularly happy because we have an impl, but I guess we can change.
<Chris> bikeshedding considered harmful
<dael> TabAtkins: Given there is 0 spec text, I think we'd be angry if you pull a we can't change due to impl.
<dael> RESOLVED: rename what was constant variables to environment variables using env()
<dael> Rossen_: Did we resolve on the list of predefined?
<dael> smfr: Well what spec do they go in?
<dael> fantasai: variables
<dael> Rossen_: variables l2?
<dael> TabAtkins: Either own or variables. variables 2 is good.
<dael> Rossen_: Makes most sense given how far variable spec is.
<dael> Rossen_: Obj adding this as ED of variable L2?
<tantek> seems reasonable
<fantasai> sgmt
<Chris> +1 to variables-2
<bkardell_> +1
<fantasai> s/sgmt/sgtm/
<dael> RESOLVED: Add this as an ED of variables L2
<dael> Rossen_: Editor?
<dael> smfr: I think I'd like to say dino will do it.
<dael> TabAtkins: He put text together so he self-volunteered
<dael> Rossen_: Obj?
<dael> RESOLVED: Add dino as an editor of variables L2 with TabAtkins
<dael> Rossen_: Now that we know what we're calling them and where, what will be the initial set of predefined values?
<dael> Rossen_: Should we take this back to github?
<dael> florian: I think so
<dael> smfr: We'd at least like safe area top, botoom, left, right
<dael> TabAtkins: Let's get a list in GH
<dael> fantasai: I think we can resolve on those 4 values.
<dael> s/botoom/bottom
<dael> Rossen_: Objections to adding the initial set as safe area top, bottom, left and right?
<dael> RESOLVED: The initial set as safe area top, bottom, left and right
@tabatkins

This comment has been minimized.

Show comment
Hide comment
@tabatkins

tabatkins Sep 20, 2017

Member

@zhouqicf Your screenshots show you using calc() with no spaces around the +; that's an error, resulting in an invalid property. constant() will have the same basic semantics as var(), so it's usable anywhere var() is.

Member

tabatkins commented Sep 20, 2017

@zhouqicf Your screenshots show you using calc() with no spaces around the +; that's an error, resulting in an invalid property. constant() will have the same basic semantics as var(), so it's usable anywhere var() is.

@jonathantneal

This comment has been minimized.

Show comment
Hide comment
@jonathantneal

jonathantneal Sep 20, 2017

Contributor

I have a few questions.

First, I am presuming the request included making it clear “that there is no way for the developer to set these properties”. And now, I see interest in doing the opposite. which is to make these properties settable. I also see interest in making these properties exposable to @media.

So, if these properties are settable, how do we distinguish the non-settable ones? The ol’ double-dash?

@env --foo 0px;

body {
  margin: env(--foo);
  padding: env(safe-area-inset);
}

That makes me wonder. If env() is no longer the distinguishing quality of being un-settable, then could we modify var() to support the same functionality?

@var --foo 0px;

body {
  margin: var(--foo);
  padding: var(safe-area-inset);
}

And if that is possible, would we need @var at that point? Or would @var be needed to expose variables to @media?

Then, if these properties are assignable and also available to @media, might they create recursion?

@env --foo 0px;

@media( width > env(--foo) ) {
  @env --foo 200vw;
}

EDITED: That last example, which I accidentally left un-finished.

Contributor

jonathantneal commented Sep 20, 2017

I have a few questions.

First, I am presuming the request included making it clear “that there is no way for the developer to set these properties”. And now, I see interest in doing the opposite. which is to make these properties settable. I also see interest in making these properties exposable to @media.

So, if these properties are settable, how do we distinguish the non-settable ones? The ol’ double-dash?

@env --foo 0px;

body {
  margin: env(--foo);
  padding: env(safe-area-inset);
}

That makes me wonder. If env() is no longer the distinguishing quality of being un-settable, then could we modify var() to support the same functionality?

@var --foo 0px;

body {
  margin: var(--foo);
  padding: var(safe-area-inset);
}

And if that is possible, would we need @var at that point? Or would @var be needed to expose variables to @media?

Then, if these properties are assignable and also available to @media, might they create recursion?

@env --foo 0px;

@media( width > env(--foo) ) {
  @env --foo 200vw;
}

EDITED: That last example, which I accidentally left un-finished.

@othermaciej

This comment has been minimized.

Show comment
Hide comment
@othermaciej

othermaciej Sep 20, 2017

Member

I notice the resolution didn't include the proposed multi-value env(safe-area-inset), is that intentional or just wasn't considered at the time?

Member

othermaciej commented Sep 20, 2017

I notice the resolution didn't include the proposed multi-value env(safe-area-inset), is that intentional or just wasn't considered at the time?

@jakearchibald

This comment has been minimized.

Show comment
Hide comment
@jakearchibald

jakearchibald Sep 21, 2017

Contributor

@othermaciej #1819 (comment) – I agree with @grorg here. Although it works well for simple examples, it isn't as useful as I initially thought.

I guess we just have to watch out for anyone advocating patterns that would break on rotation, or future devices.

Contributor

jakearchibald commented Sep 21, 2017

@othermaciej #1819 (comment) – I agree with @grorg here. Although it works well for simple examples, it isn't as useful as I initially thought.

I guess we just have to watch out for anyone advocating patterns that would break on rotation, or future devices.

@CadenP

This comment has been minimized.

Show comment
Hide comment
@CadenP

CadenP Nov 2, 2017

Perhaps it's too late, but I had a thought regarding the name choice. What about val()? It's close enough to var() that it's familiar, and has the impression that it's unsettable, and would therefore be set by some other process (the browser or what have you). It's also short.

My only issue with it would be that it is almost too similar to var(), and might be mistakenly interchanged, though I am not convinced that this would be a major problem.

CadenP commented Nov 2, 2017

Perhaps it's too late, but I had a thought regarding the name choice. What about val()? It's close enough to var() that it's familiar, and has the impression that it's unsettable, and would therefore be set by some other process (the browser or what have you). It's also short.

My only issue with it would be that it is almost too similar to var(), and might be mistakenly interchanged, though I am not convinced that this would be a major problem.

@othermaciej

This comment has been minimized.

Show comment
Hide comment
@othermaciej

othermaciej Nov 2, 2017

Member

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.

Member

othermaciej commented Nov 2, 2017

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.

@CadenP

This comment has been minimized.

Show comment
Hide comment
@CadenP

CadenP Nov 2, 2017

Ah, very good. Then don't mind me!

CadenP commented Nov 2, 2017

Ah, very good. Then don't mind me!

@jkuss

This comment has been minimized.

Show comment
Hide comment
@jkuss

jkuss Nov 9, 2017

Can anyone give me guidance on how to get at these new constant/env() properties from javascript?

jkuss commented Nov 9, 2017

Can anyone give me guidance on how to get at these new constant/env() properties from javascript?

@kiding

This comment has been minimized.

Show comment
Hide comment
@kiding

kiding Nov 15, 2017

@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 envs in general. Interestingly, WebKit has listed some of the name strings (i.e., safe-area-inset-bottom) in CSSStyleDeclaration object at [340] ~ [343], but the values are inaccessible through .getPropertyValue function unlike any other CSS property.

Being UA-specific things, it sort of makes sense that envs belong to the unholy navigator object. But on the other hand, I could see them being an another set of custom properties; defined by the UA not by users, so there is no reason to treat them differently from vars.

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 Document.

kiding commented Nov 15, 2017

@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 envs in general. Interestingly, WebKit has listed some of the name strings (i.e., safe-area-inset-bottom) in CSSStyleDeclaration object at [340] ~ [343], but the values are inaccessible through .getPropertyValue function unlike any other CSS property.

Being UA-specific things, it sort of makes sense that envs belong to the unholy navigator object. But on the other hand, I could see them being an another set of custom properties; defined by the UA not by users, so there is no reason to treat them differently from vars.

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 Document.

@js-choi

This comment has been minimized.

Show comment
Hide comment
@js-choi

js-choi Feb 8, 2018

Safari Technology Preview 49 has added support for parsing calc() in media queries, which may be a prelude to supporting env() in MQs as well.

js-choi commented Feb 8, 2018

Safari Technology Preview 49 has added support for parsing calc() in media queries, which may be a prelude to supporting env() in MQs as well.

@kiding

This comment has been minimized.

Show comment
Hide comment
@kiding

kiding Mar 22, 2018

Safari Technology Preview 52 has added two new ones: fullscreen-inset-top,fullscreen-auto-hide-delay.

kiding commented Mar 22, 2018

Safari Technology Preview 52 has added two new ones: fullscreen-inset-top,fullscreen-auto-hide-delay.

@zhouqicf

This comment has been minimized.

Show comment
Hide comment
@zhouqicf

zhouqicf Mar 22, 2018

@kiding any documents about fullscreen-inset-top and fullscreen-auto-hide-delay?

@kiding any documents about fullscreen-inset-top and fullscreen-auto-hide-delay?

@kiding

This comment has been minimized.

Show comment
Hide comment
@kiding

kiding Mar 22, 2018

@zhouqicf I don't think so, but you can infer them from WebKit's bug tracker.

kiding commented Mar 22, 2018

@zhouqicf I don't think so, but you can infer them from WebKit's bug tracker.

@tabatkins

This comment has been minimized.

Show comment
Hide comment
@tabatkins

tabatkins Apr 27, 2018

Member

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. ^_^

Member

tabatkins commented Apr 27, 2018

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. ^_^

@jonjohnjohnson

This comment has been minimized.

Show comment
Hide comment
@jonjohnjohnson

jonjohnjohnson Apr 28, 2018

Per... https://drafts.csswg.org/mediaqueries/#units

Relative length units in media queries are based on the initial value, which means that units are never based on results of declarations. For example, in HTML, the em unit is relative to the initial value of font-size, defined by the user agent or the user’s preferences, not any styling on the page.

Any idea on how "user’s preferences" will be interpreted, allowing media queries use of something like calc(env(user-font-size) * 20)?

Also, this reminds me of discussion currently happening in #2430 - font-size: 'medium' value is the user's preferred font size.

Per... https://drafts.csswg.org/mediaqueries/#units

Relative length units in media queries are based on the initial value, which means that units are never based on results of declarations. For example, in HTML, the em unit is relative to the initial value of font-size, defined by the user agent or the user’s preferences, not any styling on the page.

Any idea on how "user’s preferences" will be interpreted, allowing media queries use of something like calc(env(user-font-size) * 20)?

Also, this reminds me of discussion currently happening in #2430 - font-size: 'medium' value is the user's preferred font size.

@MatsPalmgren

This comment has been minimized.

Show comment
Hide comment
@MatsPalmgren

MatsPalmgren Apr 28, 2018

tho user agents may define additional undocumented environment variables

I think this will lead to vendor-specific, or even device-specific, dialects of CSS.
That seems like a very bad idea to me.

tho user agents may define additional undocumented environment variables

I think this will lead to vendor-specific, or even device-specific, dialects of CSS.
That seems like a very bad idea to me.

@js-choi

This comment has been minimized.

Show comment
Hide comment
@js-choi

js-choi Apr 28, 2018

@tabatkinsnew draft specification mentions:

Because environment variables don’t depend on the value of anything drawn from a particular element, they can be used in places where there is no obvious element to draw from, such as in @media rules, where the var() function would not be valid.

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.

js-choi commented Apr 28, 2018

@tabatkinsnew draft specification mentions:

Because environment variables don’t depend on the value of anything drawn from a particular element, they can be used in places where there is no obvious element to draw from, such as in @media rules, where the var() function would not be valid.

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment