CSS Selectors as Superpowers

An anonymous reader writes "Simon St. Laurent writes in praise of CSS selectors: 'After years of complaints about Cascading Style Sheets, many stemming from their deliberately declarative nature, it's time to recognize their power. For developers coming from imperative programming styles, it might seem hard to lose the ability to specify more complex logical flow. That loss, though, is discipline leading toward the ability to create vastly more flexible systems, a first step toward the pattern matching model common to functional programming.'"

Comments

Completely agree

[Chrisq]

Anyone who has used JQuery will know how their power exceeds the original intention

Re:Completely agree

[itsdapead]

Anyone who has used JQuery will know how their power exceeds the original intention

...anybody who has used jQuery will know how powerful they could have been if only browsers had implemented them completely and consistently.

Meanwhile, anybody who has used CSS will wonder what the hell the original intention was, given the arcane kludges needed to produce popular web-page layout effects easily achieved using evil tables and frames, the lack of 'constants' to set standard colours and measurements.You know there's something wrong with a standard when Microsoft's broken box-model implementation makes more sense. However, that's not the fault of the selectors.

Its as if the designers* of CSS had never looked at a web site, used a DTP package, used styles in a WP package, let alone played with a Java layout manager to get ideas about what might work and/or be useful.

(* probably unfair - I'm sure it was a mixture of committee syndrome and the notion that you can define a standard without producing a reference implementation rather than individual failings).

Re:Completely agree

[dingen]

Things like SASS and LESS point out where the big flaws of CSS are. It's crazy we still don't have variables in 2013 by default, this has been at the top of the requested features list for what, 15 years now?

Re:Completely agree

[BasilBrush]

What box model would be best?

Serious question. I'm doing a specialist graphics app at the moment, and I was just considering this the other day. What's the important rect for a box?

Most graphics app use a rect that is halfway through the border by default, as a result of the concept of "stroking" the rect. CSS is very different, and as you say a bit broken, by default using outside the margin for position, and content rect for size. So there's no concrete rect for layout of a box at all in CSS. And then there's box-sizing, which could allow the concept using the same rect for positioning and size, but doesn't.

How would a designer prefer to think of the primary metrics of a box, for the sake of alignment, snap to grid, proportional resizing etc?
1) Margin rect
2) Outside border
3) Centre of border
4) Inside border (outside padding)
5) Around the content (inside padding).

Of course, "all of them" and "it depends" are rational answers. But not much use when deciding on default or standard behaviour.

Re:Completely agree

[Lumpy]

Tell that to the guy that has to build a house with a saw that has no teeth.

He will probably beat you to death with that saw. People that have no clue at all as to the problems with the tools or even how to do the task are the first to blame the craftsman.

Re:Completely agree

[Bazman]

And now your web server has to do PHP processing on every page and every style sheet, so your load goes up. So you implement some caching. Now you have two problems.

Re:Completely agree

[RevDisk]

I always liked PHP, but I'm an infrastructure guy who only uses PHP for relatively minor stuff. Something doesn't need to be perfect to be useful.

Please don't burn me, I don't weigh the same as a duck...

Re:!Like

[LizardKing]

Bollocks. CSS was designed to separate styling from structure in web pages. It does this admirably, and only needs to be a declarative language to do so. This prevents a lot of "clever" hacks that including conditional or flow statements would have encouraged. It's the same reason why statically typed languages are better than dynamic ones - since the tooling and compile time checks can be much more comprehensive and optimisation is easier - but clueless twats prefer the dynamic ones, since they don't understand the downsides or foolishly think they are so good they wont screw up. Improved programmer productivity claims for including flow statements in CSS (or using dynamic languages) are crap as well, since while a programmer might find it easier to cobble together something that just about works, chances are very high that it will be harder to maintain.

Re:!Like

[BasilBrush]

CSS alongside 2 basic layers, regular code and HTML document itself, only creates additional unnecessary third layer of shit that eventually may introduce problems, as soon as someone starts playing with it

That's like saying MVC is unnecessary, and not just putting all your code in a single class/module/namespace may introduce problems. There are people that say that, but they are novices.

HTML5/CSS/JS is equivalent to MVC. The "VisualBasic" type people would tend towards trying to put everything in their HTML rather than the other way around.

Re:!Like

[dingen]

You have no idea what you're talking about. CSS (and HTML for that matter) have *nothing* to do with programming. CSS is merely a way for designers to code a layout, nothing more, nothing less.

I do agree CSS could have been a lot better and there are definitely some errors which needs fixing, but the general idea of separating mark up and layout is a sound one and selectors is one of CSS' best features.

Re:CSS should be a programming language

[Jason Levine]

Css has been around for 16 years and it still lacks the ability to easily declare a completely separate layout based on display height or width, something like "If width is less than _x_, use this css, else this" or "set width equal to - 30". If you want those things now, you have to use javascript, and it's sometimes pretty awkward - like calculating the width of an element filled with content prior to displaying it.

Actually, you can do that. I do it all the time when I use responsive web design. Here's some sample CSS code:

@media screen and (min-width: 501px) and (max-width: 750px) { /* Put styles in here to reformat the page for larger tablets or small desktop resolutions */
}

@media screen and (max-width: 500px) { /* Put styles in here to reformat the page for mobile devices and small tablets */
}

@media print { /* Put all of your styles in here to format the page for printing. */
}

There is no JavaScript at work here. If you loaded a page utilizing this code in Chrome or FireFox (or IE10), disabled JavaScript, and resized the browser to make it smaller, you'd see the page slowly transform from a desktop version to a tablet version to a mobile version. (A good example of this is the Boston Globe's website: http://www.bostonglobe.com/ ). I can set styles for HTML elements and override them if certain conditions are met (max-width is between 2 values, screen resolution is a certain amount, print vs screen, etc). It might not be "if-then" statements, but it has the same effect.