Risalah Panggilan Konferensi CSSWG (21-08-2024) | – Beragampengetahuan

Transisi tampilan adalah salah satu fitur terbaik yang baru-baru ini dirilis di CSS. Judulnya cukup jelas: Transisi antar tampilan hanya dengan CSSbahkan di seluruh halaman asal! Yang lebih menarik adalah subteksnya, karena tidak perlu membuat SPA yang rumit dengan perutean hanya untuk mendapatkan transisi antar halaman yang menarik.

Alasan lain mengapa View Transitions luar biasa adalah seberapa cepat ia berubah dari draf publik pertama pada Oktober 2022 hingga dirilis di browser dan bahkan di beberapa lingkungan produksi seperti Airbnb — hal yang tidak dilakukan oleh setiap pengembang CSS , jadi ini menunjukkan betapa dibenarkannya hype tersebut.

Meski begitu, API ini masih baru, jadi pasti ada beberapa kasus edge atau bug yang sedang diperbaiki. Cara menarik untuk mempelajari perkembangan terkini dalam fitur CSS seperti transisi tampilan adalah langsung dari CSS Telecom Minutes (yang dapat Anda berlangganan di W3C.org).

Transisi pandangan menjadi fokus utama pertemuan tanggal 21 Agustus yang memiliki agenda panjang. Ini dimulai dengan bug kecil di Chrome yang melibatkan navigation Deskriptor digunakan di setiap transisi tampilan lintas dokumen untuk ikut serta dalam transisi tampilan.

@view-transition 
  navigation: auto 

Saat ini, spesifikasi mendefinisikan navigasi sebagai tipe enum (sekumpulan tipe yang telah ditentukan sebelumnya), tetapi Blink memperlakukannya sebagai CSSOMString (string apa pun). Meskipun hal ini awalnya dilaporkan sebagai bug, menarik untuk melihat percakapan yang dipicunya pada Masalah GitHub:

Menurut saya, dapat diperdebatkan bahwa saat ini kami tidak memiliki aturan untuk menggunakan enum dengan cara ini, dan secara umum CSSOM tidak berusaha untuk sepenuhnya aman dalam mengetik dengan cara ini. Misalnya, jika kita menambahkan jenis navigasi baru dan beberapa browser tidak mendukungnya, hal ini akan menafsirkannya sebagai aturan yang tidak valid dan bukan aturan dengan navigasi kosong.

Pernyataan terakhir itu mungkin tidak tampak menarik, namun membuka kemungkinan-kemungkinan baru navigation di luar tipe auto Dan nonejadi pertimbangkan apa yang dapat dilakukan oleh berbagai jenis transformasi tampilan.

Berikut notulen rapat CSSWG:

Emilio: Apakah berguna untuk membedakan antara mobil yang hilang atau tidak ada mobil?

Norma: Ya, sangat penting untuk kompatibilitas ke depan. Jika satu browser menambahkan tipe lain yang belum dimiliki browser lain, maka kita akan melihat perbedaan antara Tidak Ada atau Tidak Valid

Emilio: Namun apakah Anda akan mendapatkan perilaku otomatis?

Norma: Tidak, nilai yang tidak diketahui tidak dibaca untuk tujuan navigasi. Ini adalah peran vt tanpa deskriptor navigasi dan tanpa nilai awal, mirip dengan aturan yang tidak valid

Jadi dalam implementasi selanjutnya, tidak valid navigation Deskriptor diabaikan, tetapi bagaimana tepatnya masih menjadi perdebatan:

Entim: Apa perbedaan antara itu dan tanpa navigasi?

Norma: Otomatis vs. Tidak Valid, lalu Otomatis vs. Tidak Ada. Tidak ada yang menggantikan mobil; artinya tidak ada navigasi, dan tidak aktif berarti tidak ada pengoperasian.

Entim: Jadi tidak ada yang membatalkan navigasi di dokumen sebelumnya?

Norma: Ya

ini none Bertujuan untuk membatalkan transisi tampilan apa pun pada dokumen sebelumnya, string yang tidak valid atau kosong akan diabaikan. Terakhir, jika string hilang atau tidak valid, ia akan mengembalikan string kosong.

Terselesaikan: navigasi adalah CSSOMString, yang mengembalikan string kosong ketika deskriptor navigasi tidak ada atau tidak valid

Lanjut ke agenda berikutnya. Diskusi masuk view-transition-group properti dan apakah itu harus diprioritaskan. Jangan bingung dengan elemen semu dengan nama yang sama (::view-transition-group) ini view-transition-group Properti itu diputuskan untuk ditambahkan di suatu tempat di masa depan. Sampai sekarang, pohon elemen semu yang dibuat oleh transformasi tampilan adalah tergencet:

::view-transition
├─ ::view-transition-group(name-1)
│  └─ ::view-transition-image-pair(name-1)
│     ├─ ::view-transition-old(name-1)
│     └─ ::view-transition-new(name-1)
├─ ::view-transition-group(name-2)
│  └─ ::view-transition-image-pair(name-2)
│     ├─ ::view-transition-old(name-2)
│     └─ ::view-transition-new(name-2)
│ /* and so one... */

Namun, kita mungkin ingin menyatukan kelompok transisi untuk mencapai transisi yang lebih kompleks, sehingga menghasilkan pohon dengan ::view-transition-group pada orang lain ::view-transition-groupseperti yang ditunjukkan di bawah ini:

::view-transition
├─ ::view-transition-group(container-a)
│  ├─ ::view-transition-group(name-1)
│  └─ ::view-transition-group(name-2)
└─ ::view-transition-group(container-b)
    ├─ ::view-transition-group(name-1)
    └─ ::view-transition-group(name-2)

Jadi view-transition-group Properti itu lahir, atau tepatnya, akan lahir pada suatu saat pada pengatur waktu. Jika saya mengikutinya dengan benar mungkin terlihat mirip dengan sintaks berikut:

view-transition-group: normal | <ident> | nearest | contain;

• normal terkandung dalam akar ::view-transition (perilaku saat ini).
• <ident> akan terkandung dalam elemen yang cocok view-transition-name
• nearest akan ditampung oleh nenek moyang terdekatnya view-transition-name.
• contain akan menyertakan semua turunannya tanpa mengubah posisi elemen di pohon

Nilai-nilai ini mungkin terlihat sederhana, namun bisa saling bertentangan. Bayangkan struktur bersarang berikut:

A  /* view-transition-name: foo */
└─ B /* view-transition-group: contain */
   └─ C /* view-transition-group: foo */

Di Sini, B ingin menyertakan CTetapi C Perjelas bahwa ia ingin dimasukkan ke dalamnya A. Jadi, siapa yang menang?

vmtr: Mengenai nesting dengan view-transition-group, diperlukan kata kunci atau ident. Berisi berarti semua turunan transisi tampilan disarangkan. Ident memiliki arti yang sama, namun elemennya sendiri juga bertumpu pada sesuatu dengan ident tersebut. Pertanyaannya adalah, apa yang terjadi jika suatu elemen memiliki grup transisi tampilan dengan identitas khusus dan juga menetapkan leluhur untuk ditampungnya – di mana kita menyarangkannya? Berisi satu atau satu dengan identitas? Norm dan saya setuju bahwa ident mungkin akan menang, terlihat lebih konkret.

<呼什>: +1

Pembicaraan akan dilanjutkan jika memang seharusnya ada contain Kata kunci untuk menang <ident>

Emilio: Setuju, ini tampaknya diinginkan. Apakah ada kasus penggunaan di mana penahanan benar-benar diterapkan? Apakah kita memerlukan pengendalian yang kuat? Saya kira tidak demikian?

belakang: Dalam proses menambahkan kata kunci baru seperti berisi-idents?

<幻想>: “semua termasuk”

Emilio: Ya, ingin memasukkan semuanya tetapi memerlukan kasus penggunaan

Namun saat ini, sudah diatur ke <ident> Membandingkan contain

Solusi yang diusulkan: idents lebih diutamakan daripada isinya dalam grup transisi tampilan

belakang: Keberatan, kekhawatiran atau pertanyaan?

<幻想>: seperti yang mereka lakukan <ident> nilai-nilai. (Penahanan juga berfungsi, tetapi hanya untuk elemen “normal”)

Terselesaikan: idents lebih diutamakan daripada isinya dalam grup transisi tampilan

Terakhir, ada proses utama diskusi: Apakah properti tertentu harus diambil sebagai gaya, bukan snapshotT. Transisi tampilan kini berfungsi dengan mengambil cuplikan tampilan “lama” dan beralih ke halaman “baru”. Namun, tidak semuanya disertakan dalam snapshot. Beberapa properti yang relevan disimpan sehingga dapat dianimasikan dengan lebih hati-hati.

Dari spesifikasinya:

Namun sifat-sifatnya seperti ini mix-blend-mode Properti yang menentukan bagaimana suatu elemen digambar saat disematkan tidak dapat diterapkan pada gambarnya. Properti ini diterapkan pada elemen semu ::view-transition-group() yang terkait, artinya kotak yang setara dengan elemen tersebut akan dihasilkan.

Singkatnya, beberapa properti yang bergantung pada wadah elemen diterapkan ::view-transition-group alih-alih ::view-transition-image-pair(). Karena di masa depan kita dapat menyusun grup di dalam grup, ada lebih banyak perbedaan dalam cara kita menangkap properti ini.

Norma: Masalah terbesar yang akan kita bahas hari ini adalah cara menangkap dan menampilkan komponen yang disarangkan, namun hal ini juga berlaku untuk elemen transisi tampilan yang tidak disarangkan yang berasal dari percakapan yang disarangkan. Saat kita menyusun grup, beberapa properti CSS yang sebelumnya tidak terlalu penting untuk ditangkap kini menjadi sangat penting karena jika tidak maka akan terlihat rusak. Dua kelompok: efek pohon seperti opasitas, topeng, jalur kliping, filter, perspektif, ini berlaku untuk seluruh batas pohon dan radius batas, karena setelah Anda memiliki hierarki grup, dan Anda telah meluap, maka luapan tersebut akan Mempengaruhi asal saat Anda menggambar batas dan bayangan, ini juga digambar setelah latar belakang

Norma: Kami melihat tiga opsi.

1. Mengubah semuanya secara default, tidak hanya mengambil snapshot, tetapi menambahkan lebih banyak konten yang diambil sebagai ?? daripada snapshot datar (opasitas, filter, transformasi, batas latar belakang). akan mengubah sesuatu karena gayanya adalah bagian dari grup, tetapi ada sesuatu yang telah diubah sebelumnya (tetapi ini berbeda karena mengubah gaya penghitungan yang dapat diamati)
2. Tambahkan properti baru view-transition-style atau view-transition-capture-mode. Penggemar yang pertama karena mengingatkan saya pada transform-style.
3. Miliki properti baru ini tetapi berikan nilai otomatis. Pengguna yang menggunakan nesting akan mendapatkan mode baru jika grup tersebut berisi grup lain saat mendapatkan mode baru, namun mungkin ada properti untuk mengubah perilaku. Jika orang menginginkan perilaku crossfade yang lama, mereka selalu dapat melakukannya melalui pencapaian nesting DOM biasa

Opsi pertama mengenai mengubah cara semua tampilan mengubah properti pengambilan default:

Brahm: Ya, ini akan rusak, tapi dalam arti yang baik. Mengenai nama propertinya, salah satu nilai yang direkomendasikan adalah crossfade, yang tidak saya rekomendasikan karena penulis dapat mengubah animasinya, seperti memperbesar/memperkecil dll. Saya menyarankan menggunakan nama properti nilai yang berbeda, view-transition-capture-mode: flat | layered

Tentu saja, mengubah cara kerja transisi tampilan adalah sebuah dilema nyata Pikirkan tentang hal ini:

Norma: 1 Ada beberapa sentimen, tapi menurut saya orang-orang perlu lebih memikirkan hal ini?

belakang: Dapat menyelesaikan opsi 1 dan biarkan Blink mencobanya dan melihat seberapa banyak kerusakan yang ada, jika dapat dikelola maka kita baik-baik saja dan kembali ke masalah ini. Kecuali mustahil, satu hal akan terpecahkan. Saya lebih suka tidak menentukan mode pengambilan baru tanpa saklar

…jadi tindakan terbaik adalah mengumpulkan lebih banyak data dan memutuskan:

Kush: Saat kami membuat prototipe, kami menemukan kasus tepi. Dalam hal ini, kami akan mengembalikannya ke kelompok kerja. Ingin melakukan ini dengan baik

Norma: Ini melibatkan banyak alat peraga CSS. Beberapa di antaranya diabadikan alih-alih dilukis, sementara yang lain dilukis. Yang spesifik akan ditentukan

Setelah diskusi lebih lanjut, keputusan dibuat untuk mengembalikan data kompatibilitas browser, dan Anda dapat membaca proses selengkapnya di W3C.org. Saya yakin saya melewatkan banyak hal menarik, jadi saya mendorong Anda untuk membacanya.

Terselesaikan: Ubah mode pengambilan untuk semua transisi tampilan dan tentukan bagaimana perubahan mode pengambilan ini memengaruhi setiap properti

Terselesaikan: Menjelaskan klasifikasi atribut pada bagian interaksi modul setiap spesifikasi

Terselesaikan: Jika ada masalah kompatibilitas, Blink akan bereksperimen dan mengembalikan perubahan yang diperlukan