3 ms·

Parent selector is cool but I've needed it at most 2-3% of the time when designing a site. As of now, it doesn't appear to support things I really need in almos

by chime 15y ago

Parent selector is cool but I've needed it at most 2-3% of the time when designing a site. As of now, it doesn't appear to support things I really need in almost all mid-large site layouts: variables, mixins/functions, operations, and namespaces. This means even 5 years from now, I'll need http://lesscss.org/ http://lesscss.org/ because browsers with CSS4 won't support variables. How does one go about suggesting to W3C that they should support variables in CSS4?

dhx 15y ago
http://news.ycombinator.com/item?id=3162221 http://news.ycombinator.com/item?id=3162221 (which links to through to a www-style list discussion from October 24: http://lists.w3.org/Archives/Public/www-style/2011Oct/0699.html http://lists.w3.org/Archives/Public/www-style/2011Oct/0699.h...)
- chime 15y ago
 That is quite elegant. That should take care of the variables requirement. Thanks!
- romaniv 15y ago
 This is definitely better than no variables, but is it the best solution? I think most of the advantages of variables can be achieved through a technique that introduces no new syntax and a minimum of new keywords: .element { color: #06c; border-color: #006; } h1 { apply: .element; border-style: thick; border-width: solid; } This will make H1 "pretend" that it has .element class applied to it, even though in HTML source code it doesn't. I think it's a conceptually simple and orthogonal solution. True variables differ from the current metality of CSS way too much.
 - eljaco 15y ago
 +1 - I love this idea; some/most times it's easier to change the CSS instead of the HTML/template.
 - michaelchisari 15y ago
 Wow, that's actually pretty brilliant, and doesn't feel like you're forcing CSS to act like a programming language.
 - huckfinnaafb 15y ago
 I'm torn on this. Inheritance already exists through assigning multiple classes and the cascade, and now it's impossible to use a "child" class without dragging its parent along with it unless you override "apply" inline. Not terribly clear as to why we need specific functionality for inheritance when we already have an expressive way of defining it.
 - sellandb 15y ago
 The above comment was addressing the lack of variables, not the lack of true inheritance (a single level of inheritance is not really inheritance at all, simply applying attributes en masse). What the comment does address is the lack of variables and the need/want to set a color (or anything else) once and then use that through an assortment of other definitions. This is something that is only currently possible through CSS preprocessors.
 - huckfinnaafb 15y ago
 It really doesn't look like variables to me. A variable would be a reference to a singularly defined property, such as a color or border style, not a hook to an entire list of properties. Certainly it could be used as a variable: that is, defining a class with a single property and hooking to that. But let's assume it's being used as a variable, why not write something like this? .data { font-size:11px; font-family:Courier; color: #555; } .magic { color: royalBlue; } Magical data Normal text with magical data. I've inherited .magic into .data without sacrificing the ability to use .magic and .data by itself. As long as you keep your CSS classes semantic and disperse them intelligently into the markup, it's really not an issue of making large scale changes with minimal effort. Of course, in practice, this isn't always the case, but I think adding more ways to inherit properties will increase complexity more than help write good styles. I think the outcry for these features is a symptom of a poor understanding of the cascade and the language. There are much larger issues I'd like to see addressed, like the wide adoption of layout definitions which has better rules for defining vertical positioning and more fluid widths, both of which are pretty nightmarish without resorting to tables.
alexchamberlain 15y ago
Why slow down CSS with constructs that can be achieved by prior compilation and a few Makefiles?
- masklinn 15y ago
  Why require adding a fiddly and complex toolchain making ramp up and usage of these features more complex than it has to be, and harder to troubleshoot, when it's something making production easier to maintain in the long run? Because unless you suggest adding source maps to CSS (even though they still are not in JS), a preprocessor generating CSS makes CSS far more annoying to debug or play around with than native constants support would (and even with source maps, the usability of devtools style inspectors and editors would be significantly inferior to native support)
  - alexchamberlain 15y ago
    I wouldn't mind a Chrome/Firefox extension to play around with extended CSS, but in production, I'm on the side of higher performance in Web Browser, which comes from simple style syntax.
    - masklinn 15y ago
      > I'm on the side of higher performance in Web Browser, which comes from simple style syntax. Constant parsing and replacement would add pretty much no overhead to CSS parsing in the grand scheme of things.
    - deleted 15y ago
      [deleted]
- ma2rten 15y ago
  You could still compile css to backwards compatible, compact css and test and debug in the browser without effort?
tmcw 15y ago
LESS is great stuff, but CSS should be a minimal, not maximal standard. It is the common divisor, not the maximum, most perfect thing.

by chime 15y ago

dhx 15y ago

http://news.ycombinator.com/item?id=3162221 http://news.ycombinator.com/item?id=3162221 (which links to through to a www-style list discussion from October 24: http://lists.w3.org/Archives/Public/www-style/2011Oct/0699.html http://lists.w3.org/Archives/Public/www-style/2011Oct/0699.h...)

chime 15y ago
That is quite elegant. That should take care of the variables requirement. Thanks!
romaniv 15y ago
This is definitely better than no variables, but is it the best solution? I think most of the advantages of variables can be achieved through a technique that introduces no new syntax and a minimum of new keywords: .element { color: #06c; border-color: #006; } h1 { apply: .element; border-style: thick; border-width: solid; } This will make H1 "pretend" that it has .element class applied to it, even though in HTML source code it doesn't. I think it's a conceptually simple and orthogonal solution. True variables differ from the current metality of CSS way too much.
- eljaco 15y ago
 +1 - I love this idea; some/most times it's easier to change the CSS instead of the HTML/template.
- michaelchisari 15y ago
 Wow, that's actually pretty brilliant, and doesn't feel like you're forcing CSS to act like a programming language.
- huckfinnaafb 15y ago
 I'm torn on this. Inheritance already exists through assigning multiple classes and the cascade, and now it's impossible to use a "child" class without dragging its parent along with it unless you override "apply" inline. Not terribly clear as to why we need specific functionality for inheritance when we already have an expressive way of defining it.
 - sellandb 15y ago
 The above comment was addressing the lack of variables, not the lack of true inheritance (a single level of inheritance is not really inheritance at all, simply applying attributes en masse). What the comment does address is the lack of variables and the need/want to set a color (or anything else) once and then use that through an assortment of other definitions. This is something that is only currently possible through CSS preprocessors.
 - huckfinnaafb 15y ago
 It really doesn't look like variables to me. A variable would be a reference to a singularly defined property, such as a color or border style, not a hook to an entire list of properties. Certainly it could be used as a variable: that is, defining a class with a single property and hooking to that. But let's assume it's being used as a variable, why not write something like this? .data { font-size:11px; font-family:Courier; color: #555; } .magic { color: royalBlue; } Magical data Normal text with magical data. I've inherited .magic into .data without sacrificing the ability to use .magic and .data by itself. As long as you keep your CSS classes semantic and disperse them intelligently into the markup, it's really not an issue of making large scale changes with minimal effort. Of course, in practice, this isn't always the case, but I think adding more ways to inherit properties will increase complexity more than help write good styles. I think the outcry for these features is a symptom of a poor understanding of the cascade and the language. There are much larger issues I'd like to see addressed, like the wide adoption of layout definitions which has better rules for defining vertical positioning and more fluid widths, both of which are pretty nightmarish without resorting to tables.

alexchamberlain 15y ago

Why slow down CSS with constructs that can be achieved by prior compilation and a few Makefiles?

masklinn 15y ago
Why require adding a fiddly and complex toolchain making ramp up and usage of these features more complex than it has to be, and harder to troubleshoot, when it's something making production easier to maintain in the long run? Because unless you suggest adding source maps to CSS (even though they still are not in JS), a preprocessor generating CSS makes CSS far more annoying to debug or play around with than native constants support would (and even with source maps, the usability of devtools style inspectors and editors would be significantly inferior to native support)
- alexchamberlain 15y ago
  I wouldn't mind a Chrome/Firefox extension to play around with extended CSS, but in production, I'm on the side of higher performance in Web Browser, which comes from simple style syntax.
  - masklinn 15y ago
    > I'm on the side of higher performance in Web Browser, which comes from simple style syntax. Constant parsing and replacement would add pretty much no overhead to CSS parsing in the grand scheme of things.
  - deleted 15y ago
    [deleted]
ma2rten 15y ago
You could still compile css to backwards compatible, compact css and test and debug in the browser without effort?

tmcw 15y ago

LESS is great stuff, but CSS should be a minimal, not maximal standard. It is the common divisor, not the maximum, most perfect thing.