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.'"
I use a PHP file as my CSS. Take a look... http://www.barelyfitz.com/projects/csscolor/ or http://css-tricks.com/css-variables-with-php/
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.
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.
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 -