Web 標準についてもう一度言及する時期が来ました_html/css_WEB-ITnose

Web 標準は共通のトピックです。国内に導入された時期はざっと計算して約10年。しかし、国内に優秀なフロントエンド人材が不足しており、関連する教育のフォローアップが遅れているため、多くの人がそれに十分な注意を払わず、実際のプロジェクトにそれを適用することができず、同時に、より多くのエネルギーを費やしてきました。これにより、技術的なギャップが生じ、1 人や 2 人ではなく、大部分の人々に影響を及ぼします。適切なガイダンスがなければ、多くの誤ったコーディング習慣が残り、悪影響を及ぼします。個人の成長やプロジェクトには不利です。

なぜ今このことについて再度言及するのが適切な時期なのでしょうか?まず、私のペンギンのコロニー (152128548) から撮影した次の代表的な写真をご覧ください。

1. タグは依然として悪用されています

2。ビジュアルを重視し、セマンティクスと構造を軽視する

3. 注目の新しいテクノロジーに熱心に従うが、基本には注意を払わない

4. 基本に注意を払うように言うと、次のいずれかになります。ネイティブ JS について話すとき、CSS の原則やテクニックについて話す人はいますが、HTML について話す人は誰もいません

上記の点と、これらの側面がさまざまな分野でほとんど言及されていないように見えるという事実のため機会やカンファレンス、初心者は経験豊富な手によって「導かれ」ますが、ベテランのエネルギーはこれらのより基本的なものにはありません。この記事は、皆さんと一緒に原点に立ち返り、Web 標準に準拠したコードを作成する方法を確認することを目的としています。

問題の原因

1. 敷居が低く、簡単である

HTML はよく使われるタグが少ないので安心してください。

例: h1~6、p、span、div、img、a、input など。ランダムなスクリーンショットを撮りましょう

上記はPC版のとある秘宝のログインページです 諸事情により(不明ですが)タグの数が少ないので、それが悪いとか間違っているとかではなく、反映されているのかもしれません。他にもたくさんの人。 HTML タグが 100 個以上あると言ったら、どう反応しますか?

1. わかりません。こんなにたくさんあるとは思いませんでした。2. わかっていますが、役に立たないものが多いと思います。

どれになりますか。 ?

適切なタイミングで適切な場所で適切なタグを使用する方法は、Web 標準の基本要件です。詳細は後ほど。

CSS は非常にシンプルで、一般的に使用される属性はごくわずかです。

幅、高さ、境界線、背景、位置、フローティング、マージンをマスターすれば、多くの属性を扱うことができます。ページのレイアウト状況が消えています。このため CSS が単純だと思うのであれば、CSS が「罰」を与えるのを待ってください。

悪い面: さまざまな互換性の問題、さまざまな奇妙なレイアウト要件、さまざまな予測不可能なバグ

良い面: 美しく魔法の効果を作成するのに役立つ多くの素晴らしいテクニックと新しい CSS3 プロパティ

まだ CSS が単純すぎると思われる場合は、こちらをご覧ください https://drafts.c​​sswg.org/indexes/ そして強くなってください~

2 、「正しく」実行するだけで、必要はありません

多くの場合、たとえコードが間違っていても、ブラウザはそれを許容します。コードが不規則であったり、場合によっては間違っていたりしても、現時点ではブラウザはまだ「正常に」表示しています。私たちは自分の間違いに気づいていません。見た目が大丈夫だからといって、大丈夫だと考えるのは危険です。

タグには注意を払わず、CSS の処理に任せるだけで、特定の CSS ルールによって要素のパフォーマンスを任意に変更できます。これにより、HTML タグに注意が払われなくなります。なぜなら、私たちは常に彼らに何も問題がないように見せかけているからです。

3. 「将来を見据える」ことに熱心です

新しいテクノロジーを学び、スキル ツリーを充実させます (html5、canvas、svg、react、ES6 など)。

「問題」を解決する - 普通の仕事には何の困難もないと感じているので、すでに知っていることをわざわざ深掘りすることはありません。

クールなエフェクトを作成します - 純粋な CSS アイコン、アニメーション、3D アニメーション、キャンバス アニメーションなど。

学習のトレンドに従って、誰もがそれについて話し、業界はそれを称賛しています。実際、「基礎があれば」という格言があります。強くないと地球が揺れるでしょう。」 「何か新しいことを学ぶことに興奮しているとき、十分な基礎がなければ先に進むのが難しいことがよくあります。

上記の記述は間違っていますか?もちろん、それらはすべて正しいです。特に技術の発展と反復が速いインターネット分野では、自分自身を強化するために、より多くのことを知り、実際のアプリケーションでより多くの選択肢を持ちたいと思っています。学習が興味によって動かされるのは良いことであり、私も同じように感じますが、注意する必要があるのは、学習は直線ではなく、直線に沿って急ぐことはできないということです。深さもあり、日々あらゆる面から自分の才能を磨き、磨き続ける必要があります。

文書の構造と意味が最優先

効果を達成するにはさまざまな方法があることは誰もが知っていますが、どれが最適でしょうか?例を見てみましょう

リスト

特徴は何ですか？最も明白なことは、このように、互いに独立して垂直に配置された多くの項目があることです。

私はリストです

私はリストです

I はリストです

どのように書くことができますか?

1、

我是列表<br>   我是列表<br>   我是列表<br>

2、

<li>我是列表</li>    <li>我是列表</li>    <li>我是列表</li>

3、

    <li>我是列表</li>    <li>我是列表</li>    <li>我是列表</li>    

上面三种是比较直接想到的对的写法，当然也可以用ol，算同一种方法。它们所能实现的效果是类似的，往往我们会从表现的角度考虑说第一种不够灵活，无法控制样式，第二种方法浏览器也不会不搭理你，它会把li解析成块级元素，让它们单独排列，但它失去了告诉浏览器“我是个列表”的标志，也就是外层容器（ul/ol），最好的写法肯定是第三种，它不仅看上去是对的，还告诉浏览器这是个列表，还有列表所应有的特点，比如“缩进”和“着重号”，当然，最大的益处仍然是它是有意义的，也是为什么这里没有提div和p等元素的原因。

标题

作为标题，特点也简单，比页面上其他的文本更大、更粗。我们可以这样写：

1、

<span class="head">我是标题</span>

2、

<p><b>我是标题</b></p>

3、

<h1>我是标题</h1>

不看代码的情况下，三者可以一模一样，但看了代码的话，大家应该都会第三种写法是最好的，第三种写法的好处有哪些？

1、本身是块级元素

2、是独特的，不像p或者span等元素会用到页面当中的很多地方

3、更加重要的是，在不加任何css规则的情况下，标题元素仍然明显是个标题，页面的无样式视图将显示其预期的文档结构，正确的标题元素传递了“意义”而不只是表现指令

4、屏幕阅读器、手机和其他浏览器也将知道如何处理标题元素

5、搜索引擎友好，除了title和meta，标题是最可能存在关键字的地方，利用好它，会更加方便用户找到你的页面

但是它有没有问题困扰着我们呢，答案是有，h1和h2这些标题的默认样式被认为过于粗大，这会让有些人倾向于使用更高级别的标题元素，其实这个大家都知道，不是大问题，可以用css来控制，前提是：先结构，后表现。至于选择使用h几，也不是没有讲究的，它们既然是分了级别，那自然是有一定意义所在，一般来说，h1是个重要的标识，页面当中有一个就好，然后，不要出现类似h2包裹h1的情况。

表格

现在如果提到表格（table），很多人会觉得好笑，使用web标准构建网站的一个最荒诞的说法就是你应该永远不使用表格。

是的，使用table来布局确实是有劣势，但并不代表我们不能用表格来做适合它做的事，比如：数据化表格。

最简单的表格可以有下面这个结构：

<table>    <tr><td></td><td></td></tr>    <tr><td></td><td></td></tr>    <tr><td></td><td></td></tr>    </table>

有时候，我们会在表格的上方加一点说明性文字，通常我们会习惯性的使用h*或者p标签来包裹这一段内容，如果你是用div，那么…

其实我们有更好的选择—— 63bd76834ec05ac1f4c0ebbeaafb0994 ，这个是表格自己的专有标题哦，有它为什么我们还要用别的呢？

除此之外，如果我们想给表格的第一行算作表头，可以怎么做呢？可以这样：

<tr><th></th><th></th><th></th></tr>

把这行代码放在第一行，th标签会给它不同于td的样式来区分出和其他行的不同，此外它可以是行的，也可以是列的，怎么区分呢？还有这个——scope属性scope=row/col，把此属性添加到th标签中即可设置它的归属。

但这样就够了吗，如果对于简单的表格来说已经挺好，那么好像它还没有比较清晰的逻辑结构，那么，不卖关子了。较完整的表格，应该是下面这样：

<table summary="这是一个表格的内容简介" cellspacing="0">     <caption>表格标题</caption>         <thead>             <tr> <th scope="col" id="name">姓名</th> <th scope="col" id="address">地址</th> <th scope="col" id="databirthday">出生日期</th>             </tr>         </thead>         <tbody>             <tr> <td>ewee<td> <td>hubei<td> <td>19870102<td>             </tr>             <tr> <td>rewe<td> <td>wuhan<td> <td>419880103<td>             </tr>             <tr> <td>ertww<td> <td>yichang<td> <td>19870205<td>             </tr>     <tbody>     <tfoot><tr><td>one</td><td>two</td><td>three</td></tr></tfoot></table> 

是不是顿觉十分的清晰，慢着，summary=”这是一个表格的内容简介”这句是什么鬼？好吧，看内容便知，它是关于表格的一个简介，这个简介用户是看不到的，屏幕阅读器可以利用该属性。

8e99a69fbe029cd4e2b854e244eab143 ， 907fae80ddef53131f3292ee4f81644b ， a4b561c25d9afb9ac8dc4d70affff419 ， 5a8028ccc7a7e27417bff9f05adf5932 和其他短语元素

短语元素，在于控制的颗粒更小，无关布局，和表现也没有太大关系（虽然它会有加粗或者倾斜的效果），用来对于页面中的某些特殊内容做出特别的标识，比如“强调”、“引用”等。

那么它们的区别在哪儿？

8e99a69fbe029cd4e2b854e244eab143 代替 a4b561c25d9afb9ac8dc4d70affff419 , 907fae80ddef53131f3292ee4f81644b 代替 5a8028ccc7a7e27417bff9f05adf5932

传达意义和结构，而不是给出表现指令。

907fae80ddef53131f3292ee4f81644b 表示强调， 8e99a69fbe029cd4e2b854e244eab143 表示更加强调，在语音合成器用户代理场景下，它们还表现为音量、音调及语速的区别。如果一个元素需要既强调又斜体，那么我们可以选择正确的标签，然后通过样式来控制其他方面。

如此之外还有其他短语元素，比如:

f3a85e1241a187c5ac462d886e9a968b 包含对其他来源的引言或引用

ffbe95d20f3893062224282accb13e8f 指定一个计算机代码片段

b7f90f73cad438258bf67e62f79b2113 表示一个变量或者程序参数实例

等

最小化标示

通常情况下，较少的代码意味着更快的下载，还意味着更少的服务器空间和带宽消耗。有个问题就是，即使你写出了符合web标准的页面仍然不能说明你写出了足够简洁或者合理的代码。正所谓规则是死的，容易做到，碰到实际场景，不同的做法会导致结果不同。在我们成长过程中，会遇到不同的老师，要么是一篇文章，要么是一本书，要么是具体的某个人，追溯到最后仍然是人，不同的人，观点和习惯可能不同。比如，你可能会养成一个习惯就是希望给所有单独添加样式的元素分配一个类，这样做到了较强的可控性，但是，这样引发什么潜在的问题呢？

1、过多的类2、类的命名难

除了上面两点，还有一个可能碰到的就是类名重复，然后样式冲突。

可能上面的问题你都遇到过，或许也想了办法去命名，去避免冲突，但有没有想过前因后果的关系？我们常常会“遇到问题”——“解决问题”，其实我们是在“制造问题”——“解决问题”。从现实情况看，也没有多少人在尝试的去打破它。

我认为，为什么要命名那么多的类，因为我们可以通过给予不同的类名去区别开来元素样式，即使有个类名叫info，我们可以起个a-info、b-info，那么它们俩就是不同的了，我们还可以.a.info、.b.info，同样能够对其进行区分，再向上追溯，我们为什么要使用类名来区分它们？最大的可能就是，我们在同一个父容器里，使用了较多同类型的子元素或者后代元素，这又是为什么呢？是不是回到了我们最初对于html标签的看法上——常用的标签不多？事实上，我们经常不加思索的使用div、p、span，一个用作大的包含块，一个用作包裹整段文字，span用来包裹行内文字，顶多再加上img、a、i等。我说的是不是很简单（然而这样还是会有人用错）。那么实际上有这么简单吗？正是因为“重视觉，轻语义”，至于我们能想起来使用的正确的，有意义的标签很少，觉得没有必要锱铢必较，那么网页中那么多的内容，难免会出现我们所说的那几个元素的重复，重复了怎么办？样式不同啊，加类，类多了怎么办？想办法区分类，于是，就是你所熟悉的那些行业问题了。

或许你会说，在大的、复杂项目里面，这些都是不可避免的，好，我同意你的说法，那如果我们能在结构和意义上做得更好，是不是能把这种情况大大改善？

其实我们的CSS选择器足够而且正在变得更加强大，我们完全没必要把希望都寄托在加类这个看起来很省劲的方法上

譬如：后代选择器、子选择器、各种伪类选择器、兄弟选择器、属性选择器等。

小结：任何做法都不要非白即黑，不偷懒，不含糊，把方法合理巧妙的结合起来才是正道！

多种场景的样式

在日常项目中，我们很少会碰到特殊的需要，一般只要这样一行代码就够了

<link href="" rel="stylesheet" type="text/css">

那么如果有特殊需要，该怎么做？可以看下下面这个表格

值 描述

screen 计算机屏幕（默认）。

tty 电传打字机以及类似的使用等宽字符网格的媒介。

tv 电视机类型设备（低分辨率、有限的滚屏能力）。

projection 放映机。

handheld 手持设备（小屏幕、有限带宽）。

print 打印预览模式/打印页面。

braille 盲人点字法反馈设备。

aural 语音合成器。

all 适用于所有设备。

找到它并不难，难的是，很多人可能不知从何处着手，没有这个意识或者概念的话，也就不会去查。了解了这些，就能根据不同场景给我们的页面分配不同的样式规则。

html5来了

必须承认一点，当我最初看到html5的时候，内心是激动的，在它出现之前，是没有足够用来表示页面结构的语义化标签供我们使用的，一般我们是用“类”或者“id”来定义它们。不过同时问题又来了，应该怎样正确的使用它们？正如以前我们面对旧版本的html时忽略了很多语义化的标签一样，如果我们不能对这些新增加的标签有正确的认识，那么我们同样会陷入泥淖，虽然看起来会比之前好些。较常用的有以下这些，你已经用起来了吗？

23c3de37f2f9ebcb477c4a90aac6fffd 外部コンテンツ (構造要素) を定義します。

15221ee8cba27fc1d7a26c47a001eb9b ページ コンテンツの外部のコンテンツを定義します。余談の内容は記事の内容と関連しています。 (構造要素)

24203f2f45e6606542ba09fd2181843a メディア コンテンツとそのタイトルのグループを定義します。 (構造要素)

2f8332c8dcfd5c7dec030a070bf652c3 ドキュメント内のセクション(セクション)を定義します。章、ヘッダー、フッター、またはドキュメントのその他の部分 (構造要素)

62ff3e22c78f6b1f7117a6ad3bb4ceb5 。 (インライン要素)

39000f942b2545a5315c57fa3276f220 ビデオを定義します。 (埋め込み要素)

5ba626b379994d53f7acf72a64f9b697 グラフィックス、描画パス、四角形、円、文字、および画像の追加方法を定義します

a38fd2622755924ad24c0fc5f0b4d412 ダイアログ (セッション) ダイアログ要素の表現を定義します数人の間で。 HTML5dt 要素は話者を表すことができ、HTML5dd 要素はスピーチの内容を表すことができます。 (構造要素)

bc7d5f386f474688566582ce82a65df0 マーク付きのテキストを定義します。テキストを強調表示する必要がある場合はタグを使用してください

c787b9a589a3ece771e842a6176cf8e9 ナビゲーション リンクを定義します

e02da388656c3265154666b7c71a8ddc メディア リソースの定義

その他のタグについては、この図を参照してください http://www.inmotionhosting.com/img/infographics/html5_cheat_sheet_tags.png

または、ここにアクセスして表示してください詳細 http://www.htmldog.com/guides/html/

注意点

構造と性能は分離されていますか?

私たちは分離の概念に触れ始めて以来、HTML にインライン スタイルや埋め込みスタイルがなければ分離を意味するという理解を持っていたかもしれませんが、実際にはそうではありません。 。その結果、タグとクラスの依存関係が真剣に考慮されなくなります。完全に分離したように見えますが、分離後は構造がうまく機能しなくなり、スタイルに注意する必要があるため、代わりにクラスを使用して区別する必要があるかもしれません。構造と性能の間に多くのものを構築する必要があるため、複雑な接続もメンテナンス上の問題の根本原因の 1 つです。すべてを CSS に任せるのではなく、CSS が行うべきことは CSS に行わせ、タグの間違いがあらゆる機会を利用する理由にならないようにしてください。

div は無害であり、table は無害です

10 年以上前、CSS が登場して普及したとき、人々は以前のページを再構築し始め、テーブル レイアウトを使用する多くのページが書き直されました。 、何を使うか？ 「div+css」、誰もがそのようなチュートリアルや本を見たことがあると思いますが、最初にそれを見たとき、divは並列関係にあるので技術だと思いましたが、今では明らかにそうではないことを誰もが知っています。それがもたらした div はページ内に頻繁に出現し始め、洪水になるほどで​​した。そして、より早く目覚めた人々のグループと html5 の概念の出現により、人々はセマンティクスとその考え方に注目し始めました。 divs を使用したのが間違いだったかのように変換が再び始まりました。実際、それが悪用されるかどうかに関係なく、より適切で合理的なものに置き換えられない限り、テクノロジーは理由があって作成され、独自のアプリケーションシナリオを持っていることを合理的に検討する必要があります。 html5で放棄されたタグなど）。それ以外の場合は、それは適切な場所にあるはずであり、特別に扱われるべきではありません。

テーブルについても同様です。大規模で複雑なレイアウトには適していないことが実際に証明されていますが、テーブル部分については上で説明したので説明しません。詳細はこちら。

クラスまたは ID?

これについては、Zhihu のこの質問に対する回答を参照してください。 https://www.zhihu.com/question/19550864/answer/23440690

懸念事項を簡単にまとめます。

1. ID の一意性、クラスの重複。対象要素の繰り返しや一意性から判断する

2. idの重みを高くする

3. 周囲はid、内部構造はclassを活用する

4. フロントエンドの使用 ID は DOM を操作し、リファクタリングはクラスを使用して DOM を操作します。UI とインタラクションは互いに独立しており、相互に影響しません。

さらに、クラスの一部の誤用も含まれます。以下は W3C からの説明です:

クラス: 作成者が class 属性で使用できるトークンに追加の制限はありませんが、作成者はその性質を説明する値を使用することが推奨されます。

意味: クラスは、コンテンツがどのように見えるかではなく、コンテンツの本質 (セマンティクス) を記述する必要があります。

この見解に従えば、「.f12、.fl、.mr10」などを多く見てきたことになると思います。

コードへのこだわりを克服するには、HTML タグの数が少ないことが必ずしも良いとは限りません。

結局のところ、コードは人が読むのではなく、ブラウザやスクリーン リーダーが読む必要があるため、単に人が見て快適に見えるようにするだけでは、当然のことながら間違った方向に進んでしまいます。不必要なタグやネストを正当化するのではなく、構造的および意味論的な観点から適切で意味のあるタグを使用して、Web ページ内で装飾する必要があるコンテンツを特定し、ブラウザーにそれについて伝える必要があります。単にビジュアル面で必要かどうかを考えるだけではありません。

選択を行う前に、包括的に理解し、長所と短所を比較検討してください

フロントエンドとして、リストされている HTML 構造などの構造または関数を実装するために利用できるソリューションが多数あることがよくあります。私たちはレイアウト スキーム、CSS 効果の実装、JS メソッド、ロジックの実装、よく言及するフレームワークやライブラリの選択などを一般的に使用します。

合理性 - セマンティクス、構造、ロジック、インタラクションなど

コスト - 学習、協力、反復、メンテナンスなど

互換性 - 複数バージョンのブラウザ、複数端末など

パフォーマンス - 送信、解析、クエリなど。

例えばアニメーションをやりたい場合、どうやってやりますか?

flash、css3、js、svg、canvas、Gif など。

それぞれの実装方法やソリューションに精通し、その長所、短所、および応用シナリオを知っている場合にのみ、自分で自由に選択しなければ、手と足が縛られてしまいます。

学習リソースの選択と基準の測定

学習リソースは非常に重要ですが、包括的ですか?これは正しいですか?これにより、テクノロジや知識ポイントに対する最初の印象が決まります。一度軌道から外れると、修正するのにどれくらい時間がかかるかわかりません。また、このコストは多くの場合不要です。

これらは Zhihu で見た 2 つの質問です。

「HTML を学びたい場合は、どこから始めればよいですか?」 https://www.zhihu com/ question/19753196

フロントエンド開発における強固な基盤の基準は何ですか? https://www.zhihu.com/question/38922374

どれが自分の状況と一致しているかを確認できます。それらは本当に権威があり、信頼できる選択肢ですか?たとえば、http://w3school.com.cn/ は多くの初心者に人気ですが、このドメイン名のため、w3c 組織に関連する権威ある公式 Web サイトであると思われますが、実際には何もありません。もちろん、それが悪いと言っているわけではありませんし、多くの人がその恩恵を受けてきましたが、これは本質的に認識上の誤りであり、実際、その内容の一部も間違っています。

さらに基準というと、人によって基準が異なりますが、ページを書けることが基準なのでしょうか？すべてのラベルを正しく使用するのが標準ですか?色々なレイアウトを上手に使いこなせるのがスタンダードなのでしょうか？いいえ、私たちは「点・線・面・体」を貫き、単一の技術でも、経験でも、総合力でも、常に一点、一方向の実績を積み上げ、埋めていきます。比較的優れているからといって、自分が高いレベルにあるというわけではありません。もしかしたら、別の分野でまだ大きな部分が欠けているかもしれないので、探求し、探求し、一生懸命働き続けてください。

忘れられたコーナー - アクセシブルなデザイン

開発者が HTML、CSS、JavaScript を使用してリッチ インターネット アプリケーションを作成する場合、障害のある人が置き去りにされることがよくあります。なぜなら、私たちのほとんどは健常者だからです。そのため、製品の使用に困難を抱えている他の人の使用法やニーズを無視することがよくあります。実際、この状況を逆転させることができます。 WAI-ARIA は、リッチ インターネット アプリケーションを理解できるようにするのに十分なセマンティクスを提供でき、現在では比較的よくサポートされています。

WAI-ARIA は、障害を持つ人々に動的でインタラクティブな Web コンテンツへのバリアフリー アクセスを提供する技術仕様です。主な目的は、障害のある人のための Web ページのアクセシビリティを向上させることであり、HTML のセマンティクスを補完するものです。既存の HTML 要素と属性よりも完全な表現機能があり、ページ内の要素の関係と意味がより明確になります。

WAI-ARIAの使い方は？

HTML に適用される ARIA は、role (役割) と、接頭辞として aria- が付いた属性の 2 つの部分で構成されます。その役割は次のとおりです。

role ( role) は要素の役割を識別します aria-attributes はそれに関連するもの (特性) とそれがどのようなものであるか (状態) を記述します

ARIA には、HTML で使用するための独自の仕様があります。 HTMLにARIAを利用することで、Webページのバリアフリー化とアクセシビリティの向上を実現します。つまり、ARIA をうまく使用しないと、別の落とし穴に陥り、ページがアクセスしにくくなるということです。

ARIA の使用法について詳しくは、1 ～ 2 文では明確に説明できない大きなトピックです。詳しく知りたい場合は、この記事 (http://www.w3cplus) を参照してください。 .com/wai -aria/wai-aria.html

Web 標準を超えて

平等な変化は質的な変化をもたらす

1. 保守性

例, 用事をするとき、2人か3人なら好きなところに並んで大丈夫ですが、それ以上になると誰かが順番を守る必要があります。別のレベルでは、人々をまとめて解放しなければならないかもしれない。そうしないと、状況は制御不能になるだろう。

ページが 1 ～ 2 行、コードが数十行または数百行の場合も同様なので、方法の違いによる違いはほとんどありません。数十ページではどうでしょうか？数千行のコードはどうなるでしょうか?

2. パフォーマンス

パフォーマンスは、コード実行効率とファイル サイズという少なくとも 2 つの側面に関連します。 1 つはコードの解析と実行速度を決定し、もう 1 つは送信速度を決定します。ここでは詳細には触れません。

3. 互換性

初期のブラウザ戦争から、比較的悲惨だったその後の低バージョンの IE まで、現在ではさまざまな解像度のモバイル デバイスとさまざまな Android および iOS バージョンのブラウザと互換性があります。 、WeChat カーネル ブラウザの互換性など。私たちはこれまでにもこれを行ってきましたし、今後もそうするつもりです。

上で述べたように、標準を満たす Web ページを作成したからといって、すべてがうまくいくというわけではありません。実際には、量が変化したときにトラブルを引き起こしたり、質的な変化を引き起こす可能性のある問題が他にもたくさんあります。ある程度。では、こうした質的変化に私たちはどう対応していくのでしょうか？この記事では詳細については説明しません。「Web 適応方法」については、後ほど別の記事で説明します。

また次回お会いしましょう! ~