Overly long/specific css selectors are just as bad or worse than making your styles !important.

Change my mind.

  • 1
  • 3
    😗🎶 bembembembembembembembem bembembembembembembembem bembembembembembembembem
  • 4
    Context. You are trying to style around a third party library that includes css. You need to override these styles to fit a given design.

    Would you rather:

    A) Deal with really long selectors
    B) Deal with !important

    Neither is ideal, but which is worse/harder to work around?
  • 2
    @heyheni I read this to the tune of the 2 & a Half Men theme song
  • 0
    @ElectroMantis selectors because the goddamn third-party-theme already uses !important
  • 1
    .mind-changeable-probably-element {
    stateofmind: changed;
  • 5
    You should have neither of both!

    !important is for exceptional circumstances e.g. with a media breakpoint where you need to reset a property that you had to set via JS in another media breakpoint interval AND don't need JS in the new interval.

    Eerily long CSS selector chains mean that you don't modularise your containers, or that your architecture is bad so that you abuse long chains with their specificity to paper over the crap.
  • 2
    sounds like somebodies trying to edit bootstrap styles... quick, make sure all the guns are unloaded and prescriptions are locked up in the cabinet. Better take his shoelaces too just to be safe 🤔
  • 0
    @M1sf3t Bootstrap is a piece of shit anyway. Like all CSS frameworks.
  • 2
    @M1sf3t Worse, dealing with the Gravity Forms wordpress plugin lol. 🙂🔫

    @Fast-Nop bootstrap is _kinda_ palatable if you strip all the junk out of the library via custom sass imports. Still at that point, you may as well be just making your own grid system.
  • 2
    Here's a tidbit of code found in the library

    .gform_wrapper .top_label li.gfield.gf_left_third div:not(.ginput_container_date) input:not([type=radio]):not([type=checkbox]):not(.ginput_quantity), .gform_wrapper .top_label li.gfield.gf_left_third div:not(.ginput_container_date) select, .gform_wrapper .top_label li.gfield.gf_middle_third div:not(.ginput_container_date) input:not([type=radio]):not([type=checkbox]):not(.ginput_quantity), .gform_wrapper .top_label li.gfield.gf_middle_third div:not(.ginput_container_date) select, .gform_wrapper .top_label li.gfield.gf_right_third div:not(.ginput_container_date) input:not([type=radio]):not([type=checkbox]):not(.ginput_quantity), .gform_wrapper .top_label li.gfield.gf_right_third div:not(.ginput_container_date) select {
    width: 100%!important;

    (just for the record, I think devrant should support markdown)
  • 1
    @ElectroMantis The problem with CSS frameworks is that the whole approach is dead wrong and born out of gross misunderstanding what CSS is even about.

    It litters the HTML with presentational classes like it's 1996 and people still think in terms of HTML3.
  • 1
    @Fast-Nop You would love atomic css /s
  • 0
    @ElectroMantis OMG, even a first look shows the same crap approach. No surprise of course.
  • 0
    @Fast-Nop not that i disagree with you about bootstrap but I mostly quit using it for the general bloat and because I always wound up changing the styles anyway.

    But when you say they all take the same approach what do you mean? Relying on html5 elements for their defaults would mean leaving a lot of the styling to vary between browsers wouldn't it? Or are you talking about something else entirely?
  • 1
    @M1sf3t I'm talking about avoiding presentational garbage classes altogether. Semantic markup. Or, HTML like has always been meant to be. The classnames should not say how shit looks, but what shit is, and use CSS selectors appropriately.
  • 0
    @Fast-Nop ok so your talking about the specific naming convention used for the classes?

    At first i was picturing you only using css for positioning and letting the properties that deal with presentation, like color and border style remain their defaults.
  • 0
    @M1sf3t Uhm, no, not a naming convention. Nothing to do with that. Just one random eyebleacher from the Bootstrap homepage:

    class="col-md-4 p-3 p-md-5 bg-light border border-white"

    The problem is not the naming of the classes. These classes shouldn't even exist!
  • 0
    @Fast-Nop but what would you do concerning the actual css properties that are being used, not use them or write them all into one class?

    that's what I meant by naming convention.
  • 1
    @M1sf3t Naming convention is only about names of things, by definition, and not about their content. That's structure.

    Well, as I already said, the class of an element should say WHAT this element is, and not be concerned AT ALL with how this element will look like. The latter has ZERO business in the markup. Apart from a few div containers for technical reasons, the markup should not be concerned with looks at all. It should be lean.

    And that's another crap aspect of all Bootstrap sites I've seen, the tons of garbage classes ("classitis") go hand in hand with tons of superfluous divs ("divitis") that only exist because of the garbage classes and failing to grasp CSS selectors.

    It's completely failing to understand the whole point of CSS and reverts back to the shitty ways of the 90s, only with lip-service to CSS.
  • 1
    @Fast-Nop ok yea I think I'm following you now. Just wait til you get a glimpse of tailwind, you going to pop a blood vessel.

    A lot of people that are routinely on svelte's discord swear by it because it at least removes some of bloat from the classes, but it can make your html element a mile long in some instances.
  • 0
    @ElectroMantis use bot @highlight
    console.log("It works?!"+1);
  • 0
  • 1
    Next you'll be telling us some nonsense like selector queries evaluate right to left. Who needs to know CSS or compositing rules, or the render pipeline when you can just defer to a library and let the users watch paint dry. 😛
  • 0
    @SortOfTested I have a simple litmus test for that. If all children of a node (typically LIs in a UL) have the same class, the dev needs a smack in his face and fucking read up on selectors.
  • 0
    @Fast-Nop There's a valid case for siblings sharing the same class and that is it is more flexible in allowing you to change the HTML over time without having to re-tweak the CSS.

    E.g. in the screenshot below, the styling for ".accordion" & ".accordion__item" does not need to be adapted in any of the cases, while obviously "ul li" or ".accordion > *" selectors would.
  • 0
    @webketje In that example, you don't need the latter two because the semantics of an accordion is a UL. The latter two seem like garbage anyway.
  • 2
    @webketje Here's why I think it's garbage: screenreaders can properly announce lists with a number of list items if proper semantic markup is used, but they can't do that with an unstructured div soup. So this creates accessibility problems for no good reason.

    "Helping" devs to create inaccessible div soups is an anti-feature IMO, or at least it's a badly chosen example.
  • 1
    @Fast-Nop Agreed the example may be badly chosen, although the point remains valid: more flexibility in restructuring HTML (BEM also prefers class-attached styling).

    I guess context also matters: although I'm keen on using semantic HTML and accessibility, most of the webdevs I meet, and employers I work for don't give a sh*t. It's hard to sell and developer xp usually trumps it.
  • 1
    @webketje Well yeah, that's basically the complementary point to my observation that many frontend devs havn't understood CSS: they havn't understood HTML either.

    Or, as I also frequently say: the average frontend dev is a completely clueless moron.

    And then employers like Domino's wonder why they got sued for their inaccessible trash website and lost (last year). Well, because they have been hiring dipshits to do the job, that's why.
  • 2
    @webketje I want to say that the first lessons I took offered a similar counterpoint as that but I can't quite remember. I can just hear someone coming along and telling me to change it in the back of mind anytime I do use the element itself for the selector. Which has gotten to be more and more common now that I'm writing single page components, I've been waiting for it to bite me in the ass one day.

    @Fast-Nop i think your the only person I've ever heard to say specifically that it actually works better to do it that way.
  • 1
    @M1sf3t That's because I don't start from the visuals, but from the logical structure. I only care about layout once the content is there. The layout must fit the content, not the other way around: content first!
  • 1
    @Fast-Nop thats somethin else that doesn't seem to be to common. I typically find the visual parts more interesting to work with but i can't help but think of the data as I do it.
    Being stuck with platforms that make a mess of the product information is how I got into this in the first place.
  • 0
    @Fast-Nop You got any reading material on this subject, maybe a library that you don't find quite so bad?

    Think I may make an attempt at building a component library in svelte given the lack of current options.
  • 0
    @M1sf3t Actually not - but I did use a lot of LaTeX in my uni years, so I'm used to think of a document as logical structure. It's also a bit like programming where you have to name variables. Only that in HTML the question is "what type of content is this here".

    It also helps if you install NVDA, a free screenreader, and then listen whether your structure makes sense. Plus of course the live checker https://wave.webaim.org/ with regard to structural issues (and contrast for visual ones). I assume that you already validate HTML and CSS via https://validator.w3.org/ .
  • 1
    @Fast-Nop nope, but I will be now.

    Honestly this will be my first big look back into css fundamentals since I first learned them, part of why I want to do it. I got pretty decent with it early on so I've been somewhat ignoring that area while I caught up on some of the newer stuff in javascript.
Add Comment