【问题标题】:Downsides of a Custom HTML Shiv自定义 HTML Shiv 的缺点
【发布时间】:2012-08-23 12:57:03
【问题描述】:

在最近的一个项目中,我使用了Alexander Farkas' HTML5 Shiv,我注意到缩小脚本后的大小为 2.274 KB。对于John Resig demonstrated in essentially two lines 的概念,这对我来说似乎相当大(我意识到这过于简单化了,因为 John's 不包括对支持或所有新 HTML5 元素的检查)。我挖掘了html5shiv source。它是 248 sloc,对于这样一个简单的任务来说,这似乎是很多不必要的代码。我只用了 14 行就实现了一个更简单的 shiv:

(function(document) {
    var div      = document.createElement('div'),
        elements = 'article|aside|audio|canvas|details|figure|figcaption|footer|header|hgroup|nav|output|progress|section|summary|video'.split('|'),
        i        = 0,
        length   = elements.length;

    div.innerHTML = '<header></header>';

    if(div.childNodes.length != 1) {
        for(; i < length; i++) {
            document.createElement(elements[i]);
        }
    }
})(document);

缩小到只有 ~270 字节(这比 Farkas Shiv 的大小节省了 88%)。当与适当的 CSS 结合使用时,它在 IE 6、7 和 8 中都能正常工作。

article,aside,audio,canvas,figure,figcaption,footer,header,hgroup,nav,output,progress,section,video{display:block;}

似乎 Farkas shiv 的核心在创建元素和检查 try/catch 中的函数方面具有一定的魔力。这种肉和填充物有必要吗?我的解决方案是否足够充分,或者 Farkas shiv 是否解决了我没有考虑过的问题?

编辑

脚本现在使用正确的声明创建自己的样式标签(仍然只有 21 行!):

(function(document) {
    var div      = document.createElement('div'),
        elements = 'article,aside,audio,canvas,figure,figcaption,footer,header,hgroup,nav,output,progress,section,video',
        elementArr = elements.split(','),
        i        = 0,
        length   = elementArr.length,
        script, style;

    div.innerHTML = '<header></header>';

    if(div.childNodes.length != 1) {
        for(; i < length; i++) {
            document.createElement(elementArr[i]);
        }

        script = document.getElementsByTagName('script')[0];
        style = document.createElement('style');
        style.innerHTML = elements+'{display: none}';
        script.parentNode.insertBefore(style, script)
    }
})(document);

【问题讨论】:

  • 就个人而言,我认为下载所有额外的代码对于运行 IE6/7/8 的人来说是一种合适的惩罚。事实上,也许我们应该多加几兆,以确保。
  • @SDC 对了!我可能已经有一大堆 IE 特定的 CSS。这算不算? :P 你的评论提醒我,我忽略了IE lt 9 用户可能已经在他们的缓存中拥有 shiv 的事实。但我的问题更多是关于代码膨胀而不是下载时间。
  • 希望我下面的真实答案有助于回答这个问题:-)

标签: javascript html html5shiv


【解决方案1】:

您的代码和 html5_shiv 的主要区别在于,您的版本仅适用于 IE 在页面初始加载期间对 HTML5 元素的不支持

事实上,还有很多重要的问题需要处理,如果您在加载后使用 Javascript 修改页面内容,就会遇到这些问题。

在某一时刻,实际上有一个名为html5 inner shiv 的辅助脚本,它解决了这些问题。但是,主 html_shiv 脚本的更新版本也包含这些修复程序,因此不再需要辅助脚本。但这确实意味着主脚本现在要大得多。

这说明了您看到的代码量。

如果您的 HTML 是静态的,那么答案是否定的,您不需要所有额外的代码;你的版本很好。 (或者您可以访问 html5_shiv Github 页面并下载以前的版本;早期版本看起来更像您的代码)。

但是,如果您打算编写一个包含任何类型动态内容的网站,那么建议您使用 html5_shiv 的完整当前版本。它解决的不仅仅是一个问题。

【讨论】:

  • +1 表示内部 shiv。我应该知道,当 shiv 搞乱重新定义 createElement 时,他们正在对 shiv 进行未来验证。但是,我想知道为什么您需要内部 shiv(或最新版本的主 shiv)。一旦你用 js 创建了每个 HTML5 元素,浏览器不会在页面的整个生命周期内意识到它们吗?
  • 我链接的内部 shiv 页面更清楚地解释了问题(如果你能通过“不要再使用这个”的大消息阅读它),但现在我只想说不,只是创建元素不足以解决 IE 在处理未知元素方面的所有缺陷。
  • 所以这只修复了innerHTML。如果您按照应有的方式使用 createElement 创建所有元素(包括 HTML5 元素),则不需要这样做,对吧?
  • 我相信它也有打印修复。可能更多,但我认为这涵盖了大部分内容。
  • 总结一下:只要你不使用innerHTML添加HTML5元素并且你不打印,Farkas shiv可以简化为我的版本。同意吗?
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2022-08-10
  • 2017-01-14
  • 2015-03-02
  • 1970-01-01
  • 2016-01-03
相关资源
最近更新 更多