listing 和 xmp 标签因缺乏语义、解析不安全且存在兼容性问题而被淘汰；2. 它们现在被 pre 标签取代，通常与 code 标签结合使用以实现语义化和格式保留；3. 使用 pre 和 code 标签时应正确进行html实体编码，避免解析错误；4. 通过css设置 white-space、overflow-x 等属性可优化显示效果；5. 需注意可访问性、性能优化及样式一致性，提升用户体验和页面专业性。
listing
和
xmp
标签在现代网页开发中已经过时，它们曾经被用来显示预格式化的文本，即保留文本中的空格和换行符。现在，要实现预格式化文本的显示，标准且推荐的做法是使用
pre
标签，通常还会配合
code
标签来表示代码内容。
说实话，提起
listing
和
xmp
，我脑子里首先浮现的是一些老旧的网页教材，或者说，它们是那个HTML标准还不太成熟、浏览器实现也五花八门的年代的产物。它们的主要作用就是“所见即所得”地展示文本，尤其是一些代码片段或者ASCII艺术图，你写什么样，浏览器就原样呈现，不解析里面的HTML标签。这在当时确实解决了一部分问题，比如你不想让浏览器把你的
<p></p>
当作段落标签，而是想展示
<p></p>
这几个字符本身，它们就能做到。
然而，这种“粗暴”的渲染方式，在语义化和安全性要求越来越高的今天，显然是站不住脚的。它们没有明确的语义，而且在处理一些特殊字符时也容易出现问题，甚至可能带来一些意想不到的解析行为。所以，随着HTML标准的演进，尤其是HTML4和HTML5的出现，这些标签就被明确地标记为废弃（deprecated）了。
取而代之的，是更强大、更语义化的
pre
标签。
pre
标签的全称是“preformatted text”，顾名思义，就是预格式化文本。它会保留文本中的空格、制表符和换行符，并且通常会以等宽字体（monospace font）显示。如果你想在网页上展示代码，最好的实践是把
code
标签嵌套在
pre
标签里面，这样既保证了代码的格式，又赋予了这段内容“代码”的语义。
listing
和 xmp
标签为何被淘汰？它们现在被什么取代了？
这事儿，说起来还挺有意思的。
listing
和
xmp
标签被淘汰，主要原因有几个：
首先，它们缺乏明确的语义。在HTML的发展过程中，语义化是一个非常重要的方向。一个标签应该清楚地告诉浏览器和开发者，它所包含的内容是什么类型。
listing
和
xmp
仅仅是“原样显示”，并没有说明这段内容是代码、是日志、还是其他什么。这对于搜索引擎优化、无障碍访问以及未来的内容解析都非常不利。
其次，它们的解析行为不够稳定和安全。由于它们会尝试不解析内部的HTML标签，这在某些情况下可能导致浏览器解析器行为不一致，甚至在极端情况下，如果内容没有经过适当的编码处理，可能会引发一些安全隐患，比如跨站脚本攻击（XSS），尽管这并非它们设计的初衷。更关键的是，它们并没有提供一种标准化的方式来处理包含自身结束标签（例如
）的文本，这在实践中容易造成解析错误。
最后，也是最直接的原因，是有了更好的替代品。
pre
标签的出现，完美地解决了预格式化文本的展示需求，并且它本身就带有“预格式化”的语义。当
pre
标签与
code
标签（用于表示代码片段）结合使用时，更是为代码展示提供了最佳实践。这种组合不仅保留了文本格式，还明确了内容的类型，让机器和人都更容易理解。
如何有效地使用 pre
和 code
标签来展示代码或文本？
使用
pre
和
code
标签来展示预格式化文本，尤其是代码，其实非常直观，但也有一些小技巧能让效果更好。
最基本的用法就是直接把内容放到
pre
标签里：
<pre class="brush:php;toolbar:false;">
这是一个
预格式化的文本，
它会保留所有的
空格和换行。
这段HTML在浏览器里会按照你写它时的样子来显示，包括缩进和空行。
如果你要展示的是代码，那么最好在
pre
标签内部再嵌套一个
code
标签。这样做的目的是提供更强的语义化。
pre
负责“格式”，
code
负责“内容类型”。
<pre class="brush:php;toolbar:false;"><code>
function greet(name) {
console.log(`Hello, ${name}!`);
}
greet("World");
</code>
对于更长的代码块，你可能还会遇到水平滚动条的问题。
pre
标签默认是不会自动换行的，如果一行代码太长，它就会超出容器。这时候，可以通过CSS来控制它的溢出行为，比如让它出现滚动条：
pre {
white-space: pre-wrap; /* 或者 pre-line */
word-wrap: break-word; /* 针对长单词或URL */
overflow-x: auto; /* 水平滚动条 */
font-family: monospace; /* 确保等宽字体 */
background-color: #f6f8fa; /* 稍微有点背景色，更好看 */
padding: 1em;
border-radius: 4px;
}
这里
white-space: pre-wrap;
是一个很有用的属性，它会保留空格和换行，但当内容超出容器宽度时，会自动换行。如果希望完全不换行，只出现滚动条，就用
white-space: pre;
。
overflow-x: auto;
则确保当内容溢出时，会出现水平滚动条。
处理预格式化文本时，有哪些常见的陷阱或最佳实践？
在处理预格式化文本时，有一些细节确实需要注意，避免踩坑。
一个很常见的陷阱是HTML实体编码。如果你要在
pre
或
code
标签里显示HTML代码本身，比如
<p>Hello</p>
，你不能直接写
<p>Hello</p>
。因为浏览器还是会尝试解析
<p></p>
标签。这时候，你需要把
<p> 替换 </p><pre class="brush:php;toolbar:false;"><p>，把 </p><pre class="brush:php;toolbar:false;">>
替换
>
。
<pre class="brush:php;toolbar:false;"><code> <p>这是一个段落</p> </code>
这样，浏览器才会把
<p></p>
显示成
<p></p>
。这是确保内容正确显示的关键。
另一个需要考虑的是可访问性。对于屏幕阅读器来说，
pre
和
code
标签的语义化很重要。它们能帮助屏幕阅读器正确地识别和朗读代码或特殊格式的文本。同时，确保代码块有足够的对比度，字体大小适中，对于视力受损的用户来说也很重要。
再来就是性能问题，尤其是当你有很多或者非常大的代码块时。如果你的页面上有很多
pre
标签，并且每个都包含大量的代码，这可能会影响页面的加载速度和渲染性能。对于这种情况，可以考虑使用一些代码高亮库（比如 Prism.js 或 highlight.js），它们通常会在页面加载完成后，通过JavaScript来处理代码高亮，并且有些库还支持按需加载，可以优化性能。但要注意，引入第三方库会增加文件大小和首次渲染时间，需要权衡。
最后，保持一致的样式。无论你选择哪种方式来展示预格式化文本，确保它们在整个网站上都有统一的视觉风格，比如背景色、字体、行高和内边距。这不仅提升用户体验，也让你的网站看起来更专业。这通常通过统一的CSS样式来实现。
