Do We Need Specificity in CSS? (2015) • Hacker News Board

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

#21

Post by [deleted] » Fri, Apr 17, 2020, 12:34 PM UTC

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.

[deleted]

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

#22

Post by jt2190 » Fri, Apr 17, 2020, 12:34 PM UTC

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?

Not the OP, but what I commonly see are elaborate behaviors by devs to try and avoid dealing with specificity head-on, because it’s so hard to reason about. In my opinion this leads to CSS that is two to three times longer than strictly necessary.

That said, I also believe that CSS was the wrong solution to the wrong job: CSS addresses the DOM, not the UI, and does so with a kind of “multiple inheritance by default” approach, where an element will inherit properties via the cascade from many rules, until a rule that stops the cascade is written. Reasoning about what rules apply to what elements under what conditions becomes an exercise in extreme abstract thinking, and still there is another step to think about what the resulting UI that it will generate will look like. (I’ll leave off browser differences for now.)

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

#23

Post by yohannparis » Fri, Apr 17, 2020, 12:42 PM UTC

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.

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

#24

Post by ChrisMarshallNY » Fri, Apr 17, 2020, 12:49 PM UTC

ZenPsycho wrote: post #20

ChrisMarshallNY wrote: post #19

Earlier quoted context omitted.

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…

I got the point, but I found it a convenient coat hook for my favorite ulster :).

I can certainly agree with you. Some of the dynamically-generated markup can be a nightmare.

"ZenPsycho." Great screen name.

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

#25

Post by [deleted] » Fri, Apr 17, 2020, 12:56 PM UTC

[deleted]

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

#26

Post by ChrisMarshallNY » Fri, Apr 17, 2020, 1:00 PM UTC

jt2190 wrote: post #22

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?

Not the OP, but what I commonly see are elaborate behaviors by devs to try and avoid dealing with specificity head-on, because it’s so hard to reason about. In my opinion this leads to CSS that is two to three times longer than strictly necessary. That said, I also believe that CSS was the wrong solution to the wrong job: CSS addresses the DOM, not the UI, and does so with a kind of “multiple inheritance by default”…

Thankfully, browser differences are reducing to a point near zero, for most "classic" CSS issues. They still have lots of differences in the way they interpret JS, though, as well as some of the newer CSS rules.

I've learned that if I keep my markup and style to "early" CSS3/HTML5, I can create pages that render pretty much the same on all browsers.

It's when I try to get fancy, that things go pear-shaped.

That said, check out CSSPlay (http://www.cssplay.co.uk/menu/). He's been pulling off extreme CSS acrobatics since CSS 1.

Amazing stuff.

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

#27

Post by orange8 » Fri, Apr 17, 2020, 1:56 PM UTC

ZenPsycho wrote: post #20

ChrisMarshallNY wrote: post #19

Earlier quoted context omitted.

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…

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

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

#28

Post by woodrowbarlow » Fri, Apr 17, 2020, 2:00 PM UTC

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

i think the fact that specificity isn't scoped is where it causes problems.

let's say i include a CSS reset, and then include my CSS file. if i put this in my CSS file, suddenly i'm competing (and losing) against an external dependency:

    input { padding: 0.5em; }

if all CSS conflicts were resolved as "last declared wins" (rather than specificity), i feel we'd be a lot better off in terms of organized, maintainable CSS. we'd be breaking things into more files than we do today, but i think "pruning" would be a more approachable task.

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

#29

Post by specialist » Fri, Apr 17, 2020, 2:05 PM UTC

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.

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

#30

Post by marcosdumay » Fri, Apr 17, 2020, 2:06 PM UTC

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…

Ok, just following a tangent, please let's not dismiss scopes as a clutch. They are a fundamental tool of software organization, and every large project that doesn't have scope rules ends up as spaghetti.

The fight from standard bodies against scoped CSS has lead to the current situation where every site's CSS evolves to be a mess where nobody is even sure if the rules are used, but can't delete them.