Ping @noisysocks dan @iseulde untuk perubahan editor. Saya bisa menambahkan perubahan inti.

Untuk editor, perubahannya (seperti yang saya lihat) adalah:

• Tambahkan atribut data-wp-attachment-id="1234" ke semua tag <img> .
• Selalu masukkan gambar berukuran "besar".
• Tambahkan atribut srcset dengan ukuran medium, large dan xlarge (kami akan segera menambahkan ukuran gambar xlarge ke ukuran default).
• Tambahkan atribut sizes sesuai untuk lebar gambar di editor.
• Saat menyimpan, mungkin hapus srcset dan sizes karena mungkin akan berbeda saat ditampilkan. Cara lainnya, kita dapat menggantinya di filter tampilan.
• Saat mengatur nilai piksel apa pun untuk dimensi gambar, dasarkan mereka dari lebar editor. Tidak masuk akal untuk memiliki gambar yang lebih lebar dari yang terlihat di editor.

TODO: pertimbangkan cara terbaik untuk meneruskan lebar persentase ke front-end.

Terima kasih telah menulis ini, @azaozz! Senang membantu dengan perubahan editor yang diperlukan. Mereka terdengar bagus bagiku.

Atau kita dapat mengatur lebar dalam persentase (gaya HTML 4.0) di editor, lalu menggantinya dengan piksel pada saat ini.

Keraguan saya dengan hal ini adalah jika pihak ketiga (misalnya plugin, pembaca RSS, konsumen API) menggunakan post_content tanpa memprosesnya, maka mereka tidak akan memiliki markup HTML5 yang valid. "Menghormati HTML" adalah salah satu persyaratan Gutenberg.

Berpikir keras: dapatkah kita menggunakan metadata Gutenberg untuk melakukan beberapa hal ini, misalnya untuk menyimpan ID lampiran dan persentase lebar?

<!-- wp:image {"attachmentId":123,"horizontalScale":0.25} -->
<img src="https://example.com/image.jpg" width="600" height="500" />
<!-- /wp:image -->

Ya, gambar adalah "blok dinamis" (begitulah cara mereka diperlakukan di editor klasik juga). Mereka adalah jenis blok dinamis terbaik karena memiliki "markup fallback" tepat di sana, dan diproses di
front-end untuk menyempurnakannya.

Memiliki markup fallback membuat gambar berfungsi "di mana saja" bahkan saat "filter tampilan" belum dijalankan (ini sebenarnya akan meninggalkan konten tanpa paragraf, jadi jangan berpikir ada plugin yang akan melakukannya).

Kami tentu saja dapat menambahkan data yang kami perlukan untuk meneruskan ke front-end ke meta blok, namun kami berpikir kami akan membutuhkan data yang sama di tag <img> juga. Salah satu alasannya adalah parsing blok yang ditampilkan lambat dan kita akan mendapatkan potongan HTML yang lebih besar daripada tag img yang sebenarnya (gambar dengan keterangan, dll.). Alasan lainnya adalah bahwa (mungkin) tidak semua gambar akan berada dalam blok yang terpisah, memikirkan gambar dalam blockquote, sel tabel, dll. Alasan lainnya adalah bahwa jika kiriman diedit di editor lain, blok tersebut mungkin rusak parah, tetapi <img> tag akan "bertahan" dan tetap utuh (selama kita menggunakan HTML standar).

Pada akhirnya intinya adalah:

• Mana yang lebih mudah, lebih cepat, lebih sederhana, lebih mudah dibaca / dimengerti: parsing blok dan kemudian pemrosesan potongan HTML (yang mungkin berisi beberapa elemen), atau parsing tag <img> seperti yang kita lakukan saat ini.
• Dapatkah kami menjamin bahwa semua gambar yang digunakan dalam editor akan selalu berada dalam wp:image blok. Itu termasuk gambar yang ditempelkan, gambar dalam sel tabel, tanda kutip, dan blok serta kombinasi tag lainnya yang mungkin muncul dengan plugin.

Imho kita harus menggunakan atribut meta blok dan tag img, kemudian (suatu hari) kita akan dapat memilih mana yang akan digunakan saat mengurai konten yang ditampilkan.

@azaozz Ini adalah proposal yang dipikirkan dengan

Saat ini bidang persentase terpapar tetapi saya tidak dapat menentukan apakah ini melakukan apa pun saat ini di frontend. https://github.com/WordPress/gutenberg/blob/master/blocks/library/image/block.js#L266

Pendekatan persentase bagus tetapi merusak kompatibilitas mundur dengan API tema.

mengapa kami tidak menggunakan ukuran gambar yang dinyatakan tema ...

Kami melakukannya :) Kami menggunakan semua ukuran yang tersedia (yang memiliki rasio w / h yang sama) saat menambahkan atribut srcset di front-end. Kemudian browser memutuskan file gambar mana yang akan digunakan.

@azaozz Saya yakin itu akan berfungsi sedikit berbeda dari perilaku saat ini. Ukuran gambar juga dapat digunakan untuk menyampaikan gaya, bukan hanya pemangkasan gambar yang akan digunakan. Saya juga berpikir bahwa plugin lazy load yang ada mengharapkan nilai src menjadi ukuran yang "benar" jadi saya tidak yakin kita dapat mengandalkan sepenuhnya pada srcset .

Edit: Saya kira ini akan menjadi filter image_size_names_choose .

@davisshaver Saya telah melalui beberapa plugin lazy load dalam seminggu terakhir. Banyak dari mereka mencari atribut src dan srcset dan cukup menggantinya dengan markup lain di PHP menggunakan filter the_content . Tantangannya di sini adalah bagaimana mendapatkan inti untuk menghasilkan atribut srcset dan sizes serta gambar fisik pada awalnya.

Ada beberapa masalah terkait gambar responsif yang akan memiliki solusi yang tumpang tindih. Saya mengusulkan agar kita mengkonsolidasikan semuanya ke dalam masalah ini untuk menghindari perpecahan diskusi lebih lanjut. Berikut daftar yang tidak lengkap:

Masalah terkait:

• # 5674 Gambar galeri tidak responsif
• # 4505 Tambahkan kelas dan mekanisme 'has-wide-support'
• # 4342 Konten tidak ditampilkan dengan benar saat berpindah tema
• # 6131 Izinkan tema mengontrol atribut ukuran untuk gambar lebar / penuh

Tiket inti:

• Ganti statis dengan Ukuran Gambar Dinamis untuk gambar yang disisipkan
• Cara menghapus jalur gambar ukuran penuh dari srcset dan pilihan yang lebih cerdas di daftar kandidat srcset
• Optimalkan gambar ukuran penuh

Terkait hal tersebut, dalam proposal @azaozz :

Tambahkan ukuran default baru 2x besar, lebar atau tinggi maks 2048px

Apakah ada pertimbangan untuk menaikkan ukuran piksel default saat ini dari "thumbnail", "medium", dan "large", yang awalnya ditentukan pada tahun 2008? Mungkin dengan Gutenberg ini saat yang tepat untuk meningkatkannya x2.

Jika tidak, istilah "sedang" dan "besar" akan kehilangan arti semantiknya.

Juga terkait: # 5650 content_width dan lebar blok baru

Penyebab masalah inti yang sama: paradigma lebar konten baru membuat hal-hal yang dulunya standar tidak berfungsi seperti yang diharapkan dan menimbulkan kebutuhan untuk memikirkan kembali cara kerja inti.

/ update / image-block adalah "sedang dalam proses" :) Silakan uji.

Perubahan:

• Tambahkan srcset dan sizes di dalam editor.
• Selalu masukkan ukuran gambar large , atau full jika tidak ada yang besar.
• Tampilkan ukuran gambar Default , Thumbnail , ditambah penambah ukuran apa pun dengan plugin dan tema.
• Tambahkan data-wp-attachment-id dan ata-wp-percent-width ke tag img. Akan digunakan di bagian depan untuk mengatur srcset dan sizes , dan juga img width dan height jika hilang.
• Tingkatkan pengaturan / reset dimensi gambar.
• Tambahkan srcset ke data lampiran dari API dan ke data di modal media.

MELAKUKAN:

• Tambahkan kode front-end yang akan menangani atribut tag img baru.
• Perbaiki menghapus fokus dari gambar (dan menyembunyikan tuas pengubah ukuran) saat keterangan difokuskan.
• Coba perbaiki pengubahan ukuran dengan menyeret. Saat ini menyeret sudut kiri atau kanan tidak melakukan apa-apa, hanya menyeret ke atas atau ke bawah mengubah ukuran gambar (dan tebal).

@azaozz sejauh ini terlihat sangat bagus. Kerja bagus!

Beberapa hal yang saya perhatikan saat menguji ini:

Pertama, lebar editor mungkin tidak akan cocok dengan lebar tampilan yang diinginkan di bagian depan, jadi menyimpan atribut sizes berdasarkan atribut editor mungkin merupakan pendekatan yang salah dan menyebabkan gambar dibatasi ke lebar editor , daripada wadah konten di tema. Kita perlu menggunakan nilai content_width ditetapkan oleh tema di bagian depan, atau terus menyetel sizes di bagian depan, daripada menyimpannya ke markup gambar (yang, Saya yakin Anda tidak akan terkejut mendengar saya masih menganggap itu ide yang buruk).

Yang terakhir akan menjadi saran saya. Di sini kita sekarang dapat memanfaatkan block parser di WordPress untuk menerapkan solusi gambar responsif yang jauh lebih baik, daripada filter pada the_content . Saat ini, blok tersebut menyimpan data atribut duplikat ke pembatas komentar blok gambar dan ke markup. Kita dapat terus menghemat srcset dan sizes sebagai atribut blok tanpa menambahkannya ke markup. Kami kemudian dapat terus menggunakannya dalam komponen yang dapat diedit seperti yang Anda miliki sekarang, dan membuatnya tersedia untuk parser blok. Kita juga bisa membersihkan beberapa duplikat lainnya dalam proses dengan mendeklarasikan source untuk atribut yang kita simpan ke markup.

Saya 💖 perubahan pada dropdown ukuran di sini. Saya ingin tahu jika Anda berpikir tentang bagaimana ini dapat diperpanjang untuk memungkinkan ukuran pemangkasan khusus, yaitu add_image_size() opsi untuk disertakan di sini sehingga seseorang dapat membuat satu set opsi yang dipotong keras untuk sebuah gambar.

Bug yang saya temui adalah memasukkan gambar, menyetel jenis sumber ke thumbnail, menyimpan draf, dan kemudian menyegarkan halaman. Dalam hal ini, parser blok merespons dengan kesalahan klasik "Blok ini tampaknya telah dimodifikasi secara eksternal". Tampaknya itu hanya mengharapkan atribut src dan alt dan mencekik atribut tambahan pada markup.

Masih ada keanehan dengan gambar rata kanan / kiri. Saya ingin tahu apakah dalam kasus ini kita harus mengubah ukuran secara eksplisit menjadi persentase lebar editor dan memperbarui atribut ukuran agar sesuai?

Saya terkejut dengan pilihan untuk menambahkan nilai spesifik srcset ke setiap ukuran yang dikembalikan oleh REST API dan wp_prepare_attachment_for_js tetapi ini adalah pendekatan cerdas yang belum pernah saya pertimbangkan. Kita harus membuka tiket inti untuk ini sehingga kita dapat mendiskusikan pro / kontra untuk secara eksplisit menambahkan data ini ke tanggapan tersebut daripada membiarkannya di filter begitu Gutenberg mendarat. Satu catatan kecil, saya melihat beberapa pemberitahuan di filter REST yang kadang-kadang $response->data['media_type'] tidak ada, dan mengeluarkan pemberitahuan, yang aneh karena harus selalu ditentukan. Sesuatu yang menyenangkan untuk digali.

Saya akan meninggalkan ini untuk saat ini dan melanjutkan pengujian. Bravo, Pak.

@joemcgill terima kasih sudah melihatnya!

Pertama, lebar editor mungkin tidak akan cocok dengan lebar tampilan yang diinginkan di bagian depan

Baik. Inilah alasan untuk menambahkan atribut data-wp-percent-width ke tag img. Kemudian kita akan dapat menghitung ulang lebar di bagian depan dan "mencocokkan" apa yang dilihat pengguna di editor. Ini juga membuatnya kompatibel dengan pengeditan pada telepon, dan juga mendukung lebar wide dan full ketika diatur dalam tema (kita harus mendapatkan tema untuk menambahkan ini dan mulai menggunakannya di depan- akhir).

... menyimpan atribut ukuran berdasarkan atribut editor mungkin merupakan pendekatan yang salah

Ya, memang dimaksudkan untuk diganti di bagian depan. Berpikir jika kita harus menyimpannya di tag gambar sebagai "fallback" jika terjadi kesalahan. Namun berpikir untuk meninggalkan srcset di tag sebagai peluang untuk mengubahnya setelah posting diterbitkan sangat kecil (itu akan dapat disaring di front-end tentunya). Tidak ada gunanya hanya memiliki srcset dan tidak ada ukuran, sejauh yang saya lihat browser tampaknya mengunduh gambar terbesar (mungkin fallback lain) :)

sekarang kita dapat memanfaatkan parser blok di WordPress ...

Mungkin tapi itu akan sangat lambat. Untuk saat ini menjalankan parser blok di front-end bukanlah sesuatu yang dapat kita lakukan.

Saat ini, blok tersebut menyimpan data atribut duplikat ke pembatas komentar blok gambar dan ke markup.

Begitulah cara kerja properti blok. Atau kita dapat "mengekstrak" blok gambar dengan beberapa regex dan mengurai HTML di dalamnya mencari tag gambar. Tetap saja ... mengurai sedikit HTML dengan regex sepertinya sesuatu yang harus kita hindari. Jadi untuk saat ini berpikir untuk menambahkan semua konteks yang dibutuhkan dari editor di tag img yang sebenarnya.

Saya ingin tahu apakah Anda pernah berpikir tentang bagaimana ini dapat diperpanjang untuk memungkinkan ukuran pemangkasan khusus (ukuran dropdown)

Ini seharusnya berfungsi saat ini. Hanya ukuran yang sesuai dengan rasio gambar asli yang dihapus dari drop-down, sisanya (ditambah thumbnail) yang ditampilkan. Jadi semua tanaman khusus yang ditambahkan oleh tema dan plugin ada di dalamnya.

Bug yang saya temui adalah memasukkan gambar, menyetel jenis sumber ke thumbnail, menyimpan draf, dan kemudian menyegarkan halaman.

Uh, akan periksa lagi. Pikir saya menangkap semua ini .. Ini juga mendorong saya untuk melihat validasi blok, dan mengapa blok begitu sering gagal (misalnya setelah pengguna menambahkan atribut lain). Berpikir kita akan membutuhkan beberapa perbaikan umum di sana juga, tapi itu untuk masalah lain.

Masih ada keanehan dengan gambar rata kanan / kiri. Saya ingin tahu apakah dalam kasus ini kita harus mengubah ukuran secara eksplisit menjadi persentase lebar editor dan memperbarui atribut ukuran agar sesuai?

Ya, berpikir perilaku sebelumnya lebih baik di sana. Kita mungkin harus kembali ke pengaturan gambar rata kanan / kiri ke lebar 50%. Bisa juga mengubah sizes jika kita mempertahankan atribut itu di tag img.

Saya terkejut dengan pilihan untuk menambahkan nilai srcset tertentu ke setiap ukuran yang dikembalikan oleh REST API dan oleh wp_prepare_attachment_for_js

Menguji beberapa pendekatan di sana tetapi tampaknya ini bekerja paling baik. Saat menambahkan srcset meta gambar sudah di-cache sehingga menambahkan overhead yang dapat diabaikan saat memuat data untuk perpustakaan media dan API. Dengan cara itu kami juga mencocokkan srcset yang "tepat" yang akan digunakan di front-end.

Kita harus membuka tiket inti untuk ini ...

Ya, setelah Gutenberg digabungkan, ini harus berfungsi dengan benar.

Saya melihat beberapa pemberitahuan di filter REST yang terkadang $ response-> data ['media_type'] tidak ada

Hmm, kami mungkin harus membuka tiket trac inti untuk itu. Itu harus selalu ada.

Saya akan melihat untuk menambahkan kode front-end yang menggunakan atribut baru selanjutnya. Maka kita akan memiliki awal yang baik untuk mengubah semua ini :)

Saya mengobrol dengan @azaozz di hari kontributor WCEU dan ingin berbagi pemikiran saya dengan semua orang dalam upaya untuk memajukan ini.

__Context: __ Front-end (tema / wilayah plugin)
__Assumptions: __ Proposal yang diajukan oleh @azaozz re: menyetel atribut data-wp-percent-width dengan lebar yang ditampilkan relatif terhadap ruang yang tersedia.

Usul

Tantangan yang saya minati, seperti yang telah saya tentukan sebelumnya (# 6131), adalah bagaimana pengembang tema dan plugin dapat mengontrol atribut sizes di bagian depan situs berdasarkan berbagai faktor termasuk tetapi tidak terbatas pada tata letak yang berbeda (bilah sisi atau tidak, faktor lain) tanpa harus menulis ulang secara manual seluruh atribut sizes untuk setiap kondisi seperti dalam contoh ini .

Pertimbangkan skenario berikut, a sampai i:

Secara historis, kami mengetahui dua hal tentang gambar yang ditampilkan: Lebar fisik file gambar, dan $content_width seperti yang ditentukan oleh tema. Kami kemudian menggunakan dua parameter ini untuk mencari tahu atribut sizes .

Gutenberg tidak hanya memperkenalkan lebar alignwide dan alignfull , tetapi juga kemampuan untuk membuat berbagai elemen wide atau full termasuk tetapi tidak terbatas pada kolom dll. Akibatnya, ada banyak sekali kemungkinan lebar tampilan dalam satu tema selain tantangan biasa yang ditimbulkan oleh desain web yang responsif.

Contoh berikut menunjukkan ada _dua konstanta_ yang dapat dengan mudah ditentukan oleh pengembang tema (dan oleh pengembang plugin ekstensi):

• $content_width - lebar maksimum konten ketika tidak ditampilkan sebagai alignwide atau alignfull .
• $max_display_area - ruang maksimum yang tersedia untuk diisi jika konten disetel ke alignfull .

Ada juga sepertiga asumsi yang bisa kita buat:

• Elemen yang disetel ke alignwide akan menempati $content_width ditambah setengah dari ruang yang tersedia antara $content_width dan $max_display_area , dan dapat dihitung sebagai

$content_width + ( $max_display_area - $content_width ) / 2

Dengan kata lain, jika WordPress mengetahui nilai $content_width dan $max_display_area , ia dapat menghitung secara akurat ruang di dalam konten mana yang ditampilkan dan dari sana menentukan dengan cepat apa atribut sizes gambar yang ditampilkan didasarkan pada bagaimana gambar itu ditampilkan, termasuk data-wp-percent-width diperkenalkan oleh @azaozz.

Aplikasi praktis

Pengembang tema mendefinisikan dua nilai:

• $content_width mendeklarasikan lebar maksimum _content_ (seperti pada lebar konten jika tidak ada alignwide atau alignfull diterapkan) untuk kondisi tampilan apa pun.
• $max_display_area mendeklarasikan lebar maksimum yang tersedia untuk setiap kondisi tampilan.

Kedua nilai ini akan bervariasi tergantung pada kondisi sehingga tidak ada yang bisa menjadi global seperti $content_width sekarang (kecuali saya salah paham bagaimana $content_width saat ini bekerja).

Untuk gambar yang ditampilkan tanpa alignwide atau alignfull , variabel $content_width (dan atribut data lebar tersuai jika tersedia) sudah cukup untuk menentukan atribut sizes : ukuran yang ditampilkan tidak akan lebih besar dari $content_width atau beberapa persentase dari $content-width ditentukan oleh atribut data. Ini akan jauh lebih sederhana untuk diatur untuk pengembang tema daripada metodologi saat ini btw.

Untuk gambar yang ditampilkan dalam konteks alignwide atau alignfull , kita perlu menggunakan nilai $max_display_area . Masuk akal untuk menentukan variabel ini sebagai larik yang memasangkan lebar viewport dan area tampilan yang tersedia. Larik ini dapat, dalam kombinasi dengan atribut data, diubah menjadi atribut sizes dihasilkan dengan cepat.

Jadi untuk contoh di atas sebuah tema akan menyatakan sesuatu seperti:

// In this theme there is a fixed maximum content width of 720px.
$content_width = 720px;

if ( is_active_sidebar( 'sidebar-1' ) {
  $max_display_area = [
    'min-width: 48em' => 'calc( 100vw - 30em), // sidebar is 30em wide.
    'fallback' => '100vw',
  ];
} else {
  $max_display_area = [
    'fallback' => '100vw',
  ];
}

Dengan asumsi untuk d, e, dan f, breakpoint dimana sidebar muncul adalah 48em dan untuk g, h, dan i, atribut data-wp-percent-width adalah 50%, menghasilkan atribut sizes sebagai contoh di bagian atas komentar ini adalah sebagai berikut:

/**
 * a: Image width is equal to $content_width area.
 */
sizes="(min-width: $content_width) $content_width, fallback"
sizes="(min-width: 720px) 720px, 100vw"

/**
 * b: Image width is 50% of the available space between $content_width and $max_display_area.
 */
sizes="(min-width: $content_width) calc(($max_display_area - $content_width) / 2), fallback"
sizes="(min-width: 720px) calc((100vw - 720px) / 2), 100vw"

/**
 * c: Image width is equal to fallback.
 */
sizes="fallback"
sizes="100vw"

/**
 * d: Image widths is equal to $content_width area.
 */
sizes="(min-width: $content_width) $content_width, fallback"
sizes="(min-width: 720px) 720px, 100vw"

/**
 *e: Image width is $content_width plus 50% of the available space between $content_width and $max_display_area.
 */
sizes="(min-width: $content_width) calc(($max_display_area - $content_width) / 2), fallback"
sizes="(min-width: 720px) calc((100vw - 30em) - 720px) / 2, 100vw"

/**
 * f: Image width is equal to $max_display_area.
 */
sizes="$max_display_area, fallback"
sizes="(min-width: 48em) calc(100vw - 30em), 100vw"

/**
 * g: Image width is 50% of $content_width. 
 */
sizes="(min-width: $content_width) calc($max_display_area * (data-wp-percent-width / 100)), calc(fallback * (data-image-width / 100))"
sizes="(min-width: 720px) calc(720px * .5), calc(100vw * .5)"

/**
 * h: Image width is 50% of $content_width plus 50% of the available space between $content_width and $max_display_area.
 */ 
sizes="(min-width: $content_width) calc((($max_display_area - $content_width) / 2) * (data-wp-percent-width / 100)), calc( fallback * (data-image-width / 100))"
sizes="(min-width: 720px) calc(((100vw - 720px) / 2) * .5), calc(100vw * .5)"

/**
 * i: Image width is equal to 50% of fallback.
 */
sizes="calc(fallback * (data-wp-percent-width / 100))"
sizes="calc(100vw * .5)"

Terima kasih @ mor10 ,

Ya, untuk memproses dan menampilkan gambar dengan benar di front-end kita memerlukan beberapa bit data: beberapa konteks dari editor tentang bagaimana gambar itu digunakan dengan tepat, dan beberapa data dari tema tentang bagaimana gambar itu akan ditampilkan.

Saya punya beberapa saran / klarifikasi kecil.

$content_width - lebar maksimum konten ketika tidak ditampilkan sebagai alignwide atau alignfull.
$max_display_area - ruang maksimum yang tersedia untuk diisi jika konten diatur ke alignfull.

Saya (masih) berpikir kita harus membiarkan tema (dapat) menentukan ketiga lebar: konten / kolom utama, lebar dan penuh. Dengan begitu kami tidak akan memaksakan apapun pada tema. Beberapa mungkin menginginkan gambar alignwide sedikit lebih lebar atau lebih sempit. Menggunakan setengah dari perbedaan antara content_width dan full untuk wide mungkin merupakan fallback, jika temanya sudah usang, mungkin?

Jadi ini seharusnya seperti:

• $content_width
• $alignwide_width
• alignfull_width

(Secara teknis, mereka juga bisa berada dalam array asosiatif sehingga kita tidak "mengotori" ruang global terlalu banyak. Memiliki array itu juga akan menandakan bahwa tema mendukung ini.)

Perbedaan penting lainnya adalah kita mengharapkan lebar baru ini menjadi "kontekstual". Yaitu mereka harus diatur oleh template saat ini sebelum mulai menampilkan HTML, (dan mungkin diatur ulang di akhir). Ini penting untuk menghasilkan atribut sizes lebih tepat untuk semua gambar.

Gutenberg tidak hanya memperkenalkan lebar alignwide dan alignfull , tetapi juga kemampuan untuk membuat berbagai elemen wide atau full .

Jangan berpikir kita perlu khawatir tentang re: gambar itu. Jika sebuah blok disetel ke full , tidak masuk akal untuk memiliki gambar alignfull di dalamnya. Ini akan persis sama dengan gambar "normal". Sama untuk wide blok.

Memiliki ketiga lebar yang ditentukan masuk akal, dan array asosiatif memang akan membuatnya lebih bersih. Satu-satunya pertanyaan adalah bagaimana mengubahnya dengan kondisi ... Saya kira dev tema hanya akan memodifikasi array?

Jangan berpikir kita perlu khawatir tentang re: gambar itu. Jika sebuah blok disetel ke full , tidak masuk akal untuk memiliki gambar alignfull di dalamnya. Ini akan persis sama dengan gambar "normal". Sama untuk wide blok.

Jika Anda melihat contoh di komentar saya, Anda akan melihat bahwa kita harus memperhitungkannya. Jika seseorang memiliki layar yang sangat besar dan blok disetel ke alignfull dengan gambar 50% di dalamnya, gambar itu bisa jadi jauh lebih besar daripada lebar konten. sizes atribut harus menjelaskan lebar tampilan sebenarnya dari sebuah gambar, dan apapun yang ditempatkan dalam konteks alignwide atau alignfull akan memiliki lebar yang berbeda dari yang lain.

Halo @ mor10 , dalam contoh Anda, seharusnya ukuran untuk 'b' menjadi:

size = "(min-width: $ content_width) calc ($ content_width + ($ max_display_area - $ content_width) / 2), fallback"

?

@alialaa Matematikanya mungkin miring. Itu diberikan sebagai contoh prototipe saja.

@azaozz Dimana kita dengan ini? Saya baru saja menguji Gutenberg 3.3 dengan Tema Pemula Gutenberg resmi dan sejauh yang saya tahu, blok saat ini semuanya menggunakan ukuran gambar penuh untuk semuanya. Ini menyebabkan kinerja yang signifikan saat plugin diaktifkan.

@ mor10 Saya mencoba menerapkan sesuatu yang sangat mirip dengan kode yang Anda berikan (filter wp_calculate_image_sizes ), kecuali saya mencoba mencapai ini untuk tema yang lebih besar yang memiliki lebih banyak variasi tata letak. Masalah terbesar hingga saat ini adalah menerapkan generator yang kuat dari atribut sizes untuk setiap tempat gambar dapat muncul di tema. Masalah terbesarnya adalah:

• fluid vs. tata letak lebar tetap
• Sistem kisi (dalam persen dari wadah)
• Celah kisi
• Kehadiran / ketidakhadiran sidebar
• Beberapa titik putus kueri media

Apa yang sudah saya terapkan adalah beberapa logika PHP yang menerima sekumpulan parameter dan mengeluarkan berbagai ukuran, dengan deskriptor lebar dan kueri media. Tujuan saya adalah untuk menutupi tata letak bootstrap yang paling umum, mereka sangat banyak digunakan

Untuk konteksnya, berikut adalah breakpoint (dengan kueri media yang sedikit dimodifikasi) yang digunakan untuk menghasilkan angka-angka ini.

Parameter yang valid untuk hal tersebut adalah:

1. bootstrap_class : bisa sangat panjang, menerima apa yang diterima bootstrap, ini sebenarnya diurai dan digunakan untuk menghasilkan banyak kueri media
2. gutters : true | Salah. Masukkan talang 30px ke dalam kalkulasi atau tidak. Jumlah ini dapat dikonfigurasi
3. fluid : benar | Salah. Tata letak non-fluid adalah yang paling sulit, mereka memiliki max-width dalam piksel

Berikut adalah beberapa kasus uji yang benar-benar lulus, dalam format JSON (setiap entri adalah kasus uji, objek pertama adalah masukan ke logika saya, dan yang kedua adalah keluaran):

[
    [

        {"bootstrap_class": "col-md-12", "gutters": true, "fluid": true},
        [{"media_query": false, "image_size": "calc(100vw - 30px)"}]
    ],

    [
        {"bootstrap_class": "col-sm-12", "gutters": true, "fluid": true},
        [{"media_query": false, "image_size": "calc(100vw - 30px)"}]
    ],

    [
        {"bootstrap_class": "col-xs-6", "gutters": true, "fluid": true},
        [{"media_query": false, "image_size": "calc(50vw - 30px)"}]
    ],
    [
        {"bootstrap_class": "col-xs-8", "gutters": true, "fluid": true},
        [{"media_query": false, "image_size": "calc(66.6667vw - 30px)"}]
    ],
    [
        {"bootstrap_class": "col-xs-5", "gutters": true, "fluid": true},
        [{"media_query": false, "image_size": "calc(41.6667vw - 30px)"}]
    ],
    [
        {"bootstrap_class": "col-xs-9", "gutters": true, "fluid": true},
        [{"media_query": false, "image_size": "calc(75vw - 30px)"}]
    ],
    [
        {
            "bootstrap_class": "col-xs-10 col-sm-3 col-md-7 col-lg-11 col-xl-5",
            "gutters": true,
            "fluid": true
        },
        [
            {"media_query": "1300px", "image_size": "calc(41.6667vw - 30px)"},
            {"media_query": "1000px", "image_size": "calc(91.6667vw - 30px)"},
            {"media_query": "690px", "image_size": "calc(58.3333vw - 30px)"},
            {"media_query": "480px", "image_size": "calc(25vw - 30px)"},
            {"media_query": false, "image_size": "calc(83.3333vw - 30px)"}
        ]
    ]
]

Setelah mendapatkan hasilnya, itu dapat dirakit dengan mudah menjadi atribut sizes siap untuk dimasukkan ke dalam HTML.

Misalnya, inilah output yang seharusnya untuk gambar col-xs-10 col-sm-3 col-md-7 col-lg-11 col-xl-5 sangat rumit:

[
    {
        "bootstrap_class": "col-xs-10 col-sm-3 col-md-7 col-lg-11 col-xl-5",
        "gutters": true,
        "fluid": true
    },

    [
        {"media_query": "1300px", "image_size": "calc(41.6667vw - 30px)"},
        {"media_query": "1000px", "image_size": "calc(91.6667vw - 30px)"},
        {"media_query": "690px", "image_size": "calc(58.3333vw - 30px)"},
        {"media_query": "480px", "image_size": "calc(25vw - 30px)"},
        {"media_query": false, "image_size": "calc(83.3333vw - 30px)"}
    ]
],

Yang pada HTML rakitan akhir akan terlihat seperti itu:

<div class="container-fluid">
  <div class="row">
    <div class="col-xs-10 col-sm-3 col-md-7 col-lg-11 col-xl-5">

      <img
        srcset="..."
        sizes="
          (min-width: 1300px) calc(41.6667vw - 30px),
          (min-width: 1000px) calc(91.6667vw - 30px),
          (min-width: 690px) calc(58.3333vw - 30px),
          (min-width: 480px) calc(25vw - 30px),
          calc(83.3333vw - 30px),
        "
      >

    </div>
  </div>
</div>

Sekarang kasus uji untuk tata letak non-fluid jauh lebih rumit dan lebih sulit untuk diikuti.

Juga, terkadang bootstrap_class tidak cukup dan kita harus dapat mengekspresikan lebar gambar dalam persentase mentah.

Jika tertarik, saya bisa melompat ke obrolan yang lebih detail di tempat lain tentang hal ini, saya sangat tertarik untuk meneruskannya dengan benar, masih banyak masalah yang saya hadapi 🙂

8593 telah menambahkan atribut srcset dan sizes ke masing-masing gambar galeri, tetapi atribut sizes masih bertindak seolah-olah setiap gambar mengambil lebar konten penuh dari tampilan yang jarang kasus.

Terkait: # 1450

Dimana kita dengan ini?

Melihatnya atm, terasa buruk untuk sementara waktu. Harapan akan memiliki cabang yang diperbarui dan "bisa diterapkan" dalam beberapa hari.

Memperbarui cabang blok gambar: https://github.com/WordPress/gutenberg/tree/update/image-block. Cukup banyak perubahan sejak pembaruan terakhir, semua fungsionalitas baru / yang dibutuhkan ada di sana, silakan uji!

@joemcgill @getsource @ mor10 berpikir untuk membuat pr besok, ulasan cabang dihargai :)

Memperbarui cabang lagi. Hampir siap, hanya perlu lebih banyak pengujian :)

Menambahkan ini ke tonggak WP 5.0 karena sangat penting bagi kami untuk tidak memperkenalkan regresi kinerja dengan gambar yang dimasukkan ke dalam konten posting dan saya tidak ingin lupa untuk meninjau pembaruan di sini.

Kita harus ingat bahwa masalah kinerja ini tidak hanya dengan gambar yang diintegrasikan melalui tag HTML (gambar dan blok galeri) tetapi juga dengan blok gambar sampul, di mana gambar dimasukkan melalui css sebagai gambar latar belakang.

Solusi melalui srcset tidak akan berfungsi untuk blok ini.

Twenty Nineteen sekarang memberikan landasan pengujian konkret untuk masalah ini. Lihat https://github.com/WordPress/twentynineteen/issues/50#issuecomment -434120505 untuk detail lebih lanjut.

@azaozz Menjalankan cabang yang direferensikan menggunakan Twenty Nineteen, gambar yang saya sisipkan mendapat markup berikut:

<img 
  src="http://gutenberg.local:8888/wp-content/uploads/2011/07/michelle_049-1024x768.jpg" 
  alt="Big Sur" 
  width="640" 
  height="480" 
  srcset="http://gutenberg.local:8888/wp-content/uploads/2011/07/michelle_049-1024x768.jpg 1024w, http://gutenberg.local:8888/wp-content/uploads/2011/07/michelle_049-300x225.jpg 300w, http://gutenberg.local:8888/wp-content/uploads/2011/07/michelle_049-768x576.jpg 768w, http://gutenberg.local:8888/wp-content/uploads/2011/07/michelle_049.jpg 1600w" 
  sizes="(max-width: 640px) 100vw, 640px">

Sepertinya lebar maksimal disetel agar sesuai dengan set global content_width dalam tema .

Markup baru apa (jika ada) yang harus saya tambahkan ke tema untuk menguji fungsionalitas baru?

@ mor10 benar, ini menggunakan $content_width PHP global. Itu adalah fallback dari $block_width global yang baru diperkenalkan yang seharusnya berisi tiga nilai: default, wide dan full, lihat: https://github.com/WordPress/gutenberg/blob/update/image-block/packages /block-library/src/image/index.php#L26 (perhatikan bahwa lebar ini bekerja lebih seperti max-width, seperti (lama) $content_width ).

Untuk mengujinya, mungkin ikuti contoh dari phpdoc di blok gambar:

/**
 * Get the expected block width from the global $block_width array.
 *
 * The global $block_width array is expectd to be set by the theme for each block container.
 * It should contain three values: default, wide and full, in pixels.
 * - The `default` value should be the expected block width (similarly to $content_width).
 * - The `wide` value is optional and is used when the block alignment is set to `wide`.
 * - Similarly the `full` value is optional and used then the alignment is set to `full`.
 * If `wide` and `full` are not set, the `default` value is used instead.
 *
 * Example:
 *     $GLOBALS['block_width'] = array(
 *         'default' => 640,
 *         'wide'    => 800,
 *         'full'    => 1024,
 *     );
 *
 * In addition the $block_width array should be set contextually for each block container.
 * For example: in the main content column the `default` width will be something like 640(px),
 * but for a sidebar it would be something like 250.

Jika Anda ingin menyetel atribut sizes lebih tepat, cara terbaik tetap menggunakan filter https://developer.wordpress.org/reference/hooks/wp_calculate_image_sizes/ . Sepertinya menambahkan sesuatu yang "lebih mudah" untuk tema tetapi menyetel sizes yang tepat sangat kontekstual dan sangat bergantung pada gaya (kolom, breakpoint, margin, padding, dll.). Tidak ada "cara mudah" di sana, yang terbaik adalah menyerahkan kendali penuh pada tema (yaitu, gunakan filter).

Mengapa nilai ini dalam piksel? Banyak (mungkin sebagian besar) tema tidak akan menggunakan nilai piksel untuk lebarnya. Twenty Nineteen hanyalah satu contoh. Lebar dapat ditentukan menggunakan nilai lebar apa pun. Misalnya, gambar dengan lebar penuh biasanya akan menjadi 100vw .

Juga mengapa ini disetel sebagai opsi global, vs add_theme_support atau melalui filter?

Akan sangat membantu melihat cabang ini dibuka sebagai PR, meskipun cabang itu ditandai sebagai WIP atau dengan label "Dalam Proses". Memudahkan untuk meninjau kode, mendiskusikannya, dll. ☺️

Mengapa nilai ini dalam piksel

Karena ukuran gambar (file) dalam piksel dan karena kita perlu menyetel atribut <img> tag width dan height (praktik terbaik). Nilai 100vw digunakan secara default dalam atribut sizes , tetapi tema juga harus melewati lebar-maksimal yang dapat diterima bahkan untuk blok gambar "sejajarkan penuh".

Mungkin ada tema yang akan memutuskan bahwa pengunjung situs harus mengunduh gambar 3-4MB selama situs terlihat bagus pada layar 2560px. Orang lain akan lebih pragmatis dan membatasinya pada nilai yang lebih "waras".

BTW, agar ini berfungsi dengan baik, kami membutuhkan ukuran lain yang lebih besar yang dihasilkan secara default untuk semua gambar yang diunggah.

mengapa ini disetel sebagai global, vs opsi add_theme_support atau melalui filter

Idenya adalah agar global ini menjadi "kontekstual", yaitu memiliki nilai yang berbeda untuk "template" yang berbeda. Ada beberapa cara untuk melakukan ini, tetapi PHP global atau mengaktifkan tindakan WP tampaknya paling mudah digunakan.

@azaozz Lihat https://github.com/WordPress/twentynineteen/pull/411. Kami berbicara tentang cara untuk mendeteksi apakah gambar saat ini ditampilkan sebagai biasa, alignwide , atau alignfull dari dalam wp_calculate_image_sizes beberapa waktu yang lalu. Saya yakin satu idenya adalah menambahkan atribut data di dalam elemen <img> . Tanpa informasi kontekstual ini saya tidak melihat bagaimana saya dapat memberikan atribut sizes untuk tiga opsi tata letak. Ide diterima.

Tanpa informasi kontekstual ini ...

Baik. Informasi ini ada dalam array $block_attributes . Ini sedang diteruskan ke filter (baru) render_block_core_image_tag_attributes (mungkin perlu nama yang lebih baik ...). Setelah itu digabungkan ke Gutenberg dan inti, saya pikir kita akan dapat meneruskan atribut blok ke filter wp_calculate_image_srcset dan wp_calculate_image_sizes .

Dimana kamu itu? Bisakah saya mengujinya saat ini?

Belum karena itu memodifikasi file inti. Dapat menambahkannya sebagai "retas" :)

Harus melewati $block_attributes saat menelepon wp_calculate_image_srcset() dan wp_calculate_image_sizes() , lihat https://github.com/WordPress/gutenberg/blob/update/image-block/packages/block- library / src / image / index.php # L210 dan https://github.com/WordPress/gutenberg/blob/update/image-block/packages/block-library/src/image/index.php#L213. Kemudian berikan hal yang sama ke filter dalam fungsi ini di /wp-includes/media.php.

Terima kasih telah menguji!

Apakah ada tiket inti yang dapat saya susun agar ini tetap berjalan? GB dan Twenty Nineteen tidak dapat dirilis kecuali jika ini diselesaikan imo.

@azaozz Saya mendapat kesempatan untuk melakukan beberapa pengujian cabang kemarin (maaf atas keterlambatan). Saya ingin melakukan lebih banyak hal, tetapi ingin memberikan masukan berikut:

Pertama, saya akan mengulangi lagi bahwa saya sangat menentang gagasan untuk menyimpan atribut srcset dan sizes ke markup gambar dalam database. Markup dalam database harus tidak dapat diubah dan sebagai bukti di masa mendatang. Dari perspektif konten murni, tag img dengan satu src harus tetap ada, dan srcset dan sizes adalah detail implementasi yang paling baik ditangani ujung depan. srcset atribut dapat dan harus berubah setiap kali ukuran gambar tambahan dibuat untuk lampiran (setelah mengganti tema, atau menambahkan ukuran gambar baru ke tema yang ada, dll.).

Gutenberg sudah memformat markup gambar dengan cara yang mendukung solusi gambar responsif kami saat ini melalui filter ujung depan jadi saya pikir fokusnya harus meningkatkan filter yang tersedia untuk tema untuk memodifikasi atribut sizes berdasarkan atribut blok yang berisi gambar (mis., perataan, kolom galeri, dll).

Catatan tambahan:

Saya perhatikan bahwa di editor, Chrome sekarang mengunduh dua versi dari setiap gambar (ini tidak terjadi di cabang master). Yang kedua adalah karena peralihan atribut src dari komponen gambar di fetchImageSize() yang dipanggil selama componentDidMount . Ini meniadakan keuntungan yang datang dari menambahkan srcset dan sizes ke komponen.

Pada gambar dengan lebar penuh, lebar maksimal dibatasi pada 1024 piksel yang merusak pratinjau. Ini tidak terjadi di master.

Saya akan terus menguji dan menambahkan catatan, tetapi juga echo @chrisvanpatten bahwa akan sangat membantu untuk dapat mengulas ini sebagai PR. Terima kasih!

@joemcgill terima kasih telah menguji! :)

Saya sekali lagi akan menegaskan kembali bahwa saya sangat menentang gagasan untuk menyimpan atribut srcset dan ukuran ke markup gambar dalam database ... atribut srcset dapat dan harus berubah setiap kali ukuran gambar tambahan dibuat untuk lampiran (setelah mengganti tema, atau menambahkan gambar baru ukuran ke tema yang ada, dll.).

Ini adalah sesuatu yang kami lihat beberapa tahun yang lalu ketika menerapkan srcset dan sizes . Secara teori kedengarannya mungkin, namun dalam praktiknya hal itu jarang terjadi sehingga harus ditinggalkan untuk ditangani oleh plugin. Itu juga merusak pembuatan srcset dan sizes ketika konten diekspor dari satu situs WP dan diimpor ke situs lain saat ID lampiran berubah (tetapi URL tidak berubah).

Namun dalam kasus ini atribut srcset dan sizes murni untuk kepentingan editor. Mereka selalu dibuat ulang di front-end, lihat https://github.com/WordPress/gutenberg/blob/update/image-block/packages/block-library/src/image/index.php#L244.

Masih berpikir kita harus membuka tiket inti untuk WP 5.1+ untuk melihat penggunaan kembali atribut srcset karena itu memperbaiki konten yang diimpor. Atribut default sizes adalah tema agnostik, tetapi berpikir itu harus selalu dibuat ulang dan difilter di front-end.

Gutenberg sudah memformat markup gambar dengan cara yang mendukung solusi gambar responsif kami saat ini melalui filter ujung depan

Kurang tepat :) Saat ini Gutenberg "memaksa" gambar ukuran penuh baik di editor maupun di bagian depan. Benar bahwa atribut srcset ditambahkan ke tag <img> , tetapi lihat atribut default sizes sana. Ini "borked" :)

Saya pikir fokusnya harus meningkatkan filter yang tersedia untuk tema untuk mengubah atribut ukuran ...

Sangat setuju. Ini menambahkan beberapa filter baru yang membantu di sana, tetapi yang terpenting kita harus meneruskan block_attributes ke filter wp_calculate_image_sizes (juga ke wp_calculate_image_srcset untuk dicocokkan).

Selain itu, setelah pembaruan terakhir ada cukup banyak data terkait editor yang diteruskan dalam atribut blok ini. Itu memungkinkan penskalaan gambar yang tepat di front-end, mengatur ulang width dan height (dan memastikan ini selalu ada, praktik terbaik), dan umumnya memberikan lebih banyak opsi untuk tema saat merender blok gambar.

Saya perhatikan bahwa di editor, Chrome sekarang mengunduh dua versi dari setiap gambar

Ini hanya terjadi untuk gambar yang baru diunggah. Saat gambar ditambahkan sebagai "pratinjau" saat mengunggah, kita perlu mengubah src agar mengarah ke ukuran "besar" setelah ada kiriman lampiran. Juga, di dalam editor, keuntungan memiliki srcset adalah untuk memuat dan menampilkan gambar "retina". Tidak ada keuntungan kecepatan karena konten editor (HTML) dimuat lama setelah halaman selesai dimuat.

Pada gambar dengan lebar penuh, lebar maksimal dibatasi pada 1024 piksel yang merusak pratinjau. Ini tidak terjadi di master.

Baik. Alternatifnya di sini adalah selalu mengunduh 2-4MB atau terkadang gambar yang lebih besar. Itu tidak bisa diterima, meski hanya di editor. Untuk memperbaiki batasan ini kita perlu membuat gambar lain yang berukuran lebih kecil secara default, lebih besar dari "besar". Ini telah dibahas berkali-kali di Slack, dan ada tiket inti yang cukup "lama". Kami pasti harus segera melakukannya.

Saya akan terus menguji dan menambahkan catatan

Ya silahkan! :)
Berpikir untuk membuat PR malam ini, tampaknya sebagian besar kasus tepi dalam menangani gambar diperhitungkan.

Namun dalam kasus ini atribut srcset dan size adalah murni untuk kepentingan editor.

Jika demikian, maka tidak masuk akal untuk menyimpan atribut tersebut ke markup yang disimpan dalam database.

Kurang tepat :) Saat ini Gutenberg "memaksa" gambar ukuran penuh baik di editor maupun di bagian depan. Memang benar bahwa atribut srcset ditambahkan ke tag, tapi lihat atribut ukuran default di sana. Ini "borked" :)

Ah benar, perbedaan yang membantu di sini adalah atribut lebar gambar tidak disimpan dengan benar, karena kami tidak lagi membatasi ukuran gambar menjadi content_width .

Ini hanya terjadi untuk gambar yang baru diunggah.

Saya tidak percaya ini benar. Saya dapat menyimpan posting, menyegarkan editor, dan masih melihat unduhan ganda terjadi.

Baik. Alternatifnya di sini adalah selalu mengunduh 2-4MB atau terkadang gambar yang lebih besar. Itu tidak bisa diterima, meski hanya di editor.

Maaf, saya rasa saya tidak jelas di sini. Apa yang saya lihat adalah lebar gambar dibatasi di CSS oleh gaya inline pada pembungkus div di editor. Berikut beberapa tangkapan layar untuk membantu:

Gambar ukuran penuh di editor tidak mencakup lebar penuh - https://cloudup.com/cHob4kcjLrN

Markup di atas di inspector - https://cloudup.com/cIVWetqpSoF

Cakupan tiket ini sangat besar, tetapi ada beberapa bit yang penting untuk WP 5.0. Bisakah kita memecah masalah spesifik yang akan menjadi regresi? Seperti yang saya lihat, ini termasuk:

• [] Cegah gambar ukuran penuh dimuat di bagian depan.
• [] Simpan elemen width lebih sesuai hingga img dalam konten posting (praktik terbaik, tetapi juga relevan untuk menghitung atribut default sizes untuk gambar responsif).

Prioritas tinggi, penyempurnaan:

• [] Berikan cara untuk memfilter sizes di bagian depan berdasarkan perataan gambar (# 6131).
• [x] Mencegah gambar ukuran penuh dimuat di editor.

Peningkatan (senang memiliki):

• [] Tingkatkan kinerja pemuatan gambar di editor (misalnya, melalui gambar responsif)
• [] Meningkatkan penanganan lebar gambar yang diubah ukurannya secara manual antara editor dan ujung depan.
• [] Tambahkan ukuran gambar tambahan yang dihasilkan untuk 2x besar (Kita perlu mengevaluasi dampaknya pada pembuatan gambar di sini. Ini terkait dengan https://core.trac.wordpress.org/ticket/37840 yang diblokir oleh https: // core.trac.wordpress.org/ticket/40439)

Ada yang saya lewatkan?

Memberikan contoh di Twenty Nineteen repo mengapa ini adalah pemblokir untuk tema dan untuk Gutenberg secara umum. Pukulan kinerja yang saat ini ditimbulkan oleh Gutenberg cukup signifikan: https://github.com/WordPress/twentynineteen/issues/50#issuecomment -436829300

Dari pengujian saya, gambar responsif masih belum terselesaikan di 5.0 RC1. wp_calculate_image_sizes tidak memiliki atribut properti blok, dan render_block_core_image_tag_attributes dari # 11973 belum digabungkan.

Bukan untuk memberikan poin yang terlalu bagus, tapi ini berarti semua gambar tidak secara manual diubah ukurannya dalam editor dan diselaraskan alignnone , alignwide , dan alignfull di RC1 rusak karena sizes atribut salah.

Untuk menguji, aktifkan Twenty Nineteen, unggah gambar besar (1200px atau lebih lebar) ke dalam posting, sejajarkan none , alignwide , atau alignfull , dan periksa keluaran sizes atribut. Anda akan menemukan bahwa terlepas dari lebar yang ditampilkan atau lebar intrinsik gambar, nilainya adalah:

sizes="(max-width: 1024px) 100vw, 1024px"

Ini berarti untuk setiap situasi di mana gambar ditampilkan lebih lebar dari 1024px (hampir semua contoh di mana tampilan laptop / desktop digunakan), browser akan memuat gambar sumber lebar 1024px dan meregangkannya sehingga menyebabkan blur.

Apa rencananya untuk menggabungkan ini. Apa yang saya bisa bantu?

Terkait:

• Tiket inti 45406: Tambahkan ukuran gambar default tambahan untuk srcset untuk mengakomodasi area pandang yang lebih luas
• Tiket inti 45407: Tambahkan atribut blok ke wp_calculate_image_sizes untuk memungkinkan penanganan yang tepat dari atribut sizes

Permintaan telah dibuat untuk pengujian guna menunjukkan perilaku saat ini dan yang dikoreksi, jadi saya telah membuat keduanya:

Dua posting yang ditautkan di bawah ini menunjukkan keluaran saat ini dari inti dan versi yang dikoreksi masing-masing. Perhatikan instruksi rinci tentang cara menguji ini. Gambar responsif adalah fitur browser inti dan browser bekerja sangat keras untuk membuat fungsionalitasnya tidak terlihat. Memaksakan visibilitas membutuhkan penanganan yang agak berat dalam pengujian Anda.

Perhatikan hal berikut ini: Gambar responsif dipengaruhi oleh kepadatan tampilan. Ini dapat dilakukan menggunakan pratinjau seluler di alat pengembang browser Anda.

• Demo 1: Ukuran yang dibuat secara otomatis disediakan oleh inti https://gutenberg.mor10.com/image-test-current/
• Demo 2: Konten yang sama dengan atribut ukuran yang dikoreksi https://gutenberg.mor10.com/responsive-images-demo-corrected-code/

Terima kasih semua telah menaruh banyak perhatian dan perhatian dalam hal ini. Saya melihat dua masalah kusut yang harus dipisahkan untuk bergerak maju.

• Hindari kerusakan mencolok di 5.0 (seperti memuat gambar besar).
• Pikirkan kembali bagaimana WordPress menangani ruang media dalam dunia pengalaman menonton yang fleksibel.

Untuk yang pertama, perlu ada identifikasi yang jelas dari setiap masalah yang tertunda dan kesepakatan tentang apa artinya "rusak". Khususnya seputar fitur yang baru diperkenalkan yang tidak membawa harapan apa pun dari sebelumnya (gambar lebar, blok sampul, dll). Pemahaman saya adalah kendala utama memuat terlalu besar sumber diselesaikan dengan default ke "besar".

Untuk yang kedua, saya sangat yakin kita perlu _memberikan seluruh siklus_ ke media karena kita membawa masalah dari masa ketika segala sesuatunya lebih sederhana. Sekarang media ada di dunia di mana aset dasar yang kita miliki tidak cukup - banyak perangkat yang mengakses web dengan ekspektasi yang berbeda, kepadatan piksel, ukuran layar, dll. Hal ini tidak dapat diselesaikan sepenuhnya oleh WordPress saja dan memerlukan partisipasi dari grup lain - seperti layanan hosting dan manajemen bandwidth, browser, grup standar web, dll. Juga tidak masuk akal untuk berharap untuk memperbaiki semuanya pada saat yang sama kami melakukan 5.0.

Ketika kita melihat bagaimana WordPress mengelola aset secara default, terbukti variasi yang dibuatnya tidak cukup untuk memberi daya pada berbagai perangkat, kondisi tampilan, dan ekspektasi kinerja. Dalam skala atas, kita berurusan dengan 1024px atau ukuran penuh pada pemasangan biasa. Ini tidak cukup. Ada celah besar antara "source" dan "large" yang membuat hampir semua upaya gambar responsif atau hi-dpi mendukung sesuatu yang kalah. Kami perlu memiliki segmentasi aset media yang lebih baik tanpa membebani server agar dapat menyesuaikan skala dan kualitas yang diharapkan.

Hal ini semakin diperumit oleh fakta bahwa opsi-opsi ini dapat dikonfigurasi oleh pengguna, tema, dan plugin, jadi asumsi tentang apa yang "besar" akan mengakomodasi tidak bisa terlalu berlebihan.

Mampu menyampaikan citra yang tepat untuk konteks yang tepat sangatlah penting.

Idealnya, pengguna tidak perlu campur tangan sama sekali untuk membuat kreasi mereka terlihat bagus dan performant .

Namun, proposal tetap kami saat ini tidak terlihat cukup fleksibel pada tingkat pengalaman teknis atau pengguna untuk memenuhi ini, sambil menambahkan overhead dan kompleksitas yang cukup besar:

• Penskalaan ke blok non wp:image tetap tidak terpecahkan.
• Implementasi server yang tidak ortodoks (kemungkinan membutuhkan sesuatu seperti # 10108) yang menambah kompleksitas.
• Overhead dalam mereproduksi markup gambar _ad hoc_ (server vs klien), bentrok dengan ekstensi potensial dan sisi klien kesetiaan.
• Ketidakjelasan UX yang diharapkan seputar ukuran persentase.
• Terlalu banyak tanggung jawab di sisi tema.
• Lebih penting lagi, ketidakjelasan tumpang tindih dengan kondisi dan persyaratan fase 2 .

Dalam memperkenalkan kode ini dan ekspektasi (untuk tema, dll.), Kami akan membuat web persyaratan yang rumit dan kehilangan kesempatan untuk mengambil pendekatan yang lebih holistik untuk masalah tersebut. Saya percaya ini akan lebih baik dilakukan seiring waktu dan dalam hubungannya dengan fase 2, karena ekspektasi di mana blok berada dan interaksi pengguna akan bertambah banyak.

Tema tidak lagi dapat hanya mengatakan berapa lebar konten yang mereka pedulikan, karena blok akan ditempatkan di mana saja pada halaman. Blok juga dapat dipindahkan di antara area blok, jadi lebarnya harus selalu kontekstual dan dikontrol oleh root InnerBlocks . Ini mencakup hal-hal seperti kolom di dalam area konten utama, tetapi juga area di luar konten itu sendiri. API apa pun yang kami kembangkan di sini perlu mempertimbangkan ekspektasi ini, karena jika tidak, kami akan membuat web kode lama yang akan sulit diurai secara efektif.

Apa yang saya lihat menjadi API yang lebih kuat dan tahan masa depan adalah melampirkan tanggung jawab lebar media ke setiap wadah blok, di mana post_content hanyalah satu. Ini bisa terlihat seperti ini:

innerBlocks( 'post-content', sizes: {
    default: 600,
    wide: 1000,
    full: 100vw,
}

Ini menentukan lebar-maks default dan _availabilitas_ dari perataan lebar untuk blok di bawah root tersebut. Segera setelah Anda membuat root lain (seperti kolom), konteksnya berubah.

Yang memungkinkan kami juga melakukan:

innerBlocks( 'sidebar', sizes: {
    default: 300,
    wide: false,
    full: false
} )

dan seterusnya.

Ini harus dipasangkan dengan penanganan gambar responsif intrinsik, dan yang lebih penting, dengan segmentasi yang lebih baik untuk pembuatan aset atau semacam penanganan dinamis, jika memungkinkan.

Terima kasih @mtias ,

Saya setuju sepenuhnya dengan kebutuhan untuk menghindari kerusakan di 5.0, dan kebutuhan untuk melakukan fokus tingkat tinggi pada Media di WordPress untuk mengatasi masalah ini.

Mengenai yang pertama, saya tidak yakin bahwa kami telah sepenuhnya mengatasi masalah yang saya uraikan seperlunya di https://github.com/WordPress/gutenberg/issues/6177#issuecomment -435091640, khususnya:

Simpan elemen width lebih sesuai hingga img dalam konten posting (praktik terbaik, tetapi juga relevan untuk menghitung atribut default sizes untuk gambar responsif).

Jika kami dapat mengonfirmasi bahwa telah ditangani, saya akan merasa nyaman dengan segala sesuatu yang ditangani dalam rilis 5.0.x, dan seterusnya.

Mengenai yang terakhir — memikirkan kembali penanganan media telah menjadi harapan saya selama beberapa waktu, dan merupakan salah satu alasan kami melakukan diskusi awal tentang beberapa masalah tingkat tinggi ini selama pertemuan puncak komunitas selama WCEU 2017 ketika Gutenberg baru saja dimulai. Saya berharap dapat melanjutkan percakapan tersebut setelah siklus rilis WP 5.0 berakhir.

Sepenuhnya setuju dengan @joemcgill di atas ^

Saya ingin sekali bekerja sama dalam upaya tingkat tinggi yang Anda bicarakan, dan itu adalah sesuatu yang telah kami bicarakan dan ingin kami kerjakan selama beberapa waktu.

Hitung saya. Saya pikir kita (WordPress) berada dalam posisi untuk tidak hanya menyelesaikan ini untuk diri kita sendiri tetapi juga menciptakan model baru untuk penanganan media yang membantu web secara keseluruhan. Kami bisa mendapatkan keterlibatan dari browser, host, CDN, dan badan standar dan menggunakan WP sebagai saluran distribusi untuk praktik terbaik baru.

Apa yang kami temui di sini adalah tepi keras mutlak dari spesifikasi gambar responsif RICG. Kami sekarang memiliki kasus uji untuk apa yang berhasil dan apa yang tidak berhasil. Ini menempatkan kami dalam posisi unik untuk memajukan pekerjaan.

@joemcgill Bisakah Anda menjelaskan ini:

Simpan lebar yang lebih sesuai untuk elemen img dalam konten postingan (praktik terbaik, tetapi juga relevan untuk menghitung atribut ukuran default untuk gambar responsif).

Apa yang membuat lebar "lebih sesuai"? Hanya mencoba memahami parameter item tertentu karena saya tidak yakin saya lakukan sekarang :)

Untuk pertanyaan ukuran / jank intrinsik, ini sekarang relevan:

https://www.chromestatus.com/feature/4704436815396864
https://codepen.io/eeeps/pen/qLKwEZ

Utas yang mengecewakan untuk dibaca; karena saya tidak dapat melihat kemajuan yang telah dibuat. Solusi saat ini, adalah mengunggah gambar dengan ukuran yang tepat sesuai kebutuhan dan menggandakan ukurannya atau mengabaikan retina - adakah kemajuan yang akan membuatnya masuk ke wordpress? Saat ini, saya tidak ingin memberi klien kemampuan untuk memiliki halaman 30mb karena mereka tidak dapat mengubah ukuran secara efisien dan saya tidak dapat memaksa gambar untuk berkorelasi dengan desain dan kinerja.

@yratof ya, setuju kemajuan di sini lebih lambat dari yang dimaksudkan. Namun, setelah banyak diskusi di sini (di repo Gutenberg) dan di Slack, kami telah memutuskan tidak ada gunanya menambahkan perbaikan marjinal yang "agak" meningkatkan satu atau lain hal. Cakupan ini dikurangi berkali-kali.

Cara terbaik ke depan adalah melihat dengan cermat bagaimana WP menangani media dan khususnya gambar, dan memperbaiki dan memperbaiki semua masalah yang mendasarinya. Silakan lihat komentar Matias di atas . Jika Anda (atau orang lain) ingin terlibat dalam pekerjaan itu, saya berharap kita dapat "secara resmi" meluncurkannya segera setelah WP 5.1 siap / dirilis. Sampai saat itu, pikirkan tentang apa yang ingin Anda perbaiki / perbaiki, dan bagaimana gambar di WP harus "berfungsi", sebaiknya dengan beberapa contoh kode :)

Hanya untuk mengatakan betapa saya akan menyukai ini .... Saat ini blog saya 350mb di halaman rumah ..... Ini hanya kacang

Apakah ini utas yang tepat untuk menanyakan apakah Blok Galeri Gutenberg dapat memiliki pemilih ukuran gambar yang ditambahkan sehingga gambar dapat diperkecil gambar berukuran sedang daripada gambar ukuran penuh diperkecil?

Hari ini saya mendapati diri saya melakukan ini:

// onDomReady
document.querySelectorAll('.wp-block-gallery.columns-2 figure img')
  .forEach(x => {
    x.setAttribute('sizes', '(max-width: 781px) 50vw, 344px');
  });

... yang mana yang bisa parametrize dengan $content_width dan .columns-N . Dan gulirkan plugin. Saya harap tidak akan sampai seperti itu :) ... dan saya akan ingat untuk menonaktifkan ini setelah mendarat di inti.

EDIT: Kode JavaScript berfungsi sekali, secara tidak sengaja, kurasa. Anda harus memasukkan atribut sizes di tingkat PHP, di suatu tempat, idealnya antara markup Gutenberg dan filter the_content . Ugh.

EDIT2: Jadi saya mengimplementasikan solusi PHP dengan DOMDocument & Xpath . Tampaknya berhasil & saya akan menggunakannya dalam produksi. Jelas sangat rawan kesalahan, tidak akan merekomendasikan.

Hanya untuk mengatakan betapa saya akan menyukai ini .... Saat ini blog saya 350mb di halaman rumah ..... Ini hanya kacang

Sebagai tindakan sementara, saya akan secara manual menskalakan gambar Anda ke ukuran yang jauh lebih kecil, mengompresnya, lalu membatasi blog Anda untuk menyukai 4 posting atau sesuatu. Karena Anda akan membunuh data seseorang ketika mereka melihat blog Anda lol

FYI intrinsicsize sekarang menjadi sesuatu: https://github.com/WICG/intrinsicsize-attribute

/ update / image-block adalah "sedang dalam proses" :) Silakan uji.

• Selalu masukkan ukuran gambar large , atau full jika tidak ada yang besar.

Bagaimana dengan: selalu masukkan semua opsi ukuran gambar dari get_intermediate_image_sizes (); ?
Apa nilai tambah untuk mencegah akses ke ukuran gambar tertentu?

tambahkan filter agar dapat mengaktifkan beberapa ukuran gambar, atau mengaktifkan pengetikan ukuran gambar kustom Anda untuk digunakan.
untuk saat ini pilihan saya adalah "thumbnail, medium, fullsize" yang merupakan pilihan RIDICULOUS untuk fitur produksi yang dikirimkan ke 30% situs web internet (wordpress).

pengguna semua memuat ukuran gambar 5mb, bukan 500ko.

Saya bahkan tidak yakin apakah saya dapat memfilter blok untuk menambahkan lazysizes?

Hai.
Saya bukan ahli Wordpress tetapi saya pikir:
'setidaknya fitur galeri sederhana sudah dekat'.

Baik...
Apakah ada titik waktu ketika pull-down ukuran (untuk menampilkan gambar 'kecil' = 'thumbnail' pada halaman dan link ke gambar yang lebih besar ('' besar ')?
Maksud saya, saya berbicara tentang 5.2.2 dan ini adalah Juni 2019.
Apa alternatif selain plugin berbayar?

Saya benar-benar muak menonaktifkan Gutenberg. Situs keempat saya coba, yang pertama diadakan DENGAN Gutenberg (sampai sekarang, tapi tidak lama dan itu hilang dan kolomnya akan menjadi ACF). Ini, saya tidak tahu, saya relatif baru mengenal WP (setidaknya jenisnya yang lebih mendalam) dan ini tidak membuat siapa pun senang.

Oke, bagi saya https://github.com/klihelp/Kli-Gutenberg-Gallery berfungsi. Terima kasih untuk itu !!

Seharusnya tidak perlu menambahkan plugin untuk menangani gambar setelah gutenberg @ararename :(

Nah, lalu mengapa utas ini ada di sini?
Dan ini tentang pengaturan untuk galeri, bukan tentang gambar.

Seharusnya tidak perlu menambahkan plugin untuk menangani gambar setelah gutenberg @ararename :(

Ya, tetapi blok gambar, blok galeri, blok teks media semuanya buruk dalam cara mereka menangani ukuran gambar. Saya tidak mengerti bagaimana mereka sampai ke produksi. Bagaimana Anda bisa gagal dalam memperhitungkan ukuran gambar pada 2017-2019 ketika sepenuhnya membangun kembali dari awal fitur yang paling banyak digunakan dari CMS yang paling banyak digunakan di dunia? Saat editor klasik hampir siap menangani setiap ukuran gambar dengan baik.

Ini mengerikan. Saya bingung harus memilih antara membuat blok gambar / galeri / media-teks responsif saya sendiri sementara tidak dapat memanfaatkan wordpress asli apa pun yang memblokir pembaruan di masa mendatang atau bertahan dengan yang gagal berharap gutenberg akan menjadi lebih baik sementara pelanggan mengunduh gambar 4k pada gambar seluler atau 500px pada monitor 4k mereka

Itulah yang saya pikirkan ketika saya menemukannya: mengapa sesuatu dalam keadaan ini menjadi versi 'produktif' yang didistribusikan oleh ribuan orang?
Akibatnya: Gutenberg dinonaktifkan oleh ribuan dan ribuan sebagai kesempatan terakhir untuk menyelesaikan pekerjaan tepat waktu (yah, bukan pada waktunya).
Jika saya tidak menemukan plugin 'Kli-Gutenberg-Gallery-master' berguna dan berfungsi, saya harus menginvestasikan beberapa hari hanya untuk sesuatu yang harus diberikan inti tetapi tidak.
Ini adalah kondisi alfa, bukan produksi.

Halo semua! 👋

Apakah ada kemajuan dalam hal ini? Apakah percakapan sudah beralih dari tiket ini?

Saya ingin mengikuti dan terlibat jika saya bisa untuk membantu memajukan ini. 😄

Hai Keith, saya mungkin bisa menghubungi Anda kembali tentang hal ini minggu depan. Percaya atau tidak, saya tidak dapat menjangkau backend penginstalan wordpress yang mengalami masalah tersebut dan saya tidak punya waktu untuk menginstal versi lokal lengkap dari cadangan saya.

Dari apa yang saya ingat menggunakan plugin 'simplest-gallery' PLUS 'fancybox-for-wordpress' bersama-sama DAN mengatur lebar gambar dari gambar yang dimaksud (jempol, yang saya buat ukuran gambar khusus di functions.php) menjadi 100 % width dan height to auto (ini menimpa atribut lebar- / tinggi-tinggi inline, jika ada) memenuhi kebutuhan saya. Beri tahu saya jika ini sudah membantu Anda. Akan pergi sampai setidaknya hari Selasa.

Adakah peningkatan?

Apakah ini sedang dikerjakan? Atau dilacak di tempat lain?

@mtias @azaozz - Apakah sudah waktunya untuk mulai menambahkan pemilih ukuran gambar ke setiap blok yang menggunakan gambar? Ukuran gambar belum sepenuhnya ditangani dengan 5.0 atau 5.1 dan blok gambar sudah memiliki pemilih.

Mungkin Blok Sampul bisa mendapatkan pemilih berikutnya (# 19223)?

Kami membangun multisite untuk fakultas Universitas Tulane. Gambar ukuran penuh dari blok penutup adalah sumber daya terbesar kami.

Apakah ada pembaruan tentang itu?
Saya ingin menyajikan gambar galeri sebagai thumbnail. Blok galeri default menggunakan ukuran penuh gambar dan menskalakannya menggunakan CSS.

@ararename> Oke, bagi saya https://github.com/klihelp/Kli-Gutenberg-Gallery bekerja. Terima kasih untuk itu !!

Bisakah Anda menjelaskan cara menggunakannya? Bagaimana cara kerjanya untuk Anda? Apakah Anda mengubah semua galeri posting lama dengan kode pendek plugin galeri lain? atau plugin secara otomatis melakukannya sendiri?

Saya sebenarnya menginstal plugin dan tidak mengelolanya

@ShareTextures
Itu adalah Instalasi baru, saya tidak ingat apakah penting untuk memesan saat menginstal plugin, tetapi inilah yang telah saya instal:

• FancyBox untuk WordPress, Versi 3.2.2, dari Colorlib
• Klip - Galeri Gutenberg, Versi 1.0.0, dari Klipolis
• Galeri Paling Sederhana, Versi 4.4.1

Dan setelah mengunggah gambar ke galeri itu langsung berfungsi. Sebenarnya saya lupa tentang shortcode Klip - Gutenberg Gallery menggunakan dan saya _not_ menggunakan _any_.

Saya hampir lupa setelah topik ditutup tetapi saya sudah menyiapkan teks ini:
Saya tidak ke topik seperti itu tetapi saya mengatakan akan memposting 'solusi' saya untuk galeri gambar yang diberi makan oleh blok galeri Gutenberg (yaitu, untuk frontend, backend memiliki ukuran penuh tetapi itu tidak menjadi masalah karena saya tahu pasti editor memiliki bandwidth yang cukup dan pekerjaan itu tidak dibayar dengan cara yang dapat membuat saya menyelidiki lebih dari yang diperlukan - bagaimanapun, saya kira akan tiba saatnya ketika Wordpress 5 bekerja seperti yang diharapkan ketika 5.0 keluar).

Pertama, jika saya mengingatnya dengan benar, masalah 'gambar sebagai thumbnail di elemen galeri' hilang setelah beberapa peningkatan dari 5.1. * Ke 5.2. *.

Untuk galeri yang berfungsi saya harus menginstal

• Galeri Klip-Gutenberg
• Galeri Sederhana
• FancyBox untuk WordPress

Saya tidak akan pergi dan menguji apa yang salah dengan mana yang hilang, rasanya seperti menebak-nebak, tetapi dengan salah satu dari yang hilang ini ada sesuatu yang rusak.

Dan di suatu tempat di sepanjang jalan yang harus saya lakukan
.fancyboxforwp img {width: 100%! important; tinggi: otomatis! penting;}

Dan saya harus meletakkan baris (bagian di mana $ (". Fancybox"). Fancybox diinisialisasi) 133 hingga 157 (perkiraan) di komentar agar tidak ada kesalahan Js di browser.

_Ya, ini terdengar gila._
Tapi saya periksa kembali dan masih berfungsi (fe, bukan backend, seperti yang sudah dikatakan).
Semoga Anda berhasil, selamat
jujur

Satu pemikiran lagi:
Saya telah mengatur, di functions.php saya:
add_image_size ('thumbnail', 152, 152, true);
Jadi saya secara eksplisit telah menetapkan ukuran untuk thumbnail, mungkin ini juga memengaruhi hasil keseluruhan.
Dan saya telah menggunakan Plugin Regenerate thumbnail beberapa kali, mungkin ini juga mempengaruhi hasil keseluruhan. Hanya menebak-nebak dan memeriksa hal-hal yang berhubungan ...

@ararename Terima kasih untuk balasan cepat. Situs web saya sudah memiliki 500+ postingan. Jadi itu tidak akan berhasil untuk saya :(
Saya akan menunggu pembaruan Wordpress Gutenberg berikutnya.

@azaozz Apakah ada update tentang itu? Yang saya ingin tahu cara menggunakan tautan thumbnail gambar di galeri saya alih-alih gambar penuh.

Apa statusnya, terutama terkait dengan Blok Perlindungan Responsif di Gutenberg. Itu menjadi sedikit sakit kepala kinerja bagi saya.

Gambar Sampul Responsif

Untuk mengusulkan jalur untuk gambar sampul yang responsif, saya telah mencoba memahami cara kerja set gambar CSS https://developer.mozilla.org/en-US/docs/Web/CSS/image-set dan melakukan beberapa pengujian .

Dua bagian pertama memperkenalkan image-set dan src-set / size sebagai mekanisme untuk gambar responsif. Bagian terakhir menyimpulkan dan membahas jalur ke depan untuk gambar sampul yang responsif.

Gambar-set

Properti image-set tampaknya sangat berbeda dari atribut srcset. Kumpulan gambar tidak mendukung pengaturan beberapa ukuran gambar; ini mendukung pengaturan beberapa resolusi gambar (dpi / kepadatan). Tampaknya berbagai ukuran gambar yang dihasilkan secara otomatis oleh WordPress semuanya memiliki 72 DPI.
Properti image-set membuat browser mendownload gambar terbaik tergantung pada beberapa kondisi. Beberapa contoh kondisi adalah:

• Piksel layar per inci.
• Pilih untuk mendownload gambar dpi yang lebih rendah saat koneksi sangat lambat.
• Unduh gambar yang lebih baik saat mengirim sesuatu ke printer.

Ukuran viewport sepertinya tidak mempengaruhi gambar mana yang dipilih oleh image-set.

Src-set & ukuran

Srcset memungkinkan kita menyediakan daftar ukuran gambar yang berbeda (resolusi juga didukung meskipun jarang digunakan), dan atribut ukuran menyediakan kueri media seperti sintaks untuk memilih ukuran gambar yang ditampilkan. Saat browser mengetahui lebar gambar, browser mendownload ukuran terdekat dari srcset.

WordPress menggunakan atribut ukuran berikut "(max-width: $ width px) 100vw, $ width px" di mana $ width adalah lebar file gambar, itu berarti jika viewport lebih kecil dari $ width gunakan ukuran viewport sebagai ukuran gambar jika viewport lebih besar dari $ width gunakan $ width sebagai lebar gambar.

Pasangan atribut srcset dan ukuran WordPress memastikan bahwa pada layar yang lebarnya x jumlah piksel, kami tidak mengunduh gambar yang lebarnya lebih dari x.

Jalan ke depan

Blok sampul menambahkan gambar sebagai latar belakang CSS, jadi pada awalnya, properti kumpulan gambar tampaknya cocok untuk memungkinkan browser memilih satu file gambar dari kumpulan file yang tersedia bergantung pada perangkat.
Tetapi ketika kami mengatakan "Gambar Sampul Responsif", saya pikir yang kami maksud jika area pandang perangkat kecil, kami harus mengunduh gambar kecil jika area pandang perangkat besar kami harus mengunduh gambar dengan ukuran yang lebih besar.

Image-set tampaknya tidak mengizinkan perilaku ini; ini memungkinkan seseorang untuk mengunduh gambar dengan dpi yang lebih tinggi jika kerapatan piksel perangkat tinggi (misalnya, tampilan retina) dan gambar dengan dpi rendah jika kerapatan piksel layar kecil.

Ponsel dan layar komputer mungkin memiliki kepadatan piksel yang sama, jadi tampaknya menggunakan kumpulan gambar, kedua perangkat akan mengunduh gambar yang sama (asalkan kecepatan jaringan dan variabel lain sama). Kami tidak menginginkan perilaku ini, saya rasa kami ingin mengunduh gambar yang "lebih kecil" ke ponsel.

Tantangan lain untuk penggunaan kumpulan gambar adalah tampaknya semua file gambar yang kami buat di WordPress memiliki jumlah DPI yang sama.

Setelah eksplorasi ini, tampaknya kumpulan gambar tidak sesuai untuk gambar sampul yang responsif. Jalan ke depan tampaknya membuat gambar sampul menggunakan elemen gambar dengan atribut src-set & size normal yang ditetapkan oleh WordPress dan kemudian dengan CSS membuat gambar itu terlihat seperti latar belakang (seperti yang kita lakukan untuk video). Ada beberapa tantangan di jalur itu juga, terutama dengan paralaks. Saya tidak yakin apakah itu mungkin dengan elemen gambar normal, tetapi tampaknya kita harus mencobanya.

Jika saya melewatkan sesuatu, atau Anda memiliki informasi tambahan yang mungkin berguna, silakan tinggalkan komentar.

Pikiran yang bagus, @jorgefilipecosta. Saya baru saja membuat # 19909, yang bertujuan untuk mempelajari bagaimana blok apa pun dapat menerima hasil edit yang responsif. Bisakah Anda melihat apakah ide Anda tentang gambar sampul yang responsif dapat memanfaatkan antarmuka itu?

Jika FLIF atau JPEG-XR dapat didukung secara luas ... 🐱
Dimungkinkan untuk menggabungkan kumpulan gambar dengan kueri media normal menggunakan beberapa loop,
ini akan menghasilkan CSS dalam jumlah besar. Tentu, gzip mungkin akan memadatkannya, tetapi juga kompleksitas seperti semua kueri media yang ditumpuk di Alat Pengembang.
Untuk saat ini saya menggunakan <img dengan srcset dan sizes dan memposisikannya tepat di belakang konten.
Dengan menggunakan pendekatan ini saya tidak harus menangani bagian hidpi / retina dan hanya memberikan beberapa aturan untuk ukurannya. - Tapi ini harus disesuaikan secara terpisah dengan stylesheet.

Saat ini gambar sampul ditempatkan sebagai gambar latar CSS dalam ukuran penuh, asli, tanpa pengubahan ukuran, tanpa kompresi sisi server atau pengoptimalan apa pun. Ini sangat buruk untuk waktu muat UX, ketika varian terpisah yang diperkecil harus diupload dan digunakan sebagai blok sampul.

Apakah sudah ada pembaruan untuk ini?
Saya baru saja menambahkan galeri ke situs saya dan sekarang ukuran halaman saya 25MB karena galeri tidak memuat thumbnail tetapi gambar penuh.

Halo @azaozz dan lainnya.
Bisakah kami mendapatkan pembaruan status untuk masalah ini?

Sepertinya ada banyak hal yang terjadi dalam masalah ini. Penting untuk memecahnya menjadi masalah kecil yang lebih mudah ditangani.

Terima kasih.

Apakah ada cara untuk memperbaiki masalah galleri? Maksud saya menautkan ke file media? Saat ini beberapa gambar saya memiliki tautan valid dengan lebar penuh, tetapi kebanyakan dari mereka tertaut ke format besar (1024x).

Hai @ CNK001

Lihat apakah Anda dapat menemukan masalah yang terkait. Saya menelusuri masalah label media: https://github.com/WordPress/gutenberg/labels/%5BFeature%5D%20Media
Jika Anda tidak dapat menemukannya, buka masalah baru.

Saya baru saja mendapat permintaan dukungan untuk pengguna yang membutuhkan penanganan gambar lebih lanjut.

Setelah salah satu Wordpress Autoupdates terakhir, solusi saya sia-sia seperti ...
Backend dan frontend benar-benar kacau. Saya harus memulai lagi.

Adakah yang menemukan solusi untuk masalah bahwa galeri tidak menampilkan thumbnail tetapi gambar ukuran penuh?
Saya akan sangat bersyukur karena hal ini membuat saya gelisah selama lebih dari setahun sekarang - dan saya agak jengkel ... harus menyelidiki lebih dalam topik ini lagi.
Setiap bantuan sangat dihargai, terima kasih dan: semoga harimu menyenangkan :-)

Hai @ararename

Galeri sedang dikerjakan ulang untuk menggunakan balok dalam. Untuk informasi lebih lanjut, lihat Permintaan Tarik ini.
https://github.com/WordPress/gutenberg/pull/25940

@paaljoachim Terima kasih atas balasan cepatnya! Akan diperiksa :-)

@ararename Anda dapat menggunakan plug-in PhotoPress untuk sementara. Ini memiliki transformasi galeri inti.

Terima kasih @padams untuk opsi lain. Saya pikir saya akan membahasnya hari ini tetapi akan membutuhkan beberapa hari untuk kembali ke topik ini. Akan melaporkan kembali bagaimana kelanjutannya.