Orkuncakilkaya
7e07573026
Clicking a keyword, type, builtin or namespace method in a code sample is supposed to open a summary card for it. The script that builds those cards never went away; its stylesheet did. The site redesign split item.css into base.css and docs.css and filed the card chrome — .hovercard, .hc-*, .tok, .kind-badge — under docs.css. Only the four reference page kinds link that file. The landing page links base.css and site.css, so a click there appended an unstyled, position:static div to the end of the document: built, filled with the right text, and invisible. The card chrome now sits in base.css beside the .t-* token colours it belongs with, which every page links. It is also position:fixed rather than absolute, matching the viewport coordinates positionCard() reads out of getBoundingClientRect() — absolute put the card an entire scroll offset away from its token on any reference page read past the fold. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
641 B
641 B
bump: patch
type: fix
Token cards are back on the docs site. Clicking a keyword, type, builtin or
namespace method in any code sample opens its summary card again. The card's
styling had been left behind in docs.css during the site redesign, so on the
landing page — which links only base.css and site.css — the card rendered
unstyled at the foot of the document instead of beside the token. It now lives
in base.css with the rest of the highlighter chrome, and is positioned
fixed, matching the viewport coordinates the script computes, so a card opened
on a scrolled reference page lands on its token rather than off it.