エディタの変更について@noisysocksと@iseuldeにpingを実行します。 コアの変更を追加できます。

編集者にとって、変更は（私が見ているように）次のようになります。

• すべての<img>タグにdata-wp-attachment-id="1234"属性を追加します。
• 常に「大きい」サイズの画像を挿入してください。
• 中、大、およびxlargeサイズでsrcset属性を追加します（xlarge画像サイズをデフォルトサイズにまもなく追加します）。
• エディターの画像幅に適したsizes属性を追加します。
• 保存時に、 srcsetとsizes両方を削除します。これは、表示時に異なる可能性があるためです。 または、表示フィルターでそれらをオーバーライドすることもできます。
• 画像サイズのピクセル値を設定するときは、エディターの幅に基づいて設定してください。 エディターに表示される画像よりも幅の広い画像を使用することは意味がありません。

TODO：パーセンテージ幅をフロントエンドに渡すための最良の方法を検討してください。

これを書いてくれてありがとう、@ azaozz！ 必要なエディターの変更を喜んでお手伝いします。 彼らは私にはいいですね。

または、エディターで幅をパーセンテージ（HTML 4.0スタイル）で設定し、この時点でそれらをピクセルに置き換えることもできます。

これに対する私の躊躇は、サードパーティ（プラグイン、RSSリーダー、APIコンシューマーなど）がpost_contentを処理せずに使用すると、有効なHTML5マークアップがないことです。 「HTMLを尊重する」はグーテンベルクの要件の1つ

大声で考える：Gutenbergメタデータを使用して、これを実現できますか？たとえば、添付ファイルIDとパーセンテージ幅を保存できますか？

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

ええ、画像は「動的ブロック」です（これは、従来のエディターでも同様に扱われます）。 それらは「フォールバックマークアップ」がそこにあり、で処理されるため、最高の種類の動的ブロックです。
それらを強化するためのフロントエンド。

このフォールバックマークアップを使用すると、「表示フィルター」が実行されていない場合でも、画像が「どこでも」機能します（これにより、実際には段落のないコンテンツが残るため、プラグインで機能するとは思われません）。

フロントエンドに渡す必要のあるデータをブロックメタに確実に追加できますが、 <img>タグにも同じデータが必要になると考えています。 理由の1つは、表示されているブロックの解析が遅く、実際のimgタグ（キャプション付きの図など）ではなく、HTMLのチャンクが大きくなることです。 もう1つは、（おそらく）すべての画像が別々のブロックにあるわけではなく、ブロッククォートやテーブルセルなどの画像について考えていることです。さらに別の理由は、投稿が他のエディターで編集されている場合、ブロックがひどく壊れている可能性があることですが、 <img>タグは「存続」し、そのまま残ります（標準のHTMLを使用している限り）。

最後に、これは要約すると次のようになります。

• これは、より簡単、高速、単純、読みやすく、理解しやすいものです。ブロックを解析してからHTMLのチャンク（複数の要素を含む場合があります）を処理するか、現在のように<img>タグを解析します。
• エディタで使用されるすべての画像が常にwp:imageブロック内にあることを保証できますか？ これには、貼り付けられた画像、テーブルセル内の画像、引用符、およびプラグインが思い付く可能性のあるその他のブロックとタグの組み合わせが含まれます。

ブロックメタ属性とimgタグ属性の両方を使用する必要があります。そうすれば、（ある日）表示されているコンテンツを解析するときにどちらを使用するかを選択できるようになります。

@azaozzこれはよく考えられた提案です。 ただし、テーマで宣言された既存の画像サイズを使用しない理由を完全には理解していません。 これについての事前の議論はありますか？

現在、パーセンテージフィールドが公開されていますが、これが現在フロントエンドで何かを行うかどうかを判断できませんでした。 https://github.com/WordPress/gutenberg/blob/master/blocks/library/image/block.js#L266

パーセンテージアプローチは優れていますが、テーマAPIとの下位互換性が失われます。

テーマで宣言された既存の画像サイズを使用しない理由...

フロントエンドにsrcset属性を追加するときは、使用可能なすべてのサイズ（w / h比が同じ）を使用します。 次に、ブラウザが使用する画像ファイルを決定します。

@azaozzこれは現在の動作とは少し異なる機能になると思います。 画像サイズは、使用する画像の切り抜きだけでなく、スタイルを提供するためにも使用できます。 また、既存の遅延読み込みプラグインはsrc値が「正しい」サイズであると想定しているため、 srcset完全に依存できるかどうかはわかりません。

編集：これは私が思うimage_size_names_chooseフィルターになります。

@davisshaver先週、いくつかの遅延読み込みプラグインを使用しました。 それらの多くは、既存のsrcおよびsrcset属性を探し、 the_contentフィルターを使用してPHPの他のマークアップに置き換えるだけです。 ここでの課題は、コアを取得して正しいsrcset sizes属性と

解決策が重複するレスポンシブ画像に関連するいくつかの問題があります。 議論がさらに混乱するのを避けるために、すべてをこの問題に統合することを提案します。 不完全なリストは次のとおりです。

関連する問題：

• ＃5674ギャラリーの画像が反応しない
• ＃4505「has-wide-support」クラスとメカニズムを追加
• ＃4342テーマを切り替えるとコンテンツが正しく表示されない
• ＃6131テーマがワイド/フル画像のサイズ属性を制御できるようにする

コアチケット：

• 挿入された画像の静的画像サイズを動的画像サイズに置き換えます
• srcsetからフルサイズの画像パスを削除する方法とsrcset候補リストのよりインテリジェントな選択肢
• フルサイズの画像を最適化する

これに関して、 @ azaozzの提案では：

新しいデフォルトサイズを2倍大きく、最大幅または高さ2048pxを追加

2008年に最初に定義された「サムネイル」、「中」、「大」の現在のデフォルトのピクセルサイズを増やすことを検討しましたか？ たぶんグーテンベルクと一緒に、それはそれらを2倍に増やす絶好の瞬間です。

そうしないと、「中」および「大」という用語の意味が失われます。

関連項目：＃5650 content_widthと新しいブロック幅

同じコアの問題の原因：新しいコンテンツ幅のパラダイムにより、以前は標準であったものが期待どおりに機能せず、コアの機能を再考する必要が生じます。

/ update / image-blockは「進行中の作業」です:)テストしてください。

変更点：

• エディター内にsrcsetとsizesを追加します。
• 常にlarge画像サイズを挿入するか、大きいサイズが存在しない場合はfull挿入してください。
• Default画像サイズ、 Thumbnail 、およびプラグインとテーマによる任意のサイズの加算器を表示します。
• data-wp-attachment-idとata-wp-percent-widthをimgタグに追加します。 フロントエンドで使用され、 srcsetとsizesを適切に設定します。また、不足している場合はimg widthとheightします。
• 画像サイズの設定/リセットを改善します。
• APIからの添付データとメディアモーダルのデータにsrcsetを追加します。

TODO：

• 新しいimgタグ属性を処理するフロントエンドコードを追加します。
• キャプションにフォーカスがあるときに画像からフォーカスを削除する（およびサイズ変更ハンドルを非表示にする）問題を修正しました。
• ドラッグしてサイズ変更を修正してみてください。 現在、角を左または右にドラッグしても何も起こりません。上下にドラッグするだけで画像のサイズが変更されます（分厚い）。

@azaozzこれはこれまでのところ本当に素晴らしく見えます。 よくやった！

これをテストしているときに気付いたことがいくつかあります。

まず、エディターの幅がフロントエンドの意図した表示幅と一致しない可能性があるため、エディター属性に基づいてsizes属性を保存することはおそらく間違ったアプローチであり、画像がエディターの幅に制限されます。 、テーマのコンテンツコンテナではなく。 フロントエンドのテーマで設定されたcontent_width値を利用するか、画像マークアップに保存するのではなく、フロントエンドでsizesを設定し続ける必要があります（これは、私がまだ悪い考えだと思っていると聞いても驚かないと思います）。

後者が私の提案です。 ここで、WordPressのブロックパーサーを利用して、 the_contentフィルターではなく、はるかに応答性の高い画像ソリューションを実装できるようになりました。 現在、ブロックは重複する属性データを画像ブロックのコメント区切り文字とマークアップに保存しています。 srcsetとsizesをマークアップに追加せずに、ブロック属性として保存し続けることができます。 その後、現在のように編集可能なコンポーネントでそれらを引き続き使用し、ブロックパーサーで使用できるようにすることができます。 マークアップに保存している属性に対してsourceを宣言することで、プロセス内の他の重複のいくつかをクリーンアップすることもできます。

ここでサイズドロップダウンの変更を💖します。 これを拡張してカスタムクロップサイズを可能にする方法、つまりadd_image_size()オプションをここに含めて、誰かが画像のハードクロップオプションのセットを作成できるようにする方法について考えたことがあるかどうか知りたいです。

私が遭遇したバグは、画像の挿入、ソースタイプのサムネイルへの設定、下書きの保存、そしてページの更新でした。 その場合、ブロックパーサーは、従来の「このブロックは外部から変更されたようです」というエラーで応答します。 srcとalt属性のみを期待しているようで、マークアップの追加の属性を窒息させています。

右/左揃えの画像にはまだ奇妙な点があります。 このような場合、エディターの幅のパーセンテージに明示的にサイズ変更し、サイズ属性を更新して一致させる必要があるのでしょうか。

REST APIとwp_prepare_attachment_for_jsによって返される各サイズに特定のsrcset値を追加するという選択に驚きましたが、これは私が今まで考えたことのない賢いアプローチです。 グーテンベルクが着陸したらこれをフィルターに残すのではなく、これらの応答にこのデータを明示的に追加することの賛否両論について話し合うことができるように、このためのチケットをコアで開く必要があります。 小さな注意点として、RESTフィルターに$response->data['media_type']が存在しない場合があり、通知をスローしているという通知がいくつか見られます。これは常に定義する必要があるため、奇妙です。 掘り下げるのが楽しい何か。

とりあえずこれを残してテストを続けます。 ブラボー、サー。

@joemcgill見てくれてありがとう！

まず、エディターの幅がフロントエンドの意図した表示幅と一致しない可能性があります

正しい。 これが、 data-wp-percent-width属性をimgタグに追加する理由です。 次に、フロントエンドの幅を再計算し、ユーザーがエディターに表示するものと「一致」させることができます。 これにより、電話での編集とも互換性があり、テーマに設定するとwideとfull幅もサポートされます（これらを追加するテーマを取得して、前面で使用を開始する必要があります-終わり）。

...エディター属性に基づいてサイズ属性を保存することはおそらく間違ったアプローチです

はい、前面で上書きすることを目的としています。 何か問題が発生した場合に備えて、「フォールバック」として画像タグに保持する必要があるかどうかを考えていました。 ただし、投稿が公開された後に変更される可能性があるため、タグにsrcsetを残すことを考えると、非常に小さいです（もちろん、フロントエンドでフィルタリングできます）。 ブラウザが可能な限り最大の画像をダウンロードしているように見える限り、srcsetだけでサイズがないのは良くありません（おそらく別のフォールバック）:)

WordPressのブロックパーサーを利用できるようになりました...

おそらく、しかしそれはかなり遅くなるでしょう。 今のところ、フロントエンドでブロックパーサーを実行することは私たちにできることではありません。

現在、ブロックは重複する属性データを画像ブロックのコメント区切り文字とマークアップに保存しています。

これがブロックプロパティの仕組みです。 または、正規表現を使用して画像ブロックを「抽出」し、その中のHTMLを解析して画像タグを探すこともできます。 それでも...正規表現を使用してHTMLを少しでも解析することは、避けるべきもののようです。 したがって、今のところ、実際のimgタグにエディターから必要なすべてのコンテキストを追加することを考えています。

カスタムクロップサイズ（サイズドロップダウン）を可能にするためにこれをどのように拡張できるかについて考えたことがありますか？

これは現在機能するはずです。 元の画像の比率に一致するサイズのみがドロップダウンから削除され、残り（およびサムネイル）が表示されます。 したがって、テーマとプラグインによって追加されたすべてのカスタムクロップが含まれています。

私が遭遇したバグは、画像の挿入、ソースタイプのサムネイルへの設定、下書きの保存、そしてページの更新でした。

ええと、もう一度確認します。 これらすべてを捕まえたと思いました。これにより、ブロックの検証と、ブロックが頻繁に失敗する理由（たとえば、ユーザーが別の属性を追加した後）を確認するようになりました。 そこでももっと一般的な修正が必要になると考えていますが、それは別の問題です。

右/左揃えの画像にはまだ奇妙な点があります。 このような場合、エディターの幅のパーセンテージに明示的にサイズ変更し、サイズ属性を更新して一致させる必要があるのでしょうか。

ええ、以前の行動がそこでより良かったと思います。 おそらく、右/左揃えの画像を50％の幅に設定することに戻る必要があります。 その属性をimgタグに保持している場合は、 sizes変更することもできます。

RESTAPIとwp_prepare_attachment_for_jsによって返される各サイズに特定のsrcset値を追加するという選択に驚いた。

そこでいくつかのアプローチをテストしましたが、これが最も効果的であるようです。 srcset追加する時点で、画像メタはすでにキャッシュされているため、メディアライブラリとAPIのデータを読み込む際のオーバーヘッドはごくわずかです。 このようにして、フロントエンドで使用される「適切な」 srcsetも一致させます。

このためにコアでチケットを開く必要があります...

ええ、グーテンベルクがマージされると、これは適切な機能に移行するはずです。

$ response-> data ['media_type']が存在しないことがあるというRESTフィルターの通知がいくつか見られます

うーん、おそらくそのためのコアトラックチケットを開く必要があります。 常に存在する必要があります。

次に、新しい属性を使用するフロントエンドコードを追加する方法を検討します。 次に、これらすべてを微調整するための良いスタートを切ります:)

私はWCEU寄稿者の日に@azaozzとチャットしました。これを前進させるために、私の考えをみんなと共有したいと思います。

__コンテキスト：__フロントエンド（テーマ/プラグインテリトリー）
__前提条件：__ @ azaozz reによって提案された提案：使用可能なスペースを基準にして表示された幅でdata-wp-percent-width属性を設定します。

提案

以前に規定したように（＃6131）、私が興味を持っている課題は、テーマとプラグインの開発者が、サイトのフロントエンドのsizes属性を、以下を含むが含まないさまざまな要因に基づいて制御する方法です。この例のように、すべての条件に対してsizes属性全体を

次のシナリオ、aからiについて考えてみます。

これまで、表示される画像については、画像ファイルの物理的な幅と、テーマで定義されている$content_widthつがわかっていました。 次に、これら2つのパラメーターを使用して、 sizes属性を計算しました。

グーテンベルクは、 alignwideとalignfull幅だけでなく、列などを含むがこれらに限定されないさまざまな要素wideまたはfullを作成する機能も導入しています。その結果、レスポンシブWebデザインによってもたらされる通常の課題に加えて、1つのテーマ内に無数の可能な表示幅があります。

これらの例は、テーマ開発者（および拡張プラグイン開発者）が簡単に定義できる_2つの定数_があることを示しています。

• $content_width - alignwideまたはalignfullとして表示されていない場合のコンテンツの最大幅。
• $max_display_area -コンテンツがalignfull設定されている場合に、埋めることができる最大の使用可能スペース。

私たちが作ることができる3分の1の仮定もあります：

• 設定する要素alignwideいっぱいかかります$content_widthの間に利用可能なスペースの半分を加えた$content_widthと$max_display_area 、およびように計算することができます。

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

言い換えれば、WordPressが$content_widthと$max_display_area値を知っている場合、コンテンツが表示されるスペースを正確に計算し、そこからsizes属性をその場で決定できます。表示される画像の割合は、@ azaozzによって導入された新しいdata-wp-percent-widthを含め、表示方法に基づいています。

実用化

テーマ開発者は2つの値を定義します。

• $content_width alignfullは、任意の表示条件で最大_content_幅を宣言します（ alignwideまたはalignfullが適用されていない場合のコンテンツの幅のように）。
• $max_display_areaは、任意の表示条件で使用可能な最大幅を宣言します。

これらの値は両方とも条件に応じて変化するため、現在の$content_widthのようにグローバルにすることはできません（ $content_width現在どのように機能するかを誤解していない限り）。

alignwideまたはalignfullなしで表示された画像の場合、 $content_width変数（および使用可能な場合はカスタム幅データ属性）でsizes属性を決定できます。表示されるサイズは、 $content_widthまたはdata-attributeで定義された$content-widthパーセンテージより広くなることはありません。 これは、現在の方法論よりもテーマ開発者向けの設定が大幅に簡単になります。

alignwideまたはalignfullコンテキストで表示される画像の場合、 $max_display_area値を使用する必要があります。 この変数を、ビューポートの幅と使用可能な表示領域を組み合わせたある種の配列として定義することは理にかなっています。 この配列は、data-attributeと組み合わせて、オンザフライで生成されるsizes属性に変換できます。

したがって、上記の例では、テーマは次のように宣言します。

// 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',
  ];
}

d、e、およびfの場合、サイドバーが表示されるブレークポイントは48emであり、g、h、およびiの場合、 data-wp-percent-width属性は50％であり、結果として得られるsizes属性は例です。このコメントの上部には次のようになります：

/**
 * 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)"

ありがとう@ mor10 、非常にうまく入れてください:)

はい、フロントエンドで画像を適切に処理して表示するには、いくつかのデータが必要です。画像が正確にどのように使用されたかに関するエディターからのコンテキストと、画像の表示方法に関するテーマからのデータです。

いくつかの小さな提案/説明があります。

$content_width -コンテンツがalignwideまたはalignfullとして表示されていない場合のコンテンツの最大幅。
$max_display_area -コンテンツがalignfullに設定されている場合に、埋めることができる最大の使用可能なスペース。

私は（まだ）テーマにコンテンツ/メイン列、ワイド、フルの3つの幅すべてを指定させるべきだと考えています。 そうすれば、テーマに何も強制することはありません。 少し広いまたは狭いalignwide画像が必要な場合があります。 テーマが古くなっている場合、 wide content_widthとfullの差の半分を使用することはフォールバックかもしれません。

したがって、これらは次のようになります。

• $content_width
• $alignwide_width
• alignfull_width

（技術的には、連想配列にすることもできるので、グローバルスペースをあまり「散らかす」ことはありません。その配列があると、テーマがこれをサポートしていることも示されます。）

もう1つの重要な違いは、これらの新しい幅が「コンテキスト」であると予想されることです。 つまり、HTMLの出力を開始する前に、現在のテンプレートで設定する必要があります（おそらく、最後にリセットします）。 これは、すべての画像に対してより正確なsizes属性を生成するために重要です。

グーテンベルクは、 alignwideとalignfull幅だけでなく、さまざまな要素をwideまたはfullにする機能も導入しています。

そのre：画像について心配する必要があるとは思わないでください。 ブロックがfullに設定されている場合、その中にalignfull画像を含めることは意味がありません。 「通常の」画像とまったく同じになります。 wideブロックについても同じです。

3つの幅すべてを指定することは理にかなっており、連想配列は確かにそれをよりクリーンにします。 唯一の問題は、条件を使用してそれを変更する方法です...テーマ開発者は配列を変更するだけだと思いますか？

そのre：画像について心配する必要があるとは思わないでください。 ブロックがfullに設定されている場合、その中にalignfull画像を含めることは意味がありません。 「通常の」画像とまったく同じになります。 wideブロックについても同じです。

私のコメントの例を見ると、これらを説明する必要があることがわかります。 誰かが非常に大きな画面を持っていて、ブロックがalignfull設定され、50％の画像が内部にある場合、その画像はコンテンツの幅よりも大幅に大きくなる可能性があります。 sizes属性は、画像の実際の表示幅を記述する必要があり、 alignwideまたはalignfullコンテキスト内に配置されたものalignwide 、それ以外の場合とは異なる幅になります。

こんにちは@ mor10 、あなたの例では、「b」のサイズは次のようにすべきではありません：

size = "（min-width：$ content_width）calc（$ content_width +（$ max_display_area- $ content_width）/ 2）、フォールバック"

？

@alialaa数学はかなり不安定かもしれません。 これは、典型的な例としてのみ提供されています。

@azaozzこれはどこにありますか？ 公式のグーテンベルクスターターテーマでグーテンベルク3.3をテストしたところ、現在のブロックはすべてすべてにフルイメージサイズを使用していることがわかります。 これにより、プラグインがアクティブ化されたときにパフォーマンスが大幅に低下します。

@ mor10レイアウトのバリエーションが多い、より大きなテーマでこれを実現しようとしていることを除いて、提供されたコード（ wp_calculate_image_sizesフィルター）と非常によく似たものを実装しようとしています。 これまでの最大の問題は、画像がテーマに表示される可能性のあるすべての場所にsizes属性の堅牢なジェネレーターを実装することです。 最大の問題は次のとおりです。

• 流体と固定幅のレイアウト
• グリッドシステム（コンテナからのパーセント）
• グリッドギャップ
• サイドバーの有無
• 複数のメディアクエリブレークポイント

私がすでに実装できたのは、パラメーターのセットを受け入れ、幅記述子とメディアクエリを使用してサイズの配列を出力するPHPロジックです。 私の目標は、最も一般的なブートストラップレイアウトをカバーすることであり、それらは非常に広く使用されています

コンテキストのため、ここでこれらの数字を生成するために使用されている（わずかに修正メディアクエリで）ブレークポイントです。

モノの有効なパラメータは次のとおりです。

1. bootstrap_class ：非常に長くなる可能性があり、ブートストラップが受け入れるものを受け入れます。これは実際に解析され、複数のメディアクエリを生成するために使用されます
2. gutters ：true | false。 30pxガターを計算に入れるかどうか。 この量は構成可能です
3. fluid ：true | false。 非流体レイアウトは最も難しく、ピクセル単位でmax-widthです。

JSON形式で実際に合格するいくつかのテストケースを次に示します（各エントリはテストケースであり、最初のオブジェクトはロジックへの入力であり、2番目は出力です）。

[
    [

        {"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)"}
        ]
    ]
]

出力を取得したら、HTMLに挿入する準備ができた適切なsizes属性に簡単にアセンブルできます。

たとえば、非常に複雑なcol-xs-10 col-sm-3 col-md-7 col-lg-11 col-xl-5画像の出力は次のようになります。

[
    {
        "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)"}
    ]
],

最終的に組み立てられたHTMLは次のようになります。

<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>

現在、非流動レイアウトのテストケースははるかに複雑で、従うのが困難です。

また、 bootstrap_classでは不十分な場合があり、画像の幅を生のパーセンテージで表現できる必要があります。

興味があれば、このことについてどこか別の場所でより詳細なチャットに飛び込むことができます、私はそれを適切に進めることに本当に興味があります、私が直面している問題はまだたくさんあります🙂

8593は、個々のギャラリー画像にsrcset属性とsizes属性を追加しましたが、 sizes属性は、各画像がビューのコンテンツ幅全体を占めるかのように機能します。場合。

関連：＃1450

これはどこにありますか？

それをatmで見て、しばらくafkでした。 数日以内に、更新された「実行可能な」ブランチが作成されることを願っています。

画像ブロックブランチを更新しました： https ：

@joemcgill @getsource @ mor10明日

ブランチを再度更新しました。 ほぼ準備ができており、さらにテストが必要です:)

これをWP5.0マイルストーンに追加するのは、投稿コンテンツに挿入された画像でパフォーマンスの低下を導入しないことが非常に重要であり、ここで更新を確認することを忘れたくないためです。

これらのパフォーマンスの問題は、HTMLタグ（画像とギャラリーブロック）を介して統合された画像だけでなく、画像が背景画像としてcssを介して挿入されるcover-imageブロックにもあることを覚えておく必要があります。

srcsetを介したソリューションは、このブロックでは機能しません。

Twenty Nineteenは現在、この問題の具体的なテストの場を提供しています。 詳細については、 https： //github.com/WordPress/twentynineteen/issues/50#issuecomment-434120505を参照してください。

@azaozz Twenty Nineteenを使用して参照されたブランチを実行すると、挿入された画像は次のマークアップを取得します。

<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">

最大幅は、テーマで設定されたcontent_widthグローバルに一致するように

新しい機能をテストするには、テーマにどのような新しいマークアップ（ある場合）を追加する必要がありますか？

@ mor10そうです、 $content_width PHPグローバルを使用しています。 これは、新しく導入された$block_widthグローバルのフォールバックであり、デフォルト、ワイド、フルの3つの値が含まれている必要があります。https ： ください。 /block-library/src/image/index.php#L26 （これらの幅は、（古い） $content_widthと同じように、max-widthのように機能することに注意してください）。

テストするには、おそらく画像ブロックのphpdocの例に従ってください。

/**
 * 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.

より正確なsizes属性を設定する場合でも、 https：//developer.wordpress.org/reference/hooks/wp_calculate_image_sizes/フィルターを使用するのが最善の方法です。 テーマに「より簡単な」ものを追加することを検討しましたが、適切なsizesは非常に状況に応じて行われ、スタイル（列、ブレークポイント、マージン、パディングなど）に大きく依存します。 そこには「簡単な方法」はありません。テーマを完全に制御する（つまり、フィルターを利用する）のが最善です。

この値がピクセル単位であるのはなぜですか？ 多くの（おそらくほとんどの）テーマは、幅にピクセル値を使用しません。 二十九はほんの一例です。 任意の幅の値を使用して幅を定義できる必要があります。 たとえば、全幅の画像はほとんどの場合100vwます。

また、 add_theme_supportオプションに対して、またはフィルターを介して、グローバルとして設定されるのはなぜですか？

WIPまたは「進行中」のラベルが付いている場合でも、このブランチがPRとして開かれていることを確認すると非常に役立ちます。 コードのレビューや議論などが簡単になります。☺️

この値がピクセル単位であるのはなぜですか

画像（ファイル）のサイズはピクセル単位であり、 <img>タグのwidth height属性と100vw値は、デフォルトでsizes属性で使用されますが、テーマは、「完全に整列」画像ブロックの場合でも、許容可能な最大幅を渡す必要があります。

サイトが2560pxの画面で見栄えがする限り、サイトの訪問者は3〜4MBの画像をダウンロードする必要があると判断するテーマがおそらくあります。 他のものはより実用的であり、それをいくらかより「正気の」値に制限します。

ところで、これがうまく機能するためには、アップロードされたすべての画像に対してデフォルトで生成された別のより大きなサイズが必要です。

add_theme_supportオプションに対して、またはフィルターを介して、グローバルとして設定されるのはなぜですか

このグローバルを「コンテキスト」にする、つまり「テンプレート」ごとに異なる値を設定するという考え方です。 これを行うにはいくつかの方法がありますが、PHPグローバルまたはWPアクションの起動が最も使いやすいようです。

@azaozzhttps ： //github.com/WordPress/twentynineteen/pull/411を参照してください。 しばらく前に、 wp_calculate_image_sizes内から、現在の画像が通常の画像、 alignwide 、またはalignfullとして表示されているかどうかを検出する方法について説明しました。 1つのアイデアは、 <img>要素内にデータ属性を追加することだったと思います。 このコンテキスト情報がないと、3つのレイアウトオプションに正しいsizes属性を提供する方法がわかりません。 アイデアは大歓迎です。

このコンテキスト情報がなければ...

正しい。 この情報は$block_attributes配列にあります。 これは（新しい） render_block_core_image_tag_attributesフィルターに渡されています（より適切な名前が必要な場合があります...）。 それがグーテンベルクとコアにマージされると、ブロック属性をwp_calculate_image_srcset wp_calculate_image_sizesフィルターと

どこにいるの？ 現在テストできますか？

コアファイルを変更するため、まだです。 「ハック」として追加できます:)

wp_calculate_image_srcset()とwp_calculate_image_sizes()呼び出すときに$block_attributesを渡す必要があります。https：//github.com/WordPress/gutenberg/blob/update/image-block/packages/block-を参照してhttps://github.com/WordPress/gutenberg/blob/update/image-block/packages/block-library/src/image/index.php#L213。 次に、同じものを/wp-includes/media.phpのこれらの関数のフィルターに渡します。

テストしてくれてありがとう！

これを軌道に乗せるために積み上げることができるコアチケットはありますか？ GBとTwentyNineteenは、これが解決されない限りリリースできません。

@azaozz昨日ブランチのテストを行う機会がありました（遅れてすみません）。 もっとたくさんやりたいのですが、次のフィードバックを残したいと思います。

まず、 srcset sizes属性とsrcを持つ基本的なimgタグを残す必要があり、 srcsetとsizesは、で最も適切に処理される実装の詳細です。フロントエンド。 srcset属性は、添付ファイル用に追加の画像サイズが生成されるたびに変更される可能性があり、変更される必要があります（テーマを切り替えた後、または既存のテーマに新しい画像サイズを追加した後など）。

グーテンベルクはすでにフロントエンドフィルターを介して現在のレスポンシブ画像ソリューションをサポートする方法で画像マークアップをフォーマットしているので、テーマに使用できるフィルターを改善して、含むブロックの属性に基づいてsizes属性を変更することに焦点を当てる必要があると思います画像（例：配置、ギャラリー列など）。

その他の注意事項：

エディターで、Chromeがすべての画像の2つのバージョンをダウンロードしていることに気付きました（これはマスターブランチでは発生しません）。 2つ目は、 componentDidMount間に呼び出されるfetchImageSize()の画像コンポーネントのsrc属性の切り替えによるものです。 これにより、コンポーネントにsrcsetとsizesを追加することによるメリットが無効になります。

全幅の画像では、最大幅が1024pxに制限されているため、プレビューが中断されます。 これはマスターでは起こりません。

テストとメモの追加を続けますが、これをPRとして確認できると便利だと@chrisvanpattenにエコーします。 ありがとう！

@joemcgillテストしてくれてありがとう！ :)

srcset属性とsizes属性をデータベースの画像マークアップに保存するという考えに強く反対していることをもう一度繰り返します... srcset属性は、添付ファイル用に追加の画像サイズが生成されるたびに（テーマを切り替えた後、または新しい画像を追加した後）変更される可能性があります。既存のテーマのサイズなど）。

これは、数年前にsrcsetとsizes実装したときに見たものです。 理論的にはある程度可能に聞こえますが、実際には非常にまれにしか発生しないため、プラグインで処理する必要があります。 また、コンテンツが1つのWPサイトからエクスポートされ、添付ファイルIDが変更されたときに別のサイトにインポートされると（ただしURLは変更されません）、 srcsetとsizes生成が中断されます。

ただし、この場合、 srcset sizes属性と。https：//github.com/WordPress/gutenberg/blob/update/image-block/packages/block-library/src/image/index.php#L244を参照して

それでも、インポートされたコンテンツを修正するため、 srcset属性の再利用を検討するためにWP5.1 +のコアチケットを開く必要があると考えています。 デフォルトのsizes属性はテーマに依存しませんが、常にフロントエンドで再生成およびフィルタリングする必要があると考えています。

グーテンベルクはすでに、フロントエンドフィルターを介して現在のレスポンシブ画像ソリューションをサポートする方法で画像マークアップをフォーマットしています

完全ではありません:)現在、グーテンベルクはエディターとフロントエンドの両方でフルサイズの画像を「強制」しています。 srcset属性が<img>タグに追加されているのは事実ですが、そこでデフォルトのsizes属性を見てください。 それは「ボーク」です:)

サイズ属性を変更するために、テーマで使用できるフィルターを改善することに焦点を当てるべきだと思います...

同意します。 これにより、そこで役立ついくつかの新しいフィルターが追加されますが、最も重要なのは、 block_attributesをwp_calculate_image_sizesフィルターに渡す必要があります（一致するようにwp_calculate_image_srcsetにも渡す必要があります）。

さらに、最後の更新後、これらのブロック属性で渡されるエディター関連のデータがかなりあります。 これにより、フロントエンドでの画像の適切なスケーリング、 widthとheightリセット（およびこれらが常に存在することの確認、ベストプラクティス）が可能になり、通常、テーマにより多くのオプションが提供されます画像ブロックをレンダリングするとき。

エディターで、Chromeがすべての画像の2つのバージョンをダウンロードしていることに気づきました

これは、新しくアップロードされた画像でのみ発生します。 アップロード中に画像が「プレビュー」として追加されるため、添付ファイルの投稿があった後、 srcを「大きい」サイズを指すように変更する必要があります。 また、エディター内でsrcsetを使用する利点は、「網膜」画像を読み込んで表示することです。 ページの読み込みが完了してからかなり経ってからエディターコンテンツ（HTML）が読み込まれるため、速度のメリットはありません。

全幅の画像では、最大幅が1024pxに制限されているため、プレビューが中断されます。 これはマスターでは起こりません。

正しい。 ここでの代替手段は、常に2〜4MBまたは場合によってはそれより大きい画像をダウンロードすることです。 たとえエディターだけであっても、それは受け入れられません。 この制限を修正するには、デフォルトで「大きい」より大きい別の画像サブサイズを生成する必要があります。 これはSlackで何度も議論されており、かなり「古い」コアチケットがあります。 私たちは間違いなくすぐにそれを行うことを検討する必要があります。

テストとメモの追加を続けます

はい、お願いします！ :)
今夜PRをすることを考えると、画像を扱う際のほとんどのエッジケースが説明されているようです。

ただし、この場合、srcset属性とsizes属性は、純粋に編集者のためのものです。

その場合、これらの属性をデータベースに保存されたマークアップに保存することは間違いなく意味がありません。

完全ではありません:)現在、グーテンベルクはエディターとフロントエンドの両方でフルサイズの画像を「強制」しています。 srcset属性がに追加されるのは事実ですタグがありますが、そこにあるデフォルトのサイズ属性を見てください。 それは「ボーク」です:)

ああ、ここで役立つ違いは、画像サイズをcontent_width制限しなくなったため、画像の幅属性が正しく保存されていないことです。

これは、新しくアップロードされた画像でのみ発生します。

私はこれが真実だとは思わない。 投稿を保存し、エディターを更新しても、二重ダウンロードが発生しているのを確認できます。

正しい。 ここでの代替手段は、常に2〜4MBまたは場合によってはそれより大きい画像をダウンロードすることです。 たとえエディターだけであっても、それは受け入れられません。

申し訳ありませんが、私はここで明確ではなかったと思います。 私が見ているのは、CSSで、エディターのラッピングdivのインラインスタイルによって画像の幅が制限されていることです。 役立つスクリーンショットを次に示します。

全幅に及ばないエディターのフルサイズ画像– https://cloudup.com/cHob4kcjLrN

インスペクターでの上記のマークアップ– https://cloudup.com/cIVWetqpSoF

このチケットの範囲は非常に広いですが、WP5.0にとって重要なビットがいくつかあります。 回帰となる特定の問題を分析できますか？ 私が見ているように、これには次のものが含まれます。

• []フルサイズの画像がフロントエンドに読み込まれないようにします。
• []投稿コンテンツのより適切なwidthからimg要素を保存します（ベストプラクティスですが、レスポンシブ画像のデフォルトのsizes属性の計算にも関連します）。

優先度の高い機能強化：

• []画像の配置に基づいてフロントエンドでsizesをフィルタリングする方法を提供します（＃6131）。
• [x]フルサイズの画像がエディターに読み込まれないようにします。

機能強化（あると便利）：

• []エディターでの画像の読み込みパフォーマンスを改善します（レスポンシブ画像などを介して）
• []エディターとフロントエンドの間で手動でサイズ変更された画像幅の処理を改善します。
• [] 2倍の大きさの生成された画像サイズを追加します（ここで画像生成への影響​​を評価する必要があります。これはhttps：//によってブロックされているhttps://core.trac.wordpress.org/ticket/37840に関連しています。 core.trac.wordpress.org/ticket/40439）

私が欠けているものはありますか？

なぜこれがテーマとグーテンベルク一般のブロッカーであるのかについての例をTwentyNineteenレポで提供しました。 現在グーテンベルクが被っているパフォーマンスへの影響は重大です： https ：

私のテストによると、レスポンシブ画像は5.0RC1ではまだ解決されていません。 wp_calculate_image_sizesはブロックプロパティ属性がなく、＃11973のrender_block_core_image_tag_attributesはマージされていません。

細かく言い過ぎないでください。ただし、これは、エディター内で手動でサイズ変更されておらず、RC1でalignnone 、 alignwide 、およびalignfullに配置されていないすべての画像が壊れていることを意味します。 sizes属性が正しくありません。

テストするには、Twenty Nineteenをアクティブにし、大きな画像（1200px以上）を投稿にアップロードし、 none 、 alignwide 、またはalignfullに揃えて、出力sizesを確認します。

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

これは、画像が1024pxより広く表示される状況（ラップトップ/デスクトップディスプレイが使用されているほとんどすべての場合）で、ブラウザが1024px幅のソース画像をロードして拡大し、ぼやけを引き起こすことを意味します。

これを統合する計画は何ですか。 私は何を手助けすることができますか？

関連：

• コアチケット45406：より広いビューポートに対応するためにsrcsetのデフォルトの画像サイズを追加
• コアチケット45407：ブロック属性をwp_calculate_image_sizesに追加して、 sizes属性を適切に処理できるようにします

現在の動作と修正された動作を示すテストが要求されたので、両方を作成しました。

以下にリンクされている2つの投稿は、それぞれコアからの現在の出力と修正されたバージョンを示しています。 これをテストする方法の詳細な手順に注意してください。 レスポンシブ画像はブラウザのコア機能であり、ブラウザは機能を非表示にするために非常に懸命に働きます。 可視性を強制するには、テストでかなり手間がかかる必要があります。

次の点に特に注意してください。レスポンシブ画像は、表示密度の影響を受けます。 これは、ブラウザ開発ツールのモバイルプレビューを使用して実行できます。

• デモ1：コアhttps://gutenberg.mor10.com/image-test-current/によって提供される自動生成されたサイズ
• デモ2：サイズ属性が修正された同じコンテンツhttps://gutenberg.mor10.com/responsive-images-demo-corrected-code/

これに多くの考えと注意を払ってくれてありがとう。 前進するために分離されるべき2つの絡み合った懸念があります。

• 5.0では明白な破損を避けてください（巨大な画像をロードするなど）。
• 柔軟な視聴体験の世界でWordPressがメディアスペースをどのように処理するかを再考してください。

まず、保留中の問題を明確に特定し、「壊れた」とはどういう意味かについて合意する必要があります。 特に、これまで期待されていなかった新機能（ワイド画像、カバーブロックなど）を中心に。 私の理解では、ソースが大きすぎるとロードする主な障害は、デフォルトで「大」に設定することで解決されます。

第二に、私たちは物事がより単純だった時代から問題を抱えているので、私たちはメディアに_サイクル全体を捧げる_必要があると非常に信じています。 現在、メディアは、コアにある基本的な資産だけでは不十分な世界に存在します。さまざまな期待、ピクセル密度、画面サイズなどでWebにアクセスする多数のデバイスです。これは、WordPressだけでは完全に解決できず、他のグループ—ホスティングサービスや帯域幅管理、ブラウザ、Web標準グループなど。5.0を実行しているのと同時にすべてを修正することを期待するのも無理です。

WordPressがデフォルトでアセットを管理する方法を見ると、WordPressが作成するバリエーションでは、さまざまなデバイス、表示条件、パフォーマンスの期待に応えるには不十分であることが明らかです。 上のスケールでは、通常のインストールで1024pxまたはフルサイズを扱っています。 これはたりない。 「ソース」と「ラージ」の間には大きなギャップがあり、レスポンシブ画像やhi-dpiサポートのほとんどすべての試みが敗戦のようなものになります。 品質の期待に合わせて拡張するには、サーバーに過負荷をかけずにメディア資産をより適切にセグメンテーションする必要があります。

これは、これらのオプションがユーザー、テーマ、およびプラグインによって構成可能であるという事実によってさらに複雑になるため、「大」が何に対応するかについての仮定は行き過ぎてはなりません。

適切なコンテキストに適切な画像を提供できることが重要です。

理想的には、ユーザーは自分の作品の見栄えを良くし、パフォーマンスを向上させるために介入する必要はまったくありません。

ただし、現在の現在の提案では、技術レベルまたはユーザーエクスペリエンスレベルでこれを実現するのに十分な柔軟性が見られず、かなりのオーバーヘッドと複雑さが追加されています。

• 他のwp:imageブロックへのスケーリングは未解決のままです。
• 複雑さを増す非正統的なサーバー実装（おそらく＃10108のようなものが必要）。
• 画像マークアップ_アドホック_（サーバー対クライアント）の再現のオーバーヘッド、潜在的な拡張機能および忠実度のクライアント側との衝突。
• パーセンテージサイズ周辺の予想されるUXの不明確さ。
• テーマ側の責任が大きすぎる。
• さらに重要なのは、フェーズ2の条件および要件と重複する不明確さです。

このコードと期待（テーマなど）を導入することで、要件の複雑なWebを作成し、問題に対してより包括的なアプローチを取る機会を逃します。 これは、時間の経過とともにフェーズ2と組み合わせて行う方がよいと思います。これは、ブロックが存在する場所とユーザーの操作に対する期待が大幅に高まるためです。

ブロックはページのどこにでも配置されるため、テーマはコンテンツの幅を単純に言うことができなくなります。 ブロックはブロック領域間で移動することもできるため、幅は常にコンテキストに依存し、直接のInnerBlocksルートによって制御する必要があります。 これには、メインコンテンツ領域内の列のようなものだけでなく、コンテンツ自体の外側の領域も含まれます。 ここで開発するAPIは、これらの期待を考慮する必要があります。そうしないと、効果的に解きほぐすのが難しいレガシーコードのWebを作成することになります。

より堅牢で将来性のあるAPIになると私が見ているのは、メディア幅の責任を各ブロックコンテナーにアタッチすることです。そのうち、 post_contentは1つにすぎません。 次のようになります。

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

これは、デフォルトの最大幅と、そのルートの下にあるブロックのワイドアライメントの_availability_の両方を指定します。 別のルート（列など）を作成するとすぐに、コンテキストが変更されます。

これにより、次のことも可能になります。

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

等々。

これは、本質的なレスポンシブ画像処理と組み合わせる必要があります。さらに重要なことは、アセット作成またはある種の動的処理のためのより良いセグメンテーションと組み合わせる必要があります。

ありがとう@mtias 、

私は、5.0での破損を回避する必要性と、これらの問題に対処するためにWordPressのメディアにさらに高いレベルで焦点を当てる必要性の両方に完全に同意しています。

前者に関しては、 https： //github.com/WordPress/gutenberg/issues/6177#issuecomment -435091640で必要に応じて概説した問題に完全に対処したかどうか、具体的にはわかりません。

より適切なwidthを投稿コンテンツのimg要素に保存します（ベストプラクティスですが、レスポンシブ画像のデフォルトのsizes属性の計算にも関連します）。

それが解決されたことを確認できれば、5.0.xリリース以降で処理される他のすべてに問題はありません。

後者については、メディアの取り扱いを再考することがしばらくの間私の希望であり、グーテンベルクが始まったばかりのWCEU2017のコミュニティサミット会議でこれらの高レベルの問題のいくつかについて最初に話し合った理由の1つです。 WP 5.0のリリースサイクルが終了したら、これらの会話を再開することを楽しみにしています。

上記の@joemcgillに完全に同意し

私はあなたが話しているようなハイレベルな努力で一緒に働きたいと思っています、そしてそれは私たちが話していて、かなり長い間取り組みたいと思っていることです。

私を数えてください。私たち（WordPress）は、これを自分たちで解決するだけでなく、Web全体を支援するメディア処理の新しいモデルを作成する立場にあると思います。 ブラウザ、ホスト、CDN、標準化団体から参加し、新しいベストプラクティスの配布チャネルとしてWPを使用することができます。

ここで遭遇したのは、RICGレスポンシブ画像仕様の絶対的なハードエッジです。 これで、何が機能し、何が機能しないかのテストケースができました。 これにより、作業を前進させるための独自の立場に立つことができます。

@joemcgillこれを明確にできますか：

投稿コンテンツのimg要素により適切な幅を保存します（ベストプラクティスですが、レスポンシブ画像のデフォルトサイズ属性の計算にも関連します）。

「より適切な」幅を作るものは何ですか？ 私は今私が理解しているかどうかわからないので、その特定のアイテムのパラメータを理解しようとしているだけです:)

本質的なサイズ/ジャンクの質問に、これは現在関連しています：

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

読むのが残念なスレッド。 進捗が見当たらないので。 現時点での解決策は、必要な正確なサイズで画像をわずかにアップロードし、サイズを2倍にするか、網膜を無視することです。ワードプレスに移行するための進歩はありますか？ 現時点では、クライアントに30 MBのページを表示する機能を提供したくありません。これは、クライアントが効率的にサイズを変更できず、画像をデザインやパフォーマンスに強制的に関連付けることができないためです。

@yratofええ、ここでの進捗が意図したよりも遅いことに同意します。 ただし、ここ（グーテンベルクレポ）とSlackで多くの議論を重ねた結果、「ある程度」改善するような限界修正を追加しても意味がないと判断しました。 この範囲は何度も縮小されました。

前進するための最善の方法は、WPがメディア、特に画像をどのように処理するかをしっかりと調べ、根本的な問題をすべて修正して改善することです。 上記のマティアスのコメントをご覧ください。 あなた（または他の誰か）がその作業に参加したい場合は、WP 5.1の準備ができたら、すぐに「正式に」起動できると思います。 それまでは、何を修正/改善したいのか、そしてWPの画像がどのように「機能」するのか、できればいくつかのコード例を使用して考えてください:)

私がこれをどれだけ好きかを言うだけで....現在私のブログはホームページで350mbです.....それはただのクソナッツです

これは、グーテンベルクギャラリーブロックに画像サイズセレクターを追加して、画像をフルサイズの画像ではなく中サイズの画像に縮小できるかどうかを尋ねるのに適切なスレッドですか？

今日、私は自分がこれをしていることに気づきました：

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

... $content_widthと.columns-Nパラメータ化できるもの。 そして、プラグインをロールします。 私はそれがそれに来ないことを願っています：）...そしてそれがコアに着地したらこれを無効にすることを忘れないでください。

編集：JavaScriptコードは一度、偶然に機能したと思います。 sizes属性をPHPレベルのどこかに、理想的にはGutenbergマークアップとthe_contentフィルターの間に挿入する必要があります。 うーん。

EDIT2：そこで私はDOMDocumentとXpathを使ってPHPソリューションを

私がこれをどれだけ好きかを言うだけで....現在私のブログはホームページで350mbです.....それはただのクソナッツです

一時的な対策として、画像を手動ではるかに小さいサイズに拡大縮小し、圧縮してから、ブログを4件程度に制限します。 彼らがあなたのブログを見るときあなたは誰かのデータを殺すつもりだからです笑

参考までにintrinsicsizeは次のようになりました： https ：

/ update / image-blockは「進行中の作業」です:)テストしてください。

• 常にlarge画像サイズを挿入するか、大きいサイズが存在しない場合はfull挿入してください。

どうですか：get_intermediate_image_sizes（）;から常にすべての画像サイズオプションを挿入します。 ？
特定の画像サイズへのアクセスを防ぐことの付加価値は何ですか？

フィルタを追加して、一部の画像サイズを有効にしたり、使用するカスタム画像サイズの入力を有効にしたりできます。
今のところ私の選択は「サムネイル、ミディアム、フルサイズ」です。これは、インターネットWebサイト（ワードプレス）の30％に出荷されるプロダクション機能のばかげた選択です。

ユーザーは全員、500koではなく5mbの画像サイズを読み込んでいます。

ブロックをフィルタリングしてレイジーサイズを追加できるかどうかさえわかりませんか？

こんにちは。
私はWordpressの専門家ではありませんが、次のように考えました。
「少なくともシンプルなギャラリー機能が手元にあります」。

上手...
サイズプルダウン（ページに「小さい」=「サムネイル」の画像を表示し、大きい画像（「大きい」）にリンクするための設定時点はありますか？
つまり、私は5.2.2について話していて、それは2019年6月です。
有料プラグイン以外の選択肢は何ですか？

私はグーテンベルクを無効にすることに本当にうんざりしています。 私が試した4番目のサイト、WITH Gutenbergを保持していた最初のサイト（これまでですが、長くはありませんでした。列はACFになります）。 これは、私にはわかりませんが、私はWPに比較的慣れていません（少なくともそれのより深い種類）、そしてこれは誰も幸せにしません。

わかりました、私にとってはhttps://github.com/klihelp/Kli-Gutenberg-Galleryは機能します。 それをありがとう！

gutenberg @ ararenameの後に画像を処理するためのプラグインを追加する必要はないはず

では、なぜこのスレッドがここにあるのでしょうか。
そして、それは画像ではなく、ギャラリーの設定に関するものです。

gutenberg @ ararenameの後に画像を処理するためのプラグインを追加する必要はないはず

はい。ただし、画像ブロック、ギャラリーブロック、メディアテキストブロックはすべて、画像サイズの処理方法に問題があります。 どうやって本番にたどり着いたのかわかりません。 世界で最も使用されているCMSの最も使用されている機能を最初から完全に再構築するときに、2017〜2019年に画像サイズを考慮に入れることに失敗するにはどうすればよいですか？ クラシックエディタがすべての画像サイズを問題なく処理する準備ができたとき。

これはすごいです。 ネイティブのワードプレスブロックの恩恵を受けることができない一方で、自分の応答性の高い画像/ギャラリー/メディアテキストブロックを作成するか、顧客が4k画像をダウンロードしている間にグーテンベルクが良くなることを期待して失敗したものに固執するかを選択しなければならない私は引き裂かれていますモバイルまたは4Kモニターの500px画像

それは私がそれを発見したときに私が思ったものです：なぜこの状態の何かが何千もの配布された「生産的な」バージョンになるのですか？
その結果、グーテンベルクは、時間内に（まあ、時間内にではなく）物事を成し遂げる最後のチャンスとして、何千人もが無効になります。
プラグイン「Kli-Gutenberg-Gallery-master」が便利で機能していることがわからなかった場合、コアが提供するはずの何かのためだけに何日も投資しなければならなかったでしょう。
これはアルファ状態であり、本番環境ではありません。

こんにちは、みんな！ 👋

これについては進展がありますか？ 会話はこのチケットから離れましたか？

これを前進させる手助けができれば、フォローして参加したいと思います。 😄

キースさん、来週中にこの件についてご連絡できるかもしれません。 信じられないかもしれませんが、問題が発生したWordPressインストールのバックエンドに到達できず、バックアップから完全なローカルバージョンをインストールする時間がありません。

'simplest-gallery' PLUS'fancybox-for-wordpress 'プラグインを一緒に使用し、問題の画像の画像幅（functions.phpでカスタム画像サイズを作成した親指）を100に設定したことを覚えています。 ％widthとautoへの高さ（これはインラインhtmlのwidth- / height-attributesを上書きします）は私のニーズを満たしました。 これがすでにあなたを助けたかどうか私に知らせてください。 ただし、少なくとも火曜日までは不在になります。

何か進展はありますか？

これは取り組んでいますか？ またはどこかで追跡されましたか？

@mtias @ azaozz-画像を使用するすべてのブロックに画像サイズセレクターを追加し始める時が来ましたか？ 画像サイズは5.0または5.1で完全に対処されておらず、画像ブロックにはすでにセレクターがあります。

たぶん、カバーブロックは次にセレクターを取得できますか（＃19223）？

チューレーン大学の教員にマルチサイトを構築しました。 カバーブロックのフルサイズの画像は、私たちの最大のリソースです。

それについて何か更新はありますか？
ギャラリー画像をサムネイルとして提供したい。 フルサイズの画像を使用するデフォルトのギャラリーブロックとCSSを使用して拡大縮小します。

@ararename>わかりました、私にとってはhttps://github.com/klihelp/Kli-Gutenberg-Galleryは機能します。 それをありがとう！

使い方を教えてください。 それはあなたにとってどのように機能しましたか？ 古い投稿ギャラリーをすべて別のギャラリープラグインショートコードで変更しましたか？ またはプラグインが自動的にそれを実行しますか？

私は実際にプラグインをインストールしましたが、それを管理しませんでした

@ShareTextures
これは新規インストールでした。プラグインをインストールするときに順序を維持することが重要かどうかは覚えていませんが、これが私がインストールしたものです。

• ColorlibのFancyBoxfor WordPress、バージョン3.2.2
• Klip-Gutenberg Gallery、バージョン1.0.0、Klipolisから
• 最もシンプルなギャラリー、バージョン4.4

そして、ギャラリーに画像をアップロードした後、それはうまくいきました。 実際、私はKlip-Gutenberg Galleryが使用しているショートコードを忘れていましたが、私は_any_を使用していません。

トピックが閉じられた後、私はほとんど忘れていましたが、私はこのテキストを準備しました：
私はそのようなトピックには興味がありませんが、グーテンベルクギャラリーブロックによって供給される画像ギャラリーの「ソリューション」を投稿すると言いました（つまり、フロントエンドの場合、バックエンドはフルサイズですが、それは私にとっては問題ではありませんでした編集者には十分な帯域幅があり、必要以上に調査できるような方法で仕事が支払われていないことは確かです-とにかく、Wordpress 5が5.0がリリースされたときに期待されていたように動作するときが来ると思います）。

まず、この権利を覚えていれば、「ギャラリー要素のサムネイルとしての画像」-5.1。*から5.2。*にアップグレードした後、問題は解消されました。

作業ギャラリーの場合、インストールする必要がありました

• Klip-Gutenberg Gallery
• 最もシンプルなギャラリー
• WordPress用のFancyBox

私は行って、どれが欠けているのかをテストしません。とにかく推測しているように感じましたが、これらのいずれかが欠けていると何かが壊れました。

そして、途中のどこかで私はしなければなりませんでした
.fancyboxforwp img {幅：100％！重要; 高さ：自動！重要;}

そして、ブラウザにJsエラーが発生しないように、コメントに133から157（約）の行（$（ "。fancybox"）。fancyboxが初期化される部分）を配置する必要がありました。

_はい、これは非常識に聞こえます。_
しかし、私はそれがまだ機能することを確認しました（すでに述べたように、バックエンドではなく、fe）。
なんとか成功することを願って、乾杯
フランク

もう1つの考え：
私はfunctions.phpに次のように設定しました。
add_image_size（ 'thumbnail'、152、152、true）;
だから私はサムネイルのサイズを明示的に設定しました、多分これは全体的な結果にも影響します。
そして、私はサムネイルの再生成プラグインをかなりの回数使用しています。おそらくこれは全体的な結果にも影響します。 乱暴に推測し、接続されているものをチェックするだけです...

@ararename迅速な返信ありがとうございます。 私のウェブサイトにはすでに500以上の投稿があります。 だからそれは私にはうまくいきません:(
WordpressGutenbergの次のアップデートを待ちます。

@azaozzそれについて何か更新はありますか？ ギャラリー内の画像のサムネイルリンクを完全な画像の代わりに使用する方法を知りたいのです。

特にグーテンベルクのレスポンシブカバーブロックに対して、これの状況はどうですか。 それらは私にとってパフォーマンスの頭痛の種になりつつあります。

レスポンシブカバー画像

レスポンシブカバー画像のパスを提案するために、CSS画像セットがどのように機能するかを理解しようとしていますhttps://developer.mozilla.org/en-US/docs/Web/CSS/image-setいくつかのテストを行っています。

最初の2つのセクションでは、レスポンシブ画像のメカニズムとしてimage-setとsrc-set / sizesを紹介します。 最後のセクションでは、レスポンシブカバー画像の今後の方向性について説明します。

画像セット

Image-setプロパティは、srcset属性とは大きく異なるようです。 画像セットは、複数の画像サイズの設定をサポートしていません。 複数の画像解像度（dpi /密度）の設定をサポートしています。 WordPressによって自動的に生成されるさまざまな画像サイズはすべて72DPIを持っているようです。
Image-setプロパティを使用すると、条件に応じてブラウザが最適な画像をダウンロードできます。 条件のいくつかの例は次のとおりです。

• 1インチあたりの画面ピクセル数。
• 接続が非常に遅い場合は、dpiの低いイメージをダウンロードすることを選択します。
• プリンタに何かを送信するときは、より良い画像をダウンロードしてください。

ビューポートのサイズは、画像セットによって選択される画像に影響を与えないようです。

Src-セットとサイズ

Srcsetを使用すると、さまざまな画像サイズのリストを提供でき（解像度もサポートされますが、ほとんど使用されません）、sizes属性は、画像を表示するサイズを選択するための構文のようなメディアクエリを提供します。 ブラウザが画像の幅を知っている場合、最も近いサイズをsrcsetからダウンロードします。

WordPressは、次のサイズ属性 "（max-width：$ width px）100vw、$ width px"を使用します。ここで、$ widthは画像ファイルの幅です。つまり、ビューポートが$ widthより小さい場合は、ビューポートサイズを画像サイズとして使用します。ビューポートが$ widthより大きい場合、画像の幅として$ widthを使用します。

WordPressのsrcset属性とsizes属性のペアにより、幅がxピクセル数の画面で、幅がxより大きい画像をダウンロードしないようになります。

前進する道

カバーブロックは画像​​をCSS背景として追加するため、最初は、image-setプロパティは、ブラウザがデバイスに応じて使用可能なファイルのセットから1つの画像ファイルを選択できるようにするのに適しているようです。
しかし、「レスポンシブカバー画像」とは、デバイスのビューポートが小さい場合は小さい画像をダウンロードし、デバイスのビューポートが大きい場合は大きいサイズの画像をダウンロードする必要があることを意味すると思います。

イメージセットはこの動作を許可していないようです。 これにより、デバイスのピクセル密度が高い場合（Retinaディスプレイなど）はdpiの高い画像をダウンロードでき、画面のピクセル密度が低い場合はdpiの低い画像をダウンロードできます。

携帯電話とコンピューターの画面のピクセル密度が同じである可能性があるため、イメージセットを使用しているように見えます。両方のデバイスが同じイメージをダウンロードします（ネットワーク速度と他の変数が同じである場合）。 この動作は望ましくありません。携帯電話に「小さい」画像をダウンロードしたいと思います。

画像セットを使用する際のもう1つの課題は、WordPressで生成するすべての画像ファイルに同じ量のDPIがあるように見えることです。

この調査の後、画像セットはレスポンシブカバー画像には適していないようです。 前方へのパスは、カバー画像にWordPressによって設定された通常のsrc-set＆sizes属性を持つimage要素を使用させ、次にCSSを使用してその画像を背景のように見せているようです（ビデオの場合と同様）。 その経路にも、主に視差に関するいくつかの課題があります。 通常の画像要素で可能かどうかはわかりませんが、試してみる必要があるようです。

私が何かを逃した場合、または役立つかもしれない追加情報がある場合は、コメントを残してください。

素晴らしい考え、@ jorgefilipecosta。 ＃19909を作成しました。これは、どのブロックでもレスポンシブ編集を受信する方法を探ることを目的としています。 レスポンシブカバー画像のアイデアがそのインターフェースを活用できるかどうかを確認できますか？

FLIFまたはJPEG-XRがすでに十分に広くサポートされている可能性がある場合...🐱
いくつかのループを使用して、画像セットを通常のメディアクエリと組み合わせることができます。
これにより、大量のCSSが発生します。 確かに、gzipはおそらくそれを押しつぶしますが、開発者ツールにスタックされているすべてのオーバーライドされたメディアクエリのように複雑でもあります。
今のところ、 <imgとsrcsetおよびsizesを使用し、コンテンツの完全に後ろに配置します。
このアプローチを使用すると、hidpi / retina部分を処理する必要はなく、サイズのルールをいくつか提供するだけです。 -ただし、これはスタイルシートとは別に調整する必要があります。

現在、カバー画像はCSS背景画像として元のサイズで配置されており、サイズ変更、サーバー側の圧縮、最適化は一切行われていません。 これは、UXのロード時間にとって非常に悪いことです。別の縮小されたバリアントをアップロードして、代わりにカバーブロックに使用する必要がある場合です。

これに対するアップデートはすでにありますか？
ギャラリーをサイトに追加したところ、ギャラリーにはサムネイルではなく画像全体が読み込まれるため、ページサイズはなんと25MBになりました。

こんにちは@azaozzと他の人。
この問題のステータスアップデートを入手できますか？

この号では多くのことが起こっているようです。 それをより扱いやすい小さな問題に分割することが重要です。

ありがとう。

ガレリアの問題を解決する方法はありますか？ メディアファイルにリンクするという意味ですか？ 現在、私の画像のいくつかには全角への有効なリンクがありますが、それらのほとんどは大判（1024x）にリンクしています。

ねえ@ CNK001

関連する問題を見つけることができるかどうかを確認してください。 メディアラベルの問題を検索しました： https ：
見つからない場合は、新しい問題を開いてください。

より高度な画像処理が必要なユーザーにサポートリクエストがありました。

最後のWordpressAutoupdatesの1つの後、私のソリューションは次のように無駄になりました...
バックエンドとフロントエンドは完全にめちゃくちゃです。 私は新たに始めなければなりません。

ギャラリーにサムネイルではなくフルサイズの画像が表示されるという問題の解決策を見つけた人はいますか？
これが1年以上前から神経質になっているので、私はとても感謝しています-そして私は一種の腹立たしいです...このトピックをもう一度深く調査する必要があります。
どんな助けでも本当に感謝します、ありがとうそして：良い一日を:-)

ねえ@ararename

ギャラリーは、内側のブロックを使用するように作り直されています。 詳細については、このプルリクエストを確認してください。
https://github.com/WordPress/gutenberg/pull/25940

@paaljoachim迅速な返信ありがとうございます！ チェックするつもりです:-)

@ararename当面の間はPhotoPressプラグインを使用できます。 コアギャラリートランスフォームがあります。

別のオプションを@padamsに感謝します。 今日はそこにたどり着くと思っていましたが、このトピックに戻るには数日かかります。 それがどのように進んだかを報告します。