iPhone X の Safari における Web コンテンツの表示 - ONO TAKEHIKO - Medium
iPhone X が発表されて間もなく、ディスプレイの「切り欠き」については至るところでちょっとしたイジリ合戦が始まっています。中には実際に信じてしまっている人もいるほど秀逸なものがありまして、それがこちら。 思わずクスッときてしまいますが（笑）、まあ当然こんなことにはなりません。 iPhone X にはディスプレイの上下左右に iOS の占有領域が存在し、それ以外（アプリのタッチイベントを認める領域）を Safe Area と呼ぶようです。Safe Area の外にある上部領域にはステータスバーとして時計やアンテナのインジケータなど iOS のシステムアイコン等が並び、下部の領域には iPhone X で導入された「ホームバー」が存在することになります。 では iPhone X の Safari で Web サイトを表示した場合に一体どのようになるのか？それを Web 上の情報を元にまと
iPhone X の Safari で表示する Web ページの HTML / CSS 設定 - Apple Engine
どうやら、そのままだとサイトが表示領域の全体に面表示されないっぽい。 参照元 ayogo.com 対処方法 meta タグ Viewport に「viewport-fit=cover」を入れる。 <meta name="viewport" content="width=device-width, initial-scale=1.0, viewport-fit=cover"> このままだと問題があり、本体を横に傾けてランドスケープにすると コンテンツが両サイドまでいってしまい、四隅のアールやカメラ部分でコンテンツ内容が隠れてしまう。 アプリのように Safe Area があり、CSS で padding を設定すると余白をつけてくれる。 padding: constant(safe-area-inset-top) constant(safe-area-inset-right) constan
CSSのposition:stickyがすごく便利 | q-Az
最近新しく追加された position の新しい値 sticky が場合によってはすごく便利なので記事を書いてみます。 対応ブラウザがまだあまり多くないので実用性は乏しいかもしれませんが、今まで JavaScript の力を借りなきゃ出来なかったことがたったの2行の CSS で出来てしまう魔法みたいな position の値です。 position: stickyMDN が説明が詳しいので貼っておきます。 参考：position - CSS｜MDN 簡単に言うと「スクロールでその位置まで来たらそれ以降は fixed する」みたいな感じです。 サンプルこの記事内で「position: sticky」や「サンプル」など h2 要素に position: sticky をかけています。対応ブラウザであれば h2 要素が fixed しているはずです。 HTML<h2 class="h2-stic
汚いcssを整形するWebアプリ「css2scss」でリファクタリングした際、「ヤバい」と感じた３つの機能と３つの点 - Qiita
汚いcssを整形するWebアプリ「css2scss」でリファクタリングした際、「ヤバい」と感じた３つの機能と３つの点HTMLCSSSassscssCompass あらまし 別の業者が構築したという客先のホームページのcssが非常に読みづらく、 誰も手が付けられてない状態でヤバい（compactの状態で約350行）。 そこでリファクタリングをしようと思った際に、考えた。 「どうせならsass/scss対応にした方が可読性も可用性も上がる！ヤバい！」 sass/scss → css は当たり前として、 css → sass/scss って出来るのかよ、と思い調べてみると、数個発見した。 そのうちの１つ、今回ご紹介する「css2scss」が非常にエレガントだった。 実際に使用して感激して落胆したポイントを、それぞれ３つに絞ってご紹介。 css2scss sass/scssについては、まずはアレな
画像置換のあれへの補足
先月あたり、CSS による画像置換テクニックの話題がにわかに盛り上がりを見せていました。その経緯について まとりさんの記事 で紹介されていますが、僕からも簡単に補足してみます。 まず、よく知られた画像置換のテクニックとしていわゆるファーク式がありました: /* Phark method */ .ir { height: 100px; width: 400px; background: url(image.png) no-repeat 0 0; text-indent: -9999px; } このテクニックは長らく利用され続けてきましたが、その代替として、パフォーマンス面でより良いとされる Scott Kellum さんのテクニック (ケラム式) が Jeffrey Zeldman さんの記事 で紹介されました: /* Kellum method */ .ir { height: 100px
「コード汚くてもデザインが見えればいいじゃん」への返答
なぜコードが綺麗じゃないといけないの？という質問をごく一部の方、特にデザイナーさんから受けることがあるので（半分くらいの人はネタで言ってますが）、自分なりの意見をまとめたいと思う。勉強不足で浅い感あるので、偉い人にご指摘いただけると嬉しいです。 「コード汚くてもデザインが見えればいいじゃん」の定義について 「コード汚くてもデザインが見えればいいじゃん」はかなりふわっとした印象を持つので、ここでは「コードが汚い」の定義として、以下の2つを挙げる。 メンテナンス性に欠ける （W3Cの）仕様に沿っていない なので「コード汚くてもデザインが見えればいいじゃん」というのを「メンテナンス性に欠け、仕様に沿っていなくても、デザインが見えていればいいじゃん」という意味に置き換えて話を進める。 確かに表面的な視点で見ると、エンドユーザーには関係がなさそうに見えるかもしれない。 例えばメンテナンス性の高いコー
CSS: using only a single font family and different styles with web fonts: a lesson from Google
CSS: using only a single font family and different styles with web fonts: a lesson from Google I was wondering how Google handles its web fonts so that you don't have to specify a different font family for bold and italic styles but you can simply use the main family. To answer my question, I've simply opened the URL of the Google's CSS file. The linked CSS file looks like this (retrieved with Chr
@font-face and performance | High Performance Web Sites
MAJOR CORRECTION: @font-face only blocks rendering in IE when there is a SCRIPT tag above the @font-face declaration. (more info below) Last week I was reading Ajaxian (my favorite blog) and saw the post about @font-face. I had been wondering for a few months about how font files impact web performance, so I followed the story back to Zoltan Hawryluk’s original post: @font-face in Depth. A great r
CSS には vw, vh, vmin, vmax という単位がある | DevelopersIO
例として以下の様な HTML 構造があったとします。 <body> <!-- 画像解像度: 100 x 100 (px)--> <img src="images/thumbnail.jpg" /> </body> img { display: inline-block; margin: auto; width: 10vw; } img の幅を 10vw と指定しています。基準となるビューポートの幅を vw で表すと 100vw となります。iPhone 5S のビューポート幅をピクセルで表すと 320px な訳ですが、10vw はその 1/10 ということで32px が img の幅となります。つまり 1vw は 1% と同じ長さになります。もちろんリキッドレイアウトにも対応した動きを持っています。 Demo - viewport lengthを開く（このサンプルはChromeブラウザでの
ナウでヤングな CSS Font Loading - Qiita
Web フォントがレンダリングされるタイミングを得ようとすると、そのやんちゃな挙動を制御するため人類は今まで下記のような対策をしてきた。 Web FontsをHTML Canvasで使う canvas要素にwebフォントを確実に描画する方法 typekit/webfontloader 無知な僕は同様の事象にハマり、一通り調べた後、下記の答えにたどり着いた。 canvas に WebFont を指定するとき、一回どこかの DOM で使う WebFont をレンダリングしておかないと死に至る現象を発見したので皆様もお気を付けください — ダメレオン (@damele0n) April 10, 2014 要するに DOM もしくは canvas 上で、そのフォントが指定されていて一度そのフォントがレンダリングされてからでないと canvas 上はレンダリングされない、ということだ。 (ちなみに
同棲をはじめました - はぁはぁブログ
はじめてのひとり暮らしは、はたちのときでした。 「はたちになったら家をでて自立しなさい」 という教えのもと、実家ちかくのせまいワンルームへ。 せまいし、しかも超へんなかたちの部屋に住みました。 住みにくかったし、さみしかった。 はじめてカレーを腐らせたとき「あっ腐るんだ」ってびっくりしました。 「傘もった？」とか「ごはんあるよ」といつもよくしてくれる お母さんAPIのありがたみを、実家をでてはじめてわかりました。 大学を卒業して、就職ってなったときにまたお引越し。 会社ちかくのワンルーム、すこしだけ広くなりました。 そのあとまた引越しをしたけれど、いつもひとり暮らし。 だんだんお部屋が広くなっていくことがうれしかったです。 だって、まじめに働くことでどんどん生活がよくなって、私の成長が感じられたから。 そして去年、大好きな人と出会うことができて、まじめに恋をして、まじめに交際をして このた
スタイルシートで実装するパララックススクロール | コリス
パララックス=スクリプトと思っていたのですが、スクリプト無しでも実装できるんですね。 今後、実装方法がますます進化しそうです。 実装方法を簡単に紹介します。 HTML デモのHTMLをシンプルにするとこんな感じになります。 各スライドはdivで配置し、それぞれclassにslideを、idで個別の名称を付与します。 <div id="title" class="slide header"> <h1>Pure CSS Parallax</h1> </div> <div id="slide1" class="slide"> <div class="title"> <h1>Slide 1</h1> <p>パラグラフ パラグラフ</p> </div> </div> <div id="slide2" class="slide"> <div class="title"> <h1>Slide 2</h1
300ms tap delay, gone away | Blog | Chrome for Developers
For many years, mobile browsers applied a 300-350ms delay between touchend and click while they waited to see if this was going to be a double-tap or not, since double-tap was a gesture to zoom into text. Ever since the first release of Chrome for Android, this delay was removed if pinch-zoom was also disabled. However, pinch zoom is an important accessibility feature. As of Chrome 32 (back in 201
CSSポストプロセッサー時代の到来
SassやLESSといったCSSプリプロセッサーは市民権を得たと言って良いと思う。しかしそれらCSSプリプロセッサーは開発という段階にのみ利をもたらすもので、今のところはそれ以上ではない。CSSを実際にユーザーに届けるまでには、開発だけではなくレビューとリリースという段階もある。レビューとリリースも確実性を持って効率的に行うためには、CSSポストプロセッサーと総称されるようなツール群が必要になるだろう。 この文書はFrontrend Advent Calendar 2013の4日目への記事として寄稿した。明日は@hilokiさんがスタコラサッサと書くようだ。 目次 CSSポストプロセッサーとは CSSプリプロセッサーの出力するCSS CSS Lint 開発用とレビュー用、リリース用のCSS CSSポストプロセッサーのユースケース ベンダー拡張プリフィックスの付加 Media Queries
メンテナブルCSS
概要 メンテナブルなCSSを目指し、定義された一般的なCSSルールの紹介と、それらのルールを適用するにあたって活用できるツールを報告します。 1. 序論 CSSは記述ルールが簡素であり、少しの学習コストですぐに記述ができる手軽なツールです。 しかし、大規模なアプリケーションで複数人で開発するケース等では、見栄えだけしか考えずに身勝手にコーディングしてしまうと、 非常にメンテナンスコストがかかる負の遺産が作られてしまいます。 そのためCSSの品質を保つために様々なプロジェクトで、CSSの定義ルールが決められています。 本稿では一般的なCSSの定義ルールと、そのルールがなぜ作られたのかを合せて報告致します。 また、CSSのルールを適用するにあたって、手動・目視でルールの適用をチェックするのは非常にコストが高い作業です。 これらルールの適用を補助するツール群を、合せて報告致します。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
最近の Web パフォーマンス改善について知っておきたいコト
z-indexと向き合う
モダンなCSS設計パターンを考える
今必要なCSSアーキテクチャ
大規模サイトにおける本当は怖いCSSの話
