セマンティックな要素の再考
この考えが生まれたのは、インスタント記事
のHTML構造を見たことによるものです。彼らはインスタント記事の構造が彼らの規格に準拠していなければならないと規定しており、その構造の表現も非常に明確です。私はそこで、以前気づかなかった多くのHTMLタグを見つけました。たとえば、address
、figure
、caption
、summary
などです。
好奇心から、ドキュメントなどを調べてみました。実際に、現在の主要なブラウザは、多くのセマンティックなタグをサポートしており、仕様も非常に明確に記述されています。しかし、現在のメインサイトではまだdiv + class
の方法で表現されているところが多く、一部の場所ではheader
を使用しているかもしれませんが、私はより適切なセマンティックなタグを使用することができると考えています。不要なclass名を減らすだけでなく、HTMLの可読性とSEOも向上させることができます。重要なのは、私たちが書いているのは標準に準拠したHTMLです。
また、W3CはHTML5でセマンティックなタグを推進しており、nav
、header
、dd
、dt
などのタグを推奨しています。また、b
、font
、center
などの意味のないタグは削除または非推奨としています。
セマンティックな要素を使用する最大の利点はアクセシビリティです。ほとんどのスクリーンリーダーは特定のタグに最適化されており、たとえば<a>
はハイパーリンクとして読み上げられ、li
は現在のリストと項目番号を読み上げ、<main>
は主要なコンテンツを読み上げます。これらはすべてセマンティックなタグの利点です。
ただし、UIの使用シナリオはさまざまであり、既存のタグだけで処理できるわけではありません。タブの切り替え、ダイアログ、ドロップダウンメニュー、ツールチップなどは、セマンティックなタグでは解決できないものです。この場合、aria-*
とrole
という2つの属性を使用して、スクリーンリーダーに要素の目的を伝えることができます。
クラスについての考察
長い間クラスを使用してきましたが、仕様を見返してみると、W3Cがクラスについて説明していることに気づきました。
クラス属性で使用できるトークンには制限はありませんが、コンテンツの表示方法を説明するのではなく、コンテンツの性質を説明する値を使用することが推奨されています。 -W3C
クラスには使用上の制限はありませんが、コンテンツの性質を説明するためにクラスを使用することが推奨されています。つまり、col-md-*
などの表現的なクラス名は、W3Cの仕様では推奨されていないということです。ただし、このような言い方をすると、すべてのCSS-in-JSの方法をやり直さなければならなくなります。CSSモジュールはすべてのクラスをハッシュ化し、styled-component
も同様です。ハッシュを使用することの利点は、名前の衝突を回避できることと、本番ビルド時に最小化できることです。HTMLの要素が多い場合、サイズの削減効果は非常に大きいです。
なぜ標準に準拠する必要があるのか?
- 標準仕様は委員会によって研究され、多くの議論の末に策定されたものであり、統一性を実現するために皆が従うべきものです。
- ブラウザは通常、これらの要素をさまざまなデバイスで最適化しています。
- 通常、これらの仕様はベストプラクティスです。
- 開発時間を節約するために標準に準拠しないウェブページを作成することは本末転倒です。
<!-- 表現 -->
<div class="margin-b-10">
</div>
<!-- 内容 -->
<div class="user_info">
</div>
私の理解はこれです。
なぜこのような状況になったのか、おそらくウェブの初期段階ではCSSのサポートが良くなかったため、セマンティックと表現のバランスを取るのが難しかったため、当時の純粋なスタイルのcenter
、width
などが登場したのかもしれません。しかし、今はもうその時代ではありません。私たちはセマンティックな時代に向かって進むべきであり、それがW3Cが推進していることでもあります。
グリッドシステムは素晴らしいものです!
確かに、グリッドシステムは非常に便利なパターンです。実際のシナリオでは、レイアウトをセマンティックに表現することができない場合があります。しかし、セマンティックな定義に従って、より見栄えの良いHTMLと読みやすさを実現するために、いつかはグリッドシステムを取り除く必要があるかもしれません。これは大きなプロジェクトになるかもしれませんが、現在のメインサイトの構造では、早く始めるほど良いでしょう!
- Susyを使用する
- @include @extend
ページの可視性API
現在のユーザーがこのページにフォーカスしているかどうかを知ることができます。多くの場面では、ユーザーがこのウェブページにフォーカスしていない(他のアプリに移動したり、タブを切り替えたりする場合など)場合に、不要なリクエストや操作を最小限に抑えたいと思うことがあります。Facebookも、ウェブページに戻ったときにのみ通知音を鳴らすようです。よくあるシナリオは、ビデオ再生時です。ユーザーがページを離れると、ビデオを自動停止し、ユーザーが戻ってきたら再生を再開します。
JavaScriptのイベント伝播を振り返る
最近、JavaScriptの本を取り出して読み返しました。主に、以前は理解していなかった概念を明確にするためです。インターネット上には多くのJavaScriptライブラリがありますが、私たちはすでにネイティブのJavaScriptを忘れてしまったのでしょうか?高度な抽象化は、技術の発展後に必ず起こる現象ですが、内部の動作を理解することも重要であり、将来のコーディングに対する理解も深まるでしょう!
JavaScriptのイベント伝播
JavaScriptのイベント伝播には、バブリング
とキャプチャ
の2つの主要なタイプがありますが、ほとんどの伝播はバブリング
を使用して行われます。では、バブリング
とは何でしょうか?要素のイベントハンドラが呼び出された後、イベントは上に浮上し(特定の要素の特定のイベントを除く)、祖父要素に登録されたハンドラが呼び出されます。この現象はdocument
まで上昇し、最終的にwindow
に到達します。
実際のアプリケーションでは、次のようなことがよくあります:
$(".abc").on('click', e => {
});
$(".ass").on('click', e => {
});
$(".asass").on('click', e => {
});
イベントの散在した登録が角に追いやられており、メンテナンスが困難であり、コードの検索が統一されたエントリーポイントがないため、デバッグが非常に困難です。そこで、イベントのバブリング特性を利用して、ドキュメントにイベントを統一的に登録することができます。jQueryのon
メソッドの2番目の引数は、イベントデリゲートの機能を提供しています。以下のようになります:
$('document').on('click','.sass', e => {
});
これにより、散在したイベントの登録が減少し、エントリーポイントが統一されます。新しいイベントを追加する場合は、ドキュメントで拡張するだけです。また、HTMLでは次のように書くこともできます:
<a class="js_action" data-action="foo">
<a class="js_action" data-action="bar">
var actionList = {
foo: function(),
bar: function()
}
$('document').on('click','.js_action', e => {
if(typeof e.target.dataset.action === 'function'){
actionList[e.target.dataset.action]
}
})
このようにすると、後でイベントを追加する場合は、actionListに追加するだけで済みます。actionListに書かなくても、extendの方法と組み合わせることもできます。拡張性が非常に高まります。
では、なぜキャプチャを使用する人が少ないのでしょうか?最大の理由は、可愛らしいIEがサポートされていないためです。また、イベントキャプチャはaddEventListenerの方法にのみ適用されます。 イベントキャプチャは、逆に動作するようなもので、イベントが始まりますが、イベントの親要素のイベントハンドラが呼び出されるまで、イベントは祖父から順に下に向かって伝播します。イベント要素に登録されたイベントハンドラは常に呼び出されません。
イベントのキャンセル
私たちはしばしばe.preventDefault()
のようなメソッドを見ます。実際、古いバージョンのブラウザではサポートされていない場合がありますので、キャンセルするためにはいくつかのトリッキーな方法を使用することができます。
function cancelDefault(event) {
var event = event || window.event;
if(event.preventDefault) event.preventDefault()
if(event.returnValue) event.returnValue = false
return false
}