Live data from Hacker News

What's new in CSS4

webmonkey.com

31–33 of 33 posts

Re: What's new in CSS4

#31
post #25

Earlier quoted context omitted.

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 sou…

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.

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.

Re: What's new in CSS4

#32

Earlier quoted context omitted.

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.

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 thro…

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.

Re: What's new in CSS4

#33
post #25

Earlier quoted context omitted.

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 sou…

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.

CSS cascading allows you to apply styles based on the structure of your HTML document. It does nothing for structuring CSS itself. The point of variables (and my suggestion above) is to have a tool for ogranizing and reusing CSS regardless of your HTML structure.
Post reply on HN