While I understand the desire for inheritance from one CSS rule to the next, it doesn’t fit with the paradigm for CSS; a class attribute or id attribute isn’t like specifying an instance of a class. It would create ambiguity about how rules apply or inherit:
div#gloablNav .current {
color:blue;
}
div#currentNav .current {
color:red;
}
#main .intro a[href=/'] {
.current; /* which rule does this inherit from? */
}
Is the solution to this ambiguity to copy the entire CSS rule?
… but CSS rules aren’t unique, and the author (or maintainer) have no way of knowing in which CSS file this rule would have been defined, or if it is at all. And if this rule and another ‘collide’ how do I determine precedence? Can we make CSS stricter and demand uniqueness of selectors across all CSS files? No, because in web dev Forgiveness is the Default. http://www.codinghorror.com/blog/2007/04/javascript-and-html-forgiveness-by-default.html
The reality is that CSS isn’t meant exclusively for developers and so it shouldn’t support programming paradigms like inheritance or recursion or namespaces which are overwhelmingly familiar to developers. That doesn’t mean, however, there isn’t some method to CSS’s madness; I’d worked and studied in web dev for quite some time before I discovered there was some kind of math behind the precedence of CSS rules, and it was a revelation and an eye opener; http://www.w3.org/TR/CSS2/cascade.html#specificity
Using Silverlight for what is (basically) a blog/message boards is like using a sandblaster on a soup cracker*. In practice, both Silverlight and Flex are overkill unless you need features that aren’t supported by current browsers - like easy pixel-perfect positioning for complex application previews, or application forms that don’t lend themselves to the shortcomings of HTML forms very effectively. CSS is a solvable problem, and with good class/CSS development, it’s not even particularly hard. (On the other hand, if you don’t understand why CSS is the way it is or how to architect a good CSS solution or are inheriting a poorly-architected site, it can be a complete disaster.)
Quite frankly, with HTML 5 and CSS3 on the mid-term horizon, I can’t imagine why Microsoft is dumping as much money as it is into Silverlight to kill Flash, when both technologies will probably eventually disappear, anyway.
There are a lot of really odd comments in here re: CSS (most notably, your post, Jeff)…not sure wherein the horror lies. On table layouts, yes, they’re easier sometimes. They’re also semantically broken and screw up accessibility. If you want to see some guiding wisdom on the what and why of not doing table-based layout, either get a blindfold and a voice-based browser, or head on over to the Univ. of Indiana’s FAE site (http://fae.cita.uiuc.edu/). Even Microsoft realized using tables for layout isn’t a great plan (control adapters and alternative output for menus, etc is the result of that realization).
All that aside, those layout problems are because of the state of HTML, not of CSS. It’s meant to do what it does, which is to allow for a set of consistent styles to be applied across multiple pages, and redefined by subsequent additional styles (including user stylesheets located on the end user’s PC, not under your control, and with higher precedence than the rest of your carefully-chosen rules).
Make your main stylesheet template (one time), then make a secondary one for whatever tweaks you want to apply (or dynamically create the tweaked version, etc). That’s how it’s supposed to work. Variables are nice programatically, but if you’re going to generate CSS on the fly in code, you don’t need them anyway.
CSS is static. Dynamic stuff should be set elsewhere (Javascript, anyone? There is a style attribute on DOM elements, after all).
I agree with Simonchadwick’s take on matters. When the main concern is that a site or family of sites should “look the same” across all browsers and presentation layers, what sense does it make to wrangle with X number of display implementations?
Yes, I know the whole world is on a “plugins are evil” kick right now. Even still, that they remain the easiest way to get a consistent user experience across platforms. I suspect that as long as there exists more than one browser, this will remain the case into the future regardless of how many layers of abstraction are spackled over the HTML/JS/CSS stack.
It’s not entirely CSS fault (actually, I think it’s not CSS fault at all, bat that’s just my opinion).
Cascading Style Sheets are designed so that you either avoid repeating classes/names/tags, or avoid repeating properties definitions. If you repeat both, you’re doing it wrong.
If browsers fully supported tag selectors and properties inheritance, you would probably cut duplicated stuff in CSS by 75%.
Regarding variables, maybe a simpler example would be more clear. Consider instead:
.class1{border-color: #3bbfce} and
.class2{background-color: #3bbfce}
The re-use of colors here can’t be done with cascading - maybe more common than doing math on colors.
What SASS uses Mixins for can mostly be accomplished with cascading, but doing so clutters the HTML with classes representing layout rather than meaning - it’s better CSS and produces less code, but less than ideal for separation of concerns.
On table layouts, yes, they’re easier sometimes. They’re also semantically broken and screw up accessibility.
They’re far, far easier, and they don’t have a significant impact on accessibility in the real world because they are already semantically broken, so users and assistive technology vendors already know to work round them. So, if everyone had spent the time they wasted getting CSS layout to replace tables on, say, labelling their IMG tags, or making sure their pages worked with Javascript disabled, the web would be a better place for assistive technology users. But that’s not what the fashion dictates.
This is why I generally try to get projects to output the CSS from the server’s language. I actually had a site once where, by adjusting two variables, you could completely re-do the color schema, another three handled the majority of positioning, and everything else was defined by a series of ratios.
Heya Jeff, this is Tab Atkins, member of the CSS Working Group.
I feel your pain, man. I’m a web developer too, and I’ve cursed at the same pain points you’ve found. That’s why I got myself involved in the CSSWG and eventually became a member - so I could fix them.
Vertical alignment - Yeah, it’s all kinds of suck right now. There’s no way around it. You can use
s, or, if you are okay with hacking some alternate solution for IE6 and IE7, you can use display:table and avoid people crying. My primary goal at the moment in the CSSWG is working on the layout specs, cleaning them up and making them better for us devs, and Flexbox solves the vertical layout problem better than tables ever did. That’ll still be a few years until it’s supported widely enough to use though.
Variables - This is something we’ve been trying to push for years internally, actually. It’s somewhat painful to admit how slow progress has been on this when it’s so necessary. Regardless, CSS variables is definitely going through.
Nesting - I’ve got a Mixins spec on the back burner to go alongside Variables that will partially address this. The full nesting-fixes that LESS and SASS introduce, though, will probably never be a part of CSS. But hey, never say die, right?
I must admit the first two are not pleasing to my eyes to look at but does give the familiar look of a family of sites you are trying to go for.
Please if you use one of those gems keep us updated the LessCSS looks very promising as long as it gives the flexibility that it appears to offer w/o taking away some of the CSS you thought you actually programmed into a specific tag.
The one suggestion I can make is the idea of images in the tags (like how you have it for android on the site). It is much easier to scan for images then tag names if just going down the list on the home page.
As Vvoyer pointed out, CSS is a presentational language, not a programming language; as such CSS is most valuable to visual designers and front-end developers. Trying to mutate it into a “real” programming language would make it unusable to the people who need it most: those who are charged with making web pages visually appealing, readable, and usable.
I’m not a programmer. I’ve spent four years learning the basics of CSS and know I have much more to learn; I don’t pretend to be an expert. Given that, I took a look a the stylesheets for the four sites, and frankly, that’s some of the most cumbersome and kludgy CSS I’ve seen in quite a while. The fact that so much CSS is needlessly repeated within and across four sites shows a lack of understanding of how to write CSS rather than inherent limitations in the language itself. Please do check out the principles behind OOCSS: http://wiki.github.com/stubbornella/oocss/. It’s entirely possible to write elegant, reusable, and lean CSS.
CSS definitely has problems, few of which are mentioned here. The vertical centering stuff touches on real concerns, many of which are resolved by CSS3 (which will obviously take forever to be adopted).
I’m pretty sure you guys are just not good at CSS though. There’s a correct way to cascade your CSS that will solve most of your problems. That’s what it was designed for.
I’ve looked at SASS before, but CSS is really just so easy already that I haven’t had a project where it was actually worth implementing. The main benefit of SASS seems to be that it allows people who don’t know how to use CSS correctly to have easier success in styling their pages. I find that the way you have to think about CSS is very different from the you think about a programming / scripting language, and many programmers have difficulty understanding it. SASS is a crutch that let’s people work in something that resembles their comfort zone a little more.
I’ve never really felt the need for variables/constants or other programming features in CSS. In fact I think it would make it too fiddly. After all, as has been said, HTML doesn’t have programming features but this is made up for by either JavaScript or server side languages, which are both options for CSS.
There are however several things that really annoy me about CSS:
As you say, vertical alignment is rubbish. Why tables, which are supposed to be the old way of doing things, in this instance are better at layout seems backwards to me.
Column layouts. There is no way to make all columns the same height if the height of one or more column is unknown eg. due to dynamic content. Again, tables are really the only option. Sometimes when trying to fix this without tables, I feel like I’m spending far too much time and resources into it instead of just using tables. Again, in this specific instance, a step backwards for CSS.
The box model. If you have a div that is 500px wide and you put padding, border or margins on it, the width it takes up on the page is added to. This makes no sense. If you’ve allocated 500px of space on the page for a div, then if you add borders or padding (not so much margins) then obviously you want it not to take up any more room. That is annoying enough, but if the width is 50% and you want a border, then you end up with 50%+1px. There is no way to allocate exactly 50% of the width of the container for the div. So fluid layouts can end up being a real nightmare with lots of wrapper divs (a pet hate) or you could just give up and use tables again.
I think I’ve given the impression that CSS is completely awful, but to be honest those situations don’t come up that often. But when they do I just wonder why it’s harder to do a certain styles in a method that is designed specifically for producing styles than it is in an outdated method.
