• (nodebb)

    I guess that this in CSS:

    .underline .red { text-decoration: underline red; }

    is the equivalent of this in C:

     #define ONE 1
  • Maia Everett (github)

    This is basically someone reinventing Tailwind (which is a WTF by itself).

  • TheCPUWizard (unregistered)

    Classis with using WYSIWYG : you select some text that has existing CSS, and apply a new CSS -- and it does so inside rather than replacing [neith of which is inherently right]. TRWTF are people (calling themselves developers) who do not look at the code from lower operational level... and unfortunately that seems to include the vast majority today [way worse than 13-20 years ago]

  • Allen (unregistered)

    I'm a beginner learning web development. On the one hand, I get why naming classes by content makes sense, but I'll admit it sucks for reusability. How do you strike a balance between the two?

  • Robin (unregistered) in reply to Maia Everett

    Was about to say, sounds like Remy is blissfully unaware of Tailwind. Which I remain convinced was intended as a joke but got taken seriously for some reason!

  • (nodebb) in reply to Robin

    Sounds more like strong gusts of side wind, leading to a crash during landing.

  • (nodebb)

    That's very offensive language. Have a care. Children may read this. We'll see it through the fingers this time, but please use "Clbuttical Design." from now on.

  • (author) in reply to Robin

    Oh, I'm aware. I even had a, "Well, all the kids are talking about it, maybe I should use it on a project," and after about five minutes said, "Nope. Never."

    In my experience thus far, I haven't found a CSS framework that was actually worth it. They're all opinionated, which is fine, but their opinions are wrong.

  • (author) in reply to Allen

    Does it suck for readability? It sucks if you think the DOM is supposed to tell you what the page looks like- but it isn't. The DOM is best thought of as a model of your UI state. The structure and hierarchy should basically be done without any regard to appearance, only in regards to the structure of the document.

    CSS is a function which maps that structure to a presentation. It converts that DOM tree into rendered pixels on the screen. (Yes, the underlying browser implementation makes this flow much more complicated, and understanding it can be important for performance, but we can set it aside for now)

    This approach makes it much easier to understand both your DOM and your CSS. It modularizes your code, and makes each part easier to understand in isolation. It also makes it way easier to understand how to modify your page- change the DOM to reflect the new structure, modify the presentational rules to decide what that structure looks like.

  • Hal (unregistered)

    The problem to borrow a quote a bit,is that semantic CSS is the worst solution for style and layout abstraction except for every other one that has been tried. Maintaining semantic names only works if the scope of the application or site is well understand from the start and rarely changes, and everyone on the project that touch anything that spits even a single character of HTML code out some place is a incredibly disciplined.

  • Paulo Miguel (unregistered)

    Or you could use a JS framework specific library based on a CSS library that was made for a standard website and not the dashboards that you're designing, because it's simpler, easier, and standard. Nevermind the resulting tag soup with class salad that results, usually by hammering whatever letters unintelligibly position things where you want them with the inevitable sprinkling of CSS anyway in extra divs that sometimes don't even need to be split. I love the goal of the project, and have my own stupid opinions here and there, but sometimes... sigh.

  • Argle (unregistered) in reply to Remy Porter

    I've done one project with Tailwind. This was a self-inflicted project. Now my son (who's a very good programmer in his own right) and I are having our own private religious war over Tailwind. He seems to think it's great. After I stepped back and took a look at the project, it seemed to me like I had essentially used "style" attributes on everything rather than use CSS.

  • Tim R (unregistered)

    As a programmer of many years I'd like to think I've really grokked many things like XML/XSL, SQL, Lisp, React, Serverless, OOP, pure functions, Static and Dynamic typing any many more, but CSS I think is just trying to bite off more than it can chew.

    I certainly wouldn't claim to have done my 10,000 hours of CSS but unlike all those other technologies, I can't see how a well disciplined team who knew what they were doing could produce a clean CSS solution for a reasonably sized system without having to bodge it.

  • (nodebb)

    It doesn't help when you use 8-column indentation. Even good HTML often has lots of nesting, so 2-spaces is the de facto standard. Is this in the original or due to Remy's formatting (I've noticed it in many other posts)?

  • NoLand (unregistered)

    So Alice said that Bob said that Claire said that the box was round and added that box was purple and added that box was grey and added that the box was horizontal, to which Dave added that it was vertical, as well.

  • (nodebb) in reply to Remy Porter

    I always thought it was more a case of WHEN people were thinking about convenience.

    Presentational classes (can) make it more convenient to set up the presentation on new things.

    Semantic classes are often far more convenient when it comes to modifying presentation later.

    In my limited experience (I stopped doing much styling work a decade or so ago), both of them tend to get hairier the more you style things based on their containers and the more you use nested containers for positioning.

    If your team almost never does presentation updates without a complete redesign, it's easy for me to imagine the former at least looking like it's going to have a lower total cost of ownership in maintenance time, especially if you use an opinionated framework.

    I still prefer the latter.

    Consider when on April 1 you need to add a#log-out-button { background-image: url(https://thedailywtf.com/images/remy/Remy203-300x300.png); background-position: -81px 162px; color: transparent; padding: 4px 15px; } for example.

    I don't actually have a demonstration of why that would be any better than if the classes were presentational, I just had fun setting it up.

  • Kleyguerth (github)

    The best part about using "red-underline" is when business dictate it should now be a blue strikeout.. Now either red-underline applies a blue strikeout or you have to update all your html files that use the class. I also fail to see how a class that simply describes its own style is any better than just applying the style directly through the style attribute.

  • Airdrik (unregistered) in reply to Kleyguerth

    This exactly. It's basically using an abstraction for the sake of the abstraction but in a way that bypasses any of the benefits of the abstraction. Echoing what Steve_the_Cynic posted earlier, it's basically the same as using #define ONE 1. It doesn't help you at all and just gives you extra busy-work. Seems there should be a name for that anti-pattern, maybe Abstraction Slayer?

  • xtal256 (unregistered) in reply to Allen

    It only sucks for reusability if you are doing classes too fine-grained (which is the same for classes in OO). For example, you would not be able to re-use a class called "profile-status-field" or "registry-code-field", but you would name a class "field" then use it on all fields.

    Strangely, the html in the article uses classes everywhere except on those fields, it just separates them with br elements.

  • (nodebb) in reply to Airdrik

    Seems there should be a name for that anti-pattern, maybe Abstraction Slayer?

    How about: Abstraction Assassin(ation)

  • Rani (unregistered)
    Comment held for moderation.
  • Maia Everett (github) in reply to Remy Porter

    Oh, I'm aware. I even had a, "Well, all the kids are talking about it, maybe I should use it on a project," and after about five minutes said, "Nope. Never."

    I approve!

  • aDesignClassicist (unregistered) in reply to Allen

    First, consider whether the reuse has a logical reason or is incidental. If it's incidental (e.g. you want both titles and hyperlinks to be underlined), chances are you are better off WITHOUT reuse. Maybe RIGHT NOW you want both of these unrelated elements to be underlined, but if you ever change your mind about how the titles should look, you'll need to hunt down and replace half of that class's usages. If there is a specific reason why the elements should be styled similarly, now and in the future, try to put that reason into words and use that as a semantic name. Maybe you are showing some kind of feed, which can contain recommended posts as well as channels and perhaps even profiles, and you want them to have some common styling? Something like "feed-item" would do, and would be better than "round-corners-grey-background-and-bold-text"

  • Kirby Wallace (unregistered)

    I guess the guy didn't know you can just specify multiple classes, separated with a space.

  • Duke of New York (unregistered) in reply to Airdrik
    Comment held for moderation.
  • (nodebb) in reply to Kleyguerth

    I agree with you in principle, but will still point out: A class with a name that just describes the style it applies could still be a shorthand for a style definition that's a lot longer than the class name, or a set of vendor-specific styles or other cross-browser workarounds; so it isn't necessarily entirely without comparative benefit.

Leave a comment on “Classical Design”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article