你打算关闭 javascript 吗？
我正在自己编写一个相当大且复杂的网站，所以你认为我需要支持关闭 javascript 吗？
对于我可以使用 JSON 和 ajax 快速完成的事情，支持全页面回发需要做很多额外的工作。
I'm coding a fairly large and complex site by myself, so do you think I need to support javascript being turned off?
Its a lot of extra work supporting full page postbacks for stuff I could quickly do with JSON and ajax.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（12）
我认为你应该支持这一点。事实上，如果您的网站涉及 SEO 和机器人索引您的网站等等，您应该关闭 JavaScript。
作为一名现代网页设计师，您应该首先开发您的网站以支持 Javascript OFF。然后慢慢添加效果和 Javascript 增强功能。
示例如下：
然后升级为：
假设如果 Javascript 用户单击该链接，AJAX 已完成，但通常的链接被禁用。但是，如果 Javascript-OFF 用户单击该链接，该用户将被重定向到正确的页面，其内容与将显示给 javascript 用户的内容相同。
如果您要进行回发，则可以对 AJAX 执行相同的操作，也可以不执行。
首先构建没有 Javascript 的网站，然后添加 Javascript 和 AJAX 功能的术语称为“渐进增强”。
I think you should support that. In fact, if your site involves SEO and bot indexing your site and all that, you SHOULD support javascript off.
As a modern web designer, you should first develop your site to be able to support Javascript OFF. then slowly add on effects and Javascript enhancements.
Example would be like:
Then upgrade to:
So say if a Javascript user clicks on the link, the AJAX is done but the usual link is disabled. However if a Javascript-OFF user clicks on the link, the user is redirected to the correct page with the same content that would be displayed to the javascript user.
If you're doing postbacks, you can do the same way for both AJAX or not.
The term that you build the site with no Javascript first, then add on the Javascript and AJAX features is called "Progressive Enhancement".
如果 JavaScript 被关闭，你应该优雅地失败。
作为最低限度，您应该发布一条类似于“您必须启用 JavaScript 才能使用此网站”的消息 - 但是，根据您的网站，这可能会切断大部分潜在受众。
您可能需要考虑介于此和通过回发完全复制您的功能之间的某些事情。
You should fail gracefully if JavaScript is turned off.
As a bare minimum you should put up a message along the lines of "You must have JavaScript enabled to use this site" - however, depending on your site, that could be cutting off a large proportion of your potential audience.
You might want to consider something somewhere in between this and fully duplicating your functionality with postbacks.
这取决于
我通常首先在 AJAXless 网站上工作并进行构建。
始终尝试相信优雅 降级 和 不显眼的 javascript。
在某些网站上，这可能会比其价值更多的工作，但通常人们为了酷而使用 AJAX，这总是一个糟糕的原因，并最终放弃破坏 http 常见和基本功能的页面（例如书签和在新选项卡中打开）单击时）。
It depends
I generally work first on an AJAXless site and build up.
Always try to be trustful to the concept of graceful degradation and unobstrusive javascript.
On some sites it could be more work than it's worth, but generally people use AJAX for coolness sake, that it's always a bad reason, and end up giving up with pages that break http common and basic functionality (like bookmarks and open in new tab when clicking).
无论如何，您都需要编写服务器端代码来处理帖子，无论它们是否来自 AJAX。
那么为什么不根据 DRY 原则进行编码，并为标准回发重用相同的逻辑和 AJAX 请求？
You need to write server-side code in any case to handle the posts, whether they are from AJAX or not.
So why not code according to the DRY principle, and reuse the same logic for standard postbacks and AJAX requests?
一般来说，不会。但这也取决于应用程序的类型。如果您正在开发高度窗口化（“丰富”）的应用程序，那么允许它不一定有意义。换句话说：在用例不太可能/不常见的情况下，这样做的努力可能会很重要。
如果您正在开发一个可以控制用户环境（例如公司内部网）的应用程序，那么您确实不需要这样做。
如果您正在创建一个“普通”网站，其中 Javascript 主要是装饰性的，那么您可能会发现，一个没有 Javascript 的网站在很大程度上是偶然的。如果它能起作用，那就太好了。如果没有，那就是生活。
最后，如果您的用户群非常大，那么这可能是值得的。 GMail 是一个大量使用 Javascript 的网站，但它有一个纯 HTML 版本，可能是因为它拥有如此多的用户，以至于禁用 Javascript 的 1-2% 的人口足以满足需要。
Generally, no. But it also depends on the type of application. If you're doing a highly windowed ("rich") application then it doesn't necessarily make sense to allow for it. To put it another way: the effort of doing so might be significant where the use case is unlikely/uncommon.
If you're doing an app where you control the user's environment (eg company intranet) then you really don't need to.
If you're doing a "normal" Web site where Javascript is largely decorative then you might but really, a site working without Javascript is largely incidental. If it happens to work, great. If not, well that's life.
Lastly, if your userbase is really large then it might be worth it. GMail is a Javascript-heavy site yet it has a plain HTML version, probably because it has so many users that the 1-2% of the population who disable Javascript are significant enough to cater for.
问题是，您是否同意 5% 的用户 失去任何功能你要放入 JavaScript 吗？ （假设您所做的任何事情都不会进行优雅的降级/渐进增强等...）
如果您回答“否”，那么就花时间吧。我确实喜欢要求用户打开 JavaScript 的这一点。至少那时他们意识到他们可以选择打开他们缺少的任何东西。
The question is, Are you ok with 5% of your users losing the functionality of whatever you are putting into JavaScript? (assuming whatever you are doing doesn't do graceful degradation/progressive enhancement etc...)
If you answer no, then spend the time. I do like the point of asking users to turn JavaScript on. At least then they are aware that they have an option to turn on whatever they are missing.
许多传统主义者会告诉您在浏览器之外编写 JavaScript 代码。我认为，正如您所说，对于大多数组织来说，这样做的成本太高了。但是，您应该检查 JS 是否打开，如果关闭，请将浏览器重定向到指定使用系统的要求的页面。
A lot of traditionalists will tell you to code for javascript off browser. My opinion, as you stated, it is far too expensive for most organizations to do. However, you should check if JS is on, and if it is off, redirect the browser to a page specifying the requirements for using the system.
我们这样做，但我们必须严格遵守 508 合规性（残疾人无障碍）。 JavaScript 给必须使用“阅读器”（读取页面的程序，因为人们看不到）的人带来了困难，因此我们必须有一个不使用 JavaScript 的选项。
We do, but we have to strictly follow 508 compliance (accessibility for handicapped people). JavaScript causes difficulty for people who must use "readers" (programs which read the page, because the person can't see), so we must have a no JavaScript option.
这取决于您的应用程序的目标受众。在我看来，最初使用 javascript 功能构建网站而不考虑用户是否拥有它是不好的做法。但每个人都按照自己想要的方式设计/开发网站。我喜欢首先编写一个没有任何 JavaScript 的网站。确保它有效，然后使用 JavaScript 逐步增强它。
当然，要使您的网站易于访问需要做很多工作。如果您的应用程序针对游戏社区，我不会太担心可访问性。如果您的申请须遵守政府法规，请遵循 WCAG 和 第 508 条 是一项要求。
遵循 WCAG 和第 508 条的好处是一石二鸟。您的网站不仅可供行动不便的人访问，而且还可供屏幕阅读器和搜索引擎蜘蛛访问。
It depends on which audience you're application targets. Building a site initially with javascript functionality without regard of whether the users have it or not is bad practice in my opinion. But everyone designs/develops sites the way they want. I like to first code a site without ANY javascript what so ever. Make sure it works, then progressively enhance it with javascript.
Sure it's a lot of work to make your site accessible. If your application targets the gaming community I wouldn't worry about accessibility too much. If your application is subject to government regulations then following WCAG and Section 508 is a requirement.
The benefit of following WCAG and Section 508 is that you kill 2 birds with one stone. Not only is your site accessible to humans with limited mobility, but its also accessible to screen readers and search engine spiders.
正如其他人所说，这取决于情况。
在三种传统用例中，禁用 javascript 是“预期”的：
所有这些都在不断发展，以便在正常使用场景中包含 javascript：
因此，长期趋势是，在所有情况下，作为用户，您都应该启用 JavaScript。关于您今天做什么的问题取决于您的目标受众以及他们现在正在使用的产品。这个你应该知道。
渐进式渲染……这是一个不同的话题。 Gmail 不进行渐进式渲染，它只是为无法使用完整前端的用户提供了一个单独的前端。那个单独的前端并不能完成完整 Gmail 所做的所有事情。我自己制作网络应用程序，并且尝试了一段时间的渐进式渲染，但最终使用了 gmail 的模型：
这个模型使我能够为所有人提供更好的用户体验我的用户，比使用渐进式渲染时的成本更低。 YMMV。
Like others have said, it depends.
There are three traditional use cases where disabled javascript was "expected":
All of these are evolving to include javascript in the normal usage scenario:
So, the long term trend is that for all cases you are going to be expected as a user to have javascript enabled. The question regarding what you do today is based on your target audience and what they're using right now. This you should know.
Progressive rendering ... that's a different topic. Gmail doesn't do progressive rendering, it just has a separate front-end for people who can't use the full front-end. That separate front-end doesn't do everything the full gmail does. Myself I make web apps, and I tried progressive rendering for a while, but ended up using gmail's model in the end:
This model allows me to deliver a better user experience for all my users, at a lower cost than when using progressive rendering. YMMV.
在开发网页时，我总是假设JS被禁用来开发。话虽如此，有许多增强功能需要 JS，因此使用 noscript 标签让用户知道很重要。
When developing web pages, I always develop with the assumption that JS is disabled. With that being said, there are many enhancements that require JS, so it is important to let the user know by using the noscript tag.
始终为 JS 禁用做好计划 - 但是，要了解用户群。大多数js障碍者不会使用桌面浏览器浏览，他们会使用一些蹩脚的手机浏览器，其视口只有一分钱大小。或者类似的东西。如果你觉得有必要将他们纳入其中，请为这群人做一个极其简单、最基本的设计。有些人这样做；有些人则这样做。有些则不然。这只是你的产品/用户群是什么的问题。
其次，具有 no-js 回退功能的 ajax 化表单非常简单：将表单设计为常规帖子表单，然后进行 ajax 调用，从表单中收集所需的所有信息。这包括但不限于字段数据、发布 url、方法、名称等。如果您的 js UI 部分根据用户在表单中的决定而变化（复选框、单选框等），则可以使用 jQuery检查隐藏的复选框（将显示在 no-js 表单中）并将所有事件基于复选框单击 (item.click())，而不是花哨的 js UI 元素的单击。这样，您的表单将始终准确地反映应用程序的状态，并且您的 no-js 和 js 实现完全同步。
Always plan for JS disabled - however, know the user base. Most js-disabled people don't browse with desktop browsers, they browse with some crappy mobile phone browser with a viewport the size of a penny. Or something similar. Make a dead-simple, bare bones design for this crowd if you feel the need to include them. Some do; some don't. It's simply a question of what your product/user base is.
Second, an ajaxified form with a no-js fallback is truly simple: design the form to work as a regular post form, then make an ajax call that gathers all the info it needs from the form. This includes, but is not limited to, field data, post url, method, name, etc. If you have js UI pieces that change depending on the user's decisions in the form (checkboxes, radio boxes, etc), you can use jQuery to check the hidden checkbox (that would be displayed in the no-js form) and base all of your events off the checkbox click (item.click()) rather than the fancy js UI element's click. This way, your form will accurately reflect the state of the application at all times, and your no-js and js implementations are completely in sync.