标签: web-standards

这两个标准是分开开发的吗？他们似乎正在解决同样的问题,但有什么不同之处,如果要保持分离,他们将来会在Web开发中扮演什么角色？

我最近发现大多数主要网站都没有通过W3C的标记和CSS验证测试.因此,遵循Web标准真的有多重要？

想象一下今天,2011年3月1日的某个人,从未写过一个网页,想知道他们今天应该阅读什么来开始构建网页.他们不关心向后兼容性,但希望使用Web标准构建,以便它们可以在尽可能多的浏览器中移植(是的我说我不关心我的网页是否与IE 4不兼容) 8,Opera,Netscape,Mozilla等,我真的不在乎,因为我从来没有使用它们,对于那些将使用我正在构建的工具的人来说,这可能是真的.

这个人没有偏见或坏习惯,因为他们以前从未这样做过.他们也过度活跃,所以如果他们必须阅读200页关于"为什么要使用网络标准"或"为什么网络标准比旧方式更好",他们会气馁和分心,把书扔掉,去游泳吧.说到这,我的头发是湿的.

他们正在寻找引人入胜且简明扼要的参考文献.他们并不愚蠢,这个人是一个真实的工程师,他做了一点点的开发,十年或两年的系统管理,甚至建立了一两个成功的公司.他们只是没有上大学,因为他们真的不是书本学习者,并且更善于应用实践学习而不是吸收大量无用数据以获得他们真正需要的两三件事.

鉴于所有关于个人的数据,我知道这个人很多(当然这个人就是我),你会推荐哪些书籍或资源？

(泽尔德曼的书已经出局了,因为我已经把它们扔掉然后今天去游泳了.)

在一个项目上工作,差不多完成了,只是整理了HTML,我发现你并不是真的被允许拥有一个只是一个数字的ID-

<a>属性"id"具有无效值"567"属性ID的类型为ID.如上所述,它应该以字母开头并且没有空格

Good    <a id="567" href="/index.html">
Good    <a id="n567" href="/index.html">

我可以通过我的代码并添加一个字母,然后在我的jQuery中使用该值时将其删除,但它会乱七八糟,我真的不需要.

有没有理由我不应该使用数字作为ID？

所以,每个人都知道ie9.js(来自http://code.google.com/p/ie7-js/).它似乎有效,但自2010年上一次发布以来从未离开过测试版.

显然,还有一些其他的东西有点类似(例如modernizr,html5shiv和CSS3Pie),但它们并不完全相同(尤其是因为它们需要按功能应用或范围更有限).

用它来进行现代化仍然是一种良好的做法吗？我应该使用其他东西吗？

是在HTML规范是说,任何要求value的第optionS IN一个select必须是唯一的？

我的问题是关于重复value的有效性.忽略以下代码块中的所有不切实际,是否select有效？

<select id="produce" multiple>
    <option value="2.00">Apple</option>
    <option value="1.50">Banana</option>
    <option value="1.50">Carrot</option>
</select>

<input id="total" type="text">

<script>
    $('#produce').on('change',function(e) {
        var sum = 0;
        $('#produce option:selected').each(function() {
            sum += parseFloat($(this).val());
        });
        $('#total').val(sum.toFixed(2));
    });
</script>

我相信大多数人建议使用UTF-8作为Javascript文件的编码.

是否有关于这些文件是否包含字节顺序标记的标准,还是不包括它？(即JS文件是否应该使用/不使用UTF-8 BOM？)

我希望看到一个RFC,或者这个"事实上"的标准,而不是个人喜欢哪种意见.

我一直在使用OWASP ZAP运行一些渗透测试,并为所有请求提出以下警报:X-Content-Type-Options Header Missing.

我理解标题,以及为什么建议.这个StackOverflow问题很好地解释了它.

但是,我发现各种引用表明它只用于.js和.css文件,并且为其他MIME类型设置标题实际上可能是一件坏事:

• 注意:nosniff仅适用于"脚本"和"样式"类型.将nosniff应用于图像也证明与现有网站不兼容. [1]
• Firefox遇到了支持nosniff图像的问题(Chrome不支持它). [2]
• 注意:现代浏览器仅尊重脚本和样式表的标题,并在使用错误的媒体类型提供其他资源(如图像)时发送标头可能会在旧版浏览器中产生问题. [3]

上面的引用(和其他)表明,简单地为所有响应设置此标题是不好的,但尽管遵循任何相关的链接和在Google上搜索,我找不到任何理由背后这个论点.

什么是与设置相关的风险/问题X-Content-Type-Options: nosniff和为什么要避免的MIME类型比其他text/css和text/javascript？

或者,如果没有风险/问题,为什么Mozilla(和其他人)建议有？

W3的EXI(高效XML交换)将标准化.它声称是"最后的二进制标准".

它是存储针对处理和存储而优化的XML数据的标准,与XML模式捆绑在一起(使数据具有强类型和强结构).嗯,有很多声称的优点.处理和内存效率测量给我留下了深刻的印象.

我问自己,所有已建立的XML API会发生什么？

这段与我的问题有关:

4.2现有的XML处理API

由于EXI是XML Infoset的编码,EXI实现可以支持任何常用的XML API进行XML处理,因此EXI对现有的XML API没有直接影响.但是,使用现有的XML API还要求将EXI文档中出现的所有名称和文本转换为字符串.将来,如果较高层可以直接将这些数据用作EXI文档中出现的类型值,则可以实现更高的效率.例如,如果较高层需要类型化数据,则通过其字符串形式会产生性能损失,因此直接支持类型化数据的扩展API可以在与EXI一起使用时提高性能.

来自:http://www.w3.org/TR/exi-impacts/

我理解如下:"将EXI与现有API一起使用？没有性能提升!(除非你全部重写)"

我们以Java生态系统为例:

我们有大量的XML API的最新的JDK 6(每个主要JDK版本中,越来越多的人加入.)据我判断,大部分(如果不是全部),他们使用的是内存中的DOM树,或序列化("文本")表示来转换/处理/验证/ ... XML数据.

你们怎么想？这些API会在引入EXI后发生什么？

谢谢大家的意见.

对于那些不了解EXI的人:http://www.w3.org/XML/EXI/

我一直在讨论这个问题,谷歌搜索并没有太多帮助甚至记录这个问题,但它对我目前转换为适合移动设备的设计有很大影响.

无论我走到哪里,每个人都在鼓吹使用rem基于布局的新黄金标准,从表面上看,这种方法的优点似乎是理想的(基于参考像素的缩放和字体大小缩放的完全可访问性支持,以支持许多DPI和许多屏幕尺寸/设置).

然而,我遇到了一个相当大的障碍,我发现Chrome(可能还有所有的webkit浏览器,但我没有测试的mac atm)似乎与其他浏览器不一样.

初始设置如下:

html { font-size: 62.5%; }
body { font-size: 1.6rem; }

我们应该能够使用rems中1/10像素大小设置所有测量值:

.my-element { height: 15rem; } /* 150px */

我创建了一个简单的例子来说明我的问题:https://jsfiddle.net/gLkpz88q/2/embedded/result/

当您使用Chrome并按比例缩小时,请注意布局如何停止缩放但内容仍在继续.

将它与Firefox,IE11,Edge进行比较,您根本看不到这种行为,它们都是统一且连续的.

这里(左上角:Chrome,右上:IE11,左下:边缘,右下:FireFox)并排:

正如您所看到的,如果rem单位与其他所有内容的比例不同,则会对布局产生一些可怕的影响.

我不确定如何继续这种情况,因为似乎WebKit/Chrome决定以完全不同的方式处理扩展,并且这要求对未来的所有扩展方案提出质疑.

有很多文章主张使用像素,因为CSS Reference Pixel可以很好地处理移动扩展:

• 只需使用像素
• RIP Rem,Viva CSS参考像素!

然而,这些倾向于忽略字体缩放问题,并将其视为不太可能发生的情况.

我快速浏览了大型移动友好/友好网站,我可以想到大型和成功的公司,似乎大多数人只是使用像素来满足他们所有的布局需求.(Google,Facebook,Wordpress,Twitter,Bootstrap 3,[在某种程度上Bootstrap 4],MDN和WebPlatform)

Chrome是新标准的Busting IE吗？或者我在做一些可怕的错误？我很想在这一点上使用像素来保持一致性.