
Do We Need Specificity in CSS? (2015) - edjroot
https://philipwalton.com/articles/do-we-actually-need-specificity-in-css/
======
yohannparis
I feel like this article is just another: "CSS is hard, and instead of
learning, use this clever method that works for me."

Maybe I'm just old school because I learned CSS2 by reading the docs, and not
as CSS in JS.

~~~
HelloNurse
Not only approaching the "problem" of learning CSS by eliminating things to
learn, but starting from bad assumptions (e.g. that combining stylesheets is a
problem and not a solution) and never questioning them.

------
ryannevius
A rebuttal: [https://codepen.io/davidkpiano/post/the-simplicity-of-
specif...](https://codepen.io/davidkpiano/post/the-simplicity-of-specificity)

~~~
davidkpiano
Oh wow, I barely remember writing this 4+ years ago!

I still hold to it - specificity is a necessary mechanism, and if it's hard,
it's because we're unnecessarily over-complicating it, just like anything else
considered "hard" if we misuse it.

------
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; }

~~~
d_watt
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

~~~
woodrowbarlow
exactly. more specific selectors are edge cases, which is a usually-acceptable
heuristic for rule priority but doesn't correspond 1:1.

------
mehrdadn
Warnings seem like the way to go for this? i.e. having a static analyzer to
check that the specificity matches the declaration order. (Assuming that's
possible... it's not obvious to me if there are theoretical roadblocks.)

~~~
stefanfisk
Stylelint actually has this already! [https://stylelint.io/user-
guide/rules/no-descending-specific...](https://stylelint.io/user-
guide/rules/no-descending-specificity)

------
calibas
I maintain sites with thousands of CSS rules and over a dozen style sheets,
some of which are hosted on external domains that I have no control over.
Having to manage CSS rules based upon order would be a nightmare.

It does seem that specificity isn't well understood, as I often see people
abusing !important.

~~~
cryptica
Agreed.

The article claims that "Importance also makes a lot of sense" but actually,
the way it was implemented in CSS makes no sense because eventually, given a
sufficiently old stylesheet, all styles end up being marked with !important
and then you're back to relying on source-ordering.

------
bestest
Specificity and cascading become redundant once we talk css modules. I work
with CSS modules so I can't remember the last time I had to_ cascade_ style
sheets, or _think_ about specificity.

------
ChrisMarshallNY
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://littlegreenviper.com/miscellany/stylist/introduction...](https://littlegreenviper.com/miscellany/stylist/introduction-
to-specificity/)

It’s still absolutely relevant nowadays, and just as few people follow that
workflow now, as they did then.

CSS, in general, is too complicated (IMNSHO), but that complexity is also what
makes it so powerful.

I’ve always enjoyed Stu Nicholls’ CSSPlay site, for examples of extreme CSS:
[http://www.cssplay.co.uk/menu/](http://www.cssplay.co.uk/menu/)

~~~
tiborsaas
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?

~~~
ZenPsycho
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.

~~~
ChrisMarshallNY
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...](https://littlegreenviper.com/miscellany/stylist/another-reason-to-
use-table-based-layout/#dont-tell-mom)

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

~~~
ZenPsycho
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.

~~~
orange8
> a lot of where things have gone wrong is CSS started to be used for layout

The layout is part and parcel of the style. CSS gives you 7 different layout
modes to choose from (normal, table, float, positioned, multi-column, flex and
grid). There is more than enough here to implement any sort of layout problem
you face, from using 15 year old table and flex hacks to cleaner modern
approaches like flex.

> while CSS is stuck only ever specifying properties ON elements

The "position: relative" (CSS1), float and flex are all about positioning
elements relative to one another. Other properties like margin, align and
float are also about positioning items relative to one another.

> but css is an incredibly awkward and unnatural way to express those concepts

I think CSS is pretty easy and straightforward to reason about, once you
decide that it is worth investing some time and effort in learning. It really
always surprises me how some really smart people just do not get CSS, and I
think it is not about ability, but attitude. CSS is dismissed as "that thing
for designers", and calling CSS a programming language is usually met with
smirks. That is the real problem with CSS, its reputation.

~~~
ZenPsycho
“float” and “normal” (what?) aren’t layout modes. the rest didn’t exist in css
until relatively recently. postion: relative exists, yes, but it doesn’t do
what you say it does. - it sets the top, left, bottom and right properties to
be relative _its own_ natural position. it doesn’t specify any relationship to
any other element. the other properties you say specify layout relative other
elements- don’t do what you think they do either. align and margin only
effects an element’s content, margin only refers to other elements in edge
cases, and float was only ever supposed to let you embed figures that text
would wraparound. it’s use for layout was an abuse and not what it was
designed for. Though i can see how it can seem like those elements seem like
they refer to other elements, but that is just a consequence of the properties
interacting with the document flow algorithm, which is there with or without
css.

while css now does have real layout modules: flexbox and grid, CSS wasn’t
designed for layout and it just isn’t very good at it, especially if you
compare it to say, cocoa autolayout, or the flexbox model in UI frameworks
that were designed to do this stuff at the start instesd of having it
awkwardly bolted on. and just what is document flow? is it a layout algorithm?
no, it’s a greedy word wrap algorithm applied to boxes. that’s it.

finally, 15 year old display: table and flex hacks? what are you smoking. ie8
was released in 2009 and didn’t uproot ie6 and ie7 until many years later. i
had to have fallbacks for ie7 up to 2015. flex only became _usable_ after
2015. it existed before that but not in _all the browsers_.

the closest thing in css to what I am talking about is position:absolute,
which implicitly refers an element to its nearest parent with either position
relative or position absolute. i don’t get to identify which element or
elements i would like to refer to directly.

the only other thing is percentage unit which refers to a percentage of the
paren’s width or height depending on which property it appears in- which was
annoying enough they almost fixed it with vw and vh units which refer
specifically to width and height of the _viewport_ , but if i want a
proportion of any other element’s dinensions my option is to use javascript or
eat a bag of donkeys.

~~~
orange8
> “float” and “normal” (what?) aren’t layout modes.

[https://developer.mozilla.org/en-
US/docs/Web/CSS/Layout_mode](https://developer.mozilla.org/en-
US/docs/Web/CSS/Layout_mode)

> the rest didn’t exist in css until relatively recently.

Out of the 7 layout modes, only the last two came into existence recently. The
point is, when CSS was being designed as a declarative, domain specific
programming language, it was designed to handle EVERYTHING to do with how
things appear on a browser. Even when you specify styles using JS or directly
in HTML, those are simple handed over to the browsers CSS engine. The HTML
engine deals with markup, while the JS engine deals with behavior. If you want
to talk directly and powerfully to the CSS engine, use CSS. That what it was
designed to handle: everything to do with what you SEE in a browsers screen.

> position: relative exists, yes, but it doesn’t do what you say it does. - it
> sets the top, left, bottom and right properties to be relative its own
> natural position.

If I want to position elements absolutely within a container element, one way
is to have the container "position: relative" and the child elements
"position: absolute". The same effect can be achieved via flex or grid
layouts.

> it’s use for layout was an abuse and not what it was designed for.

I am honestly flabbergasted by this assertion. The layout of something is part
of its style. See
[https://en.wikipedia.org/wiki/Visual_design_elements_and_pri...](https://en.wikipedia.org/wiki/Visual_design_elements_and_principles)
CSS was designed to handle all that. Layout is all about shape, space and
form.

> CSS wasn’t designed for layout and it just isn’t very good at it, especially
> if you compare it to say, cocoa autolayout, or the flexbox model in UI
> frameworks that were designed to do this stuff at the start instead of
> having it awkwardly bolted on.

Whenever anyone dumps on CSS, HTML and JS, I simply remind them that they run
the web, and the web is the most successful, open, flexible and used platform
in existence. CSS is doing exactly what it was designed to do, and will
outlive and outperform all those UI frameworks as it breaks out of the browser
into desktop and mobile app space.

~~~
ZenPsycho
look, i love CSS. Not dumping on it. but you have a bit of stockholme syndrome
going on here. sometimes loving something means realistically looking at its
flaws and limitations. and you seem to have a distorted view of history, and
what a “stylesheet” is. (they existed for decades before CSS was invented, and
come from the tradition of printing and writing, not design so much. they do
not, generally speaking, specify layout. layout specifies layout.) from the
start, browsers didn’t have a css engine. css was added _later_ , and has
never fully exposed every piece of the browser display engine. some of the
browsers needed to be rewritten from scratch for this to even be possible. as
for layout, from the start and for a very long rime, the position of the w3c
and browser authors is that website authors _shouldn’t want_ layout and
refused to implement any layout capabilities. in their view, layout should be
left up to the client, and a website author should focus only on writing plain
semantic documents. they told people to stop using floats for layout because
it got in the way of client decisions about layout. they have only been added
grudgingly, and after the forced removal of the people who were blocking it. i
for one welcome these layout capabilities, and am glad the old farts didn’t
get in the way. that doesn’t mean we’re up to par with the best layout engines
though.

your link makes only one reference to style: “style of shape”, and a passing
reference to
[https://en.m.wikipedia.org/wiki/Style_guide](https://en.m.wikipedia.org/wiki/Style_guide)
with regard to keeping non layout elements consistent, and that page in turn,
which makes no reference to layout.

~~~
orange8
> look, i love CSS. Not dumping on it. but you have a bit of stockholme
> syndrome going on here. sometimes loving something means realistically
> looking at its flaws and limitations.

I find that very hard to believe, sorry. And I could write a whole book about
the flaws and limitations of CSS, and then another about its elegant power and
gradual evolution over the years, but you most likely wont want to read it.
You are stuck in 2002, completly fixated about the origins or the languange
and what it was meant or not meant to do 20 years ago.

> and you seem to have a distorted view of history, and what a “stylesheet”
> is.

Right now, I am honestly not interested in the semantic meaning of the word
"stylesheet" or its etymology, or the history of computing and printing. Am
here to discuss CSS.

> from the start, browsers didn’t have a css engine. css was added later, and
> has never fully exposed every piece of the browser display engine.

Is this not obvious? A browser is made of three main engines JS, CSS and HTML.
Being a GUI, all parts will influence the GUI. That does not change the fact
that the CSS engines domain is what you see. The JS domain is interactivity
(what you do with what you see) while HTML is about data and structure.

> some of the browsers needed to be rewritten from scratch for this to even be
> possible.

Can you name even one thing in computing that's over 20 years and has not
changed or evolved? If your problem with CSS is that browsers had to be
rewritten 20 years ago to evolve with the language, then that problem applies
to every other successful language and GUI framework or system under the sun.

> website author should focus only on writing plain semantic documents. they
> have only been added grudgingly, and after the forced removal of the people
> who were blocking it.

Semantic documents are under the domain of HTML. This has nothing to do with
CSS.

------
amflare
I feel like source order should be the thing that is done away with.
Specificity allows me to style something, and trust that style will style
correctly no matter what my build system does, or what order my stylesheets
load, or what my co-worker adds later for their fancy new CTA button.

------
specialist
Nice.

Facepalm slap. Just like other matching algorithms. How did I not notice that
earlier?

Order independent specificity is like longest match rules. Regex, lexing, URL
routers, etc.

Order dependent matching overrides (correct phrase?) is like Packrat & PEG.

Which is better depends on ambiguity, meaning how well your "matcher"
algorithm can process whatever input you have.

I've done my fair share of scraping. (I usually default to my own globbing
implementation. Generally more simple than xpath or css expressions.) Now I'm
feeling pretty stupid that I'd always hard-coded precedence resolution.

------
Etheryte
While this is an interesting thought experiment, and the outlined problem is a
real issue, I don't think the outlined solution is a good way to resolve it.
The main problem here is predictability: maybe it's simply that I'm not used
to thinking about CSS this way, but the proposed CSS rewriting parser means
it's not immediately obvious how what I write maps to the end result.

It's entirely possible that I'm missing some of the benefit here, but it seems
to me that scoped styles etc largely already solve this problem.

------
dwd
The simple solution is delete before you add more specificity. Cut it back to
the common denominator and cascade from there.

Of course, you can sometimes inherit a system that is one big specificity
mess.

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

------
atrilumen
I really admire [http://tachyons.io](http://tachyons.io), with its principles
of _shallow cascade_ and _low specificity_.

( It really sucks to have to jump in and work with some project's massive blob
of vestigial, conflicting styles. )

------
z3t4
I always write the specificity in the same order as the cascade. Could
probably write a tool that compares the specificity vs the cascade to find
errors!

There is however a small problem if you want to use many CSS files - that you
need to link them in the correct order.

edit: Also I don't use ID's in CSS.

------
timwis
But what if you put your styles in multiple files?

