【Chrome】details要素の中で数式やmermaid.jsが正常にレンダリングされなくなった問題の調査

https://github.com/zenn-dev/zenn-community/issues/366
https://github.com/zenn-dev/zenn-community/issues/361

Chromeでアコーディオンの中でのみ数式やmermaid.jsが正常に表示されない。Web Componentを使っていることが影響しているかも？

ab=c

同じくweb componentを使っているツイートの埋め込みでは問題なく表示される

https://twitter.com/Jack/status/20

Chromeでは発生するが、FirefoxとSafariでは問題なくレンダリングされる。

Chrome 96では問題は発生せず、97から問題が起きることが分かった。

このあたりが影響していそうだ

• https://bugs.chromium.org/p/chromium/issues/detail?id=1276028&sort=-opened&q=component%3ABlink>HTML>Details&can=1

Chrome 97から<details>内の要素が検索可能になったが、そのために<details>のレンダリングの仕方を変えたっぽい

This was an intentional change because I made <details> use content-visibility:hidden instead of display:none.
The rationale is that we want to do find-in-page inside closed details elements, and that caching the layout information like this makes it so we can run find-in-page while the details is closed without recomputing the layout information.

その結果<details>内でgetBoundingClientRect()がこれまで通りには動かなくなったと

chromiumチームとしてはissueと認識してくれているが、現在 w3c/csswg-drafts/issues/6850で関連部分のプロポーザルを議論している段階。

しばらく待つ必要がありそう

My comment only suggested that getBoundingClientRect is already an unreliable way to detect visibility. Your point is well received that this is just making a bad situation worse, in terms of making the cases where it fails to detect visibility (or lack thereof) more prevalent.

We're currently working on a proposal ( https://github.com/w3c/csswg-drafts/issues/6850 ) to address this and other similar visibility cases (this does not address clipped overflow cases), which can be used in conjunction with viewport/getBoudngingClientRect to get the right value. Do you think this would satisfy the testing use cases?

Specifically, the code would be something like
bounds(el) {
return el.isVisibleToDocument() ? el.GetBoundingClientRect() : new DOMRect();
}

For true visibility, as in including clips and all of that, we do have IntersectionObserver which was designed specifically to detect viewport visibility.

https://github.com/w3c/csswg-drafts/issues/6850

来週より詳しく調査する

結論: Custom Elementsのthis.innerTextが空になっていたことが原因

調査したところ、Chrome 97からCustom Elements内においてthis.innerTextが空の文字列になってしまうことが分かった。例えば以下のようにCustom Elementを設置した場合、

<embed-katex>$a\ne0$</embed-katext>

<embed-katex>の処理において、通常であればthis.innerTextとして$a\ne0$という文字列が習得できる。

しかし、以下のように<details>タグ内に配置すると、Chrome 97からはthis.innerTextの値が""となる。

<details>
  <summary>詳細</summary>
  <embed-katex>$a\ne0$</embed-katext>
</details>

対策

this.textContent || this.innerTextという書き方をすれば文字列（$a\ne0$）を習得できるようになる。