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
Is it possible to embedd CSS in another (non-browser) application to use it as an DSL?
Are there libraries available for example for C++ applications?
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.
Also for changing the page's background color
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.
Using a classic XKCD poster.
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'.
I like your turn of phrase! I also rather like dynamic programming languages. However, that's a totally different story to CSS. You can tell the people who don't understand CSS - they're the ones who whine about it. It's a shame they can't take some time off from whining and actually learn how to use it properly.That's too much effort, of course - whining's so much easier.
"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"
Err , no , sorry it isn't. Declarative systems are NEVER more flexible. They might be able to do some things in 1 line that imperative might take 100 lines to do , but when it comes down to it imperative will always be more flexible and powerful simply because it allows you far more control.A declarative language is always restricted to the particular set of problems that its creators tried to solve. If that wasn't the case then why has every dialect of SQL had procedural language add-ons? Why isn't Prolog used everywhere? Why has functional - which is only midly declarative anyway but we'll let that slide - taken over the world like its proponents constantly tell us it will?
Answers on a postcard.
I call BS.
All non progammatical web code has to do is describe a page. There is no reason on earth for requiring 2 completely different formatting languages - HTML and CSS - to do this. CSS is just a nasty hack on top of HTML which was already a hack anyway and along with embedded javascript its turned web coding into a total dogs dinner.
Sure, by itself CSS is a good domain language for the problem it solves. The problem comes when you combine CSS with JavaScript and jQuery - sometimes I wonder if I am looking at a CSS selector or an anonymous JavaScript object because the syntax is so similar it all blurs together. Combine this with HTML and JSTL, two tag languages, and JavaScript and EL, two syntactically similar languages. Then put all four syntaxes into the same JSP file. I sometimes can't tell what's emitted HTML/CSS/etc and what's JSP/JSTL/EL. Any one of these is fairly elegant, but when you put them all together it's an unholy mess. Attempts to separate them further complicate matters.
Whatever else you can say about PHP, it's a whole lot simpler and somehow managed to escape J2EE's compulsive over-engineering.
Decent code to generate a definition file, like HTML, is significantly more reliable than a human punching that code in. The only real purpose for CSS is to separate the property values from the actual definition of the page, reduces the chance that you'll accidentally change the wrong values and break the page.
I wonder how many crying out for "more dynamics" has actually tried XML with XSLT. It fits the web model so nicely with the data driven nature.
Isnt TFA making the case that it's almost a programming language?
I don't think so. The fact that it's code doesn't make it programming.
Pretty good is actually pretty bad.
before CSS, HTML and javascript.
You just don't like "web coding" at all, do you?
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.
Um, no. MVC is a design pattern (i.e. a set of concepts for programming) that can apply to any language, CSS is declarative style markup (that apparently some people think should be the next programming language) that depends upon another markup language (HTML, XML).
Maybe if you compared it to some other GUI markup, the analogy would hold, but MVC is not even in the same realm. You might as well use a car analogy. I think you should look up MVC. Maybe if you said AWT or Swing, that would be a little closer. VisualBasic also had these types of visual design elements that the GP was complaining about. So while maybe the GP was a troll.... WTF you talkin' 'bout wullis.
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.
The fact that it is interpreted by the browser and applied to the web page layout does.
It isn't a general-purpose programming language, and not even Turing complete, but neither of these is necessary.
It is a domain-specific language for styling. As it is not used for modelling but for the actual implementation (the line between both being blurry anyway), it is a domain-specific programming language, which is a special case of programming language.
Anyway, nobody will call it a programming language because "styling language" is more specific.
I guess you're right. I was thinking of things like Turing-completeness, but I agree that is not actually necessary to make something a programming language. A player piano isn't a computer, but making a piano roll still is a form of programming.
Pretty good is actually pretty bad.
IE9+ did things right, but Opera and Safari are still lagging behind tremendously. Opera isn't so bad in contrast to safari but holy crap, learn to stick with the w3c standards and support ALL code not just what you feel like supporting. I haven't had any client that cared to have safari supported but I remember at least a year ago when using transparent/semi transparent images on safari would end up being a hassle to write for. These days CSS is pretty fun to work with, virtually no need to write exceptions anymore for the most part unless your client really insists on wanting older browsers supported. Yes, it's more money but it's also infuriating to work with.
The fact that it is interpreted by the browser and applied to the web page layout does.
No, it doesn't. CSS is a description language, not a programming language. It just maps elements to the layout of said elements. Calling CSS a programming language would be akin to claiming, the mapping of numbers to colors in a paint-by-numbers would "program" the picture.
Bollocks. CSS was designed to separate styling from structure in web pages.
Bollocks. CSS separates BOTH style AND structure from web pages. It wouldn't have been so bad if CSS actually did only specify style but unfortunately it also implements page structure. That is the problem with CSS. Tables, which used to create simple and easily managed structure in web documents, have been deprecated and replaced with CSS equivalents, except, of course that much of such CSS is often simply awful and relatively inconsistent and unreliable.
If only CSS did deal with just style. But CSS definitely is all about structure too.
No, a JSON file looks nothing like a CSS file, it looks a lot like a chunk of javascript though....
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...
Douglas Crockford says that Cross Site Scripting is called XSS for short because CSS would have been confused with Crappy Style Sheets
Wh47 d1d j00 541, 31337 15n't t3h r0xor5 ne m0r3???
if it only included a #define....
world was created 5 seconds before this post as it is.
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 -
Mr. St Laurent seems to be talking about JS more than CSS. According to him the "future of web development" is in wrapping CSS manipulation in JS to create ever more complex, bloated, brittle webpages that can only function with low-security browser settings.
And then of course there's that pesky problem of people expecting "content". Perhaps a giant JS library could solve that problem, too?
You can't deny there's a very similar syntax going on (blocks of key:value pairs encapsulated by curly braces). I believe Crockford himself even said he came up with JSON after staring at a CSS file and realizing it looks a lot like a Javascript object.
Pretty good is actually pretty bad.
CSS kicks ass. I love it... Combine that with jQuery and HTML5 and you have some bad-ass sites that are fun to work with and use (as long as they're done right, of course, but hopefully that goes without saying).
Something that gets exhausting is dealing with people who have some axe to grind with this stuff. You see it in Java posts, you see it in PHP posts, you see it in ASP posts, you see it in Python posts...
Stop puckering your damn lip and go grab a different employer who caters to your development needs if it means that much to you to get away from .
You're going on like the only alternative to MVC is stuffing everything in a single file. While those of us who have been doing web development long before the idea of MVC have been separating out the business logic from the web page for a long time. There was stuff like N-Tier architectures which did a pretty good job of separating out the data storage from the business logic from the presentation layer. Personally I find this to be a lot better than MVC, because I find that MVC links the presentation too much to the underlying structure of the data.
Anthropic principle: We see the universe the way it is because if it were different we would not be here to see it.
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).
You are confusing structure with layout. Tables are a used to define document structure, when the data to display is tabular. to use tables to layout the document when the contents of the table is not tabular data is plain wrong!
There are other JavaScript frameworks, beside jQuery, that support CSS selectors. i.e. Prototype
interactive hologram, or it didn't happen.
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.
Wtf are you smoking? HTML used to do presentation. And there's no reason it still can't. Please feel free to give the exact reason for CSS having an entirely different syntax and structure to HTML when XML which can store far more complicated data than CSS manages to have a pretty similar one.
The CSS property you're looking for is box-sizing. If you want modern browsers to use IE's box model where the width includes border and padding, use the value 'border-box'.
If you want stroke-style sizing, use SVG.
The CSS property you're looking for is box-sizing. If you want modern browsers to use IE's box model where the width includes border and padding, use the value 'border-box'.
As long as you're willing to drop IE7, you can use display:table. That's like GridLayout in Java.
Grids and flex boxes are finalizing soon, which can give you the equivalent of Java's BorderLayout.
You can have CardLayout today with position:absolute and z-index.
The tools are there. As for evil tables, I remember the days of slicing every image into a grid. I don't understand why you'd pine for those times.
Modern browsers can do all of the things you mentioned and more. If you want to yell at someone, yell at those folks still XP and IE8 (or earlier).
How hard is ?
And yes, that is standard HTML5.
I think MVC more like Model = JSON Data View = HTML+CSS Controller = JavaScript
As a graphic designer (yes, one who understands CSS and isn't afraid of a few lines of code), I would describe the problem as being one of visual thinking versus linear thinking. To a designer, who is accustomed to moving objects around intuitively in 2D or 3D space, it's a mental wrestle to translate this into numeral coordinates. It's not so much fear of math and numbers (most designers use quite a lot of numbers and measurements themselves), but more the mind-space of coding, where one small local change or (mistyping) can cause the whole ensemble to fall apart and be rebuilt.
In design, you step back, look, nudge the box a bit to the left.... In CSS or XHTML, you find the element, decide what it's called, figure out its place in the hierarchy of styles, tweak the pixel amount, resave, reload, check in browser, check if anything else was unknowingly affected by your tiny change, repeat incrementally, etc. Get one character typed wrong and it's like throwing a wrench into a jet turbine; everything explodes.
My analogy is that designing with CSS is like painting a picture with pieces of colored paper that you have to hang from the ceiling with invisible bits of fishing line at various lengths, getting them all to hang in the same plane somehow and form a 2D image that won't blow in the wind.
I am one of the lucky ones who can do a little bit of both worlds, and I admit, it takes a mind that's more flexible than mine at the best, most caffeinated of times. You have to shift rapidly between two complete hemispheres and mental models, as well as adapt to the different time-scales and debugging issues involved.
Of course, this has been the eternal issue on Web platforms ever since HTML started to add graphics and get fancy. The content-over-all people and the eyeball-candy people have to coexist somehow, and the final product should be as platform-independent as possible while still allowing some designer control over the visual aspect. Now, it's becoming a lot easier than in the days of tables, invisible pixels and (shudder) sites/pages designed completely in Flash.
Why not leverage people's existing SQL knowledge and create a relational-friendly DOM? There will still be tree-oriented nesting, but special functions and views can assist with that.
Table-ized A.I.
That CSS is not programming at all. It's layout design.
Um, having been a Visual Basic (and others but whatever) programmer since 1996, it was immediately obvious to me why separate CSS style sheets and script files were a Good Thing, precisely because VB separates the editing of your visual layout and your code and also forces you to put every class neatly in its own code file.
Every few years I crawl out of my sandbox and absorb any useful changes in the browser scene.
The last time I tried CSS selectors every one I wanted to use either didn't work at all or worked great until I tried the same thing in a different browser.
Another problem is that there's a fuzzy border between styling and structure.
Graphic designers and web designers have to deal with this every day. We're at the exact midline between two worlds: "content" and "appearance." In most organizations, these come from different sources, have radically different worldviews, and differ in their goals and the language used.
But they can't ever be separated neatly, because in any graphic medium, the content is always dependent on its design, and vice versa. If you are conveying information visually, every piece of information needs to be depicted according to the dictates of usability, aesthetics, corporate branding motives, hierarchy of data, salience, conciseness, and all the other factors that layout consists of.
tl/dr: In the real world, the line between content and design ain't neat and tidy. And the issues are only noticed by the people who work on that line, from day to day, solving problems by applying concrete tools (like CSS, HTML, PDF) to flexible and changing realities.
If you think CSS interferes with structure, you don't understand what structure is. CSS is only about how things look, nothing more. HTML used to do style too in a distant past and there are a few remains of that still in there (some form elements for example have their own style which can't really be changed through CSS). But the other way around? No way.
Pretty good is actually pretty bad.
Actually, CSS3+HTML5 is Turing complete. Some madman implemented Rule 110 in it.
The rest of your post is correct.
You're confusing the point.
The point is to get a job done. You're just adding unneeded semantics based on a broken philosophy. CSS is not better in several instances. Table based layouts are the proof of that. Instead of recognizing shortcomings, you're ignorance shows through as you just keep parroting the same old tired line ... which just goes to illustrate that you are having a religious debate about your preferred language rather than a discussion of technical merits.
Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
getting the job done, the wrong way. Looks like you never cared about assistive technology and people that need it. A table is a table, a definition for tabular data, using tables for other things break the correct dictation/help the assistive technology provides. Content and presentation should be separated, period.
To allow specifying a RECTangular section of the source image, so that one can place or stretch pieces of a single image that has a zillion different style elements in rectangular tiles like corners, line segments, icons etc. One image to load, one palette to manage, and all the clipped regions appear instantly, magically! Need to swap 'styles'? Change the whole image! Need to extend the style? Build out tiles within the image in the X and Y directions! Use evil tables for everything without apology.
Only joking! I wanted this in 1995. But instead of joining a standards committee I went and did other things for awhile. Well, I'm back.
Only joking! Instead of improving the IMG tag, why don't we create whole hidden empty html layers whose background images are the source image and make them invisible by default and slide them off the page.
Only joking! How about a web page that loads with a pile of layer:visible crap in the middle of it, menus open and obliterating the content, and load an external Javascript routine from another domain to make it invisible or skitter it out of the way? Eventually.
Only joking! How 'bout dem web pages that dynamically resize themselves so that the rightmost or bottom portion of text is always hidden at every possible window size or display resolution? Select all, paste into Notepad to read it. Or better yet, paste it into a Java code development window and read it with all the colored blinking syntax violations.
Only joking! I designed my whole site in Flash because with flash you can make round beeping web pages that have no volume controls.
I run NoScript by default. More than half of the Internet is just missing. I run WebDeveloper and turn off CSS to view pages as Jesus would.
Now awaiting the new specification for CCSS (Cascading Cascading Style Sheets). Under this progressive regime (CSS, CCSS, CCCSS etc) style is expected to overtake content by 2015, with content completely defecated by 2020.
<blink>down the rabbit hole</blink>
Wish I had mod points for your last sentence, but since I don't, I'll just let you know that I got the joke.
Does this allow also the benefits of isolating side effects? Superior evaluation and type models and stuff? Like in Haskell and OCaml? If not, it's worth sh*t.
Could this be a result of them using design tools that mean they don't need to think - so they don't?
To an extent, but as another poster replied, it's more down to simply how the designer's brain works, can't blame them for that, but it doesn't make life easy.
I think at the bottom of it is the common problem that CSS was developed by programmers, not designers, and the programmers didn't understand that the designers don't think like they do, and that they can't think like they do.
As a result, it's just not a good fit for designers, so they use it badly.
NZ Electronics Enthusiasts: Check out my Trade Me Listings
The job is not done when the site looks OK on your screen. The job is done when the Google bot can figure out your content so people will actually find your website.
Putting everything inside a big table so it looks OK to humans won't help Google's robot (and the wrath of the blind will be upon you).
Pretty good is actually pretty bad.