Live data from Hacker News

Do We Need Specificity in CSS? (2015)

philipwalton.com

41–50 of 53 posts

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

#41

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.

Have you worked much with mid-00's era table layouts?

There was a book written in the late 90s, which presented a method that allowed people to take a document generated in a graphics program like MM Fireworks (IIRC) and then use table rows/columns to cut up that image and create layout with more varieties of graphical elements (like using a "corner" GIF to create a rounded box).

That markup, while very useful for creating "neat" looks, was incredibly difficult to modify once it was built.

But, specifically, that's what people are railing against when they "freak out" about tables as a layout tool... not using tables for tabular data (which is, of course, just fine unless you need to reflow stuff based on screen width).

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

#42
post #35

Earlier quoted context omitted.

> “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, specif…

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

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

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

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

#44

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.

Have you worked much with mid-00's era table layouts? There was a book written in the late 90s, which presented a method that allowed people to take a document generated in a graphics program like MM Fireworks (IIRC) and then use table rows/columns to cut up that image and create layout with more varieties of graphical elements (like using a "corner" GIF to create a rounded box). That markup, while very useful for cr…

the one positive thing about table based design, is you could code a module, and just echo it out anywhere you wanted it with say, php or coldfusion, and it would mostly just work. transplanting a chunk of semantic html to a site with a different stylesheet though, if you wanted it to look the same, requires some forward planning. that is, it needs to be designed as a component, its css js and html all moved together in lockstep. and if you’re trying to be a good pure citizen, they’re in three different files and you wcho them out into the head, foot and body in turn, being careful that the js appears after anything it depends on. it would be easier to just inline the css and js and echo it all out at once, hut that will make hixie sad. and so it seems sometimes you want self contained components with all their batteries included. sometimes you want to control certain aspects of appearance in some central location so it’s easy to keep everything looking consistent. it’s not always obvious how to find the balance.

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

#45

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…

Not so sure that “last declaration wins” would be great — a very specific example: jupyter notebooks (used to?) add custom.css before the original stylesheet. It’d be impossible if that were the case, I guess?

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

#46
post #43

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.

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.

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

#47

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.

Have you worked much with mid-00's era table layouts? There was a book written in the late 90s, which presented a method that allowed people to take a document generated in a graphics program like MM Fireworks (IIRC) and then use table rows/columns to cut up that image and create layout with more varieties of graphical elements (like using a "corner" GIF to create a rounded box). That markup, while very useful for cr…

> Have you worked much with mid-00's era table layouts?

Umm... I've been designing Web sites since the mid-'90s. I used to do that very thing.

It is my shame (actually, I have many marks of shame, but we'll pretend I have just the one, for now).

That said, I also figured out how to make these "boxes" extremely flexible. I write about that in one of the links that I mentioned (https://littlegreenviper.com/miscellany/stylist/another-reas...). In that article, I describe both a "fixed," div-based "framed" table, and a flexible one; based on archaic table layout.

One advantage of having worked on sites back then (and there weren't many advantages), was that the browsers were radically different from each other, and Web designers learned to make sites that could maintain presentation in many different browsers. We generally had to do it by hand, as there wasn't really much in the way of libraries, or even prior art. We had to make it up as we went along.

I know, I know..."OK, Boomer." But it was quite helpful in understanding what was going on at the base level, and those lessons carry forward to this day.

I am not a professional Web designer. I make my own sites, and a couple of ones for NPOs, but they aren't fancy, and won't help anyone win "Buzzword Bingo." They just work fairly well, and are quite responsive.

EDITED TO ADD: You are probably thinking about this book, which became the bane of modern Web designers by the mid-oughties: https://books.google.com/books/about/Creating_Killer_Web_Sit...

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

#48

Earlier quoted context omitted.

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…

Not so sure that “last declaration wins” would be great — a very specific example: jupyter notebooks (used to?) add custom.css before the original stylesheet. It’d be impossible if that were the case, I guess?

why? custom.css would still be loaded, just that if any rules conflict between the two, the original stylesheet would win.

if custom.css makes some text bold and red, and then a second stylesheet comes along and makes the text blue, the final text would be bold and blue.

but with CSS specificity defining priority, whether the text is blue or red depends on which file has the gnarliest, most complicated selector.

custom.css could be put after the original instead of before if you want the custom rules to win.

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

#49

Earlier quoted context omitted.

Not so sure that “last declaration wins” would be great — a very specific example: jupyter notebooks (used to?) add custom.css before the original stylesheet. It’d be impossible if that were the case, I guess?

why? custom.css would still be loaded, just that if any rules conflict between the two, the original stylesheet would win. if custom.css makes some text bold and red, and then a second stylesheet comes along and makes the text blue, the final text would be bold and blue. but with CSS specificity defining priority, whether the text is blue or red depends on which file has the gnarliest, most complicated selector. cust…

Ah, thanks for the explanation -- I thought that you meant that custom.css would be disregarded, now I see you meant that css _rules_ should use "last declaration wins".

Not really a followup on my previous question: what would be done if, say one can't change the order: so custom.css is still before original css. In such cases, without the specificity rule, wouldn't the only option we'd have is to somehow inline the styles, or spray !important everywhere?

To be clear, I only ever did this once for jupyter, and using very specific selectors was the only way I could do it -- of course I learned it hard way why this approach isn't great when jupyter changed the layout slightly. :)

If you're curious, https://github.com/prashnts/dotfiles/blob/0a2e98a848a98b7010... is that custom.css

Post reply on HN