Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I've always found CSS infuriating to use when working with it (albeit not often). This looks like a clean and easy to follow course so will be one for me to look at over the weekend.


I think most web users wished web devs understood CSS better (even if they don't know what it is.) I'd be willing to bet half the stuff things like React are used to do could be accomplished much better with a small amount of CSS and probably no javascript at all.


I’ve seen this more times than I can count…

A lot of people think of CSS as if it’s not code itself. Modularize it and create patterns like you would for any other piece of code(ie. react components), and it becomes fairly straight-forward to do things that would normally take 100+ lines of code in JS, in just a fraction of the time and code.


Could you give an example? (not trolling - genuinely would like to see where the Venn Diagram between framework and CSS lie)


Animations, even 3d ones, drop-down, sliders, static scroll elements, are often implemented on horrible js with bad performance and accessibility, while trival with a small amount of css.


Sadly, the trivial CSS solutions are often not supported by some browsers that a lot of people use (apart from the obvious IE, Safari on both Mac and iOS is possibly the worst offender for this), making the godawful JavaScript solutions a tragic necessity.


lmao Safari is just fine


Safari is the bain of my existence and owes me money for the sheer amount of time I’ve had to invest in working around their god awful css and svg engines. PWA my a*.


That's fine, I didn't think you were trolling. But I'm not sure what are you an asking an example for? Do you want me to write up a comparison or just tell you some cases where HTML/CSS is lighter than JS? I'd honestly just recommend building a flashy animation primarily with Javascript and then try and build it using only HTML/CSS. Most of the time it will be easier and more readable to go with the latter, as well as more performant and likely to stand up to the test of time.

There are definitely a lot of times where Javascript makes sense, but what I really just wanted to point out is that people usually default to 'Well I'm already writing tons of Javascript, I may as well write more!' as an excuse to create simple animations or transitions with dozens, or hundreds of lines of code, or bringing in a dozen external dependencies to handle it that also break in weird ways. I'm definitely not a NoJS zealot either -- I've been working primarily with React code full-time in production systems since 2014. But over time I've found CSS to be far more pleasant and faster to work with than testing, maintaining, and/or relying on someone else to do the same thing in JS.


I wish you were right, but this is unfortunately wrong – and it's not because developers don't know CSS well enough, but rather that CSS is just plain not good enough. And ridiculous new features keep being added to it when we still don't even have some of the necessary primitives that should be there.

As an example, one of the most basic components I can think of is an accordion. You simply can't make one that works in a visually pleasing way (the way most people would expect!) in CSS because you can't animate to or from `height: auto`. The best you can do is some cop-out technique of fading out or squishing the content with `transform` and then having the content that follows it do an immediate jump up/down.

Instead, animating an accordion that actually animates the layout around it smoothly absolutely does require JavaScript, to tell CSS what non-auto values it needs to animate to and from.

And that's just the most basic component I can think of!

Another example: anchoring one element to another, when those elements don't have a parent-child relationship. Think tooltips. This requires JavaScript to measure the anchor element's position on every goddamn frame and keep the other one in sync, when the layout engine already has all the necessary information and could easily be built into CSS.


The implication here seems to be "when using HTML semantically", because I think everything you're talking about can be done with CSS if you're willing to abuse HTML.

Take this CSS accordion which uses hidden form elements: https://codepen.io/raubaca/pen/PZzpVe

I agree that if you want to use HTML semantically *and* have intuitive UX/UI, you're very limited in what you can do without Javascript, but this isn't *just* a failing of CSS; rather, I think it's due to the design of HTML and CSS historically being to the exclusion of the other, rather than with a symbiotic relationship in mind. Go far enough back into the history of web standards and it kind of makes sense though; HTML and precursors had been in development for years before CSS was standardized


I appreciate the semantics angle but I don't think it's actually related; semantics are a separate issue.

The reason the animation appears to work in the example you link to doesn't actually have anything to do with the form elements or semantics – rather, it's cheating by animating the `max-height` of the tab content from `0` to `100vh`.

This can be done just as easily without all the form stuff, but it's a bad solution to the accordion animation problem, because (1) it assumes that accordion content will never exceed the height of the viewport (what about on phones in landscape mode? you're only talking a few hundred pixels there), and (2) CSS will ease between the actual minimum and maximum values without regard for where the element's true height actually stops changing, i.e. it will animate from 0 to 100vh in the duration requested even if the height only ended up being like 20px and thus visually stops changing 5% of the way into the transition – so whatever duration and easing you specified isn't actually being rendered in the way that you wanted. If you specified an `ease-out` for example (starts fast, slows down at the end), you'd just get a super fast linear-looking transition that ends much quicker than you planned and never has the slow easing at the end (because CSS is actually still transitioning the `max-height` property which is no longer having any effect on your element that's much shorter than the max-height).


>accordion. You simply can't make one that works in a visually pleasing way

Well yeah, you can't do it in pure CSS because you can't do most things in pure CSS. The HTML element you're looking for is "details." (this seems to be one a lot of react people miss.)


I'm well aware of details (I use it in GitHub READMEs frequently), but you still can't animate it like I described – without that, no designer is ever going to want you to actually use it. Builtin elements are worth fuck all if they don't meet your requirements!

You a moment ago:

> half the stuff things like React are used to do could be accomplished much better with a small amount of CSS

you now:

> yeah, you can't do it in pure CSS because you can't do most things in pure CSS


I've gone down that rabbit hole of pure-CSS components, frankly its a worse maintainable nightmare than using JS where appropriate.


Admittedly I’ve never been very good with CSS particularly the “newer” layout stuff I’ve never really used or learned.

That being said I’d rather use CSS than the abomination used for styling in WPF.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: