day3 #186
day3 #186
Conversation
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
1 Skipped Deployment
|
Deploying studiosakupi01com with
|
| Latest commit: |
ae87f8a
|
| Status: | ✅ Deploy successful! |
| Preview URL: | https://d129853b.studiosakupi01com.pages.dev |
| Branch Preview URL: | https://feat-2025-advent-3.studiosakupi01com.pages.dev |
|
|
||
| ところで、ブラウザはパースできない HMTL タグを無視するようにできています。 | ||
|
|
||
| `<html>` 配下の要素を全消しして、`<hoge />` などという超適当なタグを挿入しても、なぜかご親切に `<head>` が入り、`<body>` が入り、`<hoge />` が `<hoge></hoge>` に変換されて、その中に文字列なんか入れていてもその文字列がちゃんと表示されます。 |
|
|
||
| ここに Web の根本的な設計思想が現れていると思います。 | ||
|
|
||
| 仕様になく、実装もされていないようなタグや属性に遭遇しても、ブラウザは処理を停止せず、理解できる部分を可能な限り表示し続ける。新しい要素や属性が追加されても、古いブラウザでコンテンツが完全に表示されなくなることはない。この 30 年で、HTML は何度もバージョンアップし、パーサすら変え、ブラウザは劇的に進化し、CSS や JavaScript といった技術が誕生したにも関わらず、初期の HTML ドキュメントは今日のモダンブラウザで完璧に表示される。 |
There was a problem hiding this comment.
サポートしてないタグを無視してエラーにはしない => 前方互換性(将来の発展を妨げない)
30 年前の HTML が今でも表示できる => 後方互換性(過去のコンテンツを切り捨てない)
なので、前半と後半が微妙に繋がってない。
|
|
||
| 仕様になく、実装もされていないようなタグや属性に遭遇しても、ブラウザは処理を停止せず、理解できる部分を可能な限り表示し続ける。新しい要素や属性が追加されても、古いブラウザでコンテンツが完全に表示されなくなることはない。この 30 年で、HTML は何度もバージョンアップし、パーサすら変え、ブラウザは劇的に進化し、CSS や JavaScript といった技術が誕生したにも関わらず、初期の HTML ドキュメントは今日のモダンブラウザで完璧に表示される。 | ||
|
|
||
| ここまで完璧な互換性が保たれたシステムは、他にないと言っても良いのではないでしょうか。 |
There was a problem hiding this comment.
Windows はかなり昔に作られたバイナリが未だに起動できたり、後方互換に気をつかってるシステムはなにも Web だけじゃないので、ちょっと言いすぎかもしれない。
|
|
||
| ここまで完璧な互換性が保たれたシステムは、他にないと言っても良いのではないでしょうか。 | ||
|
|
||
| 1991年に公開されたこの世界初の Web ページが、30年以上経った今でも問題なく読むことができるのは、「理解不能なものは無視する」という Web 初期からの設計思想があったからです。 |
There was a problem hiding this comment.
これも、前方/後方互換性が混ざってる気がする。
<NOTE> については、むしろ後方互換(つまりサポート)が捨てられた代わりに、未知のタグとしてたまたま無視されていると考えると、互換が保たれてないとも言える。
| > | ||
| > [Web Platform Design Principles](https://www.w3.org/TR/design-principles/#css-content-should-be-visible) | ||
|
|
||
| ゆえに、CSS はデフォルトではすべて表示されるようになっています。 |
There was a problem hiding this comment.
「すべて表示」が何を指してるのか、目的語がなくよくわからん文になってる。
ゆえにCSS は、デフォルトで「すべてのコンテンツが隠れず表示」されるようなデフォルト値に設定されている
みたいな？
|
|
||
| HTML パーサが理解できないものは無視し、CSS が適用できないプロパティがあってもレンダリングを続け、デフォルトではコンテンツの表示を保証し、JavaScript でエラーが発生してもページの表示は保たれる。 | ||
|
|
||
| つまり、我々が User としても Author としても（はたまた UA の実装者としても）書く HTML や CSS や JS は、あくまで **"Hints"** であるということです。 |
There was a problem hiding this comment.
詰め込む場合こそ、語順とか係り受けを整理したい
つまり、我々が User や Author (または UA 実装者)として書く、 HTML/CSS/JS は、あくまで "Hints" であるということです
とか。
|
|
||
| これらの背景を踏まえると、「Cascade」が今日まで生き残り、最重要概念とされる理由が自ずと見えてきます。 | ||
|
|
||
| Cascade が異なる Origin（(Rendering Results,) User Agent, User, Author）にスタイルを **"Hints"** として **"Suggest"** するものだと捉えると、Cascade は CSS のみならず、Web にとってさえ重要な概念を包含している設計であることがわかります。 |
There was a problem hiding this comment.
Origin に、スタイルを Hints として Suggest
なんか語順が気になる。
Origin に、 Hints として、スタイルを Suggest
or
スタイルを、 Origin に Hints として Suggest
There was a problem hiding this comment.
「とってさえ」を使うなら「A にとってのみならず、 B にとってさえ」だが、後半しかない。
- Cascade は CSS のみならず、Web にとってさえ重要な概念を包含している設計であることがわかります。
+ Cascade は CSS にとってのみならず、Web にとってさえ重要な概念を包含した設計であることがわかります。 正直これくらいでいいように思う。
Cascade は CSS のみならず、Web にとっても重要な概念であることがわかります。
|
|
||
| Cascade が異なる Origin（(Rendering Results,) User Agent, User, Author）にスタイルを **"Hints"** として **"Suggest"** するものだと捉えると、Cascade は CSS のみならず、Web にとってさえ重要な概念を包含している設計であることがわかります。 | ||
|
|
||
| Web を Web たらしめる概念を包含するゆえ、必然として重要な概念であり、Cascade との調和を図らずにいることはタブーであるといえるのではないでしょうか。 |
There was a problem hiding this comment.
大事なことを言ってそうで、何が言いたいのかぼやけてる。無駄な装飾が多い。
構造は
Cascade は重要な概念で、それと調和を図らないのはタブー
なだけなのに、前半の主語を省略し、「概念を包括する重要な概念」っていう「概念」言いたいだけちゃうんか感が挟まってる。
最後も「〜いることとは、〜であるといえるのではないでしょうか？」も「〜は、〜といえる」くらいで良い(少なくとも理系論文では)。
したがって Cascade は Web を Web たらしめる概念を包括するため、それと調和を図らない ${何か} はタブーとみなすことができる。
で、この ${何か} がなんだかはこの文ではわからない。
|
|
||
| Web を Web たらしめる概念を包含するゆえ、必然として重要な概念であり、Cascade との調和を図らずにいることはタブーであるといえるのではないでしょうか。 | ||
|
|
||
| その調和を図らずにいた（または、十分に調和する方法が存在してこなかった/調和するという概念が存在しなかった）ため、CSS は「扱いづらい」ものであったり、それゆえに「強制する」ものであったり、結果として「いや、もうなんかよくわかんないけど、みんなこの書き方/ライブラリ/ツールがいいって言ってるしこれでいいや」なものであったりしたのではないでしょうか。 |
There was a problem hiding this comment.
今回の連載の革新に迫る何かが書かれているはずだが、めっちゃ長い一文に、それっぽいだけの言い回しで適当に詰め込まれてるから、何も胸を打たない。
「その調和を図らずにいたため、 CSS は〜」ということは、さっきの ${何か} は CSS だった？ 「CSS は Cascade と調和してない」？ そんなわけあるか？
で、「調和が取れてない」が、急に出てきた「扱いづらさ」と、どう因果関係があるのかも書かれてない。
それゆえに「強制する」の主語も不明。
なんでその「結果」が出てきたのかもよくわからない。
全体として、こここそ、今回の連載の革新に迫る部分だと思うので、もっと大事に書いて欲しい。
|
|
||
| その調和を図らずにいた（または、十分に調和する方法が存在してこなかった/調和するという概念が存在しなかった）ため、CSS は「扱いづらい」ものであったり、それゆえに「強制する」ものであったり、結果として「いや、もうなんかよくわかんないけど、みんなこの書き方/ライブラリ/ツールがいいって言ってるしこれでいいや」なものであったりしたのではないでしょうか。 | ||
|
|
||
| これからは数回に分けて、我々が Cascade との調和と逆行する形で辿ってきた CSS の歴史から、Cascade Layer が誕生した今までを振り返ろうと思います。 |
There was a problem hiding this comment.
「Cascade との調和」が、わかるようで、なんかぼんやりしたまんまなんだよな。
Cascade は Hints + Suggest なのはわかった。
それと調和を「取れている/図る」ものがどういうもので「取れてないもの/タブー」がどういうことなのか、
「調和」って言葉に頼りすぎて、実はちゃんと説明がされてないからだと思う。
|
@Jxck 前方互換性（未知のタグを無視）と後方互換性（古いHTMLが表示される）を同じ「理解不能なものは無視する」で説明しちゃっていた箇所の修正は以下です。 また、主語や目的語がぼんやりしてわかりにくくなっていた”筆者の主張’”パートは以下のように修正してみました。どうでしょう？伝わりますかね・・・？ |
|
うーん、なんか難しくなってきたな。
例えば HTML の要素の場合、知らないものを HTMLUnknownElement として解釈するのは、無視をするというよりは、「エラーにしない」っていう方が大きいと思うんだよな。エラーになって画面が表示されないとか、エラー画面になるとかは、望ましいことじゃない。だから未知のものはエラーにしない仕組みは、今後新しく要素が追加されても破綻を裂けられるので、開放/閉鎖原則でいう「拡張に対して開いている」状態になって、結果まあ「前方互換性あるよね」と言えなくはないよなと。
たぶんこれが一番いいたいことなんだろうけど、 30 年前のページが表示できるのは、基本的に「後方互換」のおかげなので。両方を持ってくるのはちょっと強引な気がするんだよな。 全体として、「両方の言葉を使いたい」がありきで、強引にでっち上げられた文章に読めてしまう。 |
こっちはこっちで、まだなんか「そもそも CSS って扱いにくいものだ」っていう前提が先に来てて、「ん？そんな話してたっけ？」感がある。 CSS の何を扱いにくいって言ってるの？みたいなのがもっと説明されてないと、「それは Cascade を無視してるからだ」を急に突きつけられても「無視ってどういうこと？タブーってどれのこと？」となる。 順としては
みたいなことだと思うんだが、 2 だけしか書いてない感じがする。 |
|
確かに、「エラーにならない===前方互換がある」と言うのは、ちょっと結果論だけで話しちゃってる感じありますね・・・。
たしかに「後方互換」は必須ですが、「エラーにならないように実装されていること」に関しては、どういったページを表示するのかによりますね。 なので、「エラーにならないこと」と「後方互換」はどっちも、「あらゆるコンテンツは守られるようにWeb はつくられている」という主張を説明する上での文脈に含めておきたいです。 「エラーにならないこと」と「後方互換」は、少なくとも CSS には適用されますし、次章で述べる「Content should be viewable and accessible by default」とも合わせると効果的な考え方なのかなと言うのもあり。 エラーにならない + 後方互換 => どんなコンテンツでも表示可能 みたいなイメージなんですが、どうなんでしょうか？ |
|
↑、こんな感じで書いてみました。 |
いや〜、そうなんですが、あえてお茶を濁して書いてました😅 > 「Cascade の思想を無視した これからは、まず Cascade の思想を理解し、CSS では何がどう扱いにくかったのかから入り、それをどう頑張って扱ってきたかを話し、それらが Cascade に対してどういう解決策だったかをまとめ、Cascade Layer っていうのは何たる解決策で、Cascade の思想をどう利用できそうか・・・みたいな流れを考えてます。（事前に共有してたやつとちょっとずれててすみません） これから Node × CSS エコシステム周りの話を入れていく予定で、その大部分が Cascade の考え方を利用できずに図られてきた解決策だと思ってて、「扱いにくさ」だったり「
なので、1, 3 に関しては、 （あと、「扱いにくさ」とか「解決策」をここでまとめてしまうと、これから先いずれかのタイミングで、それらを取り上げることが見込まれてしまい、「やっぱ他を考えたら飛ばした方が辻褄が合いそうになった」っていうのがしにくいな〜、、というアドベントカレンダーのシステム的な制約も背景にあります・・・） |
アドカレは、最初にがっつり構成を決めるよりも、書きたいことを書きたい順で書いていって 100 行くらいで区切る、みたいな緩い書き方でもいいと思うよ。まあ、構成決めるほうが一般的には良いとされるだろうけど、始める前から全部は見えないしねぇ。 |
エラーにしないのは、そもそも HTML はある程度ゆるくしておくことで、メモ帳でもタグを打てば動くくらい手軽だったから普及したとか 色々思うところは無くはないけど、まあここで止まっててもしょうがないから、一旦書きたいことを書いて先に進むのがいいのかもしれん。 |
|
@Jxck |
@Jxck
Day3 の記事を執筆しました。お手隙でレビューいただけると幸いです！