**Derick Montague: Q: do you know when vw, vh will be in most modern browsers?**
IE9 and modern Chrome already support them (I'm not sure whether they support vmin/vmax yet). Other browsers have implementations coming!
**Max Degterev: Q: Why invent calc() instead of just doing it SCSS way**
The "SCSS way" means just doing math directly, without the calc() wrapper. That is, something like
width: 20px + 50%;. We thought about that, but decided that the wrapper helps with readability. For example, quickly glance at this and tell me how many values are in it:
margin: 5px + 10em 20% * 3 +20vw + 5px;? Much easier to read if you do
margin: calc(5px + 10em) calc(20% * 3) calc(+20vw + 5px);
In addition to the readability, sometimes it's legitimately ambiguous, because CSS uses the
/ in some places (such as 'font', 'background', and 'border-image') to separate values, and if you used division next to those it's impossible to tell what you meant. We'd have to make some arbitrary choice and require you to use parentheses or something to disambiguate if you wanted the other option, which I think is what SASS does.
**Keith Wyland: is cycle() in the heading supposed to be toggle() on this slide?**
Yes, apologies. This slide deck was modified from an older talk I gave, and the name of the function changed since then. The correct name is
toggle(), as the spec says.
**Derick Montague: what if the parent is neither italic or normal?**
(Context is the toggle() example:
font-style: toggle(italic, normal);.)
Then it takes the first value, which is italic in this case.
**Kevin Vrsek: what's the logic in using :any-link instead of :link-any? [:link-local too]**
Easier to read? You want to match against local links, you use
**Jesse Wallace: Q: so when are we going to get parent selectors to use with children in CSS?**
I deliberately skipped over this in my talk, because the feature will probably get punted out of Selectors 4, but right now there's a
:matches() pseudoclass that works similarly to jQuery's
:has() pseudoclass, which lets you produce "parent selectors" along with lots of other things, like selecting previous sibling, reversing a reference combinator (selecting the label associated with an input!), and tons more.
querySelector() function. I think that we'll punt
:matches() out of Selectors 4 and into a special spec that has selectors that are useful, but too slow for normal CSS.
**Doug Ramsay: What's the difference between nth-match and nth-of-type?**
:nth-of-type() is like an
:nth-match() that can only use tagname selectors. Simple, but very very limited.
**Benjamin Truyman: Q: Is there any planned support for nested selectors?**
I'm trying! I have a draft spec at http://dev.w3.org/csswg/css3-hierarchies/, but the CSS Working Group hasn't quite accepted it as a work item yet. It's also slightly different from SASS's nesting syntax (you can't omit the &, and you can't put an & later in the selector), but I hope to fix those problems somehow. I can't just do what SASS does directly, because otherwise selectors are ambiguous, from a grammar perspective, with properties, so that you need infinite lookahead (theoretically) to tell the difference between them. With variables mixed in, sometimes you can't even tell them apart theoretically!
**Keith Wyland: Q: will there be a way to specify what 1x, 2x, 10x means as far as network bandwidth/screen size?**
Not sure what this question means. The 2x multiplier means the same as saying it has a resolution of 2dppx, or 192dpi, etc. In other words, it indicates that the image is double-resolution.
All the factors that go into deciding which to use are browser-specific and hopefully magic. They can't be exposed well to authors.
**Livia Labate: Q: Why use tabular terms (row, cells) in the grid spec? There are established terms for grids systems in design (areas, etc)**
Because Grid Layout is basically just the good parts of table layouts, without the shitty parts, so we reused the same terminology.
However, if this ends up being confusing, because grid systems have inspired new terminology, let us know! Email firstname.lastname@example.org with your suggestions.
**Jeremy Dunsdon: Is there any work being done to make vertically centering text or divs possible in CSS?**
Flexbox makes it easy, but the alignment properties that Flexbox uses are meant to be used by all the layout modes! Check out http://dev.w3.org/csswg/css3-align/ for how we're defining it for Block Layout, so you can do simple vertical alignment, woo!
**Ross Smith: I would like to know if a max-width attribute would be in the works.. [related to image-set() I guess?]**
That's what Media Queries are for.
**Andrew Herrington: Q: Can you use image-set() within image()?**
**Roberts Haritonovs: Q: Why w3c can't just take CSS preprocessors experience and make it native?**
Not that simple, bro. For one, different preprocessors offer different features. Which do we choose?
For two, sometimes we can do better than the preprocessors, because we have access to more information and more magic.
For three, preprocessors are static, which means that they can introduce features that take a relatively large amount of processor time, while browsers need things to stay blazingly fast.
For four, we have to be careful that we're pulling in the good ideas, not just the things that are fashionable at the moment, but will be abandoned in a year or two. Letting the preprocessors fight this out for us is a good deal, as we can come in later and pick up the surviving good parts.
So, we need to cherry-pick what we add and be careful about it.
**Kris Bulman: Q: The Sass & Compass group often talk about wanting browsers to impliment the @extend driective. Have you put any thought into this?**
Yes! It's further down on my list, because I think there's still a lot of space to explore here. Is it better to have mixins or extends? Or is there some subtly different version of the feature that's even better, which maybe can't be done in preprocessors at all?
But yeah, it's definitely on my mind.
**Andreas Illg: Q: can I use the width or height of an element in a calculation? e.g .to achieve a certain ratio**
Not directly. It's kinda problematic.
A lot of properties are implicitly or explicitly linked to each other. For example, height usually depends on width. If you make width then rely on height, there's a dependency loop!
However, it's okay to have an element depend on a property from a parent, generally. I expect that in Variables 2 I'll have some way to pull a property into a var, so your descendants can use it.
Approaching the question from the other side, I have a proposal for an aspect-ratio property, which I hope to get into a spec sometime soon.
**Kevin Vrsek: what's with the var-variablename;? why not declare as $variablename;?**
Right now, the CSS Core Grammar disallows a $ from appearing at the beginning of a property name. This might be changeable - we'll decide on the final syntax next month hopefully. I'm in favor of just using "$foo: blue;" directly, definitely.