Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Do We Need Specificity in CSS? (2015)

philipwalton.com

Post reply on HN
Print view View original

11–20 of 53 posts

Re: Do We Need Specificity in CSS? (2015)

#11

Post by tiborsaas »

ChrisMarshallNY wrote: post #9

In my experience, very, very few Web designers actually use specificity (UPDATE: I should have added "properly," as was pointed out) . It works extremely well, if everyone follows the rules , which is uncommon. That goes for most of CSS; not just specificity. CSS is incredibly powerful, if used properly, and specificity, when actually used properly, is very cool. About ten years ago, I wrote this series: https://litt…

I find this really hard to believe. Specificity is baked into CSS at such a fundamental level that you can't not use it. Maybe you meant like they don't use it consciously of effectively?

Re: Do We Need Specificity in CSS? (2015)

#12

Post by tiborsaas »

Using SASS or LESS makes specificity a great tool

    .something { 
         .tells {
              .me {
                  content: 'we do';
              }
         }
    }
If you think of specificity as a kind of inheritance or scoping, then it makes a lot more sense.

Also it's very powerful to extend a generic component:

Framework:

    button.red { background: red; }
User code:

    button.red.disabled { background: grey; }

Re: Do We Need Specificity in CSS? (2015)

#13

Post by ChrisMarshallNY »

tiborsaas wrote: post #11
ChrisMarshallNY wrote: post #9

In my experience, very, very few Web designers actually use specificity (UPDATE: I should have added "properly," as was pointed out) . It works extremely well, if everyone follows the rules , which is uncommon. That goes for most of CSS; not just specificity. CSS is incredibly powerful, if used properly, and specificity, when actually used properly, is very cool. About ten years ago, I wrote this series: https://litt…

I find this really hard to believe. Specificity is baked into CSS at such a fundamental level that you can't not use it. Maybe you meant like they don't use it consciously of effectively?

Fair ‘nuff. People don’t use it consciously, so my statement was not specific enough.

:)

Re: Do We Need Specificity in CSS? (2015)

#14

Post by ZenPsycho »

tiborsaas wrote: post #11
ChrisMarshallNY wrote: post #9

In my experience, very, very few Web designers actually use specificity (UPDATE: I should have added "properly," as was pointed out) . It works extremely well, if everyone follows the rules , which is uncommon. That goes for most of CSS; not just specificity. CSS is incredibly powerful, if used properly, and specificity, when actually used properly, is very cool. About ten years ago, I wrote this series: https://litt…

I find this really hard to believe. Specificity is baked into CSS at such a fundamental level that you can't not use it. Maybe you meant like they don't use it consciously of effectively?

there’s using it deliberately as a tool, and running into it unexpectedly and doing absurd things to work around it like it’s an obstacle to overcome. i see much more of the latter than the former; squarely i think because most css is written by people who don’t know how to use specificity - so they come up with things like BEM, or css in js frameworks to force specificity away like it’s a flaw in the system. all this work goes in because module scope is an easier mental model to grasp than specificity, which i suppose works more like traits. but, having been in this web making game long enough, it seems like a return to table based design and font tags. just with different syntax.

Re: Do We Need Specificity in CSS? (2015)

#15

Post by d_watt »

tiborsaas wrote: post #12

Using SASS or LESS makes specificity a great tool .something { .tells { .me { content: 'we do'; } } } If you think of specificity as a kind of inheritance or scoping, then it makes a lot more sense. Also it's very powerful to extend a generic component: Framework: button.red { background: red; } User code: button.red.disabled { background: grey; }

For me, it's actually the exact opposite. When I use scoping like that, my normal expectation is that I'm saying "Only style .me if it's in a .tells that's in a .something". I'm doing it for selector behavior. I don't want to have to consider if I later scope a

  .something_else { .me: content 'we don't' }
it won't work because it's less specific, meaning cascading isn't working as expected. It isn't SOLID

Re: Do We Need Specificity in CSS? (2015)

#17

Post by ChrisMarshallNY »

tiborsaas wrote: post #11
ChrisMarshallNY wrote: post #9

In my experience, very, very few Web designers actually use specificity (UPDATE: I should have added "properly," as was pointed out) . It works extremely well, if everyone follows the rules , which is uncommon. That goes for most of CSS; not just specificity. CSS is incredibly powerful, if used properly, and specificity, when actually used properly, is very cool. About ten years ago, I wrote this series: https://litt…

I find this really hard to believe. Specificity is baked into CSS at such a fundamental level that you can't not use it. Maybe you meant like they don't use it consciously of effectively?

One of my rules of thumb, is that “!important is FAIL.”

If I find that I need to use the !important modifier, I’m usually being lazy.

Where I do tend to use it, is in print media styles, to force a style over CMS themes, which can be notoriously bad (for example, one of the themes I have used spews out multiple duplicate #ids. When I reported the bug, the response was basically “shrug Sucks to be you.” That was the least of the issues with the theme, and I was forced to use !important a few times).

Re: Do We Need Specificity in CSS? (2015)

#18

Post by CerebralCerb » 

  Specificity isn’t intuitive, and—especially for new developers—the results can often seem like a gotcha rather than the intended behavior. I’m also not sure there’s an equivalent in other systems or languages.
It is widely used as a conflict resolution strategy in production systems. I've never encountered a student who found specificity to be a difficult concept to grasp.

Re: Do We Need Specificity in CSS? (2015)

#19

Post by ChrisMarshallNY »

ZenPsycho wrote: post #14
tiborsaas wrote: post #11

Earlier quoted context omitted.

I find this really hard to believe. Specificity is baked into CSS at such a fundamental level that you can't not use it. Maybe you meant like they don't use it consciously of effectively?

there’s using it deliberately as a tool, and running into it unexpectedly and doing absurd things to work around it like it’s an obstacle to overcome. i see much more of the latter than the former; squarely i think because most css is written by people who don’t know how to use specificity - so they come up with things like BEM, or css in js frameworks to force specificity away like it’s a flaw in the system. all thi…

People have been freaking out about table-based design for twenty years. It’s a great foil, and much of the criticism is merited, but it’s not the end of the world.

You can fairly easily turn tables into blocks: https://littlegreenviper.com/miscellany/stylist/another-reas...

Also, I use “display: table” all the time in my work. It’s the best mode for layout that fits content.

Re: Do We Need Specificity in CSS? (2015)

#20

Post by ZenPsycho »

ChrisMarshallNY wrote: post #19
ZenPsycho wrote: post #14

Earlier quoted context omitted.

there’s using it deliberately as a tool, and running into it unexpectedly and doing absurd things to work around it like it’s an obstacle to overcome. i see much more of the latter than the former; squarely i think because most css is written by people who don’t know how to use specificity - so they come up with things like BEM, or css in js frameworks to force specificity away like it’s a flaw in the system. all thi…

People have been freaking out about table-based design for twenty years. It’s a great foil, and much of the criticism is merited, but it’s not the end of the world. You can fairly easily turn tables into blocks: https://littlegreenviper.com/miscellany/stylist/another-reas... Also, I use “display: table” all the time in my work. It’s the best mode for layout that fits content.

you’re kind of missing my point. which is fine because i didn’t spend a whole lot of words explaining it.

i am not saying table based design is bad. but we did originally move away from it for legitimate reasons that seem to have been largely forgotten, and as a result we now have developers who build json theme files and react frameworks that wire “darkmode=true” individually through every component instead of just using css for what it was designed to do: to exactly be a theme configuration format.

a lot of where things have gone wrong is CSS started to be used for layout, which was originally a hack, abusing the float property to do things it was never designed to do. and css has never gotten good at it, because fundamentally layout is about relationships between elements, while CSS is stuck only ever specifying properties ON elements. sure we have display table, flexbox and css grid, but css is an incredibly awkward and unnatural way to express those concepts. app frameworks deal with layout seperately from colors and fonts, which is how it should be done. and so this is why it’s all hacks and workarounds in css land. it doesn’t have to be this way. but it’s how it is.

Post reply on HN