When I was hired on the Watson team, the first thing they asked me to do was help improve performance of their AngularJS-based website. It was all-around slow, especially for the initial page view. I stripped out AngularJS and most of the other JavaScript, and published a website that was almost pure static HTML. It loaded very quickly. My manager thought it was hilarious - his "JavaScript expert" came in and deleted all of the JavaScript.
So let's show off what you can do without JavaScript...but also include SCSS as a dependency when the opening paragraph complains about a JavaScript dependency? Madness...but I digress.<p>Some of these are cool examples. Others, like the modal, won't scale very well because now you can trigger modals by tabbing (breaks keyboard navigation) or most of the form examples as you'll likely hit many endpoints that require JSON (which yeah I know "you're making a web app why can't your endpoints accept a form?" but as we all know it's never that simple and you might want to provide different behaviors for, say, showing a progress bar or disabling certain features during the submissions or a THOUSAND other things).<p>I get axing dependencies. I really do. I wrote msngr.js entirely in ECMAScript 5 using zero dependencies so I'd have the most flexibility possible. But at the same time overcomplicating your code to the point where it's breaking standard practices or making it un-maintainable <i>simply</i> to axe a dependency is the wrong way to go.<p>But by all means keep making cool stuff that shows off how versatile CSS is! Just don't expect to use all the CSS tricks you learn in a production environment.
I'm cautious about using CSS to do things that feel like actual behaviours.<p>For example, the modal that appears when you click on the button actually doesn't do things on "clicking" but <i>focusing</i>. This means if you tab over the button it'll load the modal, then tabbing away means the modal is gone. I can't tab into the content in the modal at all. How does that work with accessibility?<p>Though I generally dislike the idea of saying content isn't there by making it <i>present in the document</i> but <i>invisible</i>.<p>Edit - Some of the default behaviours are also a bit pants. In chrome, the form validation on a pattern starts working after I hit submit, then angrily shakes at me for every keypress until it's valid. Then, it ignores invalid input as I type more! Please never use this for phone numbers or credit card numbers. Stop requiring an exact format when what people type varies, and stop telling me I'm putting in something wrong when you ask for a phone number and I give you something that'll connect to me if you type into a phone.<p>Maxlength is not a validation it's just ignores any more letters you type. Quietly ignoring your users input is probably not what you want.<p>The "Would you prefer a banana or a cherry?" just shouts "Please match the requested format" if I type "a cherry". I know chrome has nothing else to go on other than "the regex wasn't matched" but it's a bad end user experience.<p>The tabs example is something I need to tab onto then use left and right, I assume because it's a radio box underneath, not a series of links. Are tabs really radio buttons?<p>The same for the accordion. Which I've found if I add any tabbable content inside them then I'm focused on a <i>hidden item</i>. Great. Tab onto "tab 1", hit tab, focus has disappeared and I'm now potentially going to click on random items I can't see. This is because although you want to pretend the content isn't there just because it's not visible, it's still there! It's in your document.<p>Sure, you might not <i>need</i> javascript. But maybe you should still use it.
It made me learn about <a href="http://caniuse.com/#feat=input-pattern" rel="nofollow">http://caniuse.com/#feat=input-pattern</a> ; thanks for that!
You <i>might</i> not, but you probably do.<p>The validation examples and input types are a case in point. Even on browsers where they work, the alerts can't be styled and the behaviors can't be controlled.
The you don't need jQuery website had a concrete use case - you need not include an entire library into your website for some simple tasks which makes your website faster.<p>Though, this site is cool in showing the power of CSS, I am not sure if there is any specific advantage of using CSS over JS to design tabs, sliders, etc. Just use the best tool for the job!
It's sad that this site uses SCSS for displaying the rules, I'm using it in production and fully understand it, but it's needlessly abstracting the rules for the sake of a few extra words in each declaration.<p>That aside, these are some pretty cool examples. Are there ways of doing this with CSS which doesn't screw with my browser back button?
Some of these are ok, but others are just misusing features for their intended purpose. An input gaining focus is not the same as a click event. Using the :checked peudoselector to keep client-side state is not an alternative to using JS.<p>Using HTML/CSS hackery where you should be using JS instead creates an anti-SEO, non-semantic mess that causes headaches for others to work on and nightmares for anybody needing to extend or modify functionality.<p>Don't get me wrong, I love pure CSS solutions and try to use them as much as possible where it makes sense. But sometimes, it definitely doesn't make sense. JS isn't something users or developers should be scared of anymore, it's much better supported and much less intrusive than it used to be.
There is some useful stuff to learn from here, undeniably, but many of these are a bit useless when you compare them with what you would actually typically need on a real site. Yes, the "image slider" is vaguely functional, but really most of the time you will want a lot more control than just the CSS animations allow; similarly, yes, the form validation is a starting point, but normally you would want to customise the error messages and generally fiddle around with it a lot more; I'm not really sure the modal is fit for purpose beyond the most basic use case... etc.<p>It's fun to see what you can partially achieve without JavaScript, but there is no shame in using JavaScript sensibly to enhance the usefulness of a web site.
So, we're all familiar with the fact that imgur requires JavaScript in order to display more than the first few images in a gallery (the 'view more' link executes JavaScript; there's no way to page forward). That's highly annoying, since HTML supports exactly this use case.<p>It's understandable, though, because we are not imgur's customers: its customers are advertisers, and if we have JavaScript disabled then imgur's customers have less ability to violate our privacy. Thus, it's in imgur's best interest to encourage us to reduce our privacy & security, so that its customers may have their way with our browsers. I can't see that the imgur programmers would care about the fact that they can do amazing things with CSS.<p>But recently I've discovered that Target's website simply refuses to display products without JavaScript. This is insane: Target are, presumably, in the business of selling things. They ought to want to display a picture of their item and provide me a link to buy it; that's in their best interest. Building that sort of website is <i>easier</i> than building the sort of ecommerce site which cannot even display an image and a link without JavaScript. It should be in Target's best interest to do the right thing.<p>But it <i>doesn't</i>. Its programmers <i>ought</i> to be interested in a site like youmightnotneedjs.com, but <i>are</i> they? If they didn't bother to build their website properly before, is this likely to encourage them now?
The issue with CSS sliders is that they mess with the browser history.<p>I expect my back button to open the previous page, not to move an image slider.
Am surprised no one has pointed out how bad these examples are for accessibility, no pause/play on the slider, hidden content that won't be read by screen readers etc.<p>I like the idea of using CSS over Javascript where it makes sense but in a lot of these examples it feels hacky.
If you use React and inline styles, you might not need HTML and CSS: <a href="https://vimeo.com/116209150" rel="nofollow">https://vimeo.com/116209150</a><p>Also, if you want the benefits of inline styles, but need media queries and the like, check out Radium: npm.im/radium
The biggest pain point with using :target is that location.hash, which powers it, is a single global state variable - which means you can't nest tabs inside tabs, for example.<p>The slider has the problem that it cannot dynamically size with the container width, and the amount of slider elements has to be known at compiletime (width: n * 100%).<p>File upload has the nastiness that you can not really independently style the inputbox with the filename and the button. Chrome has input[type="file"]::-webkit-file-upload-button, but I am not aware of a Firefox/IE solution. Also, you cannot combine the input[type="file"]::-webkit-file-upload-button with a general button selector in the same CSS rule, because Firefox doesn't know the ::-webkit-file-upload-button and discards the whole rule as invalid - you have to double declarate your button styles if you want uniform button look in Chrome. And, even on Chrome, you cannot visually separate the inputbox from the button (e.g. I have a 2-col layout, 320px/col and 16px margin, and I only can mess around with width, padding and margin instead of a clean separation).<p>To the people who whine about SASS: you can ALWAYS write the resulting CSS by hand, it just takes a boatload of manual typing.
Yuck. I'd take a simple well crafted and maintainable JS solution over an opinionated CSS preprocessor any day of the week.<p>Preprocessors do nothing but splinter the CSS scene by layering odd syntax over an already creaking/complex CSS spec. Got nothing against compiling CSS in general - postprocessing features related to current and future CSS specs with PostCSS is a great idea. But dividing the community's attention between multiple competing preprocessors while it should have been concentrating on the spec is the worst thing to have ever happened to CSS.<p>Great things happened to JS when people got behind tools that pushed the language forward while keeping the current and future spec in mind (ES6/Babel). Shame CSS took an alternative approach imo.
Funny that I had to activate javascript in order to see the previews, so, although you don't need JS in real life, you need it to convince people to stop using it.<p>Kinda like when Dante wrote in Latin about the utility of the Italian language.
A few days ago a saw a talk about CSS animations with RxJS [0] and the gist about CSS only stuff was something like: "Yes, you can do much with CSS only, but it gets ugly fast."<p>Often you're better of to do a mix of both, because some things that are very complicated in CSS are two-liners in JavaScript.<p>[0] <a href="https://www.youtube.com/watch?v=lTCukb6Zn3g" rel="nofollow">https://www.youtube.com/watch?v=lTCukb6Zn3g</a>
CSS is great, and by all means use it, while also being aware that you can build so many functional UI components without the additional dependancy.<p>Maybe you can include a few lines of utility code, or a mixin, and forgo the requirement. If you're only targeting more modern browsers, you might not need anything more than what the browser ships with.<p>This site is fully copied from youmightnotneedcss.com, an excellent resource for vanilla CSS created by @somebody and @somebodyelse. But this time, we take a look at the power of modern native HTML and g as well as some of the syntactic sugar of DuJour. Because, you might not need scripts for that task at all! (Note: these methods can all be accessible, but the demos may not be. Please take a moment to test these before using in production)
You might not need (to write any) Javascript, but you might <i>still</i> want modern UX with some AJAX.<p>I have some good news: <a href="http://intercoolerjs.org" rel="nofollow">http://intercoolerjs.org</a><p>You can add AJAX to your application without writing any javascript code, and you'll get to use REST (with real, honest to God HATEOAS) without even thinking about it:<p><a href="http://intercoolerjs.org/2016/01/18/rescuing-rest.html" rel="nofollow">http://intercoolerjs.org/2016/01/18/rescuing-rest.html</a><p><a href="http://intercoolerjs.org/2016/05/08/hatoeas-is-for-humans.html" rel="nofollow">http://intercoolerjs.org/2016/05/08/hatoeas-is-for-humans.ht...</a>
What are the performance implications of using CSS animations versus Javascript? Say, if you were trying to make an application where page animations need to be extremely fast, like under 2ms for an experiment or test.
CSS for behaviour = un-scalable non-x-platform big ball of crap<p>I understand why people try so hard to do without JS, but if you want to implement certain UI features, you're SOL. Either give up on them, or embrace the pain.
Or, you could use JavaScript and do something in 30 seconds rather than fiddling with CSS.<p>Why do people try so hard not to use tools that make their life easier?<p>You might not need a car - you can walk. But it makes life easier and it just works!
Another point of view: an exceptional article by Jenn Schiffer "A Call For Web Developers To Deprecate Their CSS" <a href="https://medium.com/cool-code-pal/a-call-for-web-developers-to-deprecate-their-css-1f6430781393" rel="nofollow">https://medium.com/cool-code-pal/a-call-for-web-developers-t...</a> - HN Submit here <a href="https://news.ycombinator.com/item?id=12691081" rel="nofollow">https://news.ycombinator.com/item?id=12691081</a>
One thing I have taken issue with a lot of these different CSS "component" implementations, is the lack of examples on how one would write a good testing suite for these. My first reaction looking at these is not "wow", but more "how can I test this?"<p>I would honestly be interested in hearing from some people here about how you would go about writing a proper test for these examples. And if the answer is "webdriver screenshotting", I might just shake my head a bit.
The problem with using CSS for animations is that if the UX designers make a minor change to the spec, you might be forced to rip out the whole thing and redo it in JavaScript.
I thew this together a while back if anyone's interested: <a href="https://github.com/johnhenry/funwithoutjavascript" rel="nofollow">https://github.com/johnhenry/funwithoutjavascript</a>
If you learn JavaScript, you would be learning an imperative language that shares many features with other languages, and you would be, as a resource, more flexible than if you just use CSS for everything.
JavaScript is overused today, even for stupidest things. If needs to be done in JS, you'll see God knows how many frameworks included. This idea reminded me of: youmightnotneedjquery.com
I would like to see more sites that use an uppercase title making it so via CSS so I can copy/paste that without having to copy from the source <title> or be lazy and rewrite.
Many of these make sense, but a few (for eg. 'View Switcher') end up obscuring the logic of what's happening, and are probably better off done in JS.
These examples are all good but I doubt whether you can really avoid javascript. In reality it's more like you can't avoid javascript if you wanted too.
Neat stuff. One small issue: the lightbox re-opens when I'm using the back button on my mouse (using Chrome), not sure if that's fixable or not?
Best of luck making this work across browsers. And even more luck to anybody who uses this, and then has to come back 6 months later to change something.
You might nod near internet, heck, you many not need staying alive, but here we are.<p>Seriously, after some minimum complexity the ability to create functions and loops its extremely important. As in you don't need a spoon and a knife to feed yourself, but it sure fucking helps.
A lot of "you don't need Javascript" articles show a bunch of CSS tricks that look flashy and cool but in reality are brittle, limited, and hard to maintain. There's a fair bit of that here, but props for also pointing out some of the new HTML5 features that may have slipped under people's radars. I was aware of the form validation and I think it's a godsend, but I had no idea there's a native color picker now too.
The site makes no claims as such, but it undermines its own credibility if it uses .js files.<p>Surely they could have figured a way to do without them.