CSSのメディアクエリでcalc()が使用できるのを知ってましたか? これは6/6,7に開催されたCSS Day 2024で共有されたときに、多くのビジターが驚いたとのことで、私も知りませんでした。 メディアクエリは比較...記事の続きを読む
![CSSのメディアクエリでcalc()が使用できるの知ってた?](https://cdn-ak-scissors.b.st-hatena.com/image/square/96a8d370b1fafc8e9d1e6f74f2f78bed48bbde59/height=288;version=1;width=512/https%3A%2F%2Fcoliss.com%2Fwp-content%2Fuploads-202402%2F2024060901%402x.png)
俺流レスポンシブコーディングの覚書。「人には人のレスポンシブ」があるのでこれが正解だってわけではないのですが、レスポンシブコーディングで悩んでいる人にとって参考になる記事になってくれたら嬉しいです。 ブレイクポイントは特定のデバイスの画面サイズを基準にしない 以前アンケートを取った時にデバイスのサイズを意識して決める人が半数以上を占めていた。 アンケート結果を抜きにしても「2021 年のブレイクポイント決定版はこれだ!」的な記事がバズっているのを定期的に目撃し、主流のデバイスのサイズを比較するアプローチがほとんどであるが、僕はデバイスの端末のサイズを基準にブレイクポイントを決めることには否定的である。 主流のデバイスのサイズなんてものは時間が経てば変化する。 昨年 iPhone 12 が発表された時に従来の画面サイズとは違うバリエーションになることが分かるやいなやタイムラインが慌てふためい
21 日目の記事です。 DevToolsおれおれAdvent Calendar 2020やります。ひとりで。 Chrome DevTools を使ってクライアント側に限らずサーバー側もデバッグできるんですが、それはそれとして開発中はエディターで開いたソースコードと行ったり来たりするのが面倒です。 VS Code なら Chrome DevTools (の機能)と連携して、エディター内でブレイクポイントを設置するなどできます。ちなみに DevTools の画面は今回出てきません。 先にまとめ サーバー側もクライアント側も VS Code からデバッグできる ブレイクポイントの設置 変数の閲覧 ログ出力 Run パネルからデバッグ設定を作成、デバッグ実行 Next.js などビルドを行うものも、ファイル出力できれば デモプロジェクト よければこちらご利用ください。JavaScript と No
※前回の2020年12月からベゼルレスのiPad mini6(8.3インチ)が出たので更新しています。 記事の詳細の内容はiPad mini6が入っていない内容です。 MacBookもM1チップでProじゃなくてAirで十分みたいになっていて、大きさやスペックが大きければいいみたいな時代は終わって、自分に合ったものを選ぶ人がより増えてきたように感じています。 前回が2019年5月にレスポンシブデザインのブレイクポイントの記事を書いて、今でもたくさんのアクセスがあり、たいへん嬉しく思っています。 そこで今回2021年に向けて内容を見直しました。 最近発売されたベゼルレスのiPad AirやiPhone12 miniなど新しいサイズも増えて、より複雑になった印象です。 iPadのSplit Viewを気にしない人は、去年と同じ560px/960pxでも問題はないです。 hashimotosan
今朝発表された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
↓↓↓最新の2021年版を作成しましたのでこちらもご覧ください。↓↓↓ hashimotosan.hatenablog.jp PDFはこちらからどうぞ[508KB] 2019年Pixel 3aやGalaxy S10など一通り新機種が発表されたので、2019年改めてブレイクポイントについて考えてみました(3年ぶり!)。 3年経ってほとんどのサイトがレスポンシブデザインになって、ブレイクポイントを少なく効率よく設定していく方向になっているのだと思います 前回、ブレイクポイントの設定はフレイムワークも参考に考えていましたが、 改めて考えてみると、モバイルファーストの観点からも640px/1024pxではないのではないかと感じました。 以下が3年前の前回の記事です。 いくつかブレイクポイントを調べましたが、 だいたい以下のような分け方が多かったです。 640px/1024px 480px/896x
スマホは年々大型化し、スクリーンサイズは多様化しています。また、タブレットは小型化の傾向ですがさまざまなスクリーンサイズのものが流通しています。デスクトップもワイドスクリーンなど、わたし達が使用しているデバイスは非常に多様化しています。 スマホ、タブレット、デスクトップ、ワイドスクリーンの異なるスクリーンサイズのレスポンシブ用に、CSSで使いやすいブレイクポイントを的確に定義する方法を紹介します。 The 100% correct way to do CSS breakpoints 下記は各ポイントを意訳したものです。 ※当ブログでの翻訳記事は、元サイト様にライセンスを得て翻訳しています。 ブレイクポイントで混乱する原因 Tips 1: ブレイクポイントを的確に取得する Tips 2: ブレイクポイントの範囲に分かりやすい名前をつける Tips 3: ブレイクポイントを定義するコード ブレ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く