プラットフォームを受け入れます

それで、人々ができることは何が彼らのウェブサイトをより良くすることです。それに答えるために、時間をさかのぼってみましょう…

年は1998年で、Webは増加しています。 WWWのアーキテクチャの高レベルの概要を示すために、Tim Berners-Lee -はい、Tim Berners-Leeは「50,000フィートからのWebアーキテクチャ」と呼ばれる論文を公開しています。このレポートでは、コンテンツネゴシエーション、セマンティックWeb、HTML、CSS、Cool URI（変更されない）など、多くのことをカバーしています。

この記事では、バーナーズリーは非常に早い段階でいくつかのデザイン原則にも注目しています。これらの原則の1つは、「最小の力のルール」です。

最小の力のルールは次のようになります：

コンピューターシステムを設計するとき、多くの場合、情報を公開するために、制約を表現するため、または何らかの問題を解決するために、多かれ少なかれ強力な言語を使用することの選択に直面することがよくあります。 […]「最小の力のルール」は、特定の目的に適した最も強力な言語を選択することを示唆しています。

フロントエンドのためにウェブ上で利用できる3つの主要言語があります。

HTML

内容を意味的に説明します

CSS

プレゼンテーションとレイアウトを制御します

JavaScript

対話性と行動を追加します

最小の力のルールは、CSSに頼る前に、HTMLを使用して可能な限り試して実行することを示唆しています。 CSSで十分でなくなったら、JavaScriptをつかみますが、実際にしなければならない場合のみです。

Derek Featherstoneがうまく言えば：

Webフロントエンドスタック（HTML、CSS、JS、およびARIA）では、スタックのより単純なソリューションの低いソリューションで問題を解決できる場合は、必要です。それは壊れやすくなく、より巧妙で、ただ機能します。

？ホールドアップ：これは、マークアップでフォントサイズと色を設定する必要があるという意味ではありません。これは、Webの「昔の」時代に行ったことです。適切な事例：バーナーズリーの作品で取り上げられているルールの1つは、形と内容の分離です。

壊れたウェブ

Berners-Leeがその記事を公開してからほぼ25年が経ちました。しかし、どういうわけか、彼が送ったメッセージは通り抜けず、多くの開発者（すべてではありませんが）はそれを知らない。この状況をとると、Devaultはそれほど前に遭遇しました：

私のブラウザは、過去28年間HTMLフォームを提出することに完全に能力がありましたが、ある理由で、一部の開発者はJavaScriptのフォームを再現することを決めました。

悲しいことに、これは孤立したケースではなく、むしろおなじみの現象です。頻繁に、私は賢くなったり、車輪を再発明しようとするウェブサイトや図書館を見ます。そうするために、彼らは彼らが目指していたものの正反対を達成します。これらのウェブサイトは、機能性が低く、アクセスしやすく、さらに悪いことに、特定の条件下ではまったく機能しません。

フォームは馴染みのある例かもしれませんが、最小の力のルールを適用することでより良い結果が得られる場合、より多くの状況があります。

• 滑らかなスクロール？
  ？ CSSがそれを行うことができるため、JavaScriptは必要ありません。
• JSONベースのAPIからエラーを通信する必要がありますか？
  ？応答本体に{エラー：true}を備えたHTTP 200を使用しないでください。ただし、HTTPステータスコードは代わりにエラーを通信します。
• javascript経由でを閉じますか？
  ？ [method = "ダイアログ"]を使用した
  要素は正常に行われます。
• 怠zyなロード画像をしたいですか？
  ？これは、属性を備えたHTMLマークアップのすべての最新のブラウザによってまもなくサポートされます。
• カスタマイズ可能な？
  ？それは私たちが話すように開発中です。
• アニメーションをスクロールオフセットにリンクしたいですか？
  ？現在はブラウザネイティブAPIであり、まもなくCSSのみを使用して実行できるため、外部JavaScriptライブラリは必要ありません。
• フォーム入力で特定の文字を防ぐ必要がありますか？
  ？貼り付けを無効にするのではなく、適切な入力タイプを選択したり、パターン属性を使用したりします。
• 崩壊セクションが必要ですか？
  ？ および
  はあなたの友達です。
• 等々…

これらすべての例では、いくつかの機能を上から下層に移動できます。バーナーズリーは私たちを誇りに思うでしょう。

回復力

Webスタックで低いテクノロジーを選択することで、Webプラットフォームのコアに近いものであるため、障害に対する弾力性が組み込まれているという利点も得られます。

JavaScriptは失敗にひどいです。プロセスで読み込まれたり、マングルされたりするスクリプト、または関数に対する1つの間違った引数があり、アプリ全体が機能しなくなる可能性があります。 「未定義のプロパティxを読むことができない」のようなエラーメッセージがあなたに馴染みのあるように聞こえる場合、あなたは私が話していることを知っています。

一方、CSSは失敗するのに非常に優れています。スタイルシートの1つに構文エラーがある場合でも、残りのCSSは機能します。 HTMLでも同じです。これらは寛容な言語です。

なぜ最小の力のルールを使用する必要があるのか​​疑問に思うなら、ジェレミーキースは彼の記事「評価テクノロジー」に答えをもたらします。

「どれだけうまく機能しますか？」と尋ねる傾向がありますが、本当に尋ねるべきは、「どれだけうまく失敗しますか？」です。

ジェレミー・キース

私たちはもっとうまくやることができます

最小の力のルールから利益を得ることができる有名なウェブサイトは、NikeのWebサイトです。 JavaScriptが無効になっているサイトにアクセスすると、画像が表示されず、靴を注文することもできません。

JavaScriptへのこの過度の依存は、これらすべての壊れた機能をフロントエンドスタックの低いテクノロジーで構築できるため、必要ありません。

• JavaScriptを介して動的に注入するのではなく、靴の写真を表示するために要素をすぐに含めてみませんか？
• a
  を使用して（サイズを選択するために）とを送信して、javascriptを介して状態全体を管理し、提出するのではなく、靴を注文してみませんか？

☝️なぜ誰かがJavaScriptを無効にしてWebを閲覧するのか疑問に思っているなら、それは多くの場合、彼らの選択ではなく、干渉する外部要因です。 「誰もがJavaScriptを持っているよね？」を参照してください。トピックについての良い説明のために。

このカテゴリのさらに悪い犯罪者は、InstagramやTwitterなどの有名なサイトです。 JavaScriptがなければ、これらのWebサイトはまったく機能しません。彼らはあなたに警告を与えるか、単に空白のままです。 JavaScriptはいつからテキストと画像をWebに表示する必要がありますか？

プログレッシブエンハンスメント

この孤立したナイキの例ほど悪い必要はありません。 JavaScriptが失敗したときに機能することを拒否するコンポーネントが小さい場合があります。例としてタブ付きインターフェイスを取ります。あなたは多くを見つけることができますがこの機能を提供するJavaScriptライブラリであるキッカーは、HTML、CSS、およびARIA自体がすでにあなたを非常に遠くに導くことができるため、そのためにJavaScriptを必要としないということです。

これらのベースレイヤーを配置したら、JavaScriptを使用してエクスペリエンスをさらに改善します。 JavaScriptを要件ではなく強化と考えてください。

同じことが、利用可能な場合と利用できない可能性のある特定のCSS機能にも当てはまります。基本的なスタイリングを提供し、@supportsを使用して検出可能な機能を使用できる場合、既に持っている結果を強化します。

このアプローチはプログレッシブエンハンスメントとして知られています。機能が利用可能になるにつれて機能を追加し、エクスペリエンスが進む限り結果を改善しますが、特徴がこれらの余分な繁栄なしでは機能しないほどではありません。

また、特定の新機能をまだサポートしていないブラウザの場合、その機能をブラウザに提供するポリフィルを試してみることができます。

ウェブが追いつきます

Webの初期の頃から、Webプラットフォームが時間の経過とともに多くの新機能を獲得するのを見てきました。新しいHTML要素が定義され、JavaScript（言語）が成熟し、CSSはレイアウトの構築、要素のアニメなどの多くの強力な新機能を獲得しました。

数年前に不可能であり、フラッシュなどの外部テクノロジーに依存することによってのみ行うことができたものは、ブラウザ自体に組み込まれています。

古典的な例は、jQueryが導入した機能です。 10年以上前、jQueryはプロジェクトに初めて立ち寄った最初のものでした。今日、Webプラットフォームが追いついており、document.queryselectorall（）、element.classlistなどが組み込まれているため、もはやそうではありません。 Jqueryはポリフィルがポリフィルと呼ばれる前にポリフィルであったと言えます。

jQueryは馴染みのある例かもしれませんが、Webが追いついた他の多くの状況があります。

• JavaScriptの非常に悪い日付（）APIに苦労していますか？
  ？時間的APIは、操作する方が良いです。
• サードパーティのJavaScriptライブラリを使用して、画面上の要素をアニメーション化しますか？
  ？組み込みのWebアニメーションAPIを試してみませんか？それは本当に強力です。
• 色付きのラジオボタンとチェックボックスが必要ですか？
  ？新しいCSS Accent-Colorプロパティはあなたのためにそれをします。
• CSS変数を使用できるようにプリプロセッサに依存していますか？
  ？ CSSカスタムプロパティは、過去20年間にわたるCSSへの最大の追加です。
• 等々…

ここでの中心的なテーマは、これらの機能がポリフィルや外部ライブラリに依存しなくなったが、Webスタックのコアに近づいたことです。ウェブが追いつきます。

これらの新しいAPIの一部はかなり抽象的ですが、コードに接続できるライブラリがあります。例は、開発者に優しいAxios互換APIを露出させながら、フードの下でフェッチを使用するRedaxiosです。これらの利便性の方法が最終的にWebプラットフォームに流れ込んでも、私は驚かないでしょう。

最後に

ほぼ25年前にバーナーズリーが書いたものは、時の試練に耐えています。開発者、そのメッセージを尊重するのは私たち次第です。 Webプラットフォームが私たちに与えてくれるものを受け入れることで、それと戦おうとするのではなく、より良いWebサイトを構築できます。

シンプルにしてください。最小の力のルールを適用します。プログレッシブエンハンスメントを念頭に置いて構築します。

HTML、CSS、およびJavaScript - その順序で。

以上がプラットフォームを受け入れますの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。