Please create an account to participate in the Slashdot moderation system

 


Forgot your password?
Close
typodupeerror
×
Programming

CSS Selectors as Superpowers 190

Posted by samzenpus from the talking-style dept.
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.'"
This discussion has been archived. No new comments can be posted.

CSS Selectors as Superpowers More

CSS Selectors as Superpowers

Comments Filter:

  • Completely agree (Score:5, Informative)

    by Chrisq ( 894406 ) on Thursday May 02, 2013 @04:37AM (#43607595)
    Anyone who has used JQuery will know how their power exceeds the original intention

    • Re:Completely agree (Score:5, Insightful)

      by itsdapead ( 734413 ) on Thursday May 02, 2013 @05:20AM (#43607735)

      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: (Score:3)

        by dingen ( 958134 )

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

        This used to be true a few years ago, but all modern browsers nowadays parse selectors quite similar. Even IE8 is not so bad (it understands CSS 2.1 selectors like :first-child and [attribute] etc.).

        Of course things keep evolving all the time, so if you want to use cutting edge stuff, you might run into some things. But in general I think especially the selectors are amongst CSS' least problematic areas.

        • Even IE8 (If you use the proper DOCTYPE to bring it out of legacy mode) is not so bad (it understands CSS 2.1 selectors like :first-child and [attribute] etc.).

          Fixed that for you. This has to be the most annoying part of it all. They really should have implemented the opposite where you required a special doctype to put the browser into legacy mode. Would have made everybody start to make their pages standards compliant much sooner.

          • Re: (Score:3)

            by dingen ( 958134 )

            On the other hand, this really forced devs to include the proper doctypes in their work, which is a good thing!

      • Re: (Score:3)

        by Yvanhoe ( 564877 )

        Meanwhile, anybody who has used CSS will wonder what the hell the original intention was

        It was to provide an easier alternative to xhtml/xsl. Instead of the total separation between data and formatting that many programmers rooted for, it is a bastard compromise that was reached : HTML would still specify both data and formatting but formatting would "skinable".

        Some days I think that we live anyway in a world of compromise and that it is true that HTML/CSS is easier to use in 95% of case, yet other days I wonder if in the end we are not doomed to come back to the original intent, after a lon

      • Re:Completely agree (Score:5, Interesting)

        by BasilBrush ( 643681 ) on Thursday May 02, 2013 @05:57AM (#43607871)

        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.

        • Don't make it standard behavior.

          E.g., instead of letting the designer specify "width", let him specify "content-width", or "outside-border-width", or "margin-width", etc.

          And in case of conflicting specs (e.g. two or more conflicting attributes given) produce an error (don't choose a precedence order!).

        • Re: (Score:2)

          by Qzukk ( 229616 )

          What box model would be best?

          One that allows me to discover BOTH inside and the outside sizes so I can measure BOTH what will fit in my box, and what my box will fit in!

          Thanks jquery!

          • As far as I can see that's still not a best box model. It's mostly just different varieties of patching over what's broken. Those are just sizes, they're not rects.

            outerWidth(true) does at least match the same rect as CSS left. But is setting/getting a rect by the outside of an invisible margin (that may or may not be collapsed) anyone's ideal metric?

        • What box model would be best?

          I'd look on it from the perspective of "encapsulation": One person should be able to design what was in the box without knowing how it was going to be placed on the page, a second person should be able to place it on the page and align it with other elements without affecting anything inside.

          That would work best if the primary size of the box included the inner margin/padding and border (which the box designer 'needs to know'), but excluded the outer margin (which the 'page designer' needs to match with ot

        • Re: (Score:2)

          by xombo ( 628858 )

          You're able to control how the box model is calculated in CSS3 using the box-model CSS property. You could standardize on the MSIE way, if you so choose.

      • Re: (Score:2)

        by Lumpy ( 12016 )

        " 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."

        This, a thousand times this. Honestly, why the hell has CSS not been fixed? They could have easily added what was needed to make things a lot easier. but instead they force everyone to fight with it.

      • You don't need another "I do agree 100% with what you said" since you already got the +5 In. But you just said a very nice way.

      • the arcane kludges needed to produce popular web-page layout effects easily achieved using evil tables

        Rejoice brother, for the era of display:table-cell has begun (supported in IE8 and up, and IE7 is effectively dead, thank god). Nice clean semantic markup, but now with access to all the juicy table features like vertical & horizontal-block centering, shared column height, and automatic column sizing. (Good article: http://www.digital-web.com/articles/everything_you_know_about_CSS_Is_wrong/ [digital-web.com])

        You know t

    • No, not really.

      jQuery does it, CSS is just the way jQuery is interfacing with the browser. CSS isn't really doing anything but making the situation more complicated and convoluted actually.

      CSS + jQuery, like most things on the web now days was stumbled on, not designed. It was stumbled on because no one bothers to think about what they are putting into HTML and how it affects the future, they only pay attention to what they want in their browser for today. The end result is that most of the system is dec

  • Practically Worthless. (Score:4, Insightful)

    by VortexCortex ( 1117377 ) <VortexCortex AT ... trograde DOT com> on Thursday May 02, 2013 @07:15AM (#43608209)

    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, unfortunately designers can't use it (Score:4, Insightful)

    by Bitsy Boffin ( 110334 ) on Thursday May 02, 2013 @07:27AM (#43608275) Homepage

    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.

    • 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

  • CSS should be a programming language (Score:4, Interesting)

    by quietwalker ( 969769 ) <pdughi@gmail.com> on Thursday May 02, 2013 @07:36AM (#43608327)

    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 -

    • Also, to you folks who are pants-on-the-head retarded, and think that html, css, and js equals an mvc, you are incredibly wrong. Javascript plus css is what defines the view, and that goes for all javascript outside of a few frameworks like Backbone that actually implement a real Controller pattern.

    • Re:CSS should be a programming language (Score:5, Informative)

      by Jason Levine ( 196982 ) on Thursday May 02, 2013 @08:17AM (#43608659) Homepage

      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.

      • I don't have mod points right now, so let me just say thanks for pointing that out. The Boston Globe's site is really neat when you re-size.

      • I have used media queries, and they are a great addition that gets us another step closer, but they're not the end-all, be-all. Once all the mobile devices can settle down and give us consistent and sane implementations (like not downloading every image, even those outside of the @media block), we'll be even better off, but it's still not a solution to each of my issues. Providing for statement evaluation, flow control, variables, and so on will.

        As someone who's actually written desktop apps, every time I

    • Re: (Score:2)

      by dingen ( 958134 )

      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

      Erm... heard of media queries? They do exactly this.

      @import url(narrow.css) (min-width:800px);

      This loads stuff from narrow.css and applies it if your window is less than 800px wide.

  • 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.

  • That CSS is not programming at all. It's layout design.

  • 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.

Slashdot Top Deals

The 11 is for people with the pride of a 10 and the pocketbook of an 8. -- R.B. Greenberg [referring to PDPs?]

Close