Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Sign up for free
Menu
Search
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Pricing
Search
Sign in
Sign up for free
ブレイクポイントをちゃんと考え直そう@2021
Search
ErinaTakei
June 09, 2021
2.4k
0
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
ブレイクポイントをちゃんと考え直そう@2021
ErinaTakei
June 09, 2021
More Decks by ErinaTakei
See All by ErinaTakei
ディレクター向けCMS案件の進め方 -WordPress中心-
skyguild
1
3k
GoogleAnalyticsの集計について ~中級編~
skyguild
0
2.6k
Googleタグマネージャーの概要
skyguild
1
2.6k
コーディング外注時の進行ポイント
skyguild
0
2.5k
GoogleAnalyticsの集計について ~入門編~
skyguild
0
2.5k
Featured
See All Featured
How GitHub (no longer) Works
holman
316
150k
Templates, Plugins, & Blocks: Oh My! Creating the theme that thinks of everything
marktimemedia
31
2.9k
Build The Right Thing And Hit Your Dates
maggiecrowley
39
3.4k
The Art of Programming - Codeland 2020
erikaheidi
57
14k
GitHub's CSS Performance
jonrohan
1033
470k
The Art of Delivering Value - GDevCon NA Keynote
reverentgeek
16
2.2k
Sam Torres - BigQuery for SEOs
techseoconnect
PRO
0
540
How to Align SEO within the Product Triangle To Get Buy-In & Support - #RIMC
aleyda
2
1.8k
Rails Girls Zürich Keynote
gr2m
96
14k
How to audit for AI Accessibility on your Front & Back End
davetheseo
0
530
Jess Joyce - The Pitfalls of Following Frameworks
techseoconnect
PRO
1
410
Avoiding the “Bad Training, Faster” Trap in the Age of AI
tmiket
0
230
Transcript
ブレイクポイントを ちゃんと考え直そう 2021.06.09 By ErinaTakei
ブレイクポイント レスポンシブWebサイトの制作に不可欠。 画面幅に合わせてCSSを切り替える時に使用する、切り替えポイントのこと。 メディアクエリと併用し、レイアウトが可変するポイントを設定することで、各デバイスに最適化した Webサイトを実現。
ブレイクポイント といえば768pxでしょ? うんうん、知ってる知ってる。
思考停止していませんか? 何故768pxなのでしょうか?
768pxって何? タブレットの最小幅 → iOS(iPad)の縦持ち時の最小幅 Androidのタブレットは600pxとか更に 小さいのもある しかし、タブレットの中でも、 768 × 1024が6割以上のシェア率
実際のところ タブレット = ほぼ768px とも言える
つまり、768pxをブレイクポイントにすると? 768px以上をPC表示 → タブレットをPCビューにする 768px以下をSP表示 → タブレット(768px)をSPビューにして、大きいサイズのタブレットはPCビューにする そもそもタブレットビューをどっちにしたいのか? ということがポイントになってくる
タブレットビューを作らないのか? そりゃタブレット用に最適化したレイアウトにするのが一番きれい しかし、 多くの案件の既存アクセスデータを見てみても、 タブレットでのアクセスは1〜2割程度のケースが多い ビューを1つ増やすには、デザインも実装も工数がその分増える・・・ しかし、PCビューにしてもSPビューにしても、 やっぱりタブレットサイズで見るとレイアウトが微妙で部分最適化する必要がある
タブレットビューのブレイクポイントは? iPadの縦持ち最小サイズは768px(iPad mini)、最大サイズは1024px(iPad Pro) Androidタブレットの最小サイズは600px iPhoneの縦持ち最小サイズは320px(SE)、最大サイズは428px(iPhone 12ProMax) iPhoneの横持ち最小サイズは568px(SE) タブレット最小の600px以上をタブレットビューとして、 iPhoneSEの横持ちはSPビュー、それ以上のサイズの横持ちはタブレットビュー
600px〜1024pxをタブレットビューの範囲とする のが良さそう
結局PCとSPのブレイクポイントは? 今までタブレットをPC表示にした際に、 ビューポートで1024px相当のレイアウトに固定する、という手段があった → UAによる操作が出来なくなるため、ビューポートの書き換えは出来なくなる 何も最適化せずに、768px幅でPCビューに すると、3カラム、4カラムのレイアウトが かなり厳しい。。。 小さいタブレットはSPビューにするのがよ いのではないか?
結局PCとSPのブレイクポイントは? 1024px以下がスマホビューでも良いのではないか? → そもそもPCでのアクセス率自体が低くなっている(サイトによるが大半は) → PCでの小さいブラウザに最適化していくコストが割りに合わない さすがに、、 1024px以下だと切り替え早すぎる・・・、1024pxはPCの方が多いだろう。 という場合は、 やはり768px以下をスマホビューにして、PCビューは1024pxを最小幅固定がよい。
少し大きいiPadを考えて820px以下辺りでも可。 PC1024px以下のアクセス率は低い。 「1920px×1080px」と「1366px×768px」がダントツでシェアが多い。 900pxという意見もある https://www.6666666.jp/html/20200213/
ありがとうございました!