- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Fri, 04 Aug 2017 12:06:31 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `dino suggestion on writing modes`.
<details><summary>The full IRC log of that discussion</summary>
<dauwhe> Topic: dino suggestion on writing modes<br>
<astearns> s/writing modes/variables/<br>
<astearns> github: https://github.com/w3c/csswg-drafts/issues/1693<br>
<dauwhe> dino: [approaches podium]<br>
<dauwhe> ... I'll explain it backwards<br>
<dauwhe> ... we're proposing a new var function<br>
<dauwhe> ... instead of exposing user custom properties<br>
<dauwhe> ... these are defined by the user agent<br>
<dauwhe> ... "contstant" means you can''t change it<br>
<dauwhe> ... user wants to control type size on iphone<br>
<dauwhe> ... css can't detect that<br>
<dauwhe> ... you can query the UA value, and then use calc to respond<br>
<dauwhe> ... User agent properties<br>
<glazou> s/contstant/constant<br>
<dauwhe> ... rest is similar to CSS variables<br>
<dauwhe> ... I show lots of examples... font size, foreground/background color...<br>
<dauwhe> ... like user pref for black background/white text<br>
<dauwhe> ... some dyslexic folks want low contrast<br>
<dauwhe> ... so CSS could query UA and then respond<br>
<dauwhe> ... or we could use safe areas when projecting to screen of different size<br>
<dauwhe> glazou: it's coming from UA and system?<br>
<dauwhe> dino: yes<br>
<glazou> q+<br>
<dauwhe> iank_: could you draw the safe area on the blackboard<br>
<bdc> q+<br>
<dauwhe> dino: this has been a concept in TV<br>
<dauwhe> ... some TVs you wouldn't see the whole frame<br>
<dauwhe> ... so there was a title safe area, where you know pixels would always be visible<br>
<dauwhe> myles: modern TVs fake this,<br>
<dauwhe> dino: if you have a circular display, the safe area might be in the middle<br>
<astearns> ack myles<br>
<astearns> q+<br>
<Florian_> q+<br>
<dauwhe> glazou: I like this<br>
<dauwhe> ... open question: could be extended to system colors?<br>
<astearns> ack glazou<br>
<gregwhitworth> q+<br>
<dauwhe> ... we'd have to find common names for system colors on all platforms<br>
<melanierichards> q+<br>
<Florian_> q-<br>
<dauwhe> ... 2nd thing: I'd like to see a 2nd part with JS elements to detect system change events<br>
<dauwhe> dino: you can't do MQ<br>
<Florian_> q+<br>
<dauwhe> glazou: being able to detect theme change, or that you switched to night view.... would be color<br>
<astearns> ack bdc<br>
<glazou> s/would be color/would be cool<br>
<dauwhe> bdc: like underlying idea of prefers-reduced-motion MQ...<br>
<dauwhe> ... so why do we want a new thing?<br>
<dauwhe> dino: unlike MQ, you want to know a value<br>
<dauwhe> ... given one of these values, tell me when it changes<br>
<dauwhe> bdc: i don't see a difference<br>
<dauwhe> Florian_: i don't think so<br>
<dauwhe> ... reduced motion is not about make things slower... it's about doing something else<br>
<dauwhe> dino: for reduced motion, sometimes we fade in instead of moving in<br>
<dauwhe> ... we're generally not removing animations<br>
<glazou> q?<br>
<dauwhe> astearns: I want to ask about support<br>
<glazou> ack astearns<br>
<dauwhe> dino: this raises issue on css var spec<br>
<dauwhe> ... but I don't know where the property lists go<br>
<dauwhe> astearns: if we don't have access for @supports, how do we author?<br>
<dbaron> you could always do @supports (color: constant(foobar)), no?<br>
<astearns> ack gregwhitworth<br>
<dauwhe> gregwhitworth: these are defined by the UA<br>
<dauwhe> ... how are we not going to end up with the -webkit- prefixes unless we agree on everything?<br>
<dauwhe> dino: these are new properties<br>
<dauwhe> ... just like a normal property<br>
<dauwhe> gregwhitworth: they'll be standardized?<br>
<dauwhe> dino: yes<br>
<fremy> q?<br>
<fremy> q+<br>
<dauwhe> ... we want them to be universal<br>
<Rossen> q+<br>
<dauwhe> dino: don't know if they should be prefixed with --<br>
<glazou> ack melanierichards<br>
<astearns> ack melanierichards<br>
<dauwhe> ... so they know they can't set, maybe it's ++<br>
<surma> q+ do we need `constant`?<br>
<dauwhe> melanierichards: let's say the ua stores the value<br>
<surma> q+<br>
<dauwhe> ... the user hasn't overwritten defeault value of foo<br>
<dauwhe> ... would it be undefined?<br>
<dauwhe> ... as a user, I'd only want the value when it was overwritten by the user<br>
<dauwhe> dino: good question<br>
<astearns> ack Florian_<br>
<dauwhe> Florian_: it's a nice hammer we have here, we should be careful with it<br>
<dauwhe> ... the examples of things are less comfortable with, as they could be solved in other ways<br>
<dauwhe> dino: I'm mostly interested in font size and inset ones<br>
<dauwhe> Florian_: for font size, why don't you change REM<br>
<dauwhe> TabAtkins: REM is font size on root element, this is initial value<br>
<astearns> q?<br>
<dauwhe> Florian_: this will be one rem if not overridden?<br>
<dauwhe> Florian_: for inset, we've been discussing a similar problem, and were trying to solve some other way?<br>
<dauwhe> dino: haven't looked at other solutions<br>
<dauwhe> myles: what's the other one<br>
<melanierichards> s/as a user, I'd/as an author, I'd/<br>
<dauwhe> Florian_: first, a media query for shape, another is another MQ about 'if I place something there, is it visible?'<br>
<dauwhe> ... third is using shape inside: display<br>
<Rossen> q?<br>
<astearns> ack fremy<br>
<dauwhe> ... let's not rush into defining through this, as it might prevent us from exploring other solutions<br>
<dauwhe> fremy: I have same concern as surma<br>
<dauwhe> ... why don't reuse var function?<br>
<dauwhe> ... we could use namespace for var function<br>
<surma> q-<br>
<dauwhe> ... so we don't need new function<br>
<dauwhe> ... just variable under new namespace<br>
<dauwhe> dino: i don't mind<br>
<dauwhe> ... but we used the name constant to remind user they can't change it<br>
<dauwhe> ... under the hood it uses same code as variables<br>
<astearns> ack Rossen<br>
<dauwhe> fremy: I think it's better to reuse namespace inside var<br>
<dauwhe> Rossen: thumbs up on the idea<br>
<dauwhe> ... we've had lots of requests<br>
<dauwhe> ... in terms of getting font size and background colors<br>
<fremy> fremy: e.g. { color: var(user preferred-color) }<br>
<dauwhe> ... respond to high contrast, etc<br>
<Florian_> var(system safe-area-inset)<br>
<dauwhe> ... would be insteresting to see the path forward<br>
<dauwhe> ... and to summarize how much stuff you want to expose<br>
<Bert> q+ to ask do you need the word "constant"? Isn't 'contant(foo)' easier written as 'foo'?<br>
<glazou> q+<br>
<dauwhe> TabAtkins: performance would be better than variables<br>
<dauwhe> ... you don't control the values<br>
<dauwhe> plinss: what about UA changing while you're animating?<br>
<SimonSapin> q+ fallback<br>
<dauwhe> dino: we should have current color blink text :)<br>
<SimonSapin> q- fallback<br>
<SimonSapin> q+<br>
<astearns> ack Bert<br>
<Zakim> Bert, you wanted to ask do you need the word "constant"? Isn't 'contant(foo)' easier written as 'foo'?<br>
<dauwhe> Bert: constant looks like an identity function. can't you use the ID itself? use "fontsize"?<br>
<dauwhe> Florian_: we need comma fallback<br>
<dauwhe> fremy: if you have properties like font-family you couldn't use it<br>
<dauwhe> TabAtkins: this would add an unlimited set of global keywords to CSS<br>
<dauwhe> ... functions prevent that<br>
<dauwhe> gregwhitworth: one should be scroll-bar-width<br>
<dauwhe> ... arrow color,<br>
<astearns> ack glazou<br>
<dauwhe> glazou: I want to expand on unlimited sets of global name<br>
<gregwhitworth> q+<br>
<dauwhe> ... we want to make sure nothing is shipped until everyone agrees on how it works<br>
<astearns> zakim, close queue<br>
<Zakim> ok, astearns, the speaker queue is closed<br>
<dauwhe> ... let's keep it clean<br>
<dauwhe> TabAtkins: you only need a few smart devs with houdini, then everyone can use libraries<br>
<dauwhe> glazou: it's like what fremy said, it's a namespace<br>
<dauwhe> ... I think we can reach consensus on the names<br>
<dauwhe> astearns: two more<br>
<astearns> ack SimonSapin<br>
<dauwhe> SimonSapin: what about fallback?<br>
<dauwhe> dino: you could do comma zero<br>
<astearns> ack gregwhitworth<br>
<SimonSapin> SimonSapin: fallback same as in var()?<br>
<SimonSapin> dino: yes<br>
<dauwhe> gregwhitworth: I think our biggest request is high contrast, which we map to system colors<br>
<dauwhe> ... it became a problem because not everyone does high contrast theming<br>
<dauwhe> ... we may have foreground/background, do we need accent color and accent color2?<br>
<dauwhe> ... I foresee problems<br>
<dauwhe> ... so fallback is what you get<br>
<dauwhe> dino: I hear general agreement<br>
<dauwhe> ... concerns about constants vs var with namespace<br>
<dauwhe> ... melanierichards wants to know when user explicitly change<br>
<dauwhe> ... them, someone else wants to ahve events<br>
<dauwhe> myles: unset is same as "i don't know what you're talking about"<br>
<dauwhe> astearns: general consensus that this is interesting<br>
</details>
--
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/1693#issuecomment-320232404 using your GitHub account
Received on Friday, 4 August 2017 12:06:36 UTC