是否为传统上不是坏习惯的元素编写自闭标签? [英] Is writing self closing tags for elements not traditionally empty bad practice?

查看:115
本文介绍了是否为传统上不是坏习惯的元素编写自闭标签?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我注意到jQuery(或者它是Firefox)会转换我的一些< span class =presentational>< / span> into< span class =presentational/>



现在我的问题是,可以这样写我的标记吗?任何浏览器都会窒息吗?



就我个人而言,我认为它看起来更干净< span class =presentational/> 如果它是空的。

解决方案

我假设你的问题与红色尾随有关在Firefox中查看源代码时会自动关闭元素。如果是这样的话,你就会陷入最强烈的冲击之中,同时在浏览器制造商与网络开发者大战中同时进行被动的激进辩论。 XHTML不仅仅是一个文档的标记。它还涉及如何通过网络提供文档。



在我开始之前;



XHTML 1.1规范指出,Web服务器应该为XHTML提供一个Content-Type的application / xhtml + xml。 Firefox将这些尾部斜杠单独列为无效,因为您的文档是以text / html而不是application / xhtml + xml的形式提供的。以这两个例子;相同的标记,一个作为application / xhtml + xml,另一个作为text / html。

http://alanstorm.com/testbed/xhtml-as-html.php



http://alanstorm.com/testbed/xhtml-as-xhtml.php

Firefox将meta标记中的斜杠标记为对于以text / html提供的文档无效,并且对于application / xhtml + xml提供的文档有效。 / p>

为什么这是有争议的



对于浏览器开发人员来说,XHT​​ML的重点在于您可以将您的文档视为XML ,这意味着如果有人发给你一些无效的东西,规范说你不必解析它。所以,如果一个文档被作为application / xhtml + xml提供,并且内容格式不正确,那么开发人员可以说不是我的问题。你可以看到在这里的行动



http://alanstorm.com/testbed/xhtml-not-valid.php



当文档作为text / html提供时,Firefox会对待它作为一个普通的旧HTML文件,并使用原谅,为您解决它,解析例程



http://alanstorm.com/testbed/xhtml-not-valid-as-html.php



因此,对于浏览器制造商来说,XHT​​ML作为text / html是很荒唐的,因为它从来没有被浏览器的渲染引擎当作XML处理过。



多年以前,寻找不仅仅是标记猴子的网站开发者(声明:我把自己包括为其中一个)开始寻找开发不涉及三次嵌套表的最佳实践的方法,但仍然允许引人注目的设计经验。他们/我们锁定了XHTML / CSS,因为W3C说这是未来,唯一的另一个选择是一个单一供应商(微软)控制事实标记规范的世界。真正的邪恶存在于单一供应商,而不是微软。我发誓。

那么争议在哪里呢? application / xhtml + xml有两个问题。第一个是Internet Explorer。在IE中有一个遗留缺陷/功能,其中内容用作application / xhtml + xml将提示用户下载文档。如果您尝试使用IE浏览上面列出的xhtml-as-xhtml.php,那很可能发生了什么。这意味着如果你想使用application / xhtml + xml,你必须<浏览器嗅探IE浏览器,检查Accepts头并只向那些接受它的浏览器提供application / xhtml + xml。这是不是微不足道的,因为它听起来是正确的,并且也违背了web开发人员正在努力的一次写入原则。第二个问题是, XML。这又是一个易受火焰影响的问题之一,但是有些人认为单个不良标记或单个字符编码不正确不应导致用户看不到他们想要的文档。换句话说,是的,规范说你应该停止处理XML,如果它没有很好地形成,但用户不关心规范,他们关心他们的猫的网站是坏的。



在这个问题上添加更多的汽油是XHTML 1.0(不是1.1)规范说XHTML文档可以作为text / html,假设某些兼容性指南。像img标签自动关闭之类的东西。这里的关键词是 may 。在 RFC发言中,可能意味着可选。 Firefox选择不使用XHTML doctype处理文档,而是使用text / html的内容类型作为XHTML。然而,W3C验证人会高兴地报告这些文件是有效的。



我会让读者思考一个文件的同时奇迹/恐怖,写一个文档来定义他们的意思可能是



向前移动



最后,这就是整个 HTML 5 的内容。 XHTML成了这样一个政治热点,一群想要推动语言前进的人决定走向另一个方向。他们为HTML 5制作了一个规范。目前这个规范正在W3C中被淘汰,预计将在未来十年内完成。与此同时,浏览器供应商正在挑选和选择正在进行的规范中的功能并实施它们。

评论中的更新



在评论中, Alex 指出,如果你要嗅到什么,你应该检查Accept标题来查看application / xhtml + xml是否被用户代理接受。



这是绝对正确的。一般来说,如果您要嗅探,请嗅探该功能,而不是浏览器。


I have noticed jQuery (or is it Firefox) will turn some of my <span class="presentational"></span> into <span class="presentational" />

Now my question is, is this okay to write my markup like this? Will any browsers choke on it?

Personally, I think it looks cleaner to do <span class="presentational" /> if it's going to be empty.

解决方案

I'm assuming your question has to do with the red trailing slash on self-closing elements when you view source in Firefox. If so, you've stumbled into one of the most vehement, yet simultaneously passive aggressive debates in the browser maker vs. web developer wars. XHTML is NOT just about a document's markup. It's also about how documents are meant to be served over the web.

Before I begin; I'm trying hard not to take sides here.

The XHTML 1.1 spec says that a web server should serve XHTML with a Content-Type of application/xhtml+xml. Firefox is singling out those trailing slashes as invalid because your document is being served as text/html rather than application/xhtml+xml. Take these two examples; identical markup, one served as application/xhtml+xml, the other as text/html.

http://alanstorm.com/testbed/xhtml-as-html.php

http://alanstorm.com/testbed/xhtml-as-xhtml.php

Firefox flags the trailing slash in the meta tag as invalid for the document served with text/html, and valid for the document served with application/xhtml+xml.

Why this is Controversial

To a browser developer, the point of XHTML is you can treat your document as XML, which means if someone sends you something that's not valid, the spec says you don't have to parse it. So, if a document is served as application/xhtml+xml and has non-well formed content, the developer is allowed to say "not my problem". You can see that in action here

http://alanstorm.com/testbed/xhtml-not-valid.php

When a document is served as text/html, Firefox treats it as a plain old HTML document and uses the forgiving, fix it for you, parsing routines

http://alanstorm.com/testbed/xhtml-not-valid-as-html.php

So, to a browser maker, XHTML served as text/html is ludicrous, because it's never treated as XML by the browser's rendering engine.

A bunch of years ago, web developers looking to be more than tag monkeys (Disclaimer: I include myself as one of them) started looking for ways to develop best practices that didn't involved thrice nested tables, but still allowed a compelling design experience. They/We latched onto XHTML/CSS, because the W3C said this was the future, and the only other choice was a world where a single vendor (Microsoft) controlled the defacto markup spec. The real evil there being the single vendor, and not so much Microsoft. I swear.

So where's the controversy? There are two problems with application/xhtml+xml. The first is Internet Explorer. There's a legacy bug/feature in IE where content served as application/xhtml+xml will prompt the user to download the document. If you tried to visit the xhtml-as-xhtml.php listed above with IE that's likely what happened. This means if you want to use application/xhtml+xml, you have to browser sniff for IE, check the Accepts header and only serve application/xhtml+xml to those browsers that accept it. This is not as trivial as it sounds to get right, and also went against the "write once" principle that the web developers were striving for.

The second problem is the harshness of XML. This is, again, one of those flame prone issues, but there's some people who think a single bad tag, or single character improperly encoded shouldn't result in a user not seeing the document they want to. In other words, yes, the spec says you should stop processing XML if it's not well formed, but the user doesn't care about the spec, they care that their cat's website is broken.

Adding even more gasoline to the issue is the XHTML 1.0 (not 1.1) spec says that XHTML documents may be served as text/html, assuming certain compatibility guidelines are followed. Things like the img tag being self closing and the like. The key word here is may. In RFC speak, may means optional. Firefox has chosen NOT to treat documents served with an XHTML doctype but a content type of text/html as XHTML. However, the W3C validator will happily report these documents as valid.

I'll leave the reader to ponder the simultaneous wonder/horror of a culture that writes a document to define what they mean by the word may.

Moving Forward

Finally, this is what the whole HTML 5 thing is about. XHTML became such a political hot potato that a bunch of people who wanted to move the language forward decided to go in another direction. They produced a spec for HTML 5. This is currently being hashed out in the W3C, and expected to finish sometime in the next decade. In the meantime, browser vendors are picking and choosing features from the in-progress spec and implementing them.

Updates from the Comments

In the comments, Alex points out that if you're going to sniff for something, you should check the Accept header to see if application/xhtml+xml is accepted by the user agent.

This is absolutely correct. In general, if you're going to sniff, sniff for the feature, not for the browser.

这篇关于是否为传统上不是坏习惯的元素编写自闭标签?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆