Topik temu duga representatif

Temu duga Frontend: Bagaimanakah anda mengasingkan anchor dalam komponen berulang dengan CSS anchor-scope?

FrontendSederhana
Pasukan Editorial Offer.ccDiterbitkan Dikemas kini

Soalan

Halaman mempunyai kad berulang yang tooltipnya semuanya menggunakan anchor-name yang sama, tetapi setiap tooltip dijajarkan dengan kad yang terakhir. Terangkan sebabnya dan reka bentuk pengasingan anchor-scope, fallback, serta strategi sokongan pelayar.

Arahan dan skop

Suatu senarai mengandungi kad yang berulang. Setiap kad mempunyai pencetus (trigger) dan tooltip yang diletakkan secara mutlak (absolutely positioned). Pencetus menggunakan anchor-name yang sama, dan tooltip merujuknya dengan position-anchor; setiap tooltip dijajarkan dengan anchor bernama serupa yang terakhir dalam dokumen. Reka bentuk skop penamaan, sempadan komponen, fallback, dan ujian.

Tumpukan perhatian kepada cara anchor-scope mengehadkan carian anchor bernama yang eksplisit. Ini bukan pengasingan Shadow DOM, dan belum semua pelayar menyokong ciri Baseline 2026 ini lagi.

Perkara yang diuji oleh penemu duga

  • Menerangkan sebab anchor bernama serupa tanpa skop boleh diselesaikan mengikut susunan sumber (source order).
  • Membezakan antara none, all, dan senarai nama dashed-ident.
  • Mengendalikan anchor tersirat (implicit anchors), pohon bayang (shadow trees), fallback limpahan (overflow), dan pelayar yang tidak disokong.
  • Mengubah aturan menjadi kontrak komponen yang boleh diguna semula, DOM yang boleh diuji, dan fallback yang boleh diperhatikan.

Soalan penjelasan

  1. Adakah tooltip mesti merentasi leluhur (ancestor) kad, atau adakah ia mesti kekal di dalam subpokok (subtree) kad?
  2. Bolehkah komponen bersarang (nest), menggunakan Shadow DOM, atau memindahkan (portal) tooltip ke tempat lain?
  3. Apakah pengalaman yang mesti dikekalkan oleh pelayar lama?
  4. Adakah nama anchor dijana oleh sistem reka bentuk atau ditulis tangan bagi setiap halaman?
  5. Kes limpahan, fokus papan kekunci, dan saiz semula yang manakah diperlukan?

Jawapan 30 saat

“Nama anchor yang sama tidak mempunyai sempadan keterlihatan, jadi elemen yang diletakkan kedudukan boleh menyelesaikan anchor sepadan yang terakhir dalam susunan sumber. Saya menetapkan bekas kad sebagai punca skop dan menggunakan anchor-scope: --card-anchor, atau all apabila setiap nama dalaman perlu diasingkan, supaya tooltip diselesaikan dalam subpokok tersebut. Saya membalut peraturan peningkatan dalam @supports dan kembali kepada bekas relatif berserta peletakan kedudukan mutlak sebagai fallback. Ujian meliputi penyarangan, portal, limpahan, tingkah laku papan kekunci, dan pelayar dengan sokongan yang berbeza. Saya mendokumentasikan nama dan sempadan DOM sebagai sebahagian daripada kontrak komponen.”

Reka bentuk langkah demi langkah

1. Diagnosis perkaitan yang salah

anchor-name dan position-anchor mencipta perkaitan yang eksplisit. Dengan beberapa anchor bernama serupa dan tiada skop, elemen yang diletakkan kedudukan boleh menyelesaikan anchor sepadan yang terakhir dalam susunan sumber, menyebabkan tooltip berulang bertindih bersama. Periksa anchor yang dihitung, susunan DOM, dan blok mengandungi (containing block) dalam DevTools sebelum menyalahkan saiz atau konteks susunan (stacking context).

2. Pilih sempadan skop

Tetapkan anchor-scope pada setiap bekas kad untuk mengehadkan carian nama yang dipilih kepada subpokok elemen tersebut. all merangkumi nama anchor dalam subpokok; --card-anchor hanya mengehadkan nama tersebut, membiarkan nama lain tersedia untuk perkaitan rentas komponen. Skop tidak mengehadkan anchor tersirat atau bertindak sebagai pengasingan gaya atau pewarisan umum.

css
.card {
  anchor-scope: --card-anchor;
}

.card__trigger {
  anchor-name: --card-anchor;
}

.card__tip {
  position: absolute;
  position-anchor: --card-anchor;
  position-area: block-end;
}

3. Tentukan kontrak penamaan komponen

Anggap nama anchor sebagai antara muka dalaman komponen. Punca, anchor, dan elemen yang diletakkan kedudukan mesti kekal dalam subpokok yang dijangkakan, dan leluhur arbitrari tidak boleh mengatasi skop. Untuk penyarangan, pilih nama mengikut tahap atau set semula skop di dalam komponen dalaman. Sahkan kontrak DOM dalam ujian komponen atau Storybook.

4. Tambah pengesanan keupayaan dan fallback

MDN menandakan anchor-scope sebagai Baseline 2026, tetapi pelayar lama mungkin belum melaksanakannya. Letakkan aturan peningkatan di belakang @supports (anchor-scope: all). Tanpa sokongan, gunakan bekas relatif dengan inset mutlak, geometri JavaScript, atau komponen tooltip sedia ada. Kekalkan susunan fokus, nama yang boleh diakses, dan kandungan yang tidak terlindung dalam fallback.

5. Nilaikan portal, Shadow DOM, dan anchor tersirat

Skop anchor mempengaruhi perkaitan anchor bernama yang eksplisit. Jika tooltip di-portal ke luar kad, ia mungkin meninggalkan subpokok skop; gunakan nama unik, hantar geometri, atau kekalkan laluan peletakan kedudukan sedia ada. Pohon bayang mempunyai skop pohon tersendiri dan memerlukan ujian sempadan. Jangan gunakan anchor-scope sebagai penyelesaian untuk setiap kes anchor tersirat.

6. Uji dan perhatikan

Uji berbilang kad, kad bersarang, sisipan dinamik, penyusunan semula, saiz semula, tatal, zum, fokus papan kekunci, dan portal. Sahkan geometri setiap tooltip, limpahan, pohon kebolehcapaian, dan kadar fallback. Log pengesanan keupayaan dan ralat peletakan kedudukan tanpa merekodkan input pengguna.

Contoh jawapan berkualiti tinggi

“Tanpa skop, anchor bernama serupa boleh diselesaikan kepada elemen terakhir dalam susunan sumber, menyebabkan tooltip berulang bertindih. Saya menetapkan anchor-scope: --card-anchor pada punca kad, anchor-name pada pencetus, dan position-anchor pada tooltip untuk mengehadkan carian eksplisit kepada subpokok kad. Jika semua nama dalaman perlu diasingkan, saya menggunakan all; ini tidak mempengaruhi anchor tersirat atau pewarisan CSS biasa. Pelayar lama menerima fallback @supports kepada peletakan kedudukan bekas relatif dan laluan tooltip sedia ada. Saya menguji penyarangan, portal, Shadow DOM, limpahan, saiz semula, fokus papan kekunci, dan operasi penyusunan semula, serta mendokumentasikan sempadan nama dan DOM dalam kontrak komponen.”

Kesilapan lazim

  • Memberikan setiap elemen nama anchor yang berbeza → komponen tidak boleh diguna semula secara bersih → skopkan nama yang berulang.
  • Menganggap all sebagai Shadow DOM → pewarisan, portal, dan skop pohon masih berbeza → uji sempadan carian dan gaya secara berasingan.
  • Mengabaikan susunan sumber → ujian pada satu kad terakhir menyembunyikan pepijat → uji berbilang kad dan penyusunan semula.
  • Tidak menyediakan fallback → pelayar lama kehilangan peletakan tooltip → gunakan @supports dan laluan mutlak atau JavaScript sedia ada.
  • Menggunakan skop pada anchor tersirat → aturan tidak memberikan kesan yang dimaksudkan → sahkan sama ada perkaitan tersebut adalah eksplisit atau tersirat.

Soalan susulan dan respons

Bilakah anda memilih anchor-scope: all berbanding nilai bernama?

Gunakan all apabila setiap nama anchor di dalam komponen mesti diselesaikan hanya dalam kad tersebut. Gunakan --card-anchor apabila satu nama memerlukan pengasingan tetapi nama lain mesti kekal tersedia merentasi sempadan. Uji kedua-duanya dengan kontrak DOM komponen.

Adakah tooltip mesti kekal di dalam subpokok kad?

Tidak. Portal atau tindanan (overlay) global boleh meninggalkan subpokok skop dan kehilangan akses kepada anchor kad. Berikan tindanan nama anchor yang unik, hantar geometri, atau kekalkan peletakan kedudukan JavaScript daripada memaksa tindanan ke dalam lapisan DOM yang salah.

Adakah sifat ini sedia untuk setiap produk?

MDN melabelkannya sebagai Baseline 2026, manakala W3C CSS Anchor Positioning Level 1 kekal sebagai Draf Kerja (Working Draft). Semak matriks pelayar sasaran dan gunakan @supports berserta ujian keupayaan untuk peningkatan progresif (progressive enhancement).

Sumber awam

Soalan berkaitan