<b>
和<i>
的含义相当明确,并且比<strong>
和<em>
易于键入。 弃用这些标签的正式论据是什么?
#1 楼
去年夏天,我阅读了完整的HTML5规范,每个以前的HTML规范(甚至是废弃的HTML规范),我能找到的所有CSS规范以及许多XML规范。由于我喜欢语义丰富的超文本文档,因此让我为您介绍HTML5中相关HTML语义的背后的概念。在HTML5之前
在HTML5之前,
i
和b
确实不存在。时尚。原因是它们本质上分别像em
和strong
一样工作,但是侧重于表示而不是语义(这是不好的)。实际上,
i
意味着文本应该用斜体显示(说了一些有关如何在屏幕上呈现文本的内容。另一方面,em
表示要强调文本(它说了一些有关文本语义的内容)。这里有一个重要的理论差异。如果使用
em
,则用户代理(= browser)知道应突出显示该文本,因此,如果在屏幕上显示该文档,则可以将其显示为斜体(如果无法设置格式,则可以全大写,甚至可以使用粗体显示)是用户偏爱的语言),如果向用户说文档等,它的发音可能会有所不同。例如,短语猫是我的。 (=不是狗!)
猫是我的。 (=不是您的!)
含义不同。
b
(粗体字体)和strong
(强烈强调)具有相同的区别。一般而言,数字写作,特别是超文本创作的一般原则是,您应将内容和样式分开。在超文本创作中,这意味着内容应在HTML文件中,样式应在CSS文件(或多个CSS文件)中。一个不同但相关的原则是文档应具有丰富的语义(例如标记页眉,页脚,列表,重点,地址,导航区域等)。这具有许多优点:
计算机程序更容易解释文档。这些程序包括浏览器,文本到语音应用程序,搜索引擎和数字助理。 (例如,浏览器可以让您将地址保存到地址簿中,前提是它可以找到并解释该地址。此外,如果正确标记标题,您可能会知道Microsoft Word可以为您创建并自动更新目录。)
以后更改样式要容易得多。 (如果要更改860页文档中所有第三级标题的颜色,则可以在样式表中更改一行。如果内容和演示文稿混合使用,则必须手动浏览整个文档
您可能会错过一个或两个标题,使文档显得不专业。)
您可以根据情况使用不同的样式表(文档是显示在屏幕上还是打印在纸上?)。您甚至可以让最终用户自己选择样式。 (我的网站提供了许多替代样式表。在IE和FF中,您可以使用“查看”菜单进行更改。)
因此,简而言之,由于不赞成使用
i
和b
是与演示有关的HTML标签,这是完全错误的。在HTML5中
在HTML5中,不再弃用
i
和b
。相反,它们被赋予语义含义。因此,它们现在实际上是关于语义的,而不是关于表示的。和以前一样,您使用
em
来标记重点:“猫是我的。”但是几乎在所有其他在印刷作品中使用斜体的情况下,请使用i
。例如:您使用
i
标记生物分类名称:“我喜欢R. norvegicus。” 您使用
i
标记短语的语言与周围的文本:点菜在谈论单词本身时,您使用
i
标记单词:“ drink既是名词又是动词” 它使用
class
属性来指定精确用法(也是Google的“微格式”和“微数据”)也是一个好主意。而且,当然,在第二种情况下,您应该真正使用lang
属性来指定正确的语言。 (否则,例如,文本语音转换代理可能会误读该文本。)大约在一年前,HTML5规范还指出
cite
应该用于标记图书名称,电影,歌剧,绘画等:您对性爱狂的看法如何?
最后,很久以前,
dfn
用于标记定义短语在文本中的实例(如数学定义或术语的定义):组是配备有单个二进制运算符*的集合X。 。
因此,印刷书籍中的斜体字可能表示许多不同的内容,由四个不同的HTML5标签表示,这非常好,因为语义很好,正如我试图说服您的那样大约早一点。 (例如,您可以要求您的浏览器列出文本中的所有定义,以确保在考试之前都知道它们。)
转到
strong
和b
,HTML5规范说strong
应该用于标记文本的重要部分,例如警告或句子中一些非常重要的单词。另一方面,应该使用b
来标记需要在文本中轻松找到的内容,例如关键字。我还将b
用作列表项(LI)中的标题。评论
更正:定义标记为,而不是
– AmeliaBR
2014年9月7日14:46
@AmeliaBR。感谢您注意打字错误(def)。关于定义列表:定义列表应用于名称-值对,而我总是为此使用它们(例如,请查看我的留言簿)。我也喜欢display:run-in,但是由于它的支持正在减少,因此您必须使用float或content:技巧,请参阅rejbrand.se/rejbrand/news.asp?ItemIndex=169。当我谈论使用b标记列表中的“标题”时,我并不是指名称/值对,而是简单的列表,其中我想在每个项目中使用“标题”。
– Andreas Rejbrand
2014年9月7日15:04
@SarahofGaia在推理保证加粗文本方面至少存在两个缺陷。 1)屏幕阅读器,盲文显示器和其他消耗文本的方法,对于它们来说,较粗的字形是没有意义的概念。 2)b {font-weight:normal},表示的显示样式也不固定。
– 8bittree
16年7月29日在13:44
最后,如果您不信任浏览器,则始终可以自由提供自己的CSS:b,strong {font-weight:bold; }。这样,您就可以尽可能确定。 CSS是指定视觉格式的方法。 HTML是关于含义(内容)的,CSS是关于视觉表示的。
– Andreas Rejbrand
16年7月31日在16:51
这个答案使我理解了为什么我需要将字体标签更改为css。我一直喜欢字体标记为黑体字,而现在,我明白了为什么不应该使用它们。谢谢
–安德烈亚斯(Andreas)
17年5月31日在21:09
#2 楼
如Doval所说,它们不被弃用。它们仍然存在,但使用方式应不同于HTML5之前的许多人。这是关于“语义” html的。它应该描述它是什么,而不是它的外观。从浏览器或理论上讲,任何其他显示媒体(例如盲人的阅读应用程序)都应该能够决定应如何准确解释。
这与为什么您不应该使用CSS类名(例如“ red”)相似。 ”,并在此处使用更具描述性的类来描述使用其他颜色背后的功能思想。您稍后可能会认为绿色更好(也许应该使用红色而不是粗体显示任何“强”)。或色盲用户可能具有一些特殊的浏览器设置,在这些设置中,其他颜色已被替换。
评论
在任何情况下,最好使用而不是吗?还是始终是“更具语义”的标记?
– LanceLafontaine
2014年9月4日14:48在
大约可以将用于应“突出显示”但不能“强调”的内容,例如文本中的关键字。在技术文档中,您经常发现用于显示某些属性的不同文本样式,例如在编程书籍中的代码示例或技术术语。对于此类用例,可以使用技术术语或。
–瑟森·穆勒
2014年9月4日14:56
@LanceLafontaine看看官方标准。
– Rufflewind
2014年9月4日15:56
@thorstenmüller我认为这也是一个不好的例子……在教科书中,管理层后来决定,他们要使用打字机字体而不是黑体而不是黑体,而是用下划线来表示属性,在这种情况下,使用 ... span>首先可以为您省去很多麻烦。
–计算机芯片
2014年9月5日在9:21
@LanceLafontaine 是一个极端的例子,但是对于不适合的情况,有很多使用的示例:物种的科学名称或英语中使用的拉丁词(您可以使用跨度和语言属性,但这还有其他各种含义-屏幕阅读器可能会切换其他语言的声音)。尽管语义上正确的方法是使用,但它也可以用于斜体其他作品的标题。
– AmeliaBR
2014年9月5日15:02
#3 楼
真实的故事是,b
和i
首先在各种HTML5草案中被废弃,弃用,被诅咒并被动画化为“代表性的”(广泛地说),但随后他们意识到这些标签被广泛使用,并且由许多创作程序生成。他们不是简单地允许他们使用,而是为他们开发了人为的新“语义”定义,以便能够允许使用元素,但仍然假装对“代表性”标记严格。新的定义从一个草稿到另一个草稿都各不相同,而且晦涩难懂:您很难找到两个人以相同的方式理解和解释它们。对不起,没有参考文献。上面的描述是跟踪更改并阅读草案和讨论的结果,通常是在两行之间。他们没有明确说明原因。我仍然认为这是真实的故事。
结论是:继续。这里没有什么用。
b
和i
元素执行与以前相同的操作:使用通常的警告分别使字体变为粗体或斜体。这是您应该考虑的现实,而不是对浏览器,搜索引擎或其他软件没有影响的准弹性“语义”。评论
就是说,只要将视为一种有趣的(默认情况下以粗体显示),就可以遵循准弹性的语义。然后,如果您可以打扰,也可以给它的使用分配一个class属性,以便在必要时可以立即重新命名使用它的多个事物,因为它们具有共同的语义。从某种意义上说,这是准弹性的,人们会认为您在做b.productname {font-weight:normal;字体样式:斜体; }在您改变了对表示的想法并利用了明智的语义标记选择之后;-)
–史蒂夫·杰索普(Steve Jessop)
2014年9月4日20:10
@SteveJessop:对于我们中仍在乎文件大小的少数人来说,说 this 似乎比 this (八个字节)前者的开销足够令人讨厌;后者的23字节开销似乎很疯狂)。我想知道为什么HTML从未定义任何简短形式的表示形式,例如<@quack> this @>等同于 this span>吗?
–超级猫
2014年9月4日20:29在
@supercat:这就是传输编码:gzip的用途。或者也许是XML + XSLT,具体取决于您要在何处以及如何为“嘎嘎”引入更简洁的符号。
–史蒂夫·杰索普(Steve Jessop)
2014年9月4日20:53
@supercat class ='大胆'? 《无代码守则》的Suku大师会与您谈谈使用此类不良类名的方法。考虑这是您最后的boldRedText。
–user69037
2014年9月4日23:33
在14.4调制解调器时代,CSS是尚未在任何用户代理中实现或实现的想法。这些HTML元素仅仅是古老的遗留问题,我们将永远坚持下去。
–迈克尔·汉普顿
2014年9月5日上午11:04
#4 楼
<b>
和<i>
标签起源于“粗体”和“斜体”的概念。问题是这些对于某些用户代理可能完全没有意义。例如,对于盲人来说,在屏幕阅读器中的“斜体”听起来像什么?用
<strong>
和<em>
代替它们会删除与印刷概念的直接链接。相反,用户代理可以根据需要呈现它们。评论
严格来说,用户代理可以渲染和,但是它也认为合适。
–乔纳森·尤尼斯(Jonathan Eunice)
2014年9月5日13:51
#5 楼
当您确实需要'bold'或'italic'文本时,<b>
和<i>
标签是必不可少的。如果您使用HTML编写的方程式中,斜体的“ I”与不斜体的“我”很重要,要能够做到这一点。等式而不使用此类“外观”标签。
纯粹的方法是使用MathML或TeX,但尚不支持浏览器...
评论
我希望推动“语义”标记的人们能够认识到,在某些情况下,旧标记比任何其他标记在语义上都更正确。如果文档的文本引用了某些带下划线的单词,那么以除下划线之外的任何方式显示这些单词在语义上都是错误的。如果要从系统中导入文本,该系统将其中的某些文本放置在等宽的字体中,但对原因不做任何区分,那么对使用“替换”之一将错误地暗示执行导入的代码知道的内容不止于此。它做到了目的。
–超级猫
2014年9月4日20:24在
我同意b和i在数学(和物理)上下文中的适用性,但是HTML5草案中未提及这种用法。当我提出这个问题时,我得到了认真的回应,改为使用Unicode特殊字符(数学粗体字母和数学斜体字母)!
– Jukka K. Korpela
2014年9月4日20:50
@supercat:一般的主张(我承认这并不总是适用)是您不应该写用户代理不能兑现的支票。特别是,您不应该写一个声称某人的屏幕阅读器将以等宽字体显示的页面(我想应该是一个机器人语音:我从未真正使用过屏幕阅读器)。当然,这忽略了大多数人的页面至少不会在屏幕阅读器上运行,因此,他们为自己不关心的假设可访问性付出了任何代价,这毫无意义。但是W3C出于原则上故意忽略了这一事实。
–史蒂夫·杰索普(Steve Jessop)
2014年9月4日在21:01
在代码导入的情况下,我想规范的答案(如果不能令人满意)是class =“ source-X-asserts-it-should-be-monospace”,从而将其与语义上有所不同的文本区分开来,其他来源出于未知原因断言它应该是等宽的。实际上,这是在审核HTML认为不良的内容,而不仅仅是将不良转化为HTML。
–史蒂夫·杰索普(Steve Jessop)
2014年9月4日在21:05
@SteveJessop:换句话说,我们应该改进,它直接建议将文本设置为具有对比的等宽字体,并在经过几层间接定向后将标记表示应以某种特定字体显示文本碰巧是等宽的。虽然我不希望所有的屏幕阅读器都对做一些有用的事情,但我希望他们使用的时间比容易得多。
–超级猫
2014年9月4日在21:13
#6 楼
HTML标签的设计原则是它们应该是“语义的”,即它们应该指示含义和意图,而不是低级的指令。经典的测试是“可以在浏览器中有意义地使用标签吗?为盲人”。
因此,对于基于音频的浏览器,斜体字的“ i”几乎没有用,因为您不能使用斜体字。但是,“ em”标签很有意义,因为音频设备可以通过许多方式来强调某个短语:提高音调,增加音量或改变重音。盲文渲染器可以通过提高点的间距,改变大小或增加振动来强调。
评论
就像您说的那样,您不能使用斜体语言-但是您可以使用斜体文本,其中斜体的事实具有语义含义,例如方程式...
– SAL
2014年9月5日在9:14
“因此,对于基于音频的浏览器,斜体字的“ i”几乎没有用,因为您不能使用斜体字。 ...是的,也是如此,因为您不会说图像,并且没有声音硬件的系统也无法显示
评论
我相当确定和不被弃用。相关阅读:和,和有什么区别?以及与?
我倾向于这样思考:我是否希望屏幕阅读器以不同的方式阅读?如果我只想挑选一个(非盲人)读者容易找到的单词,则可以使用b-字面意思是“这是粗体的”,而不是“这是强调的”。但是要点是,它们的含义不同-没有贬义,不是一个当您过去做b或i时通常表示“强”或“ em”的意思。
@MichaelT我记得当我刚开始使用LaTeX时,我对从空白文档开始(没有样式包)时斜体和粗体显示文本的所有不同方式感到困惑。
@Luaan:即使实际上不推荐使用和,但和也是不适用的,问题将同样适用于它们。