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

31–40 of 53 posts

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

#31

Post by woodrowbarlow »

d_watt wrote: post #15
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

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

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

#32

Post by ZenPsycho »

orange8 wrote: post #27
ZenPsycho wrote: post #20

Earlier quoted context omitted.

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…

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

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

#33

Post by davidkpiano »

ryannevius wrote: post #2

A rebuttal: https://codepen.io/davidkpiano/post/the-simplicity-of-specif...

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.

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

#35

Post by orange8 »

ZenPsycho wrote: post #32
orange8 wrote: post #27

Earlier quoted context omitted.

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

“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 thin…

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

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

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

#36

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

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

#37

Post by ZenPsycho »

orange8 wrote: post #35
ZenPsycho wrote: post #32

Earlier quoted context omitted.

“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 thin…

> “float” and “normal” (what?) aren’t layout modes. 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 brows…

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 with regard to keeping non layout elements consistent, and that page in turn, which makes no reference to layout.

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

#38

Post by andrei_says_ »

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…

BEM I think comes from choice to aggressively reduce complexity, not from ignorance.

Sprinkled with a tiny bit of specificity classes for state, it combines best of both worlds.

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

#39

Post by ZenPsycho »

andrei_says_ wrote: post #38
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…

BEM I think comes from choice to aggressively reduce complexity, not from ignorance. Sprinkled with a tiny bit of specificity classes for state, it combines best of both worlds.

then why is BEM more complex than just plain CSS? if the idea is to reduce complexity, that’s a giant fail.

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

#40

Post by ZenPsycho »

marcosdumay wrote: post #30
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…

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.

all I said was that scoping is an easier mental model than specificity. i am not saying that is a bad thing. but i can see how it would seem that way since a lot of programmers, whether they realise it or not, aggressively look down on things that are easy. so it’s essy to assume that when i say something is easier, i am implying it’s bad or weak, but i assure you i don’t mean that.
Post reply on HN