m31 web designing and development

「img要素をpで囲う」仕様を読むのがめんどくさい人向け解説

「img要素をpで囲う」仕様を読むのがめんどくさい人向け解説

web屋さんたちのTLで話題沸騰の「img要素、下から見るか？横から見pで囲うか？」問題について、Twitterでもやいのやいの言っていますが、件のツイートで挙がっている項目について、独自解釈ではなく、仕様についてきちんと解説したいと思います。
って書いたけどたぶんimg要素の話だけで終わる。

2019.9.12追記
この記事は書いたものを書きっぱなしにしておくつもりだったのですが、TwitterのDMでいただいたメッセージで気付かされたことがあり、一部に訂正と補足を追記することにしました。
このボックスで書かれている追記には、著者による嘘は含まれていません。もし追記の内容に誤りがありましたらそれはただのミスです。
また、追記にこのボックスを使用するにあたり、もともと記事内にあった同じボックスは別のボックスに置き換えました。
訂正の経緯については記事の最後で後述します。
目次

img要素の仕様を理解するためにどこを参照すれば良いか

こちらを読んでわかった気になってはいけません。

disっているわけではなく、これは冒頭にあるように「HTML5」の日本語訳（非公式）であり、「HTML5」はすでに廃止され、「HTML5.x」の仕様が勧告されています。（2019年9月現在HTML5.2）
過去の仕様は参考になりますが、今回は読む必要がありません。

読むならこちらの方が情報は新鮮ですが、日本語に訳したということは、日本語の解釈が必要になります。

日本語は美しくすばらしい言語ですが、表現の幅がありすぎること、受け手の「解釈」（裏読み・お察し）を前提とした相互のコミュニケーションで意味が変化すること、などから、英語の原文のニュアンスと変わってしまうことがあります。

ざっくりと日本語版でイメージを膨らませたあとは、できれば必ず原文にも目を通し、「元から書かれていること」「実は書かれていないこと」を確認する癖をつけましょう。（というか全文翻訳されてるわけではないので必ず原文に目を通さざるを得ません）

2019.9.12追記
原文への参照リンクを添えておきます。もっとも新鮮な情報を得ることが目的の場合には、こちらを参照してください。

この追記をした時点では「Last Updated 9 September 2019」ですが、将来のことはわからないためこの記事を閲覧したタイミングによってはこの参照先が「新鮮な情報」でなくなっている可能性があり、また同様に、「HTMLの正しい仕様」ではないことも考えられます。

勧告が2017年12月、すでに2年近く経過しています。
HTML5が2014年10月勧告です。
しかし勧告の数年前からHTML5対応を始め2014年にはすでにモバイル対応されたwebサイトがいくつもありました。
詳細は後述しますが、件のツイートで挙げられている「img要素はpで囲う」説は、HTML4の時代に流布されたものです。
「img要素はpで囲う」説は5年前の時点ですでに「昔話」になっていたと言えます。

2019年9月現在最新であるimg要素の仕様はこちらです。

2019.9.12追記
上記の一文と参照先の組み合わせが、問題の部分です。
「2019年9月現在最新であるimg要素の仕様」という表現には看過できない語弊があります。
誠に申し訳ございません。

なお、このあとのセクションではHTML4とHTML5の間でW3Cの仕様が大きく変化した部分をとりあげており、HTML5.2のW3C Recommendationを参照しています。これは意図したものであるため訂正はいたしません。

（途中のブラウザとサーバの処理について延々書かれているところで心が折れますが、今回の問題について論じるのには不要なセクションですので無視します）

この記事では上記の仕様について一緒に見ていきましょう。

その前に…

img要素はなぜpで囲う必要があったのか

HTML4時代の仕様に合わせて広まった「img要素はpで囲う」説は、もしかして「昔はそうだった」「昔はそれが正しかった」のでしょうか？

HTML4には「ブロックレベル要素」と「インライン要素」が存在した

今は存在しません。

Generally, block-level elements may contain inline elements and other block-level elements. Generally, inline elements may contain only data and other inline elements. Inherent in this structural distinction is the idea that block elements create “larger” structures than inline elements.

わかりやすく言うと、

  1. ブロックレベル要素にはブロックレベル要素を入れられるよ
  2. ブロックレベル要素にはインライン要素も入れられるよ
  3. インライン要素にはテキストノードやインライン要素を入れられるよ

ということが書かれています。

仕様の原文を見ると「Generally,〜 may contain 〜」とあります。
つまり「一般的にこれらの要素を入れても良い（差し障りがない）」ということしか言っていません。
そして肝心なのは次の一文です。

Style sheets provide the means to specify the rendering of arbitrary elements, including whether an element is rendered as block or inline. In some cases, such as an inline style for list elements, this may be appropriate, but generally speaking, authors are discouraged from overriding the conventional interpretation of HTML elements in this way.

スタイルシートによって、ある要素を「ブロックレベル要素」とするか「インライン要素」とするかを任意で指定できたりするんだけども〜、HTML4の要素が本来もっている振る舞い（もともとの解釈）を書き換えることは推奨しないということです。

仕様を読むときに気をつけたいのがこういった表現で、これを見て「禁止されてる！」「ダメ、絶対」と自己解釈してはいけません。

仕様に「禁ずる」「できない」「してはならない」のように明確に書かれていないことは、禁止されていません。
だからやっても怒られません。
エラーではありません。

むしろできるようにしてあります。
本当はできるようにしたくなかったけど事情がありできるようにしている場合もあります。
その場合も、できるようにしてある以上、それが仕様です。

これを「ダメ」と断定することは嘘になります。
逆に書かれてもいないことを「こうするのが正しい」と断ずることもそうです。
件のツイートが嘘つき呼ばわりされてしまうのはここがポイントです。

HTMLを勉強中の方々は、これをただダメだと覚えるのではなく、なぜ推奨されないのかを理解しようとすることが大事です。

勉強中の人に教えるときは、「できる、ただし、推奨されていない、なぜなら〜」と説明する必要があります。

この場合、仕様上HTML要素にデフォルトでもたせている「ブロックレベル要素」「インライン要素」という性質を、レイアウトの目的で書き換えることは、文書構造を変えてしまうことになるので推奨されないわけです。

でもそもそもブロックとかインラインとかがスタイルと紐づいていて、概念である枠組みを変えたり見た目を変えたりして連動するのおかしいじゃん？

そうです。

だからHTML5はさらにもっとはるかにセマンティックを意識した仕様になったのです。

imgはインライン要素だからpに入れる必要があった。のだろうか？

さてここまでの仕様の情報から、あなたはどのように「解釈」しましたか？

「img要素はインライン要素だから、ブロックレベル要素のpで囲う必要があるってことか！」

と、思ったでしょうか？

さきほどの仕様をもう一度見てみましょう。

  1. ブロックレベル要素にはブロックレベル要素を入れられるよ
  2. ブロックレベル要素にはインライン要素も入れられるよ
  3. インライン要素にはテキストノードやインライン要素を入れられるよ

この時点で、「インライン要素はブロックレベル要素に入れなければならない」という制約は存在しないので、それよりも絞り込まれた下層の条件である「p要素で囲う」という制約もまた存在しません。

Twitterでは「意味合い的に画像が入るのは段落の中だからp要素という入れ物が必要だ」という意見や「図は段落の中には入らないのではないか」という意見を見かけましたが、img要素がp要素の中に入っていても、または入っていなくても、文書構造上なんら問題のないケースもたくさんあります。

たとえばかの有名なシャーロック・ホームズシリーズに「踊る人形」という短編があります。
シャーロック・ホームズは数年前にパブリックドメインになりました。
わーい！簡単に紹介できる！

ホームズは紙切れを取り上げて、日の光に透かしてみせた。それはメモ帳から破り取ったもので、鉛筆で次のような絵が描かれていた。

この一文のすぐあとに、「次のような絵」が挿入されます。
引用元のページのHTMLは段落が構造化されていないのですが、イメージは掴めるかと思います。

またこの「次のような絵」に続いて次の文章が続いていきます。

ホームズはしばらくのあいだ、それを調べていたが、

これを、「ひとつめの段落と、画像と、ふたつめの段落」と解釈して組むのか、「ひとつの段落の中に1文目と画像（2文目）と３文目がある」と解釈して組むのか。
この議題は、HTML仕様の解釈の話ではなく文書の解釈の話になるのです。
文書の解釈として前者が選択されればHTMLはおのずと「p + img + p」となり、後者であれば「p > img」となります。

「p + img + p」って、img要素が流れ的に宙ぶらりんでは？と疑問に思うかもしれません。
だとすれば、それは文書を前者のように解釈したことを疑いましょう。

この文書は後者の構造になっている文書であるから、「p > img」ではないか？

という思考の順序でマークアップをしていきます。
先にコンテンツありきで、HTMLを書くときはそのコンテンツの構造をただマークアップしていくだけです。

このように考えていくと、img要素が宙ぶらりんになる文書はそうそう多くはないはずです。
ただ、それは文書構造がそうなっているから結果として「img要素、なんらかのブロックレベル要素の中に存在しがち」なだけであって、仕様上そうしなければいけないわけではありません。

ちなみに私自身も上記の文書を解釈するなら後者ですが、前者が誤りか？というとそうとも言えないと思います。
後者は１文の中で「次の」と指し示した絵を画像として埋め込んでおり、文章が続いているので非常に理解しやすいです。だから後者をおすすめするのですが、前者も「次のような絵が描かれていた」というところで図の提示に入り、図の後に主語が変わり、指示語で「それを調べていた」と別の説明が始まるため、文章のかたまりは一度区切られるという解釈もできます。
（ちょっとこのへんは国語警察のみなさんに出てきてもらって議論した結果を教えてほしいですね）

マークアップする上で本来論じるべきはコンテンツの解釈であり、HTMLという言語の仕様の解釈ではありません。
仕様には解釈の余地などなく、ただ一意であり正です。

あとさ〜はっきり言って仕様の解釈なんて、仕様ができる前に仕様作ってる人が議論し尽くしてるから、あとから解釈して議論しても意味なくない？すでにできた仕様に書いてあることがすべてでそれ以上もそれ以下もないから。仕様読んだ上で今後の展望について語るならまだしも仕様も読まずに妄想と捏造ばっかりしてマイルール語っても意味ないよね？そりゃ意味ないことするのはめちゃくちゃ楽しいけどさ〜

img要素自体の仕様を理解する

HTML4時代のimgの使用は上記リンクにあるとおりです。
img要素というのは埋め込み要素なので、img要素そのものにコンテンツは存在しません（内包するものがありません）。

それが仕様です。

つまり、あるimg要素がそこにあったとき、要素としての意味合いに結びつくsrc属性によって読み込まれるデータが「図であるか」「内容に関係あるか」「ただの装飾であるか」などは、alt属性やtitle属性による説明と、親要素のもつ意味合いから導き出されます。
img要素であるというだけで、それをpに入れるべきか入れないべきかという「解釈」はできないのです。
（なお、上記の仕様を見てわかるとおり、img要素に限り特になんらかの要素に内包されなければならないという制約もありません。）

前項で例にあげた踊る人形の絵をimg要素にした時点では、その絵が段落の中身であるかどうかは不明なのです。

まず最初に、その前後の文脈から、「踊る人形の絵」はテキストノードではなくimg要素で埋め込む必要があることがわかり、img要素でマークアップします。
次にその踊る人形の絵が出てくる文脈によって、そのimg要素はどの段落に含まれるのか、または段落に含まれない要素なのかを判別してマークアップするしかありません。

  • 提題の「img要素をpで囲う」については、昔からそんな仕様はなかった。
  • 意味付けのため「pで囲うのがベター」かどうかはドキュメントの解釈次第で変わる。

HTML5ではインライン要素は存在しない。もちろん、ブロックレベル要素も。

HTML5って私の記憶だと2010年くらいにはすでに話が聞こえてきてたと思うんですよね、考えるともうかれこれ10年くらい前の話なんですよね。

HTML5ではよりセマンティックなマークアップを推奨され、文書構造とスタイルが紐づくような仕様が廃止されていきました。
それぞれの要素に「ブロックレベル」「インライン」といった設定はなくなり、見た目の振る舞いはすべてスタイルシートで指定することになりました。

これを知らずに「divはブロック！」「spanはインライン！」「aにdiv入れちゃダメ！」などと覚えたままの人もまだまだいるみたいです。

というか、HTML5が浸透してからweb業界に入った駆け出しの人たちの中にHTML4の仕様が書かれた記事を一所懸命読んで新たに覚えてる人がいるのかと思うと胸が痛いです。HTML4を使ってる現場だからしょうがなく、という例もあるでしょうが、そんな現場は自分の力で変えるか自分が別の現場に行きましょう。
Google、HTML5のセマンティックなコードの評価とかとっくに通り過ぎて今MFIやってますよ。

かわりにそれぞれの要素には「フローコンテンツ」とか「フレージングコンテンツ」とか、文書構造の中でもつ性質（カテゴリ）で分類されました。
Flow contentなんだけど日本語で浸透してるフローコンテン「ツ」で表記しました

img要素は、フローコンテンツでありフレージングコンテンツでありエンベデッドコンテンツであり…って感じで複数の性質を持ち合わせており、複数のカテゴリに属していることになります。

画像＝figure要素に入れるとは限らない

HTML5.2におけるimg要素の仕様について

↑せっかくなので見出しの後に見出し持ってきましたが、これも別に違反じゃないですから…

やっと主役の登場です。
HTML4時代の仕様と比較してずいぶんとボリュームがあります。

Where embedded content is expected.

img要素は「embedded content」（Twitterのtypoすみません）つまり埋め込み要素です。
埋め込み要素が入るであろう場所で用いることができる、と書かれています。

さまざまな状況で用いられる場合のalt属性の付け方は？みたいなサンプルコードがめちゃめちゃたくさんあがっていますので、ぜひとも目を通しましょう。
もちろん、前述したHTML4の仕様の読み方と同じく、「禁止されていないことはできる」「書かれていないことは仕様ではない」ということを忘れないようにしながら。

figure要素には画像以外もガンガン入る

Twitterでは「そこはpじゃなくてfigureでは？」とか、「pに限らずfigureに入れるなどしなければならない」といった意見もありました。

HTML5の新キャラfigure要素を使いたくてしょうがない気持ちはわかりますが、落ち着いてください。

「4.7.5.1.7. Images that enhance the themes or subject matter of the page content」の「EXAMPLE 39」にあげられている例文でもこのようにp要素やfigure要素に内包されない形で用いられています。

本来この項の主題はalt属性の必要性についての話なので詳細は省きますが、例としてあげられている上記の文法がvalidであることを意識していただくために紹介しました。ちなみにあくまでも推測ですが、このようなHTMLコードならば、おそらくarticleに囲まれてでもいない限りはbody直下になると思います。

さらに、すぐあとに出てくる「EXAMPLE 41」においては、img要素がfigure要素に内包された例文が出てきます。

figure要素の中にp要素やa要素が内包されていることにも注目したいですね。

「画像＝figure要素に入れなければならない」「figure要素=画像を入れるところ」といった誤解をしている人は、下記の例を見たら卒倒するんじゃないでしょうか。心配です。

あれっ？figure要素なんでも入るじゃん？figure要素ってそもそも何？
それはもちろん仕様を読めばわかります。

figure要素は「フローコンテンツ」であり、「セクショニングルート」であり、「パルパブルコンテンツ」であると書かれています。

Certain elements are said to be sectioning roots, including blockquote and td elements. These elements can have their own outlines, but the sections and headings inside these elements do not contribute to the outlines of their ancestors.

セクショニングルートは個別にアウトラインを形成するため、その中に出てくる見出しなどは親要素のアウトラインには入りませんよ〜ってことです。
上記のような引用のblockquote要素の中身だったり、td要素の中身のデータの中の構造は、このページ自体の構造とは分離した独自の世界なわけですね。

Sectioning content elements are always considered subsections of their nearest ancestor sectioning root or their nearest ancestor element of sectioning content, whichever is nearest, regardless of what implied sections other headings may have created.

ついでにこれも覚えておいたほうがいいかもしれません。

HTML5.2の仕様ではsection要素などで明示的にセクショニングしなくても、たとえばhx要素によって、暗黙的にアウトラインが形成されます。
しかしこのセクショニングルートは、その暗黙的に作られたアウトラインには関係なく、とにかく常に一番近い祖先であるセクショニングルートか、もしくは一番近い祖先であるセクショニングコンテンツ（article要素やnav要素、section要素など、親要素とは限っていません）のサブセクションとして扱われる、とあります。

2019.9.12追記
上記、脱字がありましたので修正し、ついでなので過去も将来も意味が変わらない限定的で親切な感じの書き方の例にしました。
修正前はこちらです。
「HTMLではsection要素などで明示的にセクショニングしなくて、hx要素などによって暗黙的にアウトラインが形成されます。」

Where flow content is expected.

figure要素を使えるのは、フローコンテンツが入るであろう場所です。

また、このfigure要素のコンテンツモデルは

Flow content optionally including a figcaption child element.

任意でfigcaptionを子要素として内包できるフローコンテンツ、とありますね。
絶対つけなきゃいけないわけではありません。
というかつけられない構造の場合もあるからそのようになっています。

that is self-contained (like a complete sentence) and is typically referenced as a single unit from the main flow of the document.

ドキュメントのメインフローから「参照される」とあります。
シングルユニット、つまりこれ単体で完結するユニットとして文書から参照されるものというわけですね。
なんだかarticleみたいですね。
なんだか愛の理想みたいだね。
2019年9月8日デビュー20周年おめでとうございます東京ドーム2days最高でした

ただし注意書きがあります。

“Self-contained” in this context does not necessarily mean independent.

「自己完結」というのはここでは「独立」しているという意味ではありません、だそうです。
まあそりゃそうです。articleと違ってfigure要素は主に「図」などを参照するものだからです。

For example, each sentence in a paragraph is self-contained; an image that is part of a sentence would be inappropriate for figure,

たとえば段落の中にあるそれぞれの「文」は自己完結しています。

さきほどの踊る人形の例だと

ホームズは紙切れを取り上げて、日の光に透かしてみせた。
それはメモ帳から破り取ったもので、鉛筆で次のような絵が描かれていた。

この2文は同じ段落にありますが、それぞれ個別の内容で完結しています。

この文の中に画像が含まれる場合、たとえば

ホームズは紙切れを取り上げて、[太陽の画像]に透かしてみせた。

のように（絵文字みたいですが）画像が使われている場合、これは図としてはふさわしくないということです。

an entire sentence made of images would be fitting.

画像からなる「文」全体の場合、「図」として適切であるということです。
ちょっと日本語で考えてもピンとこないのですが、

The element can thus be used to annotate illustrations, diagrams, photos, code listings, etc.

この要素ならば、図、イラストや写真、果てはコードリストに至るまで、注釈をつけることができる、とあります。
そういった注釈のようなテキストや表のようなデータを伴ったセクションとして使えるのがfigure要素だ、と定められているわけです。

また先にあったように、ドキュメントから「参照される」ものなので、

ホームズは紙切れを取り上げて、日の光に透かしてみせた。それはメモ帳から破り取ったもので、鉛筆で次のような絵が描かれていた。
img要素で読み込んだ踊る人形の画像直線で描かれた人形がさまざまな姿勢をとった絵が整然と並んでいる
ホームズはしばらくのあいだ、それを調べていたが、〜

という構成で、「踊る人形の画像」のimg要素をfigure要素に内包し、さらにfigcaption要素で注釈をつけたりして、ドキュメントから「次のような絵」を参照させることができます。

ちなみに仕様の注意事項では、スタイリングで移動する可能性があるので（スタイリングで移動することが可能なように）「左の画像」とか「下の画像」といった相対位置を参照させるのではなく、ラベリングして参照させるのがいいよ、ということです。
前述の踊る人形も、もしかしたら本文の欄外に置かれてしまうかもしれませんからね。

The figcaption descendant of figure, if any, represents the caption of the figure element’s contents. If there is no child figcaption element, then there is no caption.

figcaption要素は任意で内包するものなので、figcaption要素そのものやその子孫要素が存在しないこともあります。
存在する場合に限り、figcaption要素の子孫要素はfigure要素のコンテンツのキャプションを表すということです。
存在しない場合はもちろん、キャプションそのものがありません。

  • figure要素は画像の入れ物ではなく、図などを参照させる目的で使われる要素である
  • figcaption要素は任意なので、画像のみ参照させても問題ない

今日は何年何月何日ですか？

さて、今これを読んでいるあなたに質問です。今日はいつですか。
2019年9月でしょうか、それとも、2022年？
この記事は、古い情報について書かれている可能性があります。

この記事を書いている現在はHTML5.3がドラフト段階ですが

もしかしたらすでに勧告されているかもしれませんよ。
いえ、ひょっとしたらHTML6が勧告されてるかも…

大事なのは、誰かが言った情報を鵜呑みにするのではなく、自分で理解を深めようと行動すること、正解である仕様を確認することです。
この記事は仕様に書かれていることを解説していますが、世の中には「他人の解釈を挟んだ仕様と異なるニュアンスの情報」がたくさんあります。

そしてもう一つ大事なことは、人に何かを教えるときは、まず自分が勉強し直すことです。

  • 参考にする記事などのタイムスタンプをチェックすること
  • わかりやすい記事だけを読んでわかった気にならず、仕様を確認すること
  • 自分が知っているはずのことと異なる意見や主張を見かけたら、調べ直すこと

ここまで読んでくださった方、ありがとうございました。

ここまで読んだのならわかっていると思いますが、この記事を鵜呑みにしてはいけませんよ。

私が参照してるリンクは私の用意したダミーサイトで偽の英文が書かれているかもしれませんからね。

一気に1万字の記事作ったからろくに校正してなくて日本語が変になってるかもしれないし、それをそのまま読んだら誤った意味になっているかもしれませんからね。

気づいたら直すけど直さないかもしれませんからね。

最後に、今回の件に関する私のツイートを抜粋し、一連の流れに対する私の「解釈」を添えてお別れしましょう。

「imgは実はpで囲うのが正しい」と断定してしまった文はどんなに「これはこういう意味で言ってます」と後出しジャンケンしたところで、その文そのものはそれをまったく表していないため、「嘘」の文として嘘のままそこにあり続けます。
もしまったく違う意味で言っているのであれば、「imgは実はpで囲うのが正しい」という文（発言）自体を撤回するしかありません。

また、上記以外にリプ欄のやりとりでも語弊があるとしか言いようのない「表現」を続けているために、仕様を理解している人たちがみんな呆れているのです。

ただし、「要は文脈に合わせて、セマンティックにしましょうってことでした」という発言自体はなんら反論するところもないまっとうな意見です。
「要」は合ってるのになんで具体例は嘘八百なんでしょうか。

もしかしたらこのツイ主は本当は仕様を（自分の頭では）理解しているのに、それを自分の言葉で説明することや日本語がものすごく下手くそすぎて言うこと全部嘘になってしまっているという可能性もあります。

とすればいくら叩いても意味もないし、本人も誤っている自覚がまったくないわけなので、今後もHTMLの話題に限らずそういった歪んだ情報を発信し続けるのは止められないと思います。
それよりも我々ができるもっと建設的なアクションは、なるべく訂正した情報を「駆け出しマークアップエンジニア」に届けることです。

私の意見ですが、HTMLもCSSも実際奥は深いんですけど、仕様という地図がもともとあるし簡単ですよ。
ネットは地図を勝手に書き換えたり横穴を掘って増やすやつだらけなので、みんな混乱させられてるだけです。

どうか「駆け出しマークアップエンジニア」のみなさんが、件のツイートよりもこの記事を、この記事よりも仕様を、目にすることを願っています。

2019.9.12追記
冒頭で触れた、訂正をしようと考えるきっかけになったメッセージを、ご本人のご了承を得て一部抜粋し掲載させていただきます。

全文読んでいただいたうえで記事の本来の意図を汲み取ってくださっています。
そのうえで所感を教えてくださったのですが、これを見て私はハッとしました。

私の発言であげている問題の箇所は追記を入れました。
このセクションの時点では記事の本来の主題についてまだ触れておりません。
そのため、読者は書かれていることを邪推せず読み進めるのが妥当な段階です。
暗黙の前提を持たない読者にとっては、「読みようによっては嘘ではない言い方」や「嘘とわかる嘘」のようなものではない明らかな嘘であったため、訂正しお詫びします。申し訳ございません。

2019.9.12追記
この記事のように「○○の仕様」と限定していない書き方をすると、「××の仕様ではそうしなければいけない」と指摘されますが（話してるのは○○の仕様なので実際は指摘というより情報共有）、それはたいてい正しく有益な情報なのですが、そこに付け加える形ではなく、先回りして情報発信しておけばみんなのためになって良いのにな、ということも考えはじめました。
自分自身もTwitterでよくそういう引用リツイートで別情報の話題を出すっていうのをやってるんですけど、そんなこと言うくらいなら先に言っといてくれよなって思いますよね、駆け出し側は。
間違った情報を訂正するより、正しい情報がいち早く浸透するのが理想なんだろうな、と思いますが…

普通に真面目に書いても誰も読んでくれないんですよね。
このブログも、私が役に立つと思って書いた記事はほとんど読まれていませんが、こういう記事は一気に広まります。

だから本当に情報を（他人を利用して）発信して広げてる件のツイートの方が、何もしないよりも結果としては有益のボリュームが大きくて、img囲む囲まないなんて、今まで考えてもいなかった人まで考え出しましたものね。
怒りのエネルギーだったり、strictな文でないとツッコまずにいられなかったり、自分はこれが間違ってるのわかってるぞって優越感があったり。
良くない情報のほうが、みんなが「これ良くないぞー！」って広めるんだよなって。

当然有害のボリュームもありますけど、指摘や訂正をされることによって有害な部分は淘汰されていくので、紙の出版と違ってwebの世界っていうのは…もしかしたらそれでもいいのかなあと数日経った今は思ったりします。