未加星标

You Might Need JavaScript

字体大小 | |
[前端(javascript) 所属分类 前端(javascript) | 发布者 店小二03 | 时间 2016 | 作者 红领巾 ] 0人收藏点击收藏

It’s been a rough couple of months for javascript. Another day, another rant about it, another article about how the ecosystem is too fragmented, the language too convoluted, and what else.

Recently enough, a project named You Might Not Need JS has seen the day. I have mixed opinions about it, and rather than writing a series of context-less tweets, I thought the sensible thing to do would be to write a couple of lines here.

Needless to say, this is obviously not meant as an offense to the project’s author, especially since I believe they (mostly) did a great job. More on that later.

A word about the inspiration

The project which has inspired the aforementioned one is You Might Not Need jQuery , in which its author outlined ways to use plain JavaScript rather than the jQuery library for simple tasks. It was quite a hit when it came out.

What I liked with this attempt is that it showed the world that JavaScript had come a long way and was not as hard to author as when jQuery was first invented. It also had the benefit of introducing new browser APIs ( .querySelectorAll , .classList , .matches , bind ) which is obviously a Good Thing.

Know your browser

Coming back to my initial point: I am all for teaching people not to abuse JavaScript and not to use it when it is not needed. No need to convince me that progressive enhancement is the way to go, and that relying on JavaScript for critical features is to be avoided. For that, I think Una (the project’s author) did a fantastic job.

However, I don’t believe replacing JavaScript with CSS hacks is any better. People, JavaScript is not a problem. I repeat it, because it doesn’t seem that obvious these days: JavaScript is not a problem . It has been invented for a reason. Replacing it for the sake of replacing it is not only useless, it’s also quite harmful.

CSS is not meant to handle logic and states. It has some simple mechanisms to ease styling based on states (pseudo-classes mostly), but it is not meant to control states. JavaScript is.

At the end of the day, it boils down to knowing your browser. There are some excellent examples in this project, and almost all of them are about replacing JavaScript with native HTML. A good one is the color picker :

<label for="color-picker">Select a color</label> <input type="color" id="color-picker" />

Fantastic! No need for JavaScript if the browser supports the color input type. Maybe only load a JS-powered color picker if it doesn’t.

Another good example is the form validation, with all the fancy HTML attributes allowing that ( required , pattern , etc.). Indeed, no need for JavaScript client-side validation if the browser can do the heavy lifting for us.

I really appreciate this project promoting these new browser features in favor of heavy JavaScript modules, the same way You Might Not Need jQuery featured new DOM APIs instead of jQuery-dependent scripts. But I don’t think all examples are correctly picked, which brings me to my last point.

A word on accessibility

The problem with blindly banishing JavaScript from interactive components is that it often means making them inaccessible. It is a popular belief to think that JavaScript is an enemy of accessibility; that’s a fallacy.

While it is strongly encouraged to make websites work without JavaScript (because it can fail to load or execute and be blocked or disabled), it does not mean JavaScript should be avoided at all cost. It means it shouldn’t be used in a critical way.

If there is one thing I learnt while building a11y-dialog and a11y-toggle , it’s that JavaScript is necessary for interactive modules to be fully accessible for people using assistive technologies (such as a screen reader for instance).

A dialog element is not going to be accessible with CSS only. The aria-hidden attribute needs to be toggled, the focus needs to be trapped, the escape key needs to close the dialog, and I could go on.

Maybe instead of trying to reproduce the exact same module without JavaScript by using CSS hacks, we could display the content in a way that is suited for no JavaScript behaviour. Nothing states that both JS and no-JS environments should behave the same. If a module cannot fully exist without JavaScript, don’t use it in a no-JS environment; find something else.

Final thoughts

Be pragmatic about your approach.If something can be done in HTML exclusively, it probably means it should be done in HTML. If the lack of browser support is likely to be an issue, fix it with JavaScript.

If something needs interactivity and state handling, it is likely to be a job for JavaScript, not CSS. A CSS hack is not any better than a clean JavaScript solution.

If you want to make it work without JavaScript: go simple. Accessible content powered by clean code is better than non-accessible content made with hacks.

With that said, happy coding. :sparkling_heart:

本文前端(javascript)相关术语:javascript是什么意思 javascript下载 javascript权威指南 javascript基础教程 javascript 正则表达式 javascript设计模式 javascript高级程序设计 精通javascript javascript教程

主题: JavaScriptJavaCSSjQueryHTML
分页:12
转载请注明
本文标题:You Might Need JavaScript
本站链接:http://www.codesec.net/view/482422.html
分享请点击:


1.凡CodeSecTeam转载的文章,均出自其它媒体或其他官网介绍,目的在于传递更多的信息,并不代表本站赞同其观点和其真实性负责;
2.转载的文章仅代表原创作者观点,与本站无关。其原创性以及文中陈述文字和内容未经本站证实,本站对该文以及其中全部或者部分内容、文字的真实性、完整性、及时性,不作出任何保证或承若;
3.如本站转载稿涉及版权等问题,请作者及时联系本站,我们会及时处理。
登录后可拥有收藏文章、关注作者等权限...
技术大类 技术大类 | 前端(javascript) | 评论(0) | 阅读(33)