我应该如何解决冗余在渐进增强/优雅降级中的作用?

发布于 2024-12-08 08:42:35 字数 628 浏览 3 评论 0原文

当我正在回答有关 inputstextareasplaceholder 文本最佳实践的另一个问题时,出现了这个问题。

使用 HTML5 placeholder 无疑是最佳选择,但目前看来仍然有必要为旧版浏览器添加降级解决方案(使用 JavaScript)。

JsFiddle在这里: http://jsfiddle.net/leifparker/DvqYU/16/

问题是:既然它们都完成了几乎完全相同的事情,为什么还要费心将两者都包括在内呢?为什么不直接使用纯 javascript 解决方案,并放弃 HTML5 实现,直到它(接近)被普遍接受?

诚然,在这个特定示例中,添加 HTML5 placeholder 属性和 hasPlaceholderSupport() 函数只需添加相当少的行 (4),但由于需要降级支持,有什么理由去烦恼渐进式冗余吗?

我确信双方都有理由,我很想听听。

提前致谢!

This question arose when I was working on answering another question about best practices for placeholder text in inputs and textareas.

Using the HTML5 placeholder is surely optimal, but at this point in time it still seems necessary to add a degraded solution for older browsers (using javascript).

JsFiddle here : http://jsfiddle.net/leifparker/DvqYU/16/

The question is : Since they both accomplish nearly precisely the same thing, why bother to include both? Why not just utilize the javascript-only solution, and forego the HTML5 implementation until it is (near) universally accepted?

Granted, with this specific example, adding the HTML5 placeholder attribute and the hasPlaceholderSupport() function is a fairly minimal addition of lines (4), but since the degraded support is desired, is there any reason to bother with the progressive redundancy?

I'm sure there is rationale on both sides, and I'm curious to hear it.

Thanks in advance!

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

深陷 2024-12-15 08:42:35

有理由打扰。随着时间的推移,预计所有浏览器都将支持占位符属性。目前,只有少数浏览器不支持它最重要的是 IE 9 及以下版本,以及 Android 浏览器)。因此,最终,您的占位符后备代码将是不必要的。如果您使用适用于所有浏览器的脚本来发布网站,那么几年后,这将是完全没有必要的。

相反,仅在必要时才使用功能检测回退到 JavaScript 解决方案:

  1. 您不必在已经支持占位符属性的浏览器中运行一些 JavaScript 代码。
  2. 您可以仅在必要时加载后备脚本,从而节省一些字节。

这就是 Modernizr 和 yepnope.js(包含在 Modernizr 中)等库已经做的事情。我建议使用 Modernizr 并提取占位符 polyfill 到一个 placeholder-polyfill.js 文件,因此您的代码可能如下所示:

Modernizr.load({
  test: Modernizr.placeholder,
  nope: 'placeholder-polyfill.js'
});

如果您只想要 yepnope.js 并运行您自己的特征检测函数:

yepnope({
  test: hasPlaceholderSupport(),
  nope: 'placeholder-polyfill.js'
});

这样,您可以节省资源加载并改进大多数浏览器的性能。将来,所有浏览器都会简单地通过测试,从而提高性能。然后,您可以简单地删除 yepnope.js/Modernizr 调用。

对我来说,这更多的是一种让代码面向未来的心态,同时已经利用了现代浏览器的功能。

There's a reason to bother. As time progresses, it's expected that all browsers will support the placeholder attribute. Right now, just a few browsers do not support it (most importantly, IE 9 and inferior, and the Android Browser). So, eventually, your placeholder fallback code will be unecessary. If you ship the website using the script for all browsers, in a few years, it will be completely unnecessary.

Instead, by using feature detection for falling back to a JavaScript solution only when necessary:

  1. You do not unnecessarily run a bit of JavaScript code in browsers which already support the placeholder attribute.
  2. You may only load the fallback script when necessary, saving a few bytes.

This is what libraries such as Modernizr and yepnope.js (included with Modernizr) already do. I'd recommend using Modernizr and extracting your placeholder polyfill to a placeholder-polyfill.js file, so your code could look like this:

Modernizr.load({
  test: Modernizr.placeholder,
  nope: 'placeholder-polyfill.js'
});

If you just want yepnope.js and run your own feature detection function(s):

yepnope({
  test: hasPlaceholderSupport(),
  nope: 'placeholder-polyfill.js'
});

This way, you save resource loading and improve performance for most browsers. In the future, all browsers would simply pass the test, improving performance. Then, you could simply remove the yepnope.js/Modernizr call.

For me, it's more of a mindset about future-proofing your code, while already taking advantage of modern browsers' capabilities.

挽容 2024-12-15 08:42:35

我看到的好处是你只能在必要时加载 jsFiddle。这节省了加载、解析和执行额外代码所需的时间。您的页面加载速度会更快,并且本机 html5 支持可能比在 JavaScript 中模拟它更快。

The gain I see is that you could only load jsFiddle when it was necessary. This saves the time needed load, parse, and execute extra code. Your page will load faster and the native html5 support is probably faster than emulating it in JavaScript.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文