6 ms·
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 Javas
by daylightsavings 8y ago
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.
- mavidser 8y agoFor 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.
- jrochkind1 8y agoMANY people? Source?
- sincerely 8y agozero people block JS: false only one person blocks JS: false therefore many block JS
- robbrown451 8y ago"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.
- basica 8y agoHaven't you studied cardinality? You don't have One to Multiple relationships, you have One to Many /s
- rodorgas 8y agoBetween zero or all, could be many or some.
- jrochkind1 8y agoOr perhaps "few".
- deleted 8y ago[deleted]
- ohitsdom 8y agoMost "stateful" functionality (including all you mentioned) can still be done with a CSS driven drop down menu.
- ThirdFoundation 8y agoCould this be handled by a templating engine like handlebars?
- Grumbledour 8y agoIt 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.
- nebulous1 8y agocss is often the slowest part of a webapp. complex css like this is not necessarily better accessibility-wise than javascipt
- Grumbledour 8y agoWhy 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.)
- jensvdh 8y agoDo you have some proof to back this? CSS matching is incredibly fast.
- deleted 8y ago[deleted]
- lucideer 8y ago> 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.