Slashdot Mirror
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.'"
Anyone who has used JQuery will know how their power exceeds the original intention
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.
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.
Yes. Qt will let you style the GUI with what is effectively CSS.
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.
Pretty good is actually pretty bad.
If that's what you think, then you don't understand why CSS and HTML are separate languages. The implementation is by no means perfect, but its a very good example of Separation of Concerns (separating content from presentation, and in javascript's case, both of those from application logic), something that all too many 'programmers' don't seem to have any idea about. Then again if you're one of those programmers who see SOLID principles as over-engineering then I can understand why you might think that its an 'additional unnecessary third layer'.
You're crazy. CSS and HTML are completely unrelated languages and technologies. None is a hack on top of another. HTML describes the structure of a document, CSS defines how things look. It's that simple. They require a different syntax because they are used for different things. And they're both very successful at what they're trying to do. Sure there are problems, sure there are things wrong with it, but show me something perfect. There are two types of languages you know: ones everybody complains about and ones nobody uses.
I have no idea what you mean by "embedded Javascript", but Javascript is the programming language of the web. Contrary to HTML and CSS, Javascript is a "real" programming language by any definition. Without it web applications would not be possible and the web would merely be a document system. Instead its the world's largest application platform, allowing users on any device to use your applications. If you are a web developer and you think that's not exciting then maybe you should think of switching careers.
Pretty good is actually pretty bad.
It sounds like your'e confused. And I can't blame you, because there are *a lot* of different languages and syntaxes involved in creating a web application these days and it can be challenging to grasp it all. It helps to separate things in your mind. Even though the syntax of e.g. a JSON file may look a bit like a CSS file, they are completely unrelated. Make sure you know what you're working on (structure, style, client side logic, server side logic) and only concern yourself with the things that are related to that, nothing else. PHP for example has nothing to do with anything on the client, so don't even realize it exists when you're working on something in the client :-)
Pretty good is actually pretty bad.
Javascript is much more a functional programming language than a procedural one. It's by no means as pure as Haskell, but this also allows it to be useful.
I suggest you read up on some of the articles by Douglas Crockford, who does an awesome job of explaining the true nature of Javascript to the world. This is a good starting point.
If you don't believe Javascript is indeed a functional programming, here is a Google Talk by the same Douglas Crockford explaining how to do monads in Javascript: http://www.youtube.com/watch?v=b0EF0VTs9Dc
Pretty good is actually pretty bad.
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.
Bollocks. Every configuration file should be Turing complete. -- The Sendmail Authors.
Think about it. It's practically worthless. We might as well be compiling CSS + HTML + JS into an interactive PDF format for all the times we actually reskin entire sites. Even mobile stuff is suspect -- I mean, yeah, I can have 10 different images to serve depending on the size of the display, and I automate that image asset generation... Then what? I make the images be CSS backgrounds? Isn't that defeating the point of separating the style from the content? Go the other way: Actually put the content wholly in the HTML, and only use CSS to style everything. Yeah, great, I can sort of reskin for printers and mobiles, but where's the detection mechanism? It's on the server side... Thus conflating the whole model, view, controller and the presentation, content, style, etc. I mean, JS to manipulate the view -- So, what, a segmented controller? CSS3 Animation instead? Oh, so that's a style thing now. Bah, whatever. A rose by any other name...
The problem is that designers would love to think these problems can be isolated and are separable. The reality is that they are not. Concentrating on making your CSS super flexible with selectors is merely mental masturbation. If it weren't then folks would be making CSS libraries for pulling off common styles and effects. Go to the "poster child" of CSS: CSS Zen Garden, and see for yourself. Tons of #id tags, tons of different designs, no one really taking any two designs and combining them with ease...
The reality of the situation is that the next person who comes along will just scrap the whole thing and re-make the design again anyway (yes, even if that person is you). Might as well be compiling it all down into a low level colored shape display system, that way we can implement CSS and HTML and even new markups atop it, instead of waiting for OVER HALF the age of the web just to move from HTML4.01 to HTML5...
CSS is great when used properly (although, somewhat hereticly, I would kill for definable constants a-la 'color: PRIMARY_WEBSITE_COLOR;' without resorting to dynamically writing the CSS ).
Unfortunately graphic (website) designers are completely shit at using it. Even simply understanding when they should use an ID and when they should use a class seems to a'splode their brain, "huh, what is wrong with using this same id a bajillion times in the page". Don't even try telling them that "redtext" is not a good classname. Heck half of the time it's ".span1"!
They don't even know (even after telling them half the time) that you can use multiple classes on a single element, let alone combine selectors, everything is a single ID or classname to them. The amount of copy-paste in most web designer's stylesheets is simply offensive, all because their brains don't allow them to modularise their desires into useful reusable CSS classes. Cascade? Inheritance? These are foreign words to the average website designer.
There is no point telling a designer how they should can make their CSS better, they just won't understand. Worse, if the programmer, who does know how to use CSS as it was intended, attempts to fix their stylesheets (or worse, cut up their photoshops into proper HTML and CSS), the original designer just won't understand how to do anything in the stylesheet anymore.
NZ Electronics Enthusiasts: Check out my Trade Me Listings
Intellectually, I know that if it were more complex, there's no way it would have seen widespread adoption, and that markup is actually still complicated for many people. I can even look back at the early days of the web, when Marc Andreessen butted heads with Tim Berners-Lee about the media tag meant to display images, sounds, video and anything else and said, 'Screw it, you guys take too long to decide anything and it's over complicated, here's an img tag, done.' - and I can see how simple beats theoretically perfect and well designed.
However, we're already at the point of widespread adoption now, and it's a good time to have a new css that actually is a programming language, with flow control, dynamic calculations of element values, and so on. This is what we need to provide real separation between the document and how it looks. Anyone experienced enough to write non-trivial web applications that are meant to be run on a browser, tablets of varying sizes (including accounting for reorientation), and even cell phones knows that it's unrealistic to use a single page - you get sent to the 'mobile' variant of the page or elsewhere.
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.
To you folks who cite javascript to fix this, realize that css no longer manages the document display at that point, the javascript does. That means that css is missing something required to manage a display. It can only do some of it's job.
- side thought; I'd be happy if css allowed javascript within the css. Assign values based on closures or predefined functions. Simple fix -
First, you lose credibility for linking w3schools.com. Professional web developers wouldn't be caught dead referencing them. Second, you're referencing a tag that's deprecated because of CSS. Professional web developers wouldn't be caught dead using a font tag (or any other stylistic tags for that matter).
Unfortunately graphic (website) designers are completely shit at using it. Even simply understanding when they should use an ID and when they should use a class seems to a'splode their brain, "huh, what is wrong with using this same id a bajillion times in the page".
If CSS did what it said on the tin - separated content from style and layout - then graphic designers wouldn't have to bother their little heads about this sort of thing because they wouldn't need to touch the semantically-marked-up HTML.
Unfortunately, (a) CSS doesn't do what it says in the tin - changing the layout inevitably needs including exactly the right permutation of DIVs in the markup because CSS doesn't have any way of doing what every half-decent DTP package since PagerMaker 1.0 can do: defining a series of frames and specifying how text should flow between them - and (b) anybody who thinks style can be completely separated from content has spent too long reading & writing rigidly structured technical documents.
Don't even try telling them that "redtext" is not a good classname.
Hell no! Any idiot knows that a classname should be something semantic, like "rubric". ;-)
In a survey of 100 programmers, 111111 thought that duck-typing was a good idea.