Hacker News Reader

Comment by daylightsavings | Hacker News Reader

Firstly, job well done. Secondly, what is the motivation of going pure CSS aside from the challenge of it?

I once prefered Pure CSS stuff until I learned Javascript myself. Now I've come to loathe that approach on complex menus and widgets.

Mainly I dislike using them because I have to refactor them to use Javascript so they can be stateful (reacting to an active category or something indicated by the url or querystrings, etc.

Again, good job though if it's just for the lulz.

View on HN

It seems to me, many web developers today don't even realize, that creating features without js and enriching the experience from that baseline, not only enhances performance and accessibility, but in the end is often not more work and might even lead to cleaner, leaner code. I guess in the end it just comes down to which tools one learned first and based on that which approach one takes to solve the problem at hand.

I can only encourage everyone that thinks js is the catch-all solution to dive a bit deeper into html&css and try out alternate solutions. It's worth it for the knowledge gain in itself but offers many other benefits.

css is often the slowest part of a webapp. complex css like this is not necessarily better accessibility-wise than javascipt

Why complex? Sure, this example is somewhat complex, but it does not need to be. Structure the menu in nested ul's, add simple hover css and don't use "display: none;" but rather "position: absolute; left: -999em;" and you get simple css and a good html structure that a screen reader for example can read easily and which also is clear to read if you turn css off entirely.

Of course, small hover menus offer their own accessibility challenges, but they don't depend on the way they are implemented but rather the choice of UX. And no reason why you could not improve this simple css menu with some js to make it more user friendly (like turning hover into clicks etc.)

Do you have some proof to back this? CSS matching is incredibly fast.

For one, many people prefer to browse websites with javascript turned off. Aside from performance benefits, you turn off user tracking, flashy ads, autoplay videos, annoying popovers, etc.

MANY people? Source?

zero people block JS: false

only one person blocks JS: false

therefore many block JS

"Many" is not synonymous with "multiple".

I would expect that the percentage of people who browse without javascript on is incredibly small. The absolute number might be largish, and I guess in that context is could be considered "many."

Still, the vast majority use javascript.

Haven't you studied cardinality? You don't have One to Multiple relationships, you have One to Many /s

Between zero or all, could be many or some.

Or perhaps "few".

Most "stateful" functionality (including all you mentioned) can still be done with a CSS driven drop down menu.

Could this be handled by a templating engine like handlebars?

> Mainly I dislike using them because I have to refactor them to use Javascript so they can be stateful

You shouldn't need to refactor anything done in HTML or CSS to add JS-driven statefulness. This is what's great about using JS: it's power allows it to wrap/augment existing functionality quite flexibly.

Reply on news.ycombinator.com