急激な変化の下でのフロントエンド思考

セマンティックを再考する

このアイデアは、instant article の HTML 構造を見ることで生まれました。彼らは instant article の構造が規定に準拠することを必須としており、その構造の表現も非常に明確です。その中で、私がこれまで気にしていなかった多くの 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 という属性を参照して、リーダーにこの要素が何をしているかを伝えることができます。

class に対する考察

セマンティックな CSS

長い間使ってきた class について、規定を調べてみたところ、W3C が class に関する記述を見つけました。

There are no additional restrictions on the tokens authors can use in the class attribute, but authors are encouraged to use values that describe the nature of the content, rather than values that describe the desired presentation of the content. -w3c

class の使用に関する明確な規定はないものの、できるだけ内容を表現するために class を使用することが推奨されています。つまり、col-md-* といった表現に特化した class 名は W3C の仕様では推奨されていません。しかし、こういったことを考慮すると、ほぼすべての CSS-in-JS の書き方を見直さなければならないかもしれません。css-module は class をすべてハッシュ化し、styled-component も同様です。ハッシュを使用する利点は、命名の衝突を避けられることや、プロダクションビルド時に最小化できることです。HTML に多くの要素が存在する場合に、節約できるサイズは驚くべきものです。

なぜ標準に準拠する必要があるのか？

1. 標準規範は委員会による研究や多くの議論を経て定められたもので、統一性を達成するために遵守することが求められます。
2. ブラウザは通常、異なるデバイス上でのこれらの要素の表示を最適化しています。
3. 通常、これらの規範はベストプラクティスです。
4. 開発時間を節約するために標準に準拠しないウェブページを書くことは本末転倒ではないでしょうか？

<!-- 要素の表示 -->
<div class="margin-b-10">

</div>

<!-- コンテンツ -->
<div class="user_info">

</div>

私の理解はこうです。

なぜこのような問題が発生するのかというと、ウェブの発展初期には CSS のサポートが不十分で、セマンティックと表現のバランスを取るのが難しかったため、当時は純粋なスタイルの center や width が登場したのかもしれません。しかし、今はそのような制約のある時代ではありません。私たちはセマンティックな時代に向かって進むべきですし、これは W3C が推進していることでもあります。

グリッドシステムは素晴らしいものです！

私はグリッドシステムが非常に便利なモデルであることを認めます。実際のシーンでも、レイアウトをセマンティックに表現できない問題に直面することがありますが、セマンティックの定義に基づくと、より美しい HTML と可読性を達成するために、いつかグリッドシステムを取り除く必要があるかもしれません。これは大きなプロジェクトになるでしょうが、現在の主要なサイトの構造においては、早く始める方が良いのではないでしょうか。

• Susy を使用
• @include @extend

Page Visibility API

現在のユーザーがこのページにフォーカスを当てているかどうかを知ることができます。 多くの状況で、ユーザーがこのウェブページにフォーカスを当てていない（他のアプリケーションに切り替えたり、タブを切り替えたり）場合には、不要なリクエストや操作を極力減らしたいと考えています。Facebook では、ユーザーがウェブページに戻ったときにのみ通知音が鳴るようです。 一般的なシナリオは、動画を再生しているときです。ユーザーがページを離れた場合、自動的に動画を停止し、ユーザーが戻ったときに再生を再開することができます。

JS のイベント伝播を振り返る

最近、リファレンスとしてリハウス書を引っ張り出してきました。主に以前あまり理解していなかった概念を明確にするためです。ネット上には多くの JS ライブラリが溢れていますが、私たちはすでにネイティブな JS を忘れてしまったのでしょうか？高度な抽象化は技術の発展に伴って必然的に起こる現象ですが、内部の動作を理解することは重要です。これは今後のコードを書く際にも参考になります。

JS のイベント伝播

JS のイベント伝播は主に二つのタイプに分けられます：bubble と capture です。ほとんどの伝播方法は bubble を使用します。bubble とは何でしょうか？オブジェクト要素のイベントハンドラーが呼び出された後、イベントは上に浮かび上がり（特定の要素のイベントを除く）、次に祖父要素に登録されたハンドラーが呼び出されます。この現象は document にまで上昇し、最終的には window に達します。

実際のアプリケーションでよく見かけるのは：

$(".abc").on('click', e => {
	
});

$(".ass").on('click', e => {
	
});

$(".asass").on('click', e => {
	
});

散発的なイベント登録が隅に散らばると、メンテナンスが難しく、コードを探す際にも統一されたエントリーポイントがなく、デバッグが非常に困難になります。したがって、JS のイベントのバブル特性を利用して、ドキュメント全体でイベントを統一的に登録できます。jQuery の on の第二引数はイベント委譲の機能を提供します。以下のように：

$('document').on('click','.sass', e => {
 
});

これにより、散発的なイベント登録が減少し、エントリーが統一されます。新しいイベントを追加する場合は、ドキュメント全体で統一的に拡張するだけで済みます。HTML ではこのように書くこともできます：

	<a class="js_action" data-action="foo"></a>
	<a class="js_action" data-action="bar"></a>

  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 に追加するだけで済みます。extend の方法と組み合わせれば、actionList に書かなくても大丈夫です。これにより、拡張性が大幅に向上します。

では、なぜ capture を使う人が少ないのでしょうか？最大の理由は、愛すべき 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
}