- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 20 Sep 2017 16:35:16 +0000
- To: public-css-archive@w3.org
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` <details><summary>The full IRC log of that discussion</summary> <dael> Topic: User Agent properties and variables<br> <dael> github: https://github.com/w3c/csswg-drafts/issues/1693<br> <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.<br> <dael> smfr: Ones we're most interested in is iPhone 10 where it tells authors how to avoid rounded corners.<br> <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?<br> <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<br> <dael> smfr: I agree<br> <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.<br> <dael> smfr: We agree.<br> <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<br> <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.<br> <dael> smfr: I think that's reasonable<br> <gregwhitworth> florian: you're really quiet<br> <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.<br> <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.<br> <dael> florian: Okay.<br> <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.<br> <dael> TabAtkins: Calc is allowed per spec, which you and then do min and max<br> <dael> smfr: Does any browser?<br> <dael> TabAtkins: Dunno.<br> <dael> smfr: If it's in spec, it's reasonable.<br> <dael> TabAtkins: You might as well be able to. It makes sense.<br> <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.<br> <dael> TabAtkins: fremy also pointed out this is the use case I was trying to reserve $ for. So that might work.<br> <dael> smfr: I do'nt like $ b/c if someone doesn't know CSS it looks like magic. I think 'constant' is way easier.<br> <dael> florian: I think we want the extra param on it so if we have $ and function.<br> <tantek> "you can't google it" is an interesting critique of any new symbol-based syntax<br> <dael> TabAtkins: A function names $ so $(stuff)<br> <tantek> "dollarsign(stuff)?"<br> <Rossen_> dollar-sign()<br> <dael> fantasai: These are environment variables so you could use the entity.<br> <fantasai> env() because these are environment variables<br> <florian> +1 to env()<br> <dael> myles: Other programming languages let you use $ for things that do vary.<br> <dael> Chris: I quite like env option. It's an environment vairable.<br> <dael> TabAtkins: Expcet we want people be able to set the custom ones.<br> <dael> Chris: Ah.<br> <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.<br> <dael> TabAtkins: So you set it once and you have a global variable across the page.<br> <dael> smfr: So you want the same syntax for that and these?<br> <Rossen_> q?<br> <dael> TabAtkins: Names would have to be -- prefix to distinguish name space<br> <Bert> q-<br> <dael> fantasai: How to declare?<br> <Rossen_> Bert, yes let's take that over mail<br> <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.<br> <dael> fantasai: That's not a good answer.<br> <dael> TabAtkins: That's the basic.<br> <dael> fantasai: I don't consider that basic.<br> <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.<br> <dael> TabAtkins: I have suggestions to this in a thread from where dino is suggesting edits.<br> <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.<br> <dael> smfr: How does that impact the naming?<br> <dael> TabAtkins: Not at all. Whatever the function name is the @rule is similar.<br> <dael> smfr: Does it promote any of the options?<br> <dael> TabAtkins: I don't think so. Any of the ones we've come up with are available and reasonable to read<br> <bkardell_> lol<br> <dael> smfr: Can we try and resolve on a name?<br> <smfr> options: constant(), const(), env(), global()<br> <dael> Rossen_: I head env and global in the running<br> <dael> smfr: Let me type them.<br> <dael> smfr: Those (a few chats before)<br> <bkardell_> I will go against the grain and say I like const() actually<br> <dael> Rossen_: So constant and const since they do change can we rule those out?<br> <florian> prefers env, ok with global<br> <dael> fremy: global is what I prefer. I quite like the $, but of those global is most clear to authors.<br> <bkardell_> prefers env<br> <dael> Rossen_: I see some people saying env, some people global. Which is easier to understand for non-english?<br> <dael> ??: I voted for env<br> <dael> Chris: THe problem with env is it doesn't work for everything that TabAtkins does<br> <bkardell_> author-env variables like bash<br> <bkardell_> yes, what tab said !<br> <dael> TabAtkins: It's the same as for what bash uses.<br> <Chris> I like env<br> <dael> Rossen_: Let's try and resolve on env. Let's get this one on the books for now.<br> <dael> Rossen_: Objections to renaming what was constant variables to environment variables using env()?<br> <Chris> also can we please stop u-turning on names because it really impacts deployment<br> <dael> smfr: I'm not particularly happy because we have an impl, but I guess we can change.<br> <Chris> bikeshedding considered harmful<br> <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.<br> <dael> RESOLVED: rename what was constant variables to environment variables using env()<br> <dael> Rossen_: Did we resolve on the list of predefined?<br> <dael> smfr: Well what spec do they go in?<br> <dael> fantasai: variables<br> <dael> Rossen_: variables l2?<br> <dael> TabAtkins: Either own or variables. variables 2 is good.<br> <dael> Rossen_: Makes most sense given how far variable spec is.<br> <dael> Rossen_: Obj adding this as ED of variable L2?<br> <tantek> seems reasonable<br> <fantasai> sgmt<br> <Chris> +1 to variables-2<br> <bkardell_> +1<br> <fantasai> s/sgmt/sgtm/<br> <dael> RESOLVED: Add this as an ED of variables L2<br> <dael> Rossen_: Editor?<br> <dael> smfr: I think I'd like to say dino will do it.<br> <dael> TabAtkins: He put text together so he self-volunteered<br> <dael> Rossen_: Obj?<br> <dael> RESOLVED: Add dino as an editor of variables L2 with TabAtkins<br> <dael> Rossen_: Now that we know what we're calling them and where, what will be the initial set of predefined values?<br> <dael> Rossen_: Should we take this back to github?<br> <dael> florian: I think so<br> <dael> smfr: We'd at least like safe area top, botoom, left, right<br> <dael> TabAtkins: Let's get a list in GH<br> <dael> fantasai: I think we can resolve on those 4 values.<br> <dael> s/botoom/bottom<br> <dael> Rossen_: Objections to adding the initial set as safe area top, bottom, left and right?<br> <dael> RESOLVED: The initial set as safe area top, bottom, left and right<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-330909067 using your GitHub account
Received on Wednesday, 20 September 2017 16:35:08 UTC