Terima kasih telah memposting ini! Sangat bersemangat untuk kemungkinan 😍

Gaya yang ditentukan ini dapat diterapkan secara global di seluruh situs pengguna (mis. Mendeklarasikan skala font, atau warna, atau tampilan semua Tombol).

Saat ini, Gutenberg hanya mendukung penyesuaian gaya di tingkat per blok. Jadi memperbarui Tombol di satu posting, tidak akan memperbarui Tombol di halaman lain secara surut.

Untuk memperjelas, apakah pengguna dapat memperbarui warna pada semua tombol, atau ukuran font pada semua paragraf, melalui UI editor? Dan jika demikian, apakah mereka masih dapat melakukan penyesuaian per blok?

Mirip dengan bagaimana blok Gutenberg disimpan/dirender, kita dapat menyimpan dan menyimpan output HTML dari Global Styles. HTML ini berisi variabel yang dihasilkan, yang dapat disuntikkan ke kepala melalui PHP, artinya tidak diperlukan konsolidasi variabel/gaya saat dimuat. Ini sudah dilakukan.

Apakah ada alternatif yang baik untuk menggunakan variabel CSS di ujung depan? Kekhawatirannya di sini adalah bahwa situs web apa pun yang menggunakan WP akan berhenti bekerja di IE. Bahkan jika WP sebagai proyek memutuskan untuk berhenti mendukung IE (yang kemungkinan akan terjadi di beberapa titik di masa mendatang), jika pengguna tidak dapat lagi membangun situs web yang kompatibel dengan IE dengannya, itu bisa menjadi masalah besar bagi pemerintah atau lembaga resmi lainnya yang menggunakan WP.

Sangat keren dan tidak sabar menunggu fitur ini!

Apakah ada alternatif yang baik untuk menggunakan variabel CSS di ujung depan? Kekhawatirannya di sini adalah bahwa situs web apa pun yang menggunakan WP akan berhenti bekerja di IE. Bahkan jika WP sebagai proyek memutuskan untuk berhenti mendukung IE (yang kemungkinan akan terjadi di beberapa titik di masa mendatang), jika pengguna tidak dapat lagi membangun situs web yang kompatibel dengan IE dengannya, itu bisa menjadi masalah besar bagi pemerintah atau lembaga resmi lainnya yang menggunakan WP.

Ini adalah poin penting dan kenyataan yang disayangkan. Akan lebih baik jika kita bisa mendapatkan beberapa data keras tentang seberapa besar dampak yang akan terjadi.

Dengan itu, saya ingin tahu apakah sesuatu seperti https://www.npmjs.com/package/postcss-css-variables akan menjadi sesuatu yang dapat digunakan dalam proses pembuatan untuk membantu css akhir. Mungkin ada plugin untuk WP yang akan melakukan pemrosesan dengan cepat dari output css ke transpile (menggunakan paket itu) ke output ramah IE yang kemudian dapat digunakan oleh situs-situs yang membutuhkannya?

@tellthemachines + @nerrad Terima kasih atas tanggapan Anda! Saya setuju, kekhawatiran dengan Variabel CSS dan kurangnya dukungan browser (yang lebih lama) sangat nyata.

Mungkin ada plugin untuk WP yang akan melakukan pemrosesan dengan cepat dari output css ke transpile (menggunakan paket itu) ke output ramah IE yang kemudian dapat digunakan oleh situs-situs yang membutuhkannya?

Itu akan menarik! Sesuatu sisi server untuk mengurangi kebutuhan polyfill berbasis JS mengisi sisi klien.

Saya sangat berharap kita dapat menggunakan Variabel CSS untuk mekanisme penataan untuk proyek ini. Entah menggunakan teknik seperti yang disarankan @nerrad , dan pony/polyfill, atau yang lainnya.

Dengan itu, saya tidak berpikir variabel CSS bagian yang membuat/menghancurkan global styles .

Saya pikir bagian yang paling penting, akan menciptakan sistem yang memungkinkan Tema, Blok, dan Kustomisasi pengguna (global + satu kali) untuk bermain dengan baik satu sama lain. Sebuah sistem yang mengurangi kompleksitas dan overhead untuk Pengembang dan Tema Blok. Ini kemudian akan memberikan pengalaman yang lebih kohesif bagi pengguna. Mungkin pengguna yang sering mengkustomisasi sesuatu atau mencoba menggunakan blok khusus yang berbeda dari pembuat blok yang berbeda.

Berfokus pada pengalaman pengguna itu, saya pikir, pada akhirnya merupakan bagian besar dari pengalaman Gutenberg :). Saya diingatkan oleh komentar yang ditulis @nerrad (tautan di bawah), di mana ia dengan fasih menekankan pentingnya pengalaman pengguna dalam WordPress.

https://github.com/WordPress/gutenberg/pull/16384#issuecomment -573430079

Halo semua!

Saya memiliki pembaruan. Saya telah bekerja dengan @karmatosed untuk mencari tahu

Saya telah membuat prototipe yang menunjukkan aliran + hierarki tentang bagaimana gaya global akan bekerja dengan blok dan tema

Saya merekam screencast yang membahas prototipe + konsep:

:video_camera: Video
https://www.loom.com/share/73f721797f524dfeb2c3a222e9e24561

:raised_hands: Demo
https://yvz8y.csb.app/#/v2/post

Terlalu Lama, Tidak Menonton

Jangan khawatir! Saya akan mencoba meringkas <3

Hirarki gaya dapat diwakili oleh piramida ini:

Inti : Gaya dasar yang hadir dengan sistem penataan Gutenberg/global
Tema : Gaya khusus yang ditentukan oleh tema
Global : Gaya khusus yang diterapkan oleh pengguna, ditujukan untuk seluruh situs
Dokumen : Gaya khusus yang diterapkan oleh pengguna, ditujukan untuk halaman/bagian template tertentu (FSE)
Blok : Gaya khusus yang diterapkan oleh pengguna, untuk blok individu

Dalam piramida di atas, kita dapat melihat bahwa gaya Inti (teks hitam), telah bertahan, karena tidak ada gaya yang ditentukan pada lapisan lain. Menghasilkan sesuatu yang terlihat seperti ini:

Jika kita mengganti tema ke Blue , gaya kustom tema biru (dalam hal ini, teks biru), akan menggantikan gaya inti. Ini akan bertahan ke atas karena tidak ada gaya khusus lainnya yang diterapkan

Menghasilkan situs yang terlihat seperti ini:

Jika kita menerapkan gaya global, itu akan menimpa tema:

Jika kami menerapkan gaya dokumen, itu akan menimpa global (jika berlaku):

Terakhir, jika kita menyesuaikan blok tertentu, itu akan menimpa lapisan lainnya:

Sehingga menyebabkan:

Kami juga akan memiliki kemampuan untuk "mengatur ulang" atau menghapus pengaturan khusus. Dalam contoh ini, katakanlah pengguna menghapus pengaturan gaya global mereka. Namun, gaya dokumen tetap, yang dirender seperti ini:

Pergantian Tema

Gaya Global + Dokumen digabungkan dengan tema. Anda dapat menganggapnya sebagai konfigurasi tema pengguna. Jika pengguna beralih ke tema lain, itu akan menerapkan gaya dokumen global + tema tersebut.

Katakanlah pengguna telah menyesuaikan banyak tema ("biru") yang ada.
Katakanlah pengguna memasang tema baru ("merah"). Tema yang baru saja mereka unduh.

Setelah mereka beralih, gaya dokumen + global akan diatur ulang.

Alasannya adalah karena mereka belum pernah mengkustomisasi apa pun pada tema "merah".

Beralih kembali ke "biru", akan mengembalikan gaya global/dokumen mereka sebelumnya.

TLDR (Terlalu Panjang, Tidak Dibaca)

• Ada hierarki gaya - Inti, Tema, Global, Dokumen, Blok
• Gaya Global, Dokumen, Blok disesuaikan oleh pengguna
• Gaya Global + Dokumen dikaitkan dengan tema
• Ini memungkinkan peralihan tema dengan efek samping yang diminimalkan

Terima kasih banyak atas waktu Anda! Pikiran + umpan balik diterima

Kerusakan luar biasa, terima kasih @ItsJonQ!
Bukankah Theme & Global hampir sama?
Maksud saya memikirkan seperti apa masa depan tema, sebagian besar tema mungkin akan beralih dari menggunakan penyesuai ke sistem gaya global. Pengaturan yang sekarang ada di penyesuai akan dimigrasikan ke sistem ini... Mereka dapat dianggap sebagai hal yang sama. Kita dapat menyebutnya "tema" jika tema menggunakan penyesuai dan "global" jika tema menggunakan sistem gaya global, tetapi itu satu atau yang lain, tidak ada tema yang memiliki pengaturan yang sama baik di penyesuai & global- editor gaya karena tidak ada alasan untuk melakukannya, tidak ada gunanya memiliki keduanya.

Mengenai css-vars: Saya tidak akan khawatir tentang dukungan IE... Mengurai konten dan mengganti css-vars dengan nilainya tidak akan sulit dilakukan di PHP.
IMO kami dapat bekerja dengan css-vars dan filter sederhana yang melakukan pencarian dan penggantian sisi server di sisi PHP dapat bekerja dengan baik.

Apakah ada alternatif yang baik untuk menggunakan variabel CSS di ujung depan? Kekhawatirannya di sini adalah bahwa situs web apa pun yang menggunakan WP akan berhenti bekerja di IE.

Ini dapat dipecahkan dengan membuat fallback seperti:

p {
    font-size: 16px; // Fallback for IE.
    font-size: var( --font-size-paragraph );
}

Itu dapat diotomatisasi menggunakan https://www.npmjs.com/package/postcss-custom-properties Pendekatan lain adalah mixin SASS, meskipun CSS menjadi berlumpur (Anda harus menulis <strong i="11">@include</strong> font-size-mixin( 16px ); yang sedikit tidak wajar Ada opsi untuk mengatasi warga web yang lebih tua, jadi properti khusus CSS boleh digunakan.

Saya baru saja membaca semua #9534 dan masalah ini dan saya ingin mengemukakan perspektif yang belum disebutkan sama sekali sejauh yang saya baca.

Gaya Pengguna vs. Gaya Pembangun

Semua hal di atas sebagian besar berkaitan dengan fleksibilitas dan kontrol maksimum untuk "Pengguna" , menawarkan mereka dasar yang kuat dalam bentuk gaya inti dan tema tetapi memberi mereka keputusan akhir dan beragam kemampuan untuk mengubah gaya situs web.

Ini adalah kasus penggunaan yang valid dan pasti yang paling umum, tetapi saya datang dari arah yang sama sekali berbeda (tidak untuk mengatakan sebaliknya): Situs di mana ada banyak pengguna serta pemisahan yang jelas antara desainer, pengembang, dan editor . Dalam pengaturan itu, pengguna secara khusus tidak boleh atau setidaknya sangat sedikit mengontrol gaya situs. Mereka membuat konten semantik menggunakan kumpulan blok (yang sangat dimoderasi) meninggalkan gaya di tangan desainer dan pengembang. Pikirkan pemisahan masalah antara konten dan tata letak/gaya demi konsistensi.

Dalam situasi itu "Hirarki Gaya" yang disebutkan di atas bukanlah yang dibutuhkan atau diinginkan seseorang karena gaya harus semata-mata ditentukan oleh tema. Mengubah apa pun di Level Global, Dokumen, dan Blok seharusnya tidak dimungkinkan. Dan bahkan Core Styling mungkin terlalu keras kepala. Alih-alih, Level Tema harus menjadi yang pertama, terakhir, dan satu-satunya yang memutuskan bagaimana semuanya ditata .

Bukankah kita harus merangkul pengguna yang memegang kendali?

Umumnya ya, tapi mungkin tidak di sini. Mari kita lihat mengapa.

Jika sebuah situs web didasarkan pada desain korporat, panduan gaya, atau sistem lain yang dipikirkan tidak perlu bagi pengguna (pikirkan editor konten) untuk bahkan dapat mengelola hal-hal seperti warna latar belakang tombol. Mempertahankan konsistensi global tidak mungkin dilakukan dengan kontrol pengguna individu.

(Terlebih lagi menurut saya pribadi, menghilangkan beberapa pilihan seperti yang berkaitan dengan penataan gaya sebenarnya membantu pengguna menjadi editor konten dengan membebaskan mereka dari keharusan memikirkan gaya. Ini sebenarnya membuat mereka merasa lebih memegang kendali meskipun secara teknis mungkin tidak demikian. _ "Keputusan, bukan Pilihan"_)

Gaya inti selalu berpendirian.

Saya mengerti bahwa harus ada beberapa dasar, tetapi bahkan itu sering perlu diubah secara drastis jika bahkan tidak dihapus. Contoh sederhana: Saat ini Blok Kolom dan Galeri menggunakan CSS Flexbox untuk tata letak, membuat setiap Blok Inti CSS benar-benar usang jika bahkan tidak menghalangi jika tata letak seluruh situs Anda didasarkan pada Grid CSS.

Jadi pada dasarnya di sini seluruh konsep penimpaan multi-lapisan berada di suatu tempat antara tidak relevan hingga berbahaya di luar fakta bahwa seseorang dapat menonaktifkan, menimpa, atau mengambil kendali sebanyak mungkin. Dan bahkan jika beberapa hal mungkin diizinkan untuk ditata oleh pengguna, saya akan melihat piramida diacak seperti lapisan tema di atas yang memiliki keputusan akhir dan hanya "membiarkan" pilihan gaya tertentu oleh pengguna.

Jadi jika seluruh sistem ini memberikan lebih banyak kontrol gaya kepada pengguna daripada yang sudah kami miliki sekarang, pastikan bahwa pengaturan apa pun yang diperkenalkan sebagai dapat dikontrol pengguna memiliki cara untuk dinonaktifkan, dibatasi, atau ditimpa. Ini agar tidak sesulit untuk tetap memegang kendali seperti saat ini dengan hal-hal seperti warna/gradien khusus, ukuran font, jumlah kolom, drop caps,...

Pikiran terakhir

Untuk menutup semuanya, saya menyadari bahwa arah umum yang Gutenberg tuju adalah pendekatan yang sangat visual untuk pengeditan konten. WordPress selalu cukup mengabaikan pemisahan konten dan tata letak, tetapi saat ini saya melihat risiko bahwa ini mungkin menjadi paku terakhir di peti mati sehingga tidak hanya sulit tetapi menjadi sangat tidak mungkin semakin jauh kita pergi ke rute memberikan kekuatan penataan yang tidak terikat kepada pengguna.

Dalam pengaturan itu, pengguna secara khusus tidak boleh atau setidaknya sangat sedikit mengontrol gaya situs.

@kraftner Ini benar-benar tepat dan saya hanya ingin menunjukkan bahwa tingkat kontrol ini sudah terjadi "di luar sana". Saat ini tidak ada kekurangan plugin yang memberdayakan pengguna untuk mengatur tata letak situs webnya sendiri - bahkan merugikannya sendiri.

Dengan menerapkan sistem baru ini dalam inti, praktik itu akhirnya akan dimaafkan oleh WordPress itu sendiri, yang IMO bukan kepentingan terbaik dari jenis pengguna tertentu yang tidak tahu apa itu sistem desain, dan oleh karena itu, relevansi dan dampaknya. Dan saya bahkan akan mengatakan bahwa pengguna semacam ini mewakili mayoritas basis pengguna.

Ini adalah sesuatu yang penting untuk diatasi sebelum melanjutkan.

Terima kasih atas pemikiran terperinci Anda, @kraftner , ini adalah poin bagus.

Semua hal di atas sebagian besar berkaitan dengan fleksibilitas dan kontrol maksimum untuk "Pengguna", menawarkan mereka dasar yang kuat dalam bentuk gaya inti dan tema tetapi memberi mereka keputusan akhir dan beragam kemampuan untuk mengubah gaya situs web.

Saya tidak berpikir ini harus terjadi di sini. Sistem mengusulkan cara untuk menyusun kemampuan gaya blok dengan cara yang dapat dikontrol dengan lebih baik, tetapi tidak banyak bicara tentang siapa yang akan menanggung kendali ini. Sangat mungkin bahwa sebagian besar dari ini hanya akan diekspos sebagai alat pembuat tema, kepada admin dan desainer, tidak harus kepada pengguna akhir.

Anggap saja lebih sebagai evolusi "editor tema" daripada harus memberikan kendali atas semua detail gaya kepada pengguna. Yang terakhir juga tidak akan bagus untuk sebagian besar pengguna, karena itu akan sangat berlebihan, tetapi tema membutuhkan kontrol yang lebih baik dan lebih mudah atas blok (terutama blok yang mereka tidak tahu bahkan ada!).

Situs di mana ada banyak pengguna serta pemisahan yang jelas antara desainer, pengembang, dan editor. Dalam pengaturan itu, pengguna secara khusus tidak boleh atau setidaknya sangat sedikit mengontrol gaya situs.

Ini sangat masuk akal, dan tidak perlu dikatakan lagi bahwa sebuah situs akan memiliki kendali atas apakah alat-alat ini diekspos, peran mana, dan kapasitas mana — dengan cara yang sama seperti pengguna biasa Anda tidak memiliki akses ke editor tema PHP.

Dan bahkan Core Styling mungkin terlalu keras kepala. Alih-alih, Level Tema harus menjadi yang pertama, terakhir, dan satu-satunya yang memutuskan bagaimana semuanya ditata.

Itu harus dalam kendali Anda untuk mengatur hal-hal dengan cara ini - jangan memuat gaya blok default (di luar yang struktural, mungkin) dan membatasi kemampuan untuk mengedit opsi gaya blok global dan lokal. Saya pikir apa yang Anda uraikan adalah kasus penggunaan yang benar-benar valid yang seharusnya mudah diakomodasi dan ditingkatkan.

Jadi jika seluruh sistem ini memberikan lebih banyak kontrol gaya kepada pengguna daripada yang sudah kami miliki sekarang, pastikan bahwa pengaturan apa pun yang diperkenalkan sebagai dapat dikontrol pengguna memiliki cara untuk dinonaktifkan, dibatasi, atau ditimpa.

Tentu saja. Sekali lagi, saya melihat fondasi ini memberikan kontrol yang lebih disengaja pada tema di atas blok. Efek sampingnya adalah bahwa kita berakhir dengan sistem yang juga dapat diekspos ke pengguna jika mereka ingin memiliki tingkat kontrol menggunakan GUI daripada menulis CSS dan memodifikasi template PHP dengan tangan, tetapi ini tidak akan menjadi satu -size-fits-all-use-cases, karena dunia WordPress sangat beragam dan kami membutuhkan alat yang mengakomodasi beragam kasus penggunaan.

Jika ada lebih banyak contoh hal-hal yang menurut Anda melepaskan kendali itu dari Anda, harap laporkan sebagai masalah sehingga dapat didiskusikan dan ditangani. Saya setuju bahwa saat ini diperlukan upaya untuk melalui semua hal yang mungkin ingin Anda nonaktifkan. Bagian dari motivasi untuk sistem gaya blok yang lebih komprehensif adalah untuk membuatnya lebih mudah dikendalikan — baik dengan membuka atau menutupnya.

Saya pikir apa yang Anda uraikan adalah kasus penggunaan yang benar-benar valid yang seharusnya mudah diakomodasi dan ditingkatkan.

Kedengarannya bagus @mtias. Saya hanya ingin menekankan kembali ini, terutama poin yang menurut saya harus menjadi persyaratan pemblokiran untuk masing-masing dan salah satu fitur yang dapat dikontrol pengguna ini untuk hanya masuk ke plugin atau setidaknya inti ketika datang dengan opsi untuk mengontrol (konfigurasi, batasi, nonaktifkan).

Alasan saya datang ke sini pada dasarnya adalah karena fakta bahwa Anda cukup banyak mengatakan hal yang sama di Jam Kerja di WCEU pada bulan Juni ketika Anda, saya dan @m membicarakan topik khusus ini. Tapi saya sudah mendapat kesan bahwa ini dilihat sebagai hal yang "bagus untuk dimiliki" untuk nanti, bukan persyaratan yang sulit atau bahkan prioritas.

Mengenai contoh kehilangan kontrol yang saya bicarakan - kebanyakan dari mereka sudah memiliki masalah, tapi sayangnya untuk banyak dari mereka ada sedikit atau tidak ada gerakan. Seringkali saya juga tidak mengerti bagaimana bug yang sesuai bisa terjadi, mengapa mematikannya ternyata bahkan tidak dicoba untuk fitur baru selama pengembangan.
Jadi pada akhirnya rasanya seperti situasi "Whac-a-mole" yang sangat membuat frustrasi di mana untuk setiap fitur seseorang dapat memperoleh kembali kendali, dua lagi yang tidak dapat dikendalikan memasuki editor. Hanya untuk menekankan apa yang saya bicarakan, berikut adalah daftar masalah yang saat ini atau sebelumnya saya perjuangkan, tidak memiliki atau hanya cara hacky untuk mengendalikannya. (Ini benar dari penelitian saya yang masih berlangsung untuk pembicaraan WC saya yang akan datang tentang topik ini)

• Drop caps: #6184 / #14654 -> #6023 (Ini diketahui/dilaporkan bermasalah jauh sebelum WP 5.0, mengapa fitur ini masuk sama sekali?)
• Warna latar belakang untuk tabel #16478 / #19659 (Mengapa "pertukaran" itu baik-baik saja dan bukan masalah pemblokiran?)
• Ukuran font #13824 / 46290 (Bagaimana ini bisa lolos? Menonaktifkan item adalah salah satu hal pertama yang harus dicoba setelah menambahkan opsi apa pun, bukan?)
• Gradien: #18213 (Mengapa fitur ini tidak menunggu solusi umum untuk menonaktifkan, alih-alih menambahkan tanda eksperimental, tidak ada dokumentasi , memperkenalkan hanya mekanisme baru untuk menonaktifkan sesuatu?)
• Jumlah kolom #10791 -> #18892 (Saya memahami perlunya solusi umum, tetapi mengapa fitur baru tidak ditahan sampai saat itu?)
• Penguncian template #8112 / #7845 (Ini adalah persyaratan mendesak untuk dapat mengunci struktur CPT untuk menggantikan pendekatan Plugin Bidang Kustom yang lama)

Saya tahu bahwa pada akhir daftar ini saya agak menyimpang dari masalah gaya, tetapi saya percaya semua ini bersama-sama menunjukkan tema menyeluruh: Mengambil kendali Gutenberg masih berada di antara sulit dan tidak mungkin.

Jangan salah paham: Saya mengerti bahwa Gutenberg masih dalam pengembangan yang berat dan melihat semua masalah ini secara terpisah, tentu saja dapat dikatakan bahwa bug terjadi, tidak ada yang sempurna dan kami hanya dapat mengerjakan satu demi satu. Tetapi jumlah dari semua hal di atas membuat saya merasa seperti itu tidak dilihat sebagai prioritas oleh pimpinan proyek dan alih-alih menyelesaikan masalah penting ini dengan pengeditan konten terlebih dahulu, kami sudah maju ke area berikutnya yang bahkan lebih kompleks. dari pengeditan situs penuh.

TL; DR: Kontrol atas kemampuan pengguna adalah kebutuhan penting dan mendesak di seluruh Gutenberg, dan saya benar-benar berpikir bahwa inilah saatnya untuk lebih fokus pada hal ini. Tolong, tolong beri kami kembali kontrol sebelum menerapkan fitur lagi. :berdoa:

Saya tidak ingin menggali rumput liar terlalu banyak, tetapi satu hal yang menarik perhatian saya adalah salah satu contoh dari deskripsi masalah:

Agar blok mulai menggunakan gaya global, CSS-nya perlu difaktorkan ulang untuk menggunakan variabel CSS yang dikeluarkan oleh sistem.

dan kemudian ini adalah bagian dari contoh:

border: 1px solid var(--wp-gs-color-primary-dark20);

Warna selalu sulit dalam hal tema karena sulit untuk mendasarkannya pada semantik tertentu. Pada dasarnya ini adalah hard-coding hubungan antara skema tema dan gaya blok, dan itu mungkin membatasi. Saya mungkin salah, tetapi saya pikir itu berarti jumlah warna dan jenis warna yang dapat ditentukan adalah tetap. Juga pelaksana blok harus membuat penilaian tentang konfigurasi tema dan warna seperti apa yang seharusnya. Saya bertanya-tanya apakah mungkin perlu ada lapisan terpisah di mana gaya ini dihubungkan ke skema tema.

Sebaliknya, ini mungkin didefinisikan sebagai:

border: 1px solid var(--wp-button-block-border-color);

Dan kemudian suatu hubungan didefinisikan (berdasarkan tema?):

--wp-button-block-border-color: --wp-gs-color-primary-dark20

Tidak yakin apakah saya sudah menjelaskannya dengan jelas. Ini sudah terdengar cukup rumit, tapi itu sesuatu yang saya antisipasi mungkin perlu dipecahkan.

edit: Lebih lanjut meskipun tidak yakin bagaimana apa yang saya usulkan akan bekerja dengan blok pihak ketiga. Mungkin masalahnya adalah bahwa semantik perlu didefinisikan lebih jelas, jadi kami menghindari penamaan sesuatu 'gelap' atau 'terang'.

Karena saya visual, saya bertanya-tanya apakah ini dapat membantu siapa pun untuk melihat apa yang terpengaruh setiap kali sesuatu diulang. Misalnya, bagaimana lapisan menyaring. Ini dibangun di atas kaskade piramida yang dibuat oleh @ItsJonQ dan dilakukan dalam kolaborasi.

Apa yang dilakukan adalah melihat tindakan spesifik:

• Mengubah gaya secara global: misalnya, meningkatkan ukuran font dasar. Dalam hal ini ia melintasi segala sesuatu sebagai global. Titik-titik menunjukkan bahwa itu adalah yang teratas (menghormati hierarki) dan apa yang terpengaruh olehnya.
• Lokal/dokumen mengubah gaya: misalnya ukuran font dasar meningkat hanya di halaman tentang.
• Perubahan gaya blok: misalnya hanya mengubah ukuran font dasar hanya pada blok kutipan.

Jika Anda melihat ada 2 kolom yang tidak memiliki interaksi apa pun di sana, kolom ini akan tetap ada sebelum Anda melakukan interaksi apa pun.

Poin lain yang perlu diperhatikan blok mencakup beberapa hal:

• Variasi gaya
• Gaya kustom
• Pengembang (plugin) memblokir gaya

Dalam gambar ini, tema adalah lapisan di sebelah default inti, apa pun yang berubah secara global di atasnya hingga blok di atas.

Gaya Global - Iterasi Pertama

Pagi ini (waktu Toronto), saya menelepon @nosolosw dan @jorgefilipecosta untuk menyelaraskan fokus Gaya Global baru ini.

Kami masing-masing secara independen mengerjakan masalah ini pada satu titik waktu. Mengingat bahwa banyak aspek gaya Global yang benar-benar baru (dalam konteks Gutenberg), dan kompleksitas yang terlibat dalam semua bagian yang bergerak, kami merasa sebaiknya menyelaraskan - untuk berbagi pengalaman, pemikiran, eksperimen, dan untuk memulai perencanaan.

3 Bagian

Setelah membahas berbagai detail implementasi dan berbagai kasus tepi, kami menyederhanakan konsep awal yang diusulkan menjadi 3 bagian utama:

• Resolver (kami menyebutnya "Gabung" selama rapat)
• Blok
• Kontrol

3 bagian ini masih mewujudkan semangat desain aslinya, kecuali bagian "Transformer", "Hooks", dan "Renderer" disederhanakan dan digabungkan menjadi "Resolver" dan "Blocks"

pemecah masalah

Resolver bertanggung jawab untuk memeriksa file theme.json dan data gaya global yang disimpan sebelumnya dari database. Ini kemudian akan menggabungkan dataset bersama dan menyiapkan sesuatu untuk dikonsumsi Gutenberg.

Blok

Blok adalah blok Gutenberg yang kita semua kenal dan cintai! Pembaruan perlu dilakukan pada .css blok untuk mulai menggunakan variabel CSS yang akan menjadi inti sistem Gaya Global.

Kontrol

Kontrol adalah antarmuka pengguna yang memungkinkan pengguna untuk menyesuaikan nilai gaya global. Ini akan disajikan dalam pengalaman Pengeditan Situs Lengkap.

Catatan: Kontrol juga ada untuk instance blok individual. Mereka adalah berbagai bidang kontrol yang tersedia di blok InspectorControls . Pembaruan hanya akan menyesuaikan bagaimana nilai gaya diterapkan, yaitu menambahkan variabel CSS gaya sebaris, bukan nilai kode keras. (Lebih lanjut tentang itu nanti)

Aliran ("Latar Belakang")

Berikut ini akan merinci aliran backend dari sistem Global Style.

pemecah masalah

Ketika Resolver dimulai, pertama kali mencari file theme.json .

1. theme.json

Untuk proposal ini, file theme.json adalah cara mudah bagi sebuah tema untuk:

A. Ikut serta dalam gaya global
B. Deklarasikan nilai gaya khusus tema

Contoh theme.json mungkin terlihat seperti ini:

{
    "name": "Awesome Theme",
    "global": {
        "color": {
            "background": "black",
            "text": "red"
        }
    },
    "blocks": {
        "core/paragraph": {
            "color": {
                "text": "hotpink"
            }
        }
    }
}

Dalam contoh ini, tema menggantikan default global color.background dan color.text . Itu juga secara khusus menyesuaikan blok Paragraph inti color.text .

2. Memeriksa Basis Data

Jika theme.json ditemukan, resolver akan memeriksa database untuk gaya global yang disimpan sebelumnya.

Gaya global khusus tema

Gaya global harus disimpan dengan cara yang khusus untuk sebuah tema. Ini memungkinkan kemampuan untuk beralih tema dengan aman tanpa konflik estetika gaya.

Ini dapat ditunjukkan dalam demo ini

(Coba terapkan beberapa gaya global / dokumen dan ganti tema).

3. Penggabungan

Data theme.json dan data database digabungkan dan disiapkan untuk digunakan oleh Gutenberg.

Memblokir

1. Diberikan

Blok dimuat dan dirender oleh editor Gutenberg. Blok menggunakan serangkaian variabel CSS yang sesuai dengan konvensi gaya global.

Variabel CSS

Berikut ini adalah contoh blok Paragraph inti menggunakan Global Styles:

p {
    color: currentColor;
}

.wp-gs p {
    color: var(--wp-gs-paragraph-color-text, var(--wp-gs-color-text));
}

.wp-gs lingkup

Untuk implementasi awal kami, idenya adalah untuk menerapkan pemilih CSS tertentu ( .wp-gs ) ke node DOM html atau body untuk secara efektif membangun "lingkungan yang didukung Gaya Global" .

Ini meningkatkan kekhususan CSS untuk blok bergaya global.

Dalam contoh di atas, rendering <p> tanpa gaya global (seperti yang mereka lakukan hari ini) akan mewarisi warnanya dari pemilih induk.

Namun, dalam "Lingkungan yang didukung gaya global", aturan .wp-gs p akan berlaku.

var(...)

Konvensi yang akan kita gunakan adalah mengawali variabel CSS gaya global dengan --wp-gs (WordPress Global Styles). Dalam contoh di atas:

.wp-gs p {
    color: var(--wp-gs-paragraph-color-text, --wp-gs-color-text);
}

var() diatur untuk:

1. Menangani rendering gaya khusus blok
2. Kembali ke nilai umum

Konvensi menggunakan gaya khusus blok dengan fallback memberikan sistem kontrol butir yang lebih baik serta stabilitas.

2. Blokir x Kontrol

Jika instance blok memiliki perubahan estetika khusus, misalnya pembaruan textColor, atribut yang diperbarui akan dirender sebagai gaya sebaris. Perbedaan antara implementasi saat ini dan implementasi yang diusulkan, adalah penggunaan Variabel CSS di atas nilai kode keras.

Saat ini:

<p style="color: red;">...</p>

Diajukan:

<p style="--wp-gs-paragraph-color-text: red;">...</p>

Dalam banyak hal, efeknya sama. Namun, menggunakan Variabel CSS memungkinkan sebagian besar efek kaskade CSS untuk diterapkan.

Kontrol

Kontrol akan ada dalam aliran edit situs dari Pengeditan Situs Lengkap.

1. Perbarui

Saat pembaruan dibuat, atribut yang diperbarui dikirim ke resolver.

Penyelesai melakukan hal itu (mungkin berkoordinasi dengan toko @wordpress/data ), dan mendorong data konsumsi yang diperbarui kembali ke Gutenberg.

Terakhir, data yang diperbarui (serta variabel CSS yang diperbarui) dihidrasi dan dirender ke antarmuka pengguna FSE, dan semua blok yang terlihat.

Aliran ("Depan")

Solusi yang kami buat (saat ini) mengharuskan Resolver untuk memeriksa/membaca theme.json dan database untuk mendapatkan dan membuat kombinasi terbaru dari nilai gaya untuk halaman tertentu.

Ini terjadi di sisi server pada pemuatan halaman.

Resolver kemudian akan membuat tag <style> untuk disuntikkan ke <head> halaman yang sedang dimuat. Contoh:

<head>
    ...
    <style>
        :root {
            --wp-gs-color-text: black;
            --wp-gs-color-background: white;
            --wp-gs-color-primary: blue;
            ...
            --wp-gs-paragraph-color-text: hotpink;
        }
    </style>
</head>

Terakhir, pemilih CSS .wp-gs perlu disuntikkan untuk mengaktifkan gaya global dari blok.

- <html>
+ <html class="wp-gs">

Dan itu saja!

Inisiatif Pertama

@nosolosw , @jorgefilipecosta , dan saya akan bekerja sama untuk membuat 3 bagian yang diuraikan di atas:

• Resolver - @jorgefilipecosta
• Blok - @nosolosw
• Kontrol UI - @itsjonq

Inisiatif pertama yang akan kami bangun memungkinkan pengguna untuk:

1. Atur gaya global untuk warna teks default
2. Aktifkan blok Paragraf + Judul inti untuk menggunakan gaya global
3. Izinkan tema untuk menyesuaikan warna teks default, judul dan warna teks blok paragraf

Gotcha

Masalah terbesar saat ini adalah kami tidak yakin bagaimana mendukung IE dengan benar. Sistem kami saat ini sangat bergantung pada Variabel CSS, dan fitur asli browser yang tidak didukung di IE11 .

Ada polyfill yang tersedia, tetapi tidak cukup untuk melakukan konsolidasi rendering yang kita butuhkan (setidaknya, tidak out of the box).

Kami sangat memperhatikan kesenjangan ini. Untuk saat ini, kami akan melanjutkan dengan solusi berbasis Variabel CSS, karena kami ingin memvalidasi mekanisme dan alur sistem. Mereka tidak hanya berfungsi, tetapi mereka tidak boleh merusak kompatibilitas ke belakang, dan mereka harus membantu Block Builder, Themers, dan Users merasa diberdayakan daripada kewalahan (oleh hal-hal seperti verbose API atau CSS fiddliness).

Umpan Balik + Terima kasih!

Pertama, jika Anda telah berhasil membaca (apakah Anda telah membaca ini atau tidak), terima kasih banyak ! Saya tahu ini sangat banyak untuk dibaca. :jantung:

Niat saya adalah menjadi setransparan mungkin dalam hal desain, eksperimen, dan implementasi apa pun.

Gaya global melibatkan banyak bagian yang bergerak. Semakin banyak konteks + pembaruan yang dapat saya berikan, semakin banyak orang yang terlibat dalam proyek ini. Yang akan mengarah pada diskusi dan keputusan yang lebih baik.

Seperti biasa, pemikiran dan umpan balik diterima!!

Terima kasih lagi :)

Masalah terbesar saat ini adalah kami tidak yakin bagaimana mendukung IE dengan benar. Sistem kami saat ini sangat bergantung pada Variabel CSS, dan fitur asli browser yang tidak didukung di IE11.

Hanya untuk menampilkan statistik di sekitar IE11 jika itu membantu orang untuk berpadu:

• Penggunaan IE11 1,43% pada Januari 2020 (melalui CanIUse )
• Penggunaan pembaca layar IE11 10,9% pada Agustus-September 2019 (melalui WebAim . Pada 2017 adalah 23,3%).

Ini adalah standar industri umum untuk meninggalkan dukungan IE11 ke tingkat "fungsional" daripada "visual sempurna".

Itu mungkin cukup cukup di sini juga terutama mengingat kasus penggunaan pembaca layar juga bahwa sisa tema dan gaya blok berfungsi sebagai mundur?

Saya tidak tahu seberapa solid misalnya ie11CustomProperties polyfill, tetapi pengembang selalu dapat memasukkannya secara manual bila diperlukan. Anda bahkan dapat menyediakannya dari inti melalui semacam sakelar keikutsertaan?

Penggunaan IE11 1,43% pada Januari 2020 (melalui CanIUse)

Dari semua kunjungan desktop dari Januari 2019 hingga Januari 2020, penggunaan IE11 adalah:

• 4,09% di seluruh dunia ( penghitung statistik )
• 6,17% di Belanda ( statcounter )

Ini adalah standar industri umum untuk meninggalkan dukungan IE11 ke tingkat "fungsional" daripada "visual sempurna".

Sepakat

Saya tidak tahu seberapa solid misalnya polyfill ie11CustomProperties, tetapi pengembang selalu dapat memasukkannya secara manual bila diperlukan. Anda bahkan dapat menyediakannya dari inti melalui semacam sakelar keikutsertaan?

Dari pengalaman pribadi, sebagian besar polyfill css-vars tidak berfungsi sebagaimana mestinya, dan ketika mereka melakukannya, mereka sangat menghambat kinerja.

Ini adalah standar industri umum untuk meninggalkan dukungan IE11 ke tingkat "fungsional" daripada "visual sempurna".

Itulah cara kebanyakan dari kita berurusan dengan css-vars & teka-teki IE... Mendefinisikan beberapa aturan CSS global yang waras yang kemudian ditimpa oleh css-vars. Jika pengunjung menggunakan IE, maka mereka masih dapat menggunakan situs web dengan baik - hanya dengan skema warna, spasi, dll. yang berbeda.
WordPress kompatibel dengan IE11, tetapi "kompatibel dengan IE11" tidak berarti bahwa IE11 harus menunjukkan hal-hal seperti yang dirender oleh browser pasca-dinosaurus... Selama berfungsi, kami jelas.

Saya adalah pembuat ie11CustomProperties. https://github.com/nuxodin/ie11CustomProperties/
Sementara Polyfill cukup cepat dan mendukung banyak.
Jika Anda ingin mencobanya, saya akan mendukung Anda dengan senang hati jika ada masalah.

@nuxodin agar adil, saya belum mengujinya selama berbulan-bulan, terakhir kali saya memeriksa repo spesifik itu di v1.3, saya melihatnya telah berjalan jauh sejak saat itu :+1:

Resolver kemudian akan membuat

@nuxodin Wow! Ini terlihat menjanjikan! Terima kasih banyak. Kami pasti akan menjelajahi ie11CustomProperties setelah kami siap untuk mulai menguji IE11.

Saya baru saja mulai berpikir bagaimana ini bisa berhasil di sana, tetapi saya ingin menandai masalah ini lebih awal.
@koke Terima kasih 🙏 !! Saya sangat menghargai Anda dan orang lain yang memikirkan masalah/masalah sedini mungkin.

Jika pengunjung menggunakan IE, maka mereka masih dapat menggunakan situs web dengan baik - hanya dengan skema warna, spasi, dll. yang berbeda.
WordPress kompatibel dengan IE11, tetapi "kompatibel dengan IE11" tidak berarti bahwa IE11 harus menunjukkan hal-hal seperti yang dirender oleh browser pasca-dinosaurus... Selama berfungsi, kami jelas.

@aristath , saya sangat setuju dengan sentimen ini. Saya membayangkan jika IE11 adalah browser utama Anda, Anda sudah kehilangan banyak hal yang ditawarkan web modern saat ini. Selama versi fallback itu berfungsi dan dapat diakses, itu akan baik-baik saja, tetapi ini mungkin hanya benar jika Anda adalah _pengunjung situs_ yang menjelajahi situs WordPress orang lain.

Dari perspektif _site admin_ yang menggunakan WordPress dengan browser IE11, sulit untuk mengetahui seperti apa pengalaman pengeditan/penyesuaian. Kami mungkin perlu menambahkan sesuatu untuk menonaktifkan Gaya Global untuk admin situs WordPress saat menggunakan browser IE11. Jika tidak, mereka tidak akan dapat melihat penyesuaian apa pun yang mereka buat yang mungkin terasa seperti pengalaman yang rusak bagi mereka.

Ini adalah standar industri umum untuk meninggalkan dukungan IE11 ke tingkat "fungsional" daripada "visual sempurna".

Itu mungkin cukup cukup di sini juga terutama mengingat kasus penggunaan pembaca layar juga bahwa sisa tema dan gaya blok berfungsi sebagai mundur?

Saya lebih senang menggunakan opsi ini untuk sisi editor. Perhatian utama saya adalah dengan mengeluarkan vars CSS di ujung depan, karena itu berarti siapa pun yang membuat situs web dengan WP _tidak lagi memiliki opsi_ untuk sepenuhnya mendukung IE jika mereka mau. Dan dengan komentar saya sebelumnya (maaf jika tidak cukup jelas) saya bermaksud menunjukkan bahwa ini bisa menjadi masalah bagi pemerintah dan entitas resmi lainnya yang mungkin _memiliki_ untuk memberikan dukungan penuh itu.

Saya juga enggan menggunakan rute polyfill karena implikasi kinerja. Mungkin ada baiknya melakukan sedikit penyelidikan tentang bagaimana kita bisa mencapai ini tanpa menggunakan CSS vars di front end (bahkan jika kita menggunakannya di editor).

Perhatian utama saya adalah dengan mengeluarkan vars CSS di ujung depan, karena itu berarti siapa pun yang membuat situs web dengan WP tidak lagi memiliki opsi untuk sepenuhnya mendukung IE jika mereka mau.

Dimungkinkan untuk menambahkan parser PHP yang akan menjalankan sisi server jika diaktifkan dan mengganti css-vars dengan nilai sebenarnya. Ini akan membuat semua yang ditampilkan di IE sama persis seperti yang ditampilkan di browser modern.
Kami telah melakukannya sebelumnya untuk agensi tempat saya bekerja dan itu berfungsi dengan baik.
Semua filter yang diperlukan untuk tugas semacam itu sudah ada, jadi ini bukan tugas yang tidak dapat diselesaikan.

Dimungkinkan untuk menambahkan parser PHP yang akan menjalankan sisi server jika diaktifkan dan mengganti css-vars dengan nilai sebenarnya. Ini akan membuat semua yang ditampilkan di IE sama persis seperti yang ditampilkan di browser modern.

Ini pasti cara yang harus ditempuh. Meskipun dengan satu batasan saya berasumsi, selama vars CSS disimpan di :root atau pemilih tingkat atas yang serupa. Mirip dengan https://jhildenbiddle.github.io/css-vars-ponyfill/

Dimungkinkan untuk menambahkan parser PHP yang akan menjalankan sisi server jika diaktifkan dan mengganti css-vars dengan nilai sebenarnya. Ini akan membuat semua yang ditampilkan di IE sama persis seperti yang ditampilkan di browser modern. Saya telah melakukannya sebelumnya untuk agensi tempat saya bekerja dan itu berfungsi dengan baik.

Ide PHP ini terdengar sangat menarik terutama jika tidak berjuang dengan keterbatasan yang sama seperti yang dilakukan fallback. Saya ingin melihat PR atau cuplikan kode dari ini bekerja—kedengarannya cukup menjanjikan :-)

Tentu, saya dapat mengerjakan implementasi PHP untuk ini ...
Kami pada dasarnya membutuhkan 2 hal:

1. Dapatkan nilai vars CSS.
2. Tambahkan gaya fallback untuk IE11.

Untuk yang pertama saya meninggalkan komentar di https://github.com/WordPress/gutenberg/pull/19883#pullrequestreview -349737431 tentang menambahkan filter. Kita dapat menggunakan filter itu untuk mendapatkan css-vars dan nilainya.

Yang ke-2 tergantung di mana css aktual yang menggunakan css-vars itu dicetak. Apakah akan inline dalam blok? Jika demikian, maka kita dapat menggunakan filter render_block untuk menangani penyuntikan CSS kompatibilitas mundur.
Jika tidak, apakah ada PR atau ide bagaimana/di mana ini akan dicetak? Atau akankah tema hanya mengantrekan stylesheet menggunakan wp_enqueue_style ?
Jika wp_enqueue_style digunakan, itu masih bisa dilakukan tetapi akan membutuhkan penguraian konten file yang diantrekan, cari css-vars, dan jika vars ini digunakan dalam file maka hitung gaya yang perlu ditambahkan dan cetak . TBH Saya ingin menghindari opsi terakhir ini karena mungkin menambahkan beberapa overhead jika tema menambahkan file besar.

Peta Jalan Gaya Global

Terima kasih, semuanya, atas pemikiran/masukan Anda sejauh ini!

Ada beberapa diskusi mengenai aspek-aspek tertentu dari sistem (misalnya rendering CSS), yang valid. Tampaknya tidak ada banyak perlawanan atau perhatian untuk keseluruhan sistem dan bagaimana bagian-bagiannya cocok, yang merupakan pertanda baik. Sepertinya kita berada di jalur yang benar!

Minggu ini, saya fokus pada penjelajahan dan perencanaan. Memikirkan detail teknis, detail implementasi, batasan, persyaratan, dan kasus penggunaan. Gaya global adalah proyek besar, dengan banyak bagian yang bergerak. Ini adalah proyek yang dapat memiliki dampak besar pada pengalaman pengguna dan ekosistem.

Karena itu, saya pikir sangat penting untuk memberikan visi (tingkat tinggi) yang jelas - memudahkan siapa pun yang terlibat untuk memahami dan mengikuti.

Saya telah mengumpulkan ikhtisar tingkat tinggi tentang cara kerja sistem, serta peta jalan kasar untuk mengurutkan fase kerja.

Video Screencast / Panduan
https://www.loom.com/share/9e63b821916a4f70821a52ced069b92b

Dalam video, saya berjalan melalui aliran Rendering sistem dan melewati fase-fase.

Render Aliran

Diagram (di atas) mengilustrasikan aliran render Global Styles. Ini memvisualisasikan hierarki gaya sistem. Saya telah menjuluki ini "Cascade Sintetis".

Itu dimulai di sebelah kiri (dengan Gutenberg dan Blok). Gaya untuk blok dapat dimodifikasi ketika melewati lapisan tema , lapisan global , lapisan lingkup , dan perubahan terakhir yang dilokalkan dalam editor Gutenberg. Akhirnya, semua akumulasi perubahan ini dirender ke frontend situs pengguna.

"Cakupan"

Istilah "cakupan" mengacu pada bagian "dokumen" atau "templat" dari pengalaman FSE. Pada dasarnya, blok "Wadah" yang berisi blok.

Blok Pihak Ketiga

Blok pihak ke-3 adalah blok non-inti . Sistem perlu memberi mereka cara untuk mendaftarkan gaya kustom mereka sendiri, dan membuat gaya tersebut dapat disesuaikan melalui antarmuka pengeditan Gaya Global.

Global Pihak Ketiga

3rd Party Globals merujuk pada gaya non-inti yang tidak terkait dengan blok . Misalnya, menambahkan gaya global khusus untuk kecepatan animasi situs secara keseluruhan. Atau mungkin pasangan font Tipografi situs secara keseluruhan (header/body).

Fase

Saya telah memecah pekerjaan menjadi 6 fase berbeda (di atas). Catatan: Vibrancy menekankan fokus yang kita perlukan untuk area itu. Misalnya, pada fase pertama, Merah, area Inti/Blok sangat bersemangat.

Merah

Fase pertama! Tujuannya adalah untuk menciptakan sistem dasar di dalam inti dan memasang beberapa blok inti ke sistem penataan global. Kami juga perlu menyediakan antarmuka sederhana untuk memperbarui nilai-nilai ini. Terakhir, kita perlu membuat sistem rendering gaya sisi klien (Gutenberg) dan sisi server (Situs) awal.

Untuk memulai, kita akan menargetkan blok core/paragraph dan core/heading .

Anggap ini MVP!

Jeruk

Fase Kedua! Fase ini berfokus pada pengenalan dukungan tema ke dalam sistem. Bagaimana opsi tema dan file theme.json akan berinteraksi dengan default inti. Terakhir, bagaimana nilai yang ditentukan tema dirender dan dapat dimodifikasi dalam UI editor Gaya Global.

Kuning

Fase Ketiga! Fase ini berfokus pada Editor Gaya Global. Bagaimana nilai gaya blok disajikan dan bagaimana mereka dapat dimodifikasi. Bagaimana gaya global yang disesuaikan pengguna memengaruhi tema dan nilai inti.

Ini adalah fase pertama yang akan melibatkan banyak desain visual/interaksi.

Hijau

Fase keempat! Fase ini melanjutkan fokus pada Editor Gaya Global, tetapi dalam kaitannya dengan bagian Dokumen/Templat, dan cara memainkannya dalam pengalaman FSE. Sistem perlu memastikan bahwa perubahan cakupan berfungsi dengan benar dengan hierarki gaya.

Biru

Fase kelima! Fase ini sangat berfokus pada aspek rendering gaya. Di sini, kita akan meninjau kembali di mana variabel CSS adalah solusi yang tepat. Jika tidak, apa yang dapat kita lakukan untuk meniru pengalaman itu saat bekerja dengan sistem lainnya. Saat mengerjakan solusi, kita perlu memastikan bahwa pelingkupan serta penggantian tema berfungsi seperti yang diharapkan. Terakhir, fase ini akan mulai melihat dukungan blok pihak ke-3, dan melihat cara bermainnya dengan sistem lainnya.

Ungu

Fase keenam! Fase ini melanjutkan fokus pada rendering dan memastikan bahwa itu berfungsi dengan benar di frontend situs pengguna. Ini juga memastikan bahwa mekanisme rendering baru (yang berpotensi) berfungsi dengan hierarki gaya lainnya. Terakhir, ini mengintegrasikan blok pihak ke-3 dan dukungan global pihak ke-3.

Di mana kita berada?

Sampai sekarang, dengan fase yang dijelaskan (di atas), kami telah memulai Fase Merah, dengan inisiatif pertama kami .

@jorgefilipecosta telah membuat PR awal yang menyentuh semua aspek fase ini.

@karmatosed sedang mengeksplorasi desain untuk antarmuka pengeditan Gaya Global .

@nosolosw sedang mengerjakan aspek Resolver x Client-side renderer dari sistem.

Saya telah menyodok ke depan untuk melihat Kontrol.

Linimasa

Saya belum dapat memberikan garis waktu yang akurat untuk proyek tersebut. Saya pikir kita akan mendapatkan pemahaman yang lebih baik setelah kita mulai membangun, menguji, dan menggabungkan. Sampai saat itu, mudah-mudahan, rincian fase akan membantu.

Seperti biasa, pemikiran dan umpan balik diterima! Jika Anda telah berhasil sampai akhir, terima kasih banyak atas waktu Anda! :jantung:

Tentu, saya dapat mengerjakan implementasi PHP untuk ini ...
Kami pada dasarnya membutuhkan 2 hal:

1. Dapatkan nilai vars CSS.
2. Tambahkan gaya fallback untuk IE11.

Untuk yang pertama saya meninggalkan komentar di #19883 (ulasan) tentang menambahkan filter. Kita dapat menggunakan filter itu untuk mendapatkan css-vars dan nilainya.

Yang ke-2 tergantung di mana css aktual yang menggunakan css-vars itu dicetak. Apakah akan inline dalam blok? Jika demikian, maka kita dapat menggunakan filter render_block untuk menangani penyuntikan CSS kompatibilitas mundur.
Jika tidak, apakah ada PR atau ide bagaimana/di mana ini akan dicetak? Atau akankah tema hanya mengantrekan stylesheet menggunakan wp_enqueue_style ?
Jika wp_enqueue_style digunakan, itu masih bisa dilakukan tetapi akan membutuhkan penguraian konten file yang diantrekan, cari css-vars, dan jika vars ini digunakan dalam file maka hitung gaya yang perlu ditambahkan dan cetak . TBH Saya ingin menghindari opsi terakhir ini karena mungkin menambahkan beberapa overhead jika tema menambahkan file besar.

Hai @aristath ,

Terima kasih telah berbagi ide dan mencoba mengatasi masalah ini.

Saya pikir kita berada di hadapan skenario kedua, wp_enqueue_style digunakan. Gaya yang menggunakan variabel adalah gaya blok normal, dan mereka sering diantrekan menggunakan wp_enqueue_style. Selain itu, kami memiliki masalah gaya blok inti yang lebih besar yang berisi variabel-variabel ini dimuat menggunakan sistem penggabungan gaya WordPress, sehingga mereka adalah bagian dari spreadsheet raksasa.

Poin lainnya adalah bahwa penggantian sederhana vars mungkin tidak berfungsi karena idenya adalah bahwa di masa mendatang kita akan, dapat menyesuaikan gaya global untuk hal-hal di dalam blok tertentu (misalnya, di dalam grup tertentu warna utamanya adalah biru). Nilai yang dimiliki variabel tidak statis; mereka akan tergantung pada konteksnya.

Saya kira kita harus mencoba memiliki polyfill untuk variabel CSS yang berfungsi di IE. Kami bahkan dapat menyesuaikan satu untuk kebutuhan spesifik kami dan misalnya, meneruskan objek javascript dari server dengan nilai variabel, dll.

Resolver kemudian akan membuat

@ItsJonQ

Itu dimulai di sebelah kanan (dengan Gutenberg dan Blok)

Saya pikir maksud Anda itu dimulai di sebelah kiri?

Apa yang belum saya pahami: Bagaimana palet warna dan terutama warna latar belakang berperan dalam hal ini?

• Jika saya dapat mengontrol warna untuk elemen yang berbeda pada tingkat global, dapatkah saya juga menentukan palet warna yang akan digunakan sebagai Palet Warna Editor?
• Jika saya memiliki palet warna untuk warna latar belakang, dapatkah saya mengontrol pada tingkat global bagaimana suatu elemen terlihat pada latar belakang yang berbeda?

Ambil tombol misalnya. Jika saya memilih warna merah sebagai latar belakang untuk tombol default saya, bagaimana tampilannya pada latar belakang yang berbeda, misalnya pada oranye?

Bisakah saya mengontrol warna latar belakang tombol secara global pada latar belakang oranye? Atau apakah saya masih harus memilih warna latar belakang untuk setiap tombol secara terpisah, ketika muncul di latar belakang yang berbeda?

Bagaimana palet warna dan terutama warna latar belakang berperan dalam hal ini?

@gchtr Itu pertanyaan + contoh yang bagus! Jika saya memahami pertanyaan/kasus penggunaan Anda dengan benar... sepertinya kita perlu menangani kasus di mana:

• Semua tombol ditata secara global untuk memiliki latar belakang merah
• Tapi, ketika mereka muncul dalam sesuatu dengan latar belakang yang bentrok (misalnya oranye), mereka perlu membuat warna yang berbeda, (misalnya putih, dengan teks hitam ).

Di situlah ide "melingkupi" gaya global kustom berperan.

Dalam hal HTML/CSS, Anda dapat membayangkan ini:

<button>...</button>
<div class="orange-section">
    <button>...</button>
</div>

button { background: red; }

.orange-section button {
    background: white;
    color: black;
}

Bagian yang sulit adalah. Bagaimana kita mereplikasi hierarki model/gaya ini dalam sistem gaya Global Gutenberg?
Dalam konteks Gutenberg, bit-bit ini adalah Blok.

Jadi dengan cara ... itu akan menjadi:

<Block>
<Block>
    <Block />
</Block>

Atau cara pandang lain...

<Block>
<ContainerBlock>
    <Block />
</ContainerBlock>

Itu berarti, bahwa kita harus dapat melingkupi gaya khusus untuk blok "Penampung", sehingga setiap blok anak (bertarget) akan mewarisi gaya ini. Sistem gaya harus mendukung ini dari perspektif UI (kontrol pengeditan gaya) dan perspektif rendering.

Semoga masuk akal!!! 🙏

Saya pikir maksud Anda itu dimulai di sebelah kiri?

@ZebulanStanpill Ya! Terima kasih banyak! sudah saya koreksi :)

Hai @ItsJonQ ,

Ini terlihat sangat menarik, namun, saya juga bertanya-tanya bagaimana Sistem Gaya Global akan bekerja dengan palet warna. Saya telah membuat pembuat halaman mini untuk klien saya menggunakan Gutenberg, di mana mereka memiliki kontrol penuh atas tata letak, tetapi tidak ada kontrol skema warna. Jika mereka membutuhkan perubahan pada warna yang tersedia di palet warna, saya harus melakukannya untuk mereka, tetapi saya lebih suka jika mereka memiliki kemungkinan untuk melakukannya sendiri.

Komponen palet warna memainkan peran besar dalam pengaturan saya karena warna yang sama mungkin digunakan untuk Latar Belakang Judul dan Tombol, berikut adalah contoh untuk membuatnya sedikit lebih jelas:

Oksigen sudah melakukannya dengan cara yang luar biasa, memungkinkan untuk mengubah warna global DAN melihat efeknya secara langsung. Saya berharap perilaku ini akan datang ke Sistem Gaya Global dalam beberapa cara juga.

Oksigen sudah melakukannya dengan cara yang luar biasa, memungkinkan untuk mengubah warna global DAN melihat efeknya secara langsung. Saya berharap perilaku ini akan datang ke Sistem Gaya Global dalam beberapa cara juga.

@dnnsjsk Terima kasih atas dukungan Anda dan untuk contoh yang indah itu!

Ya, kita harus mendukung interaksi ini.

Pada akhirnya, seluruh upaya ini adalah untuk meningkatkan pengalaman pengguna (akhir). Penyesuaian tidak hanya harus mengubah apa yang Anda harapkan, tetapi pengalaman harus terasa menyenangkan saat Anda membuat penyesuaian tersebut. Itu harus terasa kreatif, membebaskan, dan menyenangkan. Yang sejalan dengan tujuan pengalaman pengeditan Gutenberg :).

Memang, pengalaman ini sulit untuk dipilih berdasarkan dinding teks yang saya bagikan di edisi ini . Saya sebagian besar fokus pada aspek teknis dan bagaimana bagian-bagian itu akan bekerja bersama. Selain pengalaman pengguna akhir yang baik, pengalaman pengembang harus baik. Alur kerja yang kami buat terasa lebih mudah dan lebih baik bagi pengembang Themers dan Block.

@karmatosed , @shaunandrews , dan lainnya mulai menjelajahi desain/UX dari pengalaman ini di sini:

https://github.com/WordPress/gutenberg/issues/19255

Kami masih sangat awal! Saya pikir Roadmap baru-baru ini akan membantu upaya desain dev x bekerja sama.

Halo! Saya baru saja menulis komentar panjang di https://github.com/WordPress/gutenberg/issues/19255#issuecomment -582315718 yang seharusnya saya posting di sini? Bagaimanapun, kunci pengambilan dari komentar itu adalah bahwa sebagai bagian dari upaya untuk merancang pola blok dasar, saya secara tidak sengaja membuat daftar keinginan item yang ingin saya lihat dapat dicapai oleh sistem gaya global (seperti berat font, garis -height, dropcap-size), sebagian besar hal yang telah saya lihat disebutkan.

Harap buat bilah geser "sedikit lengket" (penggeser halus adalah pengalaman pengguna yang buruk pada rentang besar) dan tampilkan nilai saat ini.

@carike-codes Kami memiliki fitur tersebut di komponen RangeControl diperbarui
https://github.com/WordPress/gutenberg/pull/19916

Penggeser berperilaku persis seperti HTML default input[type="range"] . Dalam situasi di mana ada banyak langkah, misalnya, min: 0, max: 1000, step: 1 , itu akan terasa "lebih halus", karena ada nilai 1000 untuk bertambah

(Semoga membantu)

_Catatan: Komentar ini tentang kompatibilitas asli-reaksi_

API itu tidak akan menyertakan gaya default tema, hanya penyesuaian pengguna. Jadi kita mungkin akan membutuhkan API lain yang menyediakan gabungan default WordPress dengan default tema. Masalah ini sangat mirip dengan apa yang terjadi dengan FSE...

Jadi jika saya memahami ini dengan benar, kami ingin mengimplementasikan versi sisi klien dari resolver yang akan menggunakan API itu? Bukankah itu juga membantu FSE untuk dapat memperbarui gaya blok saat gaya global diperbarui di Kontrol?

Jika itu masalahnya, penduduk asli gutenberg ingin menggunakan kembali resolver sisi klien ini.

Masih ada masalah variabel css yang tidak didukung pada react-native. Transformasi postcss tidak akan berfungsi karena kami membutuhkannya agar dinamis untuk memperbarui dengan pengambilan baru ke API.

Mempertimbangkan fakta bahwa kita hanya dapat menggunakan gaya sebaris dalam bahasa asli, jadi kita memerlukan modul tambahan untuk mengisi gaya untuk blok tertentu di editor.

Mari kita ambil contoh gaya blok di mana pengguna menimpa warna teks untuk blok ini di InspectorControls, kita memiliki ini:

--wp-gs-color-text: #fff;
--wp-gs-background-color: yellow;
--wp-gs-paragraph-color-text: #000;

.wp-gs p {
    color: var(--wp-gs-color-text);
    background-color: var(--wp-gs-background-color);
}

<!-- wp:paragraph {"textColor":"red"} -->
<p style="--wp-gs-paragraph-color-text: red;">
Lorem ipsum dolor sit amet</p>
<!-- /wp:paragraph -->

Di ponsel kita perlu membuat kode yang sama persis, jadi save harus tidak berubah. Namun, edit harus menghindari penggunaan variabel css:

<RichText style={ { color: "red", backgroundColor: "yellow" } } .../>

Saya belum yakin apa implikasinya dalam hal penulisan blok platform-X. Menulis modul seperti itu yang secara otomatis menyelesaikan semua gaya untuk blok tertentu harus dapat dilakukan, setidaknya jika kita membatasi diri pada beberapa properti CSS dan jika kita tidak memiliki beberapa elemen yang dapat disesuaikan di dalam komponen RichText.
Web dan seluler mungkin dapat membagikan ini meskipun mungkin memiliki dampak kinerja dalam hal ini kami hanya perlu mengaktifkan ini di seluler. @jorgefilipecosta @koke Tidak yakin apakah Anda memiliki pemikiran tentang ini?

@koke Tidak yakin apakah Anda memiliki pemikiran tentang ini?

Ya, saya memiliki kekhawatiran yang sama, tetapi saya belum memiliki jawaban yang jelas. Naluri saya saat ini adalah bahwa taruhan terbaik kami mungkin benar-benar meningkatkan parser CSS yang kami gunakan pada native untuk benar-benar mendukung variabel CSS (dan beberapa hal lainnya, seperti mode gelap, kueri media, dan @supports ). Alih-alih mencoba mengonversi CSS menjadi StyleSheet dalam satu langkah, kita dapat membuatnya menghasilkan DynamicStyleSheet yang dapat menyesuaikan beberapa variabel dan kueri saat runtime. Ini terdengar seperti upaya besar, jadi saya masih mencari alternatif yang mungkin lebih mudah.

Bisakah saya menggunakan ini untuk menimpa variabel scss yang didefinisikan dalam bootstrap?

Saya baru saja selesai membaca Petualangan Dengan Sistem Global Kompleks di Situs Web Berbasis Blok - Bagian Satu , dan saya pikir akan menjadi ide yang baik untuk membagikannya di sini. Ini adalah bacaan yang panjang, tetapi menarik, yang mungkin memberi beberapa orang di sini beberapa ide.

Kami telah bermain dengan Global Styles dan memiliki beberapa pemikiran/ide/pertanyaan.

Arah Global Styles saat ini

Jika saya memahami arah saat ini, idenya adalah untuk membuat hardcode variabel gaya global menjadi blok sehingga mereka menggunakannya.

Bagian yang sulit tentang ini adalah bahwa kontrol granular bisa menjadi sangat banyak dan luas, dan juga sulit untuk digunakan di tempat khusus. Misalnya, ini mungkin cara kerja kontrol granular (secara konseptual, bukan contoh sintaksis):

gs-another-background-color
gs-yet-another-background-color
gs-h1-font-color
gs-h1-font-color-exception
gs-yet-another-h1-font-color-variation
...many more variables required

Ide lain untuk arah Global Styles

Setelah bermain dengan pendekatan itu, kami bertanya-tanya apakah gaya global bisa lebih "hal-agnostik", dan disederhanakan seperti ini:

gs-color-2
gs-color-3
...more variables required, but no values are ever duplicated

Idenya di sini adalah bahwa blok dapat memilih apakah mereka ingin latar belakang menjadi gs-color-1 , gs-color-2 , atau gs-color-3 . Mungkin bahkan melalui UI pemilih gaya global. Berikut adalah _really_ mockup kasar tentang tampilannya.

Beberapa keuntungan dari pendekatan ini:

• Kurang total variabel gaya global yang diperlukan.
• Penerapan gaya berpindah ke blok, memungkinkan lebih banyak fleksibilitas desain.
• Tidak diperlukan duplikasi nilai (pilih #fffff sebagai gs-color-1 sekali, bukan berkali-kali)
• Pengguna blok memiliki fleksibilitas untuk menggunakan gaya global di mana pun mereka mau. Misalnya, itu bisa untuk latar belakang, atau font, atau perbatasan, tetapi semua bisa menggunakan gs-color-1 , alih-alih mendefinisikan #fffff 3 waktu terpisah.

Jika saya harus memilih di antara keduanya, saya akan menggunakan Pendekatan B, tetapi versi yang saya gunakan untuk tema ini adalah versi Pendekatan A yang kurang terperinci yang dibangun di atas Pendekatan B.

Pertama, saya mendefinisikan sekelompok warna:

--white: #ffffff;
--gray-light: #d4d4d4;
--gray-dark: #333333;
--black: #141414;
--aqua: #7fdbff;
--blue: #0074d9;
--navy: #00203f;
--teal: #38cccc;
--fuchsia: #f012bc;
--purple: #b00dc9;
--maroon: #85144b;

(Saya dapat melihat keuntungan dari pengaturan tipe --color-1 yang lebih umum yang Anda usulkan untuk Wordpress pada umumnya, tetapi prinsipnya sama.)

Kemudian, saya memetakannya ke beberapa variabel tingkat tinggi yang relatif umum seperti ini:

--text-color: var(--black);
--text-color-secondary: var(--gray-dark);
--accent-color: var(--aqua);
--background-color: var(--white);
--heading-color: var(--navy);
--action-color: var(--purple);
--action-color--invoked: var(--maroon); /* hover & focus states */

Ini kemudian dapat diturunkan melalui variabel yang lebih spesifik sesuai kebutuhan tema:

--focus-ring-color: var(--accent-color);

--link-color: var(--action-color);
--link-color--hover: var(--action-color--invoked);

--input-color: var(--text-color);
--input-border-color: var(--input-color);
--input-background-color: var(--background-color);

--button-color: var(--action-color);
--button-color--hover: var(--action-color--hover);

/* whatever other theme-specific variables I want to make up */

Penulis tema bisa mendapatkan granular seperti yang mereka inginkan di sini (--h2-color, --page-title-color, --subhead-color, apa pun), tetapi mereka selalu dapat mencoba membangun dari inti dengan mempertimbangkan kaskade . Misalnya, jika saya menambahkan blok dengan skema warna gelap di tema saya:

.is-theme-dark {
    --text-color: var(--white);
    --text-color--secondary: var(--gray-light);
    --accent-color: var(--aqua);
    --background-color: var(--navy);
    --heading-color: var(--blue);
    --action-color: var(--fuchsia);
    --action-color--invoked: var(--purple);
    /* whatever other theme-specific variables I want to switch */
}

Mengganti persneling, seseorang yang membuat plugin resep yang telah menggunakan warna tingkat atas seperti itu akan memiliki peluang yang layak untuk berfungsi dengan baik ketika masuk ke blok grup .is-theme-dark penulis tema:

.recipe {
   color: var(--text-color);
}
.recipe__image {
    border: 0.5rem solid var(--accent-color);
}
.recipe-print-button {
   color: var(--action-color);
}
.recipe-print-button__icon {
   color: var(--accent-color);
}

Mengenai dukungan IE11:

Sudahkah Anda memeriksa solusi ini: https://github.com/jhildenbiddle/css-vars-ponyfill ?

Saya disarankan untuk memberikan kejelasan tentang di mana kita berada mengenai Sistem Gaya Blok. Saya mencoba mengkonsolidasikan apa yang kami miliki di dua utas utama: visi https://github.com/WordPress/gutenberg/issues/9534 dan langkah-langkah spesifik https://github.com/WordPress/gutenberg/issues/20331 yang Saya akan memperbarui di hari-hari berikutnya.

Sejak masalah ini dibuat, kami telah banyak maju, dari segi implementasi: kami memiliki perannya untuk mengontrol editor , kami telah membuat alat desain baru , mekanisme awal untuk hubungkan blok & level global dari sistem gaya blok , dan lebih dari yang saya lewatkan.

Masalah ini telah mencapai tujuannya, jadi saya menutupnya. Petunjuk di atas seharusnya menjadi bukti betapa mendasarnya percakapan ini untuk mengungkap langkah-langkah konkret yang perlu kita jalani.