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

My favourite 3 lines of CSS

andy-bell.co.uk

Post reply on HN
Print view View original

81–87 of 87 posts

Re: My favourite 3 lines of CSS

#81

Post by ironmagma »

the_other wrote: post #80
ironmagma wrote: post #68

Earlier quoted context omitted.

In response to "How would you do it otherwise?", like I said, it kind of seems like the language is just what it has to be in order to be workable. In other words, it seems like it designed itself to some extent. And you're right, CSS has practicality. But with almost any pre-built solution, those selectors would look something like `button.cta.xl-2-large:not(:is(.container > .button))`. At that level of complexity,…

I detect a pungent "code smell", and probably a design bug via your example selector. Does the designer really want such a specific edge case to an edge case? Can they explain or justify it according to the design patterns they laid down? Why are we using such a general ".container" to specify a ".button", and whilst we're at it why do we have a "button" AND a ".button". Our codebase was going off the rails long befo…

I think the issue is that CSS is somewhere between unopinionated and encouraging complexity. Is that the best kind of selector? Certainly not, but in Bootstrap, one of the most widely-used CSS packages, it was trivial to find a similar one: `.table-striped-columns > :not(caption) > tr > :nth-child(even) `, so it definitely happens a lot.

Also a lot of it comes down to the original plan to have semantic HTML, which ultimately failed. But we rarely talk about whether semantic CSS is possible, I think the assumption is that it is. But IMO it's not practical because of the poor specificity controls. That's something I'd do different, add in a manual specificity level (like how z-index has manual weights).

Re: My favourite 3 lines of CSS

#83

Post by ironmagma »

kenmorechalfant wrote: post #82
ironmagma wrote: post #3

It’s amazing that CSS has such advanced features that can do these things, but at the same time if you actually use them extensively and then I inherit your code, you kind of deserve a knifing.

How is ".stack > * + *" advanced? This is CSS 101.

I was more referring to margin-block-start, var (with two arguments), gap... Also, no, sibling selector wasn't really supported very well until 2012, so only in the last ~30% of CSS's lifetime.

Re: My favourite 3 lines of CSS

#84

Post by jraph »

xigoi wrote: post #72
jraph wrote: post #48

Earlier quoted context omitted.

> avoid using * selector as much as possible in my CSS So do I, I am somehow wired to think "* is going to be very bad for performance because now the rendering engine will need to apply this bunch of rules to any and every element on earth, which might not be only overkill, but which also might have undesirable side effect." It might not really apply here but the feeling is present.

:not applies to almost every element, so it's not any better.

very true indeed!

Re: My favourite 3 lines of CSS

#85

Post by alwillis »

lelanthran wrote: post #47
alwillis wrote: post #33

Earlier quoted context omitted.

> I am increasingly worried about the “smart” CSS solutions. I'm not worried. > The spec is already huge, the selectors are hard to read and google, the interplay between various features is devilishly complex. Actually things are getting less complex due the fact we don't need to use all of the hacks, work-arounds and polyfills that were once just what pretty much every web developer did not that long ago. And of co…

> And of course, the original sin of the misuse of HTML tables for layout. Hardly a sin - there were no alternatives at the time (1996 - 1998) if you wanted a tabular or grid layout.

Sure, but developers continued to use tables long after there were alternatives.

The first edition of Zeldman’s seminal book Designing with Web Standards [1] was released in 2003; two additional editions were released in 2007 and 2009.

[1]: https://en.wikipedia.org/wiki/Designing_with_Web_Standards

Re: My favourite 3 lines of CSS

#86

Post by the_other »

ironmagma wrote: post #81
the_other wrote: post #80

Earlier quoted context omitted.

I detect a pungent "code smell", and probably a design bug via your example selector. Does the designer really want such a specific edge case to an edge case? Can they explain or justify it according to the design patterns they laid down? Why are we using such a general ".container" to specify a ".button", and whilst we're at it why do we have a "button" AND a ".button". Our codebase was going off the rails long befo…

I think the issue is that CSS is somewhere between unopinionated and encouraging complexity. Is that the best kind of selector? Certainly not, but in Bootstrap, one of the most widely-used CSS packages, it was trivial to find a similar one: `.table-striped-columns > :not(caption) > tr > :nth-child(even) `, so it definitely happens a lot. Also a lot of it comes down to the original plan to have semantic HTML, which ul…

I don't see so many problems with that Bootstrap selector. It's long, but right from the first class to the final element selector it's fairly obvious why that clause exists. In fact, the left-most one explains all the rest: from reading it, I can tell what it does and _why_ it's that long. Your earlier example, much less so.

> the original plan to have semantic HTML, which ultimately failed

I feel that browser developers still build browsers with this in mind. You can see this expressed in the default ARIA roles, for example. I feel that developers of large web apps are the ones who aren't thinking about the semantics the right way and who think semantic HTML has failed. It didn't, they gave up trying to use it. Most of us think only in terms of using JS to render anonymous boxes, rather than about outputting an implementation of an underlying information design. Browsers and HTML still supports that very well. We're wrapping all the conceptual design up into JS and components, and treating the HTML + CSS as some kind of dumb output... when in fact that's the browser's job, and it hides that dumb render from us on purpose. If you use your web framework to output an expressive information design, the browser will render it just fine and more of your code will make sense (IMO).

I don't think you gain much from allowing manual specificity. No-one finds managing z-indexes easy. In fact, I think manual specificity would accentuate the problems we already have. You can fix most z-index issues by not using it, because the stacking is mostly handled already for you by the browser. Imagine trying to find the "specificity 203" in your codebase, or to establish a pattern for which disparate Thing A on the page is the same specificity as a Thing B. It'd be harder than the current system, I"m sure.

Re: My favourite 3 lines of CSS

#87

Post by jraph »

irrational wrote: post #78
jraph wrote: post #21

Earlier quoted context omitted.

Of all the JS features you are picking the arrow function? Is it the syntax, or the this binding thing that works differently than function expressions / statements you are complaining about? Because the syntax looks somewhat like the function notation in math, and a variation of it is also present in many programming languages, often functional, but also Java since version 8. It's quite widespread and not very bizar…

The syntax. I don’t see how prior use in mathematics or other languages has any bearing. JavaScript could have led the way by using a clear syntax instead of perpetuating complexity.

> how prior use in mathematics or other languages has any bearing

It counts, because it makes it familiar to many people.

Had JS introduced this syntax without it being anywhere else I would be completely with you: it would just be weird and unnecessarily complicated.

I find this syntax very clear too (though I still prefer function () { ... } for most functions). It has the merit to make some code using small functions, often somewhat functional, lighter to read. But this is a matter of taste, of course.

Post reply on HN