技术控

    今日:86| 主题:49471
收藏本版 (1)
最新软件应用技术尽在掌握

[其他] You Might Need JavaScript

[复制链接]
娜娜爱 发表于 2016-10-14 03:06:26
273 3

立即注册CoLaBug.com会员,免费获得投稿人的专业资料,享用更多功能,玩转个人品牌!

您需要 登录 才可以下载或查看,没有帐号?立即注册

x
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 JShas 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 hacksis 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:  
  1. <label for="color-picker">Select a color</label>
  2. <input type="color" id="color-picker" />
复制代码
Fantastic! No need for JavaScript if the browser supports the    colorinput 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-dialogand    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-hiddenattribute 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:
友荐云推荐




上一篇:VMware Horizon 7 Blast Extreme Primer—Everything an Admin Needs to Know
下一篇:Ubuntu 16.10 Yakkety Yak Launches Officially with Linux Kernel 4.8, Download Now
酷辣虫提示酷辣虫禁止发表任何与中华人民共和国法律有抵触的内容!所有内容由用户发布,并不代表酷辣虫的观点,酷辣虫无法对用户发布内容真实性提供任何的保证,请自行验证并承担风险与后果。如您有版权、违规等问题,请通过"联系我们"或"违规举报"告知我们处理。

靖儿 发表于 2016-10-14 03:53:25
非常好,顶一下
回复 支持 反对

使用道具 举报

仟~qinyip 发表于 2016-10-21 15:20:28
最近病院在打折!?
回复 支持 反对

使用道具 举报

景兴波 发表于 2016-11-15 08:58:49
路过。。。。
回复 支持 反对

使用道具 举报

*滑动验证:
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

我要投稿

推荐阅读

扫码访问 @iTTTTT瑞翔 的微博
回页顶回复上一篇下一篇回列表手机版
手机版/CoLaBug.com ( 粤ICP备05003221号 | 文网文[2010]257号 )|网站地图 酷辣虫

© 2001-2016 Comsenz Inc. Design: Dean. DiscuzFans.

返回顶部 返回列表