如何突出显示HTML文本而不用标签包装它？

Question

是否可以突出显示HTML文档中的文本而不包含它<span>或任何其他标记？

例如,在HTML代码中<p>The quick fox</p>我想突出显示quick但不添加围绕它的DOM元素.将DOM元素添加到父元素就可以了.

谢谢!

Answer 1

不,这是不可能的.

无论是静态还是动态地改变DOM,您都无法告诉浏览器以不同方式呈现一段文本(例如,使用Javascript作为后处理步骤).

Answer 2

CSS 自定义突出显示 API

浏览器供应商正在努力明确支持突出显示模式 - 使用令人难以置信的多功能新“自定义突出显示”API。

自版本 105 (2022-09-02) 起，该功能已在 Chrome 衍生品中提供，目前 Firefox Nightly也支持此功能。

https://developer.mozilla.org/en-US/docs/Web/API/CSS_Custom_Highlight_API

请注意我的回答，我用更长的形式描述了这一点：

/sf/answers/5463581301/

现在有多种方法可以在不修改 DOM 元素结构的情况下实现这种效果。

然而，它们都有自己的警告。

这个答案源自我对开源浏览器扩展“标记我的搜索”（存储库）所做的研究，该扩展突出显示您在网页上搜索的文本。所接受的方法的自然破坏性导致我考虑了许多替代方案。如果未选中高级选项“使用经典突出显示”，则扩展将仅使用以下方法之一，由于我将要描述的缺点，这不是默认选项。

我下面的所有方法都只涉及向 DOM 添加额外的绘制，因此没有设置文本样式或以其他方式更改现有内容的选项。然而，它们完全是非破坏性操作，可以提高效率，使其成为具有竞争力的替代方案。

重要提示：此答案的假设是您可以直接将样式应用于元素，或者使用样式表和生成的属性来远程应用它。这种类型的 DOM 操作仍然是需要的。

方法

1. 整体式

   • 用单个元素覆盖整个内容区域。

   • 将所有突出显示绘制到元素上。

     • 获取所需文本范围的客户端矩形。
     • Compare with the client rects of the overall element, obtaining the relative drawn text positions.*
     • Use one of the implementations below.

   Pros:

   • Simple, obvious.
   • All highlighting managed in one place.
   • Efficient for mutations of many elements at once.

   Cons:

   • Many compromises. If you choose to overlay the highlights, opacity of highlighting is necessarily a compromise between visibility and obscuring text. If you underlay, you must remove all backgrounds to avoid highlights being hidden.
   • Inefficient for mutations of few elements, as everything must be recalculated at once (partially mitigated by caching).
   • Inefficient for implementations that perform best in small, disparate frames.

2. Composite

   • For all text to be highlighted, look at the lowest-level distinct elements which contain parts of the text ranges.

   • Draw highlighting onto each of these elements.

     • Get client rects of the required ranges of text.
     • Compare with the client rects of the specific containing element, obtaining the relative drawn text positions.*
     • Apply one of the implementations below to the containing element.

   Pros:

   • Removes problem of highlights being hidden by element backgrounds.
   • Layout shifts will to an extent carry highlighting with them, reducing the need for vigilant updates/recalculations.
   • Much more pertinent to underlay instead of overlay, so less compromise between obscuring text and emphasising it.
   • Efficient for updates of few elements, as highlighting is modular and decomposed into a range of distinct areas.

   Cons:

   • Complex, nuanced.
   • Under some implementations, one background (normally background-image) is still potentially lost per highlighted element.
   • Inefficient for mutations of many elements at once
   • Inefficient for implementations that perform best in large, few frames.

3. Hybrid

   • Combine highlighting responsibility into a few elements (for example, ones with display: block to handle highlights for its display: inline children).

Implementations

1. Elements

   • Create highlighting elements of appropriate sizes.
   • Absolutely position them such that they cover the intended areas.

   Pros:

   • Faultless browser support.
   • Infinite effects are available.

   Cons:

   • Heavyweight, slow, DOM-reliant.
   • Adds many superfluous elements to the main structure of the page, disruptive.

2. SVG

   • Percent-encode an SVG drawing the laid out highlighting elements.
   • Use url() on the background-image of the ancestor element.

   Pros:

   • Pretty fast.
   • Compatible with modern browsers.

   Cons:

   • Page CSPs will (rarely) block the use of url(), expecting it to extract remote content.

3. Canvas

   • Percent-encode a canvas drawing the laid out highlighting elements, or use a <canvas> element.
   • Use url() on the background-image of the ancestor element.

   Pros:

   • Compatible with modern browsers.

   Cons:

   • Extremely slow after only a few canvases (especially large ones), presumably due to each pixel being explicitly painted. Seems to be poorly optimised, particularly for transparent pixels.
   • If url() is used: Page CSPs will (rarely) block the use of url(), expecting it to extract remote content.

4. Houdini

   • Register a Paint worklet that draws highlights based on sizing and positioning CSS variables, with whatever additional info you deem necessary (see details of Houdini Paint API).
   • Use background-image: paint({worklet name}) as appropriate on elements to display highlighting.
   • Define CSS variables (the ones consumed by the worklet) on the same element - consider using a stringified JSON object for this which will be unpacked within the worklet, it's surprisingly efficient.

5. element()

   • Create highlighting elements of appropriate sizes.
   • Absolutely position them such that they cover the intended areas, in a dedicated portion of the DOM (offscreen).
   • Use background: element({ID of highlighting element}) as appropriate on elements to display highlighting.

   Pros:

   • Infinite effects are possible.
   • Much more viable than the direct DOM alternative.

   Cons:

   • Specific to Firefox, on which it is experimental but has been supported for years.
   • For some reason requires application to background instead of just background-image, resulting in more overriding of element backgrounds. This seems to be an oversight.
   • Heavyweight, a little slow, DOM-reliant.

Dynamically Updating

I won't go into much detail about this, as it is very specific to your needs. However, to obtain fully up-to-date highlighting when applied to an entire page, I needed:

• A MutationObserver observing subtree, childList, and characterData for the document body, in order to detect all changes that may affect matching. My case is very extreme, which is why I must observe the entire document; I optimised using various methods, including filtering out events that did not require attention.

• A ResizeObserver observing highlighted elements currently in view, in order to recalculate highlighting when layout shifts occur.

• An IntersectionObserver observing all highlighted elements for when they appear in the viewport, in order to draw highlighting and the ResizeObserver only when needed. This is an optimisation measure only.

Information

Here is the PR in which I achieved this, using multiple of the above methods which could be swapped out. I used a highly structured approach - involving caching across the DOM and other optimisations, such as decomposing it into multiple stages - to make it efficient even for cases where all of an average page has been highlighted in various colours. An overview is presented in the PR.

This being one of the most extreme possible cases, it should be entirely possible for others to achieve good results without significant performance loss.

I am happy to answer any questions regarding my implementation, or getting started with these technologies.

Articles

• https://developer.mozilla.org/docs/Web/API/CSS_Painting_API
• https://developer.chrome.com/blog/paintapi/
• https://drafts.csswg.org/css-images-4/#element-notation

Notes

*Due to convoluted browser behaviour when it comes to the association of client rects with actual layout+position, it is very difficult to make sure an overlay-based highlighting algorithm will position highlight-boxes correctly in all cases. I have still not managed to correctly account for the effect of border (which disrupts calculations) or strange cases of flow content, but it is technically possible using only the results of Range.getClientRects() and Element.getClientRects().