dl や ul で組むべきでないという主張ではありませんので誤解のなきよう！ dl で書くんだ！と思える人はそれがいいと思います😉👍 私自身は dl と table が HTML の使い方としてはどちらも正解で差がないように感じられて、どちらを使うべきか判断がつかず悩んだ末、具体的なメリットの部分を見て table にしたという話です。 同じように迷った人の参考になれば幸いです。 詳しくは以降で説明します。 想定する表の内容 この記事の議論では、名前と値の組が複数並んでいる、メタデータの表を想定します。 プログラミング言語でいうところの、連想配列 (Map, Dictionary, JS では Object) の構造に相当します。 具体的には以下のようなものです。 会社概要（「会社名：〇〇、所在地：〇〇、資本金：〇〇、…」） 商品の仕様表（「商品名：〇〇、価格：〇〇、サイズ：〇〇、…」

inline-block を使う理由、それは 入れ子構造を作れることにより、改行位置の優先順位をつけられるから！ 詳しくは以降で説明します。 （前提）そもそも改行調整ってなんの話？ このタイトルを見て記事を開いた方であれば知っていると思いますが、一応説明です。 スペースで単語が区切られる欧文とは違い、日本語は単語の区切りがないので、改行すべき位置を機械的に判断できず、不自然な位置で改行されてしまうことがあります。そこで、見た目を整えるため、改行すべき位置を指定するための手法が必要になります。 他に詳しい記事がいくつもありますので、詳細はそちらを参照してください。 代表的な改行調整の手法 <wbr> 要素 <wbr>要素は、改行してよい位置を表す要素です。 親要素に対して word-break: keep-all; を指定して基本的には改行されないようにすることで、<wbr>要素がある位置で

TypeScript を学習中の方に勧められる練習問題集として手頃なものがないなと思い、作ってみました。 TS の問題集としてはtype-challenges がよく話題に上がりますが、実用上あそこまでの型パズルを使うことはあまりないため、最初に取り組むにはハードルが高いです（もちろん知っていたら便利ではありますが、初学者向けではない）。 想定読者 JavaScript を書くことには慣れている TypeScript はこれから・まだ慣れていない TypeScript の基本的な型についてはすでに知っている はじめに JavaScript の機能に関する問題は扱いません。TypeScript の型システムに関する問題のみ扱います。 そもそも TypeScript についてよくわかっていない場合、サバイバル TypeScriptなどで学習から始めてみてください。 「型がつけられると何が嬉しい

「strongもbも太字になるのにどう違うんだ…？」 「emもiもイタリック体になるけど、そもそもイタリック体ってなんなんだよ…？」 「strongの重要と、emの強調って何が違うんだ…？」 などなど、使い方がよくわからなくなりがちな HTML 要素（主にテキストレベルセマンティックスに分類される要素）の違いを調べてみました。 長めの記事になっていますので、気になる要素だけつまみ食いしてもらうのもよいかと思います。 今回の調査対象はこちら span strong b em i dfn cite var mark u ins del s strike big small ブラウザのデフォルトの見た目確認用 CodePen 調査する内容 HTML Standard の仕様に書かれている説明 一部、HTML 4.01 から HTML 5 での変更が理解の助けになるものもあり、HTML 4.01

はじめに結論から ホバースタイルは、 :hover だけで指定するのではなく、次のように指定しましょう！ @media (hover: hover) { /* リンクの場合 */ a:any-link:hover { } /* ボタンの場合 */ button:enabled:hover { } /* 特定できない場合 */ .button:where(:any-link, :enabled, summary):hover { } } ポイント 1 マウスのときだけホバースタイルを当てる :hover 擬似クラスで指定したスタイルは、タッチデバイスの場合フォーカス状態で適用されてしまいます。 つまり、タッチしたあとのスタイルがずっとホバースタイルのままになってしまいます。 これは意図と合わないため、マウスで操作しているかどうかを区別してスタイルを当てる必要があります。 マウス（正確には、ホ

ウェブアクセシビリティを実践する際、基準となるのがWCAG（Web Content Accessibility Guidelines、ウェブコンテンツアクセシビリティガイドライン）です。しかし、WCAGの文章は難しい！ なので、簡単な言葉に読み替えながら理解しましょう！

HTMLファイルで特殊記号を使う際、① は &#9312;、© は &copy; のように置き換えて書かないといけないものだと思いこんでいないでしょうか。 現代ではそれは誤解です。 UTF-8では特殊記号の文字参照は不要 そもそも環境依存文字とは、データを扱う機種・ソフトウェアなどの違い（文字コードの割り当ての違い）により表示に違いが出てしまう文字のことでした。 例えばShift_JISには © が含まれておらずそもそも保存できなかったり、 ① などの丸数字は含まれているものの、WindowsとMac OS（当時）の割り当ての違いにより正しく表示できなかったりしました。[1] しかし現在ではUnicodeによって文字コードは統一化されており、その問題はほとんど起きなくなっています。 近年では多くの場合 UTF-8 でファイルを記述すると思います。 HTMLファイルの文字エンコーディングが

Webエンジニアを始めて丸2年が経ちました。 複数プロジェクトを進める中で、CSSコーディングを行うときの「こうしておくと便利」「このほうが管理しやすい」といった知見が溜まってきたのでまとめます。 はじめに 長くなってしまった細かい説明はところどころ折りたたんでいます。概要だけで理解できたら飛ばしていただき、詳しい話が気になったら開いて読んでください。 これらは「自分がよく取り入れている手法」であって、必ずしもどのプロジェクトにも当てはまるものではないと思います。 各項目について、自分がその判断に至った 「理由」 を説明していますので、 理由を読んだ上で自分のプロジェクトに取り入れるか判断いただくと良いと思います。 この記事は、すでにCSSコーディングをしていてアイデアがほしい人に向けた記事で、 CSSをこれから学び始めるような 初学者向けではない ことご了承ください。 一般的と思われるキ