俺流レスポンシブコーディング
俺流レスポンシブコーディングの覚書。「人には人のレスポンシブ」があるのでこれが正解だってわけではないのですが、レスポンシブコーディングで悩んでいる人にとって参考になる記事になってくれたら嬉しいです。 ブレイクポイントは特定のデバイスの画面サイズを基準にしない 以前アンケートを取った時にデバイスのサイズを意識して決める人が半数以上を占めていた。 アンケート結果を抜きにしても「2021 年のブレイクポイント決定版はこれだ！」的な記事がバズっているのを定期的に目撃し、主流のデバイスのサイズを比較するアプローチがほとんどであるが、僕はデバイスの端末のサイズを基準にブレイクポイントを決めることには否定的である。 主流のデバイスのサイズなんてものは時間が経てば変化する。 昨年 iPhone 12 が発表された時に従来の画面サイズとは違うバリエーションになることが分かるやいなやタイムラインが慌てふためい
「SEOに強いHTMLの書き方」についての個人的な見解
「SEO に強い HTML の書き方」というツイートがそこそこバズっていて、その内容に対して駆け出しエンジニアの方たちが「参考になった」などと称賛の声を挙げていたのを見かけて思うところがあったのでこの記事を書きました。 元ツイの概要は次の通り。 body > main > article > sectionに h1は 1 ページに 1 つ（要キーワード） 見出しタグは毎度 section で囲む ヘッダーメニューは nav で囲む 画像に適切な alt を設定する title / description を書く 階層を意識して書く div はあまり使わない 画像は p で囲む この記事は元ツイおよび元ツイの投稿者を批判する意図で書いたものではなく、あくまで挙げられている内容に対する個人的見解をまとめたものです。 正しいか正しくないかをそれぞれの項目のはじめに書いていますが、あくまで僕個人の
キーボード操作を意識したHTML/CSSコーディング
この記事は 「Webアクセシビリティ Advent Calendar 2020」 5日目の記事です。 アクセシビリティ Advent Calenderの記事を寄稿するにあたり、少しの工夫であらゆるユーザーに対して優しいWebサイトを作れるようなHTML/CSSコーディングの方法についてまとめました。より多くの人にとって優しい・使いやすいWebサイトを作ることは訪れてくださるユーザーの方々だけでなく、クライアントにとってもユーザーの機会損失を防ぐことができるので多大なるメリットがあります。（よくコードが適当でもデザインが見えていれば良いって意見を聞くけれどそんなことはない） ただ、アクセシビリティを意識したHTML/CSSコーディングについてのまとめだと内容量が非常に多くなりZennなら記事より本で出したほうがベターになってしまうので、今回は数あるアクセシビリティの視点から「キーボード操作で
実装者が作業前にデザイナーへ確認しておくとよいこと
TAK(@tak_dcxi)です。 コーダーやフロントエンドエンジニア（以下実装者と呼ぶ）が作業に取り掛かる前に事前にデザイナーに確認しておくとよいことを独断と偏見でまとめました。過去に面倒臭がって聞くのを放棄して失敗した経験もあるので、自戒の念も込めています。 デザインの共通ルールを確認する 余白のサイズやフォントサイズや使用している色などはルール決めがされているとは思いますが、デザインのルールを実装時に分かりやすくしておくことで効率的かつ保守性や拡張性に強いコードが書きやすくなります。 逆に実装時にルールが分からないと、実装者がデザインカンプを見てもそのルールを理解するのに時間がかかってしまうことも多いです。余白であれば感覚で配置されてるのか、似たような箇所で17pxであったり23pxであったり…と意図が分かりかねる場合もあります。余白は原則8の倍数で行うみたいなルールが事前に実装者に
デザイナーとフロントエンドエンジニアに知ってほしいWebのフォント周りのお話
こんにちは。TAK(@tak_dcxi)です。 今回記事にするのはタイトル通り「デザイナーとフロントエンドエンジニアに知ってほしいWebのフォント周り」についてです。以前ツイートしましたが、特に説明もなかったので自分の備忘録も兼ねて。 Androidに明朝体は無い Apple製品しか利用しないデザイナーの方に話したら非常に驚かれるのですが、Androidにはデフォルトで明朝体は入っていないです。 よく明朝体マシマシのデザインを見かけたりするのですが、デバイスフォントだけではAndroidでそのデザインを実現することは不可能だと思っておいたほうが良いでしょう。 ただ、明朝体のWebフォントを利用すればAndroidでも明朝体は表示できるので、デザイン的に明朝体が必須って場合はWebフォントを利用しない手は無いと思います。 個人的見解ですが、デザイン重視なら明朝体はGoogle FontsでN
iPhone 12系統のレスポンシブ対応のメモ書き
今朝発表された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
iOSでも100vhをいい具合に調整して画面の高さいっぱいに要素を表示させる
TAK(@tak_dcxi)です。今回もCSSに関する投稿です。 以前このようなツイートをしました。 メインビジュアルなど、画面いっぱいに要素を表示するためにheightやmin-heightに100vhを指定する。そして、iOSで表示確認した時に以下のような問題が起こるわけです…。 iOSのSafariでの100vhが気に食わない問題 iOSのSafariでは100vhの計算にアドレスバーが考慮されていないため、アドレスバー分押し出されて格好悪く表示されます。ちなみにiOSのGoogle Chromeは中身SafariなのであれもSafariです。 この問題に立ち向かうために、実装者はJavaScriptを利用して高さを指定したり、height: 100%;のバケツリレーを行ってアドレスバーまで考慮した画面いっぱいの表示を実現するために頑張ってきたわけです。 そんな中、先程のツイートから
CSS設計において特に大切にしている思想をまとめてみた
Zennの投稿は初です。TAK(@tak_dcxi)です。 今回投稿するのは自分なりのCSS設計のメモ。ある程度の規模感のサイトでのCSS設計において、僕がいくつか大切にしている思想の中から特に重要だと思っているものをピックアップしてまとめてみた。 「ある程度の規模感」とは以下のようなイメージ。 テンプレートの数（※サイトのページ総数ではない）が10枚以上 ローンチ後もPDCAが定期的に行われ、その都度サイトの更新や改修が行われるようなWebサイト サイトの更新や改修は自分以外のスキルを定義しないコーダーやエンジニアによって行われる 最後の「スキルを定義しないコーダーやエンジニアによって更新や改修が行われる」というのがポイントで、つまりスキルに大きな幅がある、とりわけ未経験入社の方のようなマークアップの知識が乏しい方が更新する可能性があることを前提としている。場合によっては急遽量産で知識の
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
