はてなブックマーク

「SEO に強い HTML の書き方」というツイートがそこそこバズっていて、その内容に対して駆け出しエンジニアの方たちが「参考になった」などと称賛の声を挙げていたのを見かけて思うところがあったのでこの記事を書きました。 元ツイの概要は次の通り。 body > main > article > sectionに h1は 1 ページに 1 つ（要キーワード） 見出しタグは毎度 section で囲む ヘッダーメニューは nav で囲む 画像に適切な alt を設定する title / description を書く 階層を意識して書く div はあまり使わない 画像は p で囲む この記事は元ツイおよび元ツイの投稿者を批判する意図で書いたものではなく、あくまで挙げられている内容に対する個人的見解をまとめたものです。 正しいか正しくないかをそれぞれの項目のはじめに書いていますが、あくまで僕個人の

TAK(@tak_dcxi)です。 モーダルやドロワーメニューを開いている時に背面コンテンツが勝手にスクロールされるとヘイトポイント溜まりがちなので、ユーザビリティ向上のためにも背面コンテンツのスクロールは抑制しておきましょう。 結論 // ドキュメントの書字方向を取得し、縦書きかどうかを判定 const isVerticalWritingMode = (): boolean => { const writingMode = window.getComputedStyle(document.documentElement).writingMode return writingMode.includes('vertical') } // スクロールバーの幅を計算する const getScrollBarSize = (): number => { const scrollBarXSize =

こんにちは。TAK(@tak_dcxi)です。 2020年最後のZennの投稿ということで、Web制作テンプレートの年末大掃除も兼ねて僕がよく使うSassのmixinとfunctionを厳選してまとめてみました。 Sassを使っている方でmixinとかfunctionをあまり利用してないという方は参考にしてみてください。 ブレークポイントの指定 おそらくmixinで最も利用されているのはレスポンシブでのブレークポイントの指定だと思います。 $breakpoints: ( 'xs': (min-width: 0), 'sm': (min-width: 576px), 'md': (min-width: 768px), 'lg': (min-width: 992px), 'xl': (min-width: 1200px), 'xxl': (min-width: 1400px) ) !defau

こんにちは。TAK(@tak_dcxi)です。 今回は SNS で頻繁に話題になる「font-size の指定はpxとremどちらを使うべきか？」問題について。 自分が観測している限りだと、 font-size の指定は px と rem どちらを使うべきか？ Web デザイナーはコーディングの知識があったほうがいいか？ jQuery はオワコンなのか？ 実装者はピクセルパーフェクトに拘らないとダメか？ h1 タグはどこに使うべきか？ あたりは四半期に一度は話題になっている感覚がありますね。 おそらくこの記事を読んでいる方や、もしくはタイムラインにこの記事の Twitter カードなんかが流れてきてウンザリしている方も多いことでしょう。僕も正直「またこの話題か…」という感想ですが、頻繁に話題になるということはそれだけ意見が割れているということなので、自分なりの見解をまとめるためにもこの記事

この記事は 「Webアクセシビリティ Advent Calendar 2020」 10日目の記事です。（執筆が終わったのが11日目になってしまい申し訳ございません） 先日投稿したWebアクセシビリティ Advent Calendarの記事「キーボード操作を意識したHTML/CSSコーディング」は思いがけず大変な反響をいただきました。ありがとうございます。 今回はWeb制作において頻出度の高いアコーディオンをアクセシビリティを意識しながら作ってみたという「やってみた」系記事です。 今回の記事を書くにあたり、そめさんよりいくつかレビューを頂きました（ありがとうございます）。今回はそのレビューも含めて修正前と修正後も同時掲載します。 はじめに はじめに今回のアコーディオンのサンプルを掲載します。（サンプルではaria属性の付与はJSで行っています） この記事を書いた理由は WAI-ARIAの知識

この記事は 「Webアクセシビリティ Advent Calendar 2020」 5日目の記事です。 アクセシビリティ Advent Calenderの記事を寄稿するにあたり、少しの工夫であらゆるユーザーに対して優しいWebサイトを作れるようなHTML/CSSコーディングの方法についてまとめました。より多くの人にとって優しい・使いやすいWebサイトを作ることは訪れてくださるユーザーの方々だけでなく、クライアントにとってもユーザーの機会損失を防ぐことができるので多大なるメリットがあります。（よくコードが適当でもデザインが見えていれば良いって意見を聞くけれどそんなことはない） ただ、アクセシビリティを意識したHTML/CSSコーディングについてのまとめだと内容量が非常に多くなりZennなら記事より本で出したほうがベターになってしまうので、今回は数あるアクセシビリティの視点から「キーボード操作で

TAK(@tak_dcxi)です。 コーダーやフロントエンドエンジニア（以下実装者と呼ぶ）が作業に取り掛かる前に事前にデザイナーに確認しておくとよいことを独断と偏見でまとめました。過去に面倒臭がって聞くのを放棄して失敗した経験もあるので、自戒の念も込めています。 デザインの共通ルールを確認する 余白のサイズやフォントサイズや使用している色などはルール決めがされているとは思いますが、デザインのルールを実装時に分かりやすくしておくことで効率的かつ保守性や拡張性に強いコードが書きやすくなります。 逆に実装時にルールが分からないと、実装者がデザインカンプを見てもそのルールを理解するのに時間がかかってしまうことも多いです。余白であれば感覚で配置されてるのか、似たような箇所で17pxであったり23pxであったり…と意図が分かりかねる場合もあります。余白は原則8の倍数で行うみたいなルールが事前に実装者に

TAK(@tak_dcxi)です。今回はTwitterでちょくちょく話題になるBootstrapについて。 Bootstrapは非常に便利なフレームワークで、使いようによっては極めて高いコストパフォーマンスを発揮できるツールなのですが、適材適所という言葉があるように明らかにBootstrap向きではない案件でBootstrapを使ってコストパフォーマンスを高めるどころか運用コストを高めているような現場を何度か見てきました。 今回はBootstrapが適する案件と適さない案件について、またBootstrapを利用する上で気をつけたいことなど、個人的に思うことを纏めていこうかと。 Bootstrapが向いている案件と向いていない案件 いきなり結論ですが、僕が思うBootstrapが向いている案件・向いていない案件は以下のとおりです。 Bootstrapが向いている案件 開発にかけられる時間が極

こんにちは。TAK(@tak_dcxi)です。 今回記事にするのはタイトル通り「デザイナーとフロントエンドエンジニアに知ってほしいWebのフォント周り」についてです。以前ツイートしましたが、特に説明もなかったので自分の備忘録も兼ねて。 Androidに明朝体は無い Apple製品しか利用しないデザイナーの方に話したら非常に驚かれるのですが、Androidにはデフォルトで明朝体は入っていないです。 よく明朝体マシマシのデザインを見かけたりするのですが、デバイスフォントだけではAndroidでそのデザインを実現することは不可能だと思っておいたほうが良いでしょう。 ただ、明朝体のWebフォントを利用すればAndroidでも明朝体は表示できるので、デザイン的に明朝体が必須って場合はWebフォントを利用しない手は無いと思います。 個人的見解ですが、デザイン重視なら明朝体はGoogle FontsでN

今朝発表されたiPhone 12系統のレスポンシブ対応についてのメモ書き。取り急ぎ。 12 Pro Max 👉 428px (3x) PlusシリーズやXR,11,11 Maxの414pxよりも14px広い。 12 / 12 Pro 👉 390px (3x) 6〜8、Xや11 Proの375pxよりも15px広い。 12 mini 👉 360px (3x) ただし、miniの場合は375pxで描写してスケーリング表示するらしい？ とは言え、Androidのデバイスの多くは360pxなのでiPhone 12 miniの描写サイズが375pxだろうが360pxだろうが関係なかったりします。 横幅360pxでしっかり表示されていることは必須条件です。 追記1：これからも4インチ(320px)を意識する必要はあるのか？ 個人的見解ですが、あります。 理由としてはiPadのSlide Over

TAK(@tak_dcxi)です。今回もCSSに関する投稿です。 以前このようなツイートをしました。 メインビジュアルなど、画面いっぱいに要素を表示するためにheightやmin-heightに100vhを指定する。そして、iOSで表示確認した時に以下のような問題が起こるわけです…。 iOSのSafariでの100vhが気に食わない問題 iOSのSafariでは100vhの計算にアドレスバーが考慮されていないため、アドレスバー分押し出されて格好悪く表示されます。ちなみにiOSのGoogle Chromeは中身SafariなのであれもSafariです。 この問題に立ち向かうために、実装者はJavaScriptを利用して高さを指定したり、height: 100%;のバケツリレーを行ってアドレスバーまで考慮した画面いっぱいの表示を実現するために頑張ってきたわけです。 そんな中、先程のツイートから

TAK(@tak_dcxi)です。今回もCSS設計に関する投稿です。 皆様はWebサイトの運用でCSSを更新・改修する際に、既存のスタイルが上書きできなくて苦しんだことはありませんか？ class名のタイポミスだったり、そもそも指定したセレクタに対応する要素が無い…といった凡ミスも原因だったりはしますが、大抵の場合他のスタイル指定が強くて上書きできない、つまり「詳細度」が影響していることが多いです。 CSSを破綻させる原因の一つの「詳細度」とは？ MDNの説明を引用すると以下の通り。 詳細度は、どの CSS プロパティが要素に最も関係があるか、すなわち適用されるかをブラウザーが決定する手段です。詳細度は様々な組み合わせの CSS セレクターで構成される一致規則に基づいています。 CSSのスタイル指定が競合した時に優先される、セレクタが生まれながらに持つ「強さ」みたいなものです。 全称セレク

Zennの投稿は初です。TAK(@tak_dcxi)です。 今回投稿するのは自分なりのCSS設計のメモ。ある程度の規模感のサイトでのCSS設計において、僕がいくつか大切にしている思想の中から特に重要だと思っているものをピックアップしてまとめてみた。 「ある程度の規模感」とは以下のようなイメージ。 テンプレートの数（※サイトのページ総数ではない）が10枚以上 ローンチ後もPDCAが定期的に行われ、その都度サイトの更新や改修が行われるようなWebサイト サイトの更新や改修は自分以外のスキルを定義しないコーダーやエンジニアによって行われる 最後の「スキルを定義しないコーダーやエンジニアによって更新や改修が行われる」というのがポイントで、つまりスキルに大きな幅がある、とりわけ未経験入社の方のようなマークアップの知識が乏しい方が更新する可能性があることを前提としている。場合によっては急遽量産で知識の