我正在自己编写一个相当大且复杂的网站,所以您认为我需要支持关闭 javascript 吗?
对于我可以用 JSON 和 ajax 快速完成的东西,它需要做很多额外的工作来支持整页回发。
我正在自己编写一个相当大且复杂的网站,所以您认为我需要支持关闭 javascript 吗?
对于我可以用 JSON 和 ajax 快速完成的东西,它需要做很多额外的工作来支持整页回发。
我觉得你应该支持。事实上,如果您的网站涉及 SEO 和 bot 索引您的网站以及所有这些,您应该支持关闭 javascript。
作为现代网页设计师,您应该首先开发您的网站以支持 Javascript OFF。然后慢慢添加效果和 Javascript 增强功能。
示例如下:
<a href="page.php?p=2">Continue</a>
然后升级到:
<a href="page.php?p=2" onclick="doajax();return false;">Continue</a>
因此,如果 Javascript 用户单击该链接,则 AJAX 完成,但通常的链接被禁用。但是,如果 Javascript-OFF 用户单击该链接,用户将被重定向到正确的页面,该页面的内容与显示给 javascript 用户的内容相同。
如果你在做回发,你可以对 AJAX 做同样的事情,也可以不做。
您首先在没有 Javascript 的情况下构建网站,然后添加 Javascript 和 AJAX 功能的术语称为“渐进增强”。
如果 JavaScript 被关闭,你应该会优雅地失败。
作为最低要求,您应该按照“您必须启用 JavaScript 才能使用此站点”的方式发布一条消息 - 但是,根据您的站点,这可能会切断您的大部分潜在受众。
您可能需要考虑介于两者之间的东西,并使用回发完全复制您的功能。
我通常首先在 AJAXless 网站上工作并建立起来。
始终尝试相信优雅 降级和不显眼的 javascript的概念。
- 将功能(“行为层”)与网页的结构/内容和表示分离
- 避免传统 JavaScript 编程问题的最佳实践(例如浏览器不一致和缺乏可扩展性)
- 逐步增强以支持可能不支持高级 JavaScript 功能的用户代理
这可以通过确保链接和表单可以正确解析并且不仅仅依赖于 Ajax 来实现。在 JavaScript 中,例如可以通过使用“return false”来停止表单提交。如果没有任何问题,Ajax 代码将被执行并跳过表单提交。如果用户代理的 Ajax 支持出现任何问题,或者如果用户没有启用 JavaScript,则将提交表单并执行传统版本的操作。
在某些网站上,它可能比它的价值更多的工作,但通常人们为了酷而使用 AJAX,这总是一个不好的理由,并最终放弃破坏 http 常见和基本功能的页面(如书签和在新标签中打开)点击时)。
在任何情况下,您都需要编写服务器端代码来处理帖子,无论它们是否来自 AJAX。
那么为什么不按照DRY 原则进行编码,并为标准回发和 AJAX 请求重用相同的逻辑呢?
一般来说,没有。但这也取决于应用程序的类型。如果您正在做一个高度窗口化(“丰富”)的应用程序,那么允许它不一定有意义。换句话说:在用例不太可能/不常见的情况下,这样做的努力可能很重要。
如果您正在开发一个可以控制用户环境(例如公司内部网)的应用程序,那么您真的不需要。
如果您正在做一个“普通”网站,其中 Javascript 主要是装饰性的,那么您可能会但实际上,一个没有 Javascript 的网站在很大程度上是偶然的。如果它碰巧有效,那就太好了。如果没有,那就是生活。
最后,如果您的用户群真的很大,那么它可能是值得的。GMail 是一个大量使用 Javascript 的网站,但它有一个纯 HTML 版本,可能是因为它拥有如此多的用户,以至于 1-2% 的禁用 Javascript 的人口足以满足需求。
问题是,你对5% 的用户失去你在 JavaScript 中的任何功能感到满意吗?(假设你正在做的任何事情都不会做优雅的降级/渐进式增强等......)
如果你回答不是,那就花时间。我确实喜欢要求用户打开 JavaScript 的观点。至少那时他们意识到他们可以选择打开他们缺少的任何东西。
许多传统主义者会告诉你在浏览器之外编写 javascript 代码。正如您所说,我的观点是,对于大多数组织来说,这样做的成本太高了。但是,您应该检查JS是否打开,如果它关闭,请将浏览器重定向到指定使用系统要求的页面。
我们这样做,但我们必须严格遵守 508 合规性(残障人士的可访问性)。JavaScript 给必须使用“阅读器”(阅读页面的程序,因为人们看不到)的人带来了困难,所以我们必须有一个不使用 JavaScript 的选项。
这取决于您的应用程序目标受众。在我看来,最初使用 javascript 功能构建网站而不考虑用户是否拥有它是不好的做法。但是每个人都以他们想要的方式设计/开发网站。我喜欢首先编写一个没有任何 javascript 的网站。确保它有效,然后使用 javascript 逐步增强它。
当然,要使您的网站易于访问需要做很多工作。如果您的应用程序针对游戏社区,我不会太担心可访问性。如果您的申请受政府法规的约束,则必须遵守WCAG和第 508 节。
遵循 WCAG 和第 508 条的好处是您可以用一块石头杀死 2 只鸟。不仅行动不便的人可以访问您的网站,而且屏幕阅读器和搜索引擎蜘蛛也可以访问您的网站。
正如其他人所说,这取决于。
在三种传统用例中“预期”禁用了 javascript:
所有这些都在发展,以在正常使用场景中包含 javascript:
因此,长期趋势是,对于所有情况,您都将被期望作为用户启用 javascript。关于您今天做什么的问题取决于您的目标受众以及他们现在正在使用什么。这个你应该知道。
渐进式渲染......这是一个不同的话题。Gmail 不进行渐进式渲染,它只是为无法使用完整前端的人提供了一个单独的前端。那个单独的前端并不能做完整的 gmail 所做的一切。我自己制作网络应用程序,我尝试了一段时间的渐进式渲染,但最终使用了 gmail 的模型:
与使用渐进式渲染相比,此模型允许我以更低的成本为我的所有用户提供更好的用户体验。YMMV。
在开发网页时,我总是假设 JS 被禁用。话虽如此,有许多增强功能需要 JS,因此使用 noscript 标签让用户知道很重要。
<noscript>JavaScript is required to use the advanced features on this page, please enable JavaScript.</noscript>
始终计划禁用 JS - 但是,了解用户群。大多数 js-disabled 人不使用桌面浏览器浏览,他们使用一些蹩脚的手机浏览器浏览,视口只有一分钱大小。或类似的东西。如果您觉得有必要将他们包括在内,请为这群人制作一个非常简单、简单的设计。有些人这样做;有些没有。这只是您的产品/用户群是什么的问题。
其次,一个没有 js 后备的 ajaxified 表单非常简单:将表单设计为作为常规的 post 表单工作,然后进行 ajax 调用,从表单中收集它需要的所有信息。这包括但不限于字段数据、post url、方法、名称等。如果您的 js UI 片段会根据用户在表单中的决定(复选框、单选框等)而更改,则可以使用 jQuery检查隐藏的复选框(将显示在 no-js 表单中)并将所有事件都基于复选框单击 (item.click()) 而不是花哨的 js UI 元素的单击。这样,您的表单将始终准确地反映应用程序的状态,并且您的 no-js 和 js 实现完全同步。