Risalah Rapat Jarak Jauh CSSWG (18-09-2024)

21/09/2024

Selama beberapa bulan terakhir, seluruh mata pencaharian saya adalah membaca, meneliti, memahami, menulis dan mengedit topik positioning, dan dengan beberapa entri kalender yang diterbitkan dan panduan cara kerja yang lengkap, saya pikir saya adalah siap untuk mengakhiri semuanya dan mengakhirinya. Saya tahu positioningnya masih baru dan menetap. Namun, kecepatan pergerakannya sungguh menakjubkan. Ada lebih banyak lagi CSSWG!

Jadi, saya sedang melihat risalah pertemuan CSSWG terakhir, dan saya tahu bahwa saya berada dalam posisi yang lebih tepat ketika saya mengambil keputusan berikut:

Saat Anda membandingkan nama, dan setidaknya salah satu nama berada dalam cakupan pohon, keduanya berada dalam cakupan pohon, dan cakupannya harus tepat (bukan sub) (Masalah #10526: Kapan anchor-scope kata benda yang “cocok”?

Resolusi bukanlah bagian dari spesifikasi atau semacamnya, namun merupakan indikator terkuat arah yang Anda tuju. Jadi, saya pikir ini adalah kesempatan bagus untuk tidak hanya melihat apa yang mungkin kita hadapi anchor-scope Dan sentuh bagian menarik lainnya dari panggilan telepon.

Ingat, Anda dapat berlangganan dan membaca prosiding selengkapnya di W3C.org. 🙂

Teks lengkap

Apa itu anchor-scope?

Untuk mendaftarkan jangkar, kita bisa memberinya tanda pembeda anchor-name Kemudian tempatkan elemen-elemen tersebut pada posisi absolutnya dengan pencocokan position-anchor terkait dengannya. Meski kelihatannya begitu, anchor-name Tidak harus unik – kita dapat menggunakan kembali elemen jangkar di dalam komponen dengan elemen yang sama anchor-name.

<ul>
   <li>
	<div class="anchor">Anchor 1</div>
	<div class="target">Target 1</div>
   </li>
   <li>
	<div class="anchor">Anchor 2</div>
	<div class="target">Target 2</div>
   </li>
   <li>
	<div class="anchor">Anchor 3</div>
	<div class="target">Target 3</div>
   </li>
</ul>

Namun, jika kita mencoba menghubungkannya menggunakan CSS,

.anchor {
  anchor-name: --my-anchor;
}

.target {
  position: absolute;
  position-anchor: --my-anchor;
  position-area: top right;
}

Kami mendapat kejutan yang tidak menyenangkan di mana alih-alih… .anchor Mereka punya .target Letaknya di tepi kanan atas, artinya semuanya bertumpuk di tepi terakhir .anchor Misalnya, kita dapat melihatnya lebih baik dengan memutar sedikit setiap target. Anda mungkin ingin melihat demo berikut di Chrome 125+ untuk melihat perilakunya:

Opsi penyertaan CodePen alternatif

itu anchor-scope Properti harus membuat elemen jangkar hanya dapat ditemukan oleh target di subpohon individualnya. Jadi contoh sebelumnya akan diperbaiki kedepannya sebagai berikut:

.anchor {
  anchor-name: --my-anchor;
  anchor-scope: --my-anchor;
}

Hal ini cukup jelas – anchor-scope Membuat elemen jangkar hanya tersedia di subpohon tertentu. Tapi kemudian kita harus mengajukan pertanyaan lain: <>Apa yang seharusnya anchor-scope Apakah ini domain pribadi? Kita tidak bisa memilikinya anchor-scope-scope Properti kalau begitu anchor-scope-scope-scope Dan seterusnya… Bagaimana seharusnya perilakunya?

Inilah yang memulai percakapan, awalnya dari sebuah masalah di GitHub:

Kapan itu terjadi anchor-scope Hal ini ditentukan oleh <dashed-ident>ini menetapkan cakupan nama untuk subpohon tersebut ketika nama jangkar “cocok”. Masalahnya adalah pencocokan ini dapat diinterpretasikan setidaknya dalam tiga cara: (Dengan asumsi demikian anchor-scope Ini adalah referensi cakupan pohon, yang juga tidak jelas dalam spesifikasinya):

  1. Pencocokan dilakukan berdasarkan bagian identitas dari nama saja, mengabaikan cakupan pohon apa pun yang mungkin terkait dengan nama tersebut, atau
  2. Cocok dengan pencocokan tepat bagian identitas dan rentang pohon terkait, atau
  3. Pencocokan dilakukan melalui beberapa mekanisme yang mirip dengan dereferensi cakupan pohon, di mana pencocokan terjadi ketika cakupan pohon dari nama domain jangkar adalah nenek moyang global dari cakupan pohon kueri jangkar.

Dan kemudian kita beralih ke notulensi CSSWG:

Tabatkin: Dalam penempatan jangkar, nama jangkar dan referensi ditentukan di seluruh pohon. anchor-scope Properti yang menentukan cakupan tidak menunjukkan apakah nama termasuk dalam cakupan pohon. Pertanyaan yang harus kita putuskan: Haruskah demikian?

Tabatkin: Saya pikir jawabannya harus ya. Jika Anda memiliki jangkar di pohon bayangan yang memiliki bagian yang terlibat, masalah akan terjadi jika rentang jangkar tidak ditentukan pada skala pohon. Ini buruk, jadi menurut saya mereka harus dicakup dalam lingkup pohon, sejauh yang saya bisa mengerti, ini sangat masuk akal 🙂

Solusi ini memperluas properti cakupan ke arah transisi tampilan, yang juga mengandalkan cakupan pohon agar berfungsi:

Bagus: Saat memikirkan hal ini dalam konteks transisi tampilan: Di API ini, Anda dapat memberikan nama dan cakupan pohon harus sama agar cocok. Ada fitur lain dari transisi tampilan di mana saya tidak yakin apakah spesifikasi menyatakan itu adalah cakupan pohon

Bagus: Saya ingin memastikan fitur ini tercakup dalam resolusi yang lebih umum

Tabatkin: Solusi paling umum yang diusulkan: setiap kali Anda membandingkan nama, dan setidaknya salah satunya berada dalam cakupan pohon, maka keduanya berada dalam cakupan pohon, dan cakupannya harus tepat (bukan subpohon)

Jadi jangkauannya anchor-scope Ruang lingkup pohon ditentukan. Katakan itu lima kali dengan cepat!

Terselesaikan: Saat Anda membandingkan nama, dan setidaknya salah satu nama berada dalam cakupan pohon, keduanya berada dalam cakupan pohon, dan cakupannya harus tepat (bukan subpohon)

Keputusan selanjutnya sangat jelas. Selain mengizinkan <dashed-ident>itu anchor-scope Dapat mengambil properti all Kata kuncinya, artinya semua jangkar adalah cakupan pohon, sementara <dashed-ident> Dia bilang <>Yang Jangkar yang dipilih mempunyai tiga jalur. Jadi, pertanyaannya adalah apakah all Ini juga merupakan nilai yang mencakup pohon.

Tabatkin: anchor-scopeSelain pengidentifikasi, kata kunci 'all“, yang mencakup semua nama. Haruskah ini menjadi cakupan pohonnya”all'? (yaitu ini hanya berlaku untuk cakupan pohon saat ini)

Tabatkin: Resolusi yang diusulkan: 'all'Rentang kata kunci juga ditentukan dengan cara yang sama seperti sgtm +1, sekali lagi dengan pola yang sama view-transition-group

Terselesaikan: yang 'all'Kata kuncinya adalah pohon domain

Percakapan beralih ke fitur-fitur baru yang hadir dalam rancangan Modul Snap Gulir CSS Level 2, yang berkisar pada perubahan gulir pengguna awal menggunakan CSS. Dengan menggunakan contoh langsung dari spesifikasinya, misalkan kita memiliki galeri gambar:

<div class="carousel">
  <img src="img1.jpg">
  <img src="img2.jpg">
  <img src="img3.jpg" class="origin">
  <img src="img4.jpg">
  <img src="img5.jpg">
</div>

Kita dapat mulai menggulir untuk menampilkan gambar lain dengan menyesuaikannya scroll-start-targe ke auto: 

.carousel {
  overflow-inline: auto;
}

.carousel .origin {
  scroll-start-target: auto;
}

Sejauh ini, satu-satunya cara untuk menyelesaikan perintah ini adalah dengan menggunakan JavaScript untuk meneruskan elemen ke tampilan:

document.querySelector(".origin").scrollIntoView({
  behavior: "auto",
  block: "center",
  inline: "center"
});

Contoh terakhir mungkin berupa carousel yang hanya dapat di-scroll ke arah sebaris. Namun, ada ketidakpastian mengenai kapan pengguliran dapat dilakukan baik dalam arah sebaris maupun blok. Seperti yang dijelaskan dalam masalah GitHub awal:

Spesifikasi Snap Scroll 2 mengatakan bahwa ketika ada beberapa item, itu bisa terjadi scroll-start-targets Untuk container yang bergulir, “agen pengguna harus menentukan container mana yang muncul lebih dulu dalam urutan pohon.”

Memilih elemen pertama dalam urutan pohon tampaknya merupakan cara alami untuk menyelesaikan persaingan antara beberapa target yang akan di-scroll pada sumbu tertentu, namun mungkin tidak sefleksibel yang mungkin diperlukan untuk kasus 2D di mana penulis menginginkannya. gulir ke satu elemen di satu sumbu dan elemen lain di sumbu lainnya.

Dan kembali ke menit CSSWG:

David A: Kami memiliki properti yang kami tambahkan bernama scroll-start-target Hal ini menunjukkan bahwa jika ada item di dalam wadah pengguliran, proses pengguliran harus dimulai dengan item tersebut di layar. Pertanyaannya, apa jadinya jika ada banyak target?
David A: Saya sarankan melakukan ini dalam urutan DOM terbalik, yang akan menghasilkan elemen pertama yang diterapkan terakhir dan kemudian muncul di layar. Posisi gulir hanya boleh diubah jika diperlukan.

Setelah berdiskusi mengapa diperlukan definisi scroll-start-target Saat kita memilikinya scroll-snap-alignDiskusi berlanjut membahas pengurutan DOM terbalik:

fantasi: Ada banyak diskusi tentang pengurutan DOM reguler versus pengurutan DOM terbalik. Di manakah kita berakhir dan mengapa?
penipu: Saat ini, kami mengharapkannya untuk bergulir ke elemen pertama dalam urutan DOM. Mungkin kita ingin hal itu terjadi. Itu sebabnya sarannya adalah menggulir ke setiap elemen dalam urutan terbalik dari DOM.

Jadi kita melakukan kebalikannya untuk meneruskan item tersebut, tetapi hanya seperlunya agar item berikut muncul sebanyak mungkin:

penipu: Ada juga masalah kedekatan…
fantasi: Bisakah Anda menjelaskan lebih dekat?
penipu: Hal yang sama seperti menggulir untuk melihat
fantasi: ?
penipu: Ini diperlukan ketika Anda menggulir beberapa hal dalam tampilan dan ingin mencari posisi yang bagus (?)
fantasi: Anda dapat menggulir dalam urutan DOM terbalik… Saat Anda menambahkan spesifikasinya, dapatkah Anda memperjelas bahwa ini adalah hasil akhir dari algoritme?
penipu: Ya, tentu saja
fantasi: Kalau tidak, sepertinya masuk akal

Beginilah cara penyelesaiannya:

Usulan Resolusi No.2: Kapan scroll-start-target Menargetkan beberapa elemen, menelusuri setiap elemen dalam urutan DOM terbalik dengan teks yang akan diprioritaskan, elemen pertama

Akhirnya terjadilah diskusi mengenai… text-underline-positionitu ketika diatur ke auto “Agen pengguna dapat menggunakan algoritma apa pun untuk menentukan posisi garis bawah; namun, itu harus ditempatkan pada atau di bawah garis dasar alfabet,” katanya. Perdebatannya adalah tentang apakah auto Nilai tersebut akan secara otomatis menyesuaikan posisi garis bawah agar sesuai dengan tata bahasa bahasa yang ditentukan, misalnya, di sebelah kanan teks untuk mode tipe vertikal, seperti Jepang dan Mongolia.

fantasi: Nilai awal dari text-underline-position Dia adalah autoyang didefinisikan sebagai “menemukan tempat yang baik untuk menghasilkan keuntungan.”
Terdapat tiga pilihan: (1) di bawah garis dasar abjad, (2) di bawah semua teks (cocok untuk kasus dengan banyak turunan), (3) untuk teks vertikal di sisi kanan
fantasi: Nilai default ditentukan dalam spesifikasi tentang “spasi di bawah teks”, tetapi tidak menjelaskan apa pun tentang membalik. Spesifikasi saat ini mengatakan “di atau di bawah”. Untuk menangani aspek spesifik bahasa, terdapat style sheet UA default karena terdapat perbedaan antara bahasa Mandarin, Jepang, dan Korea untuk bahasa-bahasa tersebut. Beberapa aplikasi melakukan hal ini
fantasi: Haruskah kita mengubah spesifikasi untuk menyebutkan hal-hal ini?
fantasi: Atau haruskah kita tetap menggunakan pendekatan tabel gaya UA?

Soalnya Chrome dan Firefox sudah memasang garis bawah di sebelah kanan dalam bahasa Jepang vertikal text-underline-position Dia adalah auto.

Opsi penyertaan CodePen alternatif

Kelompok ini mempunyai tiga pilihan:

<فانتاساي> a) Pertahankan spesifikasi yang sama, perbarui Gecko+ Blink agar sesuai (menggunakan tabel gaya UA untuk beralih antar bahasa)
<فانتاساي> b) Menyediakan mobil untuk text-emphasis-position dan menggunakannya di keduanya text-emphasis-position Dan text-underline-position Untuk mempengaruhi peralihan bahasa
<فانتاساي> c) Mengadopsi perilaku yang tidak konsisten: text-underline-position kegunaan'auto'Dan text-emphasis-position Ini menggunakan lembar gaya UA

Beberapa anggota CSSWG seperti Emilio Cobos, Tabatkins, Miriam Susan, Rachel Andrew, dan Fantasai memberikan suara mereka, sehingga menghasilkan keputusan berikut:

Terselesaikan: Menambahkan nilai otomatis untuk posisi penekanan teks, dan mengubah arti posisi garis bawah pada teks: secara otomatis memperhatikan kiri versus kanan dalam teks vertikal

Saya sangat mendorong Anda untuk membaca seluruh transkripnya! Atau jika Anda tidak punya waktu, Anda bisa membaca saja daftar keputusannya.

Risalah Rapat Jarak Jauh CSSWG (18-09-2024) awalnya diterbitkan di CSS-Tricks, bagian dari keluarga DigitalOcean. Anda harus mendapatkan buletin.

Sumber