スクロールは制御するな - Weblog - Hail2u.net
WWD Japanのウェブサイトがリニューアルして、スッキリした見やすそうな印象のものに変わった。しかし実際のところ見やすさは見せかけだけで、ナビゲーションをクリックしても見当違いのタブに切り替わったり、ニュース一覧からニュースをクリックしたら、要約ページへ移動するだけで、本文へはもう一度クリックしなければならなかったりする。中でもひどいのがMobile Safariでの閲覧だ。 このウェブサイトではスクロールをほぼ自前で制御しようとしているため、常にこのようにMobile SafariのURLバーとツールバーが上下にそれぞれ表示され続ける。その上、最上端にロゴとグローバル・ナビゲーション、最下端に広告がそれぞれ固定位置であるので、コンテンツの領域がかなり制限されている。iPhone 5SやSEどころか6+や7+でさえも致命的なのではないかと感じられる狭さだ。 とにかく文書を読ませようとい
pre要素3行 = p要素2行
pre要素の行間をどのように調節するのがいいのかということをしばらく考えていた。今までは本文の行間よりも少し狭めるというだけのものだったが、もう少し論理的なものにしたいと、いろいろ考えている。まずは少しフォント・サイズを落とした上で本文とある程度揃うように、具体的にはp要素の2行分の高さとちょうど揃うようにpre要素の3行分を調節してみることにした。 $line-height-root: 1.7; :root { line-height: $line-height-root; } pre { $r: 0.8; font-size: percentage($r); line-height: ($line-height-root * 2 / 3 / $r); // 1.7 * 2 / 3 / 0.8 = 1.41667 } p要素の行数である2とそれに対応するpre要素の行数である3、そしてフ
Git for Windows v2.x.xのインストール
Git v2系のWindows版がGit for Windowsの方で少し前から公開され始めていたことを今さら知ったので、更新した。2015/05/05現在はv2.4.0がリリースされている。インストールから動かすまでけっこう手間取ったので、メモがてら記事に残しておく。Git v2の使い勝手とかについては特に書かない。 ~/.bashrcの読み込み このGit for Windowsでは、デフォルトで無理やり~/.bashrcを読みに行くことがなくなった。~/.bash_profileは読みに行くので、~/.bash_profileから~/.bashrcを読みに行くように、つまり普通にBashを設定してやれば良い。 if [ -f ~/.bashrc ]; then . ~/.bashrc; fi これだけ書いた~/.bash_profileを作成するのが良い。あまり関係ないイシューではそ
ファビコン・カンニング・ペーパー
Translation of: favicon-cheat-sheet ファビコンのサイズや形式についての読むと頭が痛くなる偏執的なカンニング・ペーパーです。以下のURLを参考にしました: rel="shortcut icon" considered harmful · Mathias Bynens <-- special thanks @mathiasbynens Everything you always wanted to know about touch icons · Mathias Bynens <-- special thanks @mathiasbynens Jonathan T. Neal | Understand the Favicon Favicon - Wikipedia, the free encyclopedia Making a Good Favicon -
1文字だけの改行の拒否
日本語の文章では任意の位置で改行できるため、レスポンシブ・ウェブ・デザインでは多くの場合、望まない位置での改行が起きる。例えば最後の1文字だけ次の行になってしまうと、読みやすさや理解度に致命的な影響を与える。例えば「？」だけ次の行に送られた場合、あるとないのでは大きく印象が変わるだろう。Twitterで@Takazudoと@oosugi20の会話を見て、やはりみな似たようなことは考えるものだと感じ、このあたりのことについて書いてみたくなった。 僕はjQueryで最後の五文字では改行が起きないようにいじったりしていた(うろ覚えで書いたもので、実際にはもっと複雑にやっていたと思う)。見出しがテキストのみの場合、最後の数文字の間に非改行ゼロ幅スペース(U+FEFF)を仕込むことで、その間で改行が起こらなくなるという仕組みだ。ここでは比較のためにクラスで判定するように書いてあるが、実際にはh1から
max-widthを否定するクエリー
モバイル・ファーストが浸透して久しくなり、めっきりmin-widthクエリー以外を見かけることはなくなった。そんな中、not (max-width: 768px)という書き方を見かけて、なるほどなと思った。現状のブラウザーにおける実装(と安定した仕様)では768pxを含まずそれより大きいという表現がmin-widthでは書くことができないが、notキーワードとmax-widthを組み合わせることで実現できる。 Demo: Negation of max-width query 特定のデバイスや解像度を強く意識したクエリーの是非はとりあえず脇へ置いておいて、iPhone 5s以下やらiPad Airやら一般的なノートブックやらを意識してクエリーを書くことはままある。多くの場合はそれら特定のデバイスのサイズからを区切りにしてクエリーを書くわけだが、それらのサイズまでで書くとなると少し曖昧な記述
厚いレイヤー
Sitepointに書かれたBEMやSMACSSを使っている開発者たちからのアドバイスを読んでいた。僕は今いかにして命名規則をなくすかといったことを考えている最中のため否定的に読んだが、それでもここに書かれたアドバイスは正しいとは感じた。BEMやSMACSSが概ね想定以上に機能することは確かだし、スケールするし、指揮もとりやすい。 僕が避けたいのは何かしらへの強い依存だ。薄いレイヤーならともかく、厚いレイヤーの場合は重度の依存をもたらす。その依存はこれからもそのまま通用するのかというと、不安が大きい。厚いレイヤーとは心中する覚悟が必要というのは正しいが、多くの場合心中する羽目になるのは導入した人ではなかったりもする。もっと薄いレイヤーでウェブ標準(など)に寄せた形の解があれば安心できるはずだ。 HTML 4.01に対するHTML5を始めとして、CSS 2.1に対するCSS 3、いわゆるJa
OOCSSの欠点とEvery Declaration Just Onceのもたらすもの
昨日も少し書いたEvery Declaration Just Onceアプローチ(以下EDJOと略す)について、皆が目を瞑っているOOCSSの欠点、CSSが持つ特徴、HTMLとの兼ね合いという点からもう少し書いてみたい。これについては未だ誰ともちゃんと議論していない。機会があったらこの記事をベースにでも誰かと話してみたい。 上記Googleの文書は、主にパフォーマンスの観点で書かれている。どうしても長くなりがちな定義を分散して書くよりも、能動的に短くすることができるセレクターを分散して書いた方が、プロダクションにおいてリリースされるCSSファイルのサイズを小さくすることが可能だろうというものだ。同時にこの文書の筆者は自身のブログで、より自然にCSSを書くための手法(原文: 「The Natural Way of Writing CSS」)としてこのEDJOという手法について述べている。 僕
CSSの簡略プロパティー - Weblog - Hail2u.net
CSSの標準仕様では一部のプロパティーに簡略(ショートハンド)プロパティーが用意されている。marginやbackground、fontプロパティーなどがそれ。うまく使うとCSSをかなり短くできるので、積極的に使いたいけど、なかなかの複雑さでそうもいかない。かといって機械的に処理するのも、CSSは人が簡単に書けることを想定して仕様が作られている節がある(根拠はない)のでまた難しい。 先日知ったCSS Shorthand Generatorの内部で使われているshrthndパッケージはまさに機械的に処理するためのもの。でも予想通り、全然ちゃんと機能するものではなかった。 例えばshrthndパッケージでは複数のfont-*プロパティーをまとめることができることになっている。 .test { font-family: serif; font-size: 1.5em; } このように書くと、以下
HTML5 Shivの削除
このウェブサイトは、rem単位を使っていたりと、Internet Explorerだと事実上バージョン9以降でしかうまく閲覧できないようになっている。となるともうHTML5 Shivを使う意味もあまりないので削除した。これでようやく不格好な条件付きコメントを見ないで済む。 条件付き○○というものはうまく機能するが、それの利用には継続したメンテナンスが必要になる。条件付きで何かを特別視するので、プラットフォームに変化が加わるごとに、意図した通りに機能してくれるかどうかや追加で特別視する必要があるかどうかを確認しなければならない。そうしないと古く時代遅れのプラットフォームに依存し続けることになる。 現実世界の多くの仕組みではメンテナンスなしでも大体うまくいく。それはプラットフォームに変化が加わることがあまりないからだ。人々も大体そう感じているので、何もしなければそのまま動くはずだと考えている。
CSSとJavaScriptで文章をメモ書き風に
または和文フォントから仮名部分のみ抜き出してサブセット化したものとYahoo! Japanのルビ振りAPIを組み合わせて、ユーザー環境やサーバー性能に左右されずに比較的自由なフォント表現を行うためのイロハ。おれ ここ めも かき なぐる！ Demo: Scribble My Tweet #3 フォントのサブセット化 ここでいうサブセット化とはつまりフォントから必要な部分のみ抜き出して再構築すること。Webフォントとして使えるからといって、サブセット化までは許されていないことがあったりするので、それには気をつける必要がある。例として新BSDライセンスで提供されている、きろ字 プロポーショナルを取り上げる。 サブセット化に留まらないWebフォントのジェネレーターとしてFont Squirrelの@font-face Generatorが利用できるが、アップロードするフォントのサイズ制限が厳しい
CSSでアイコンをデザイン
ものすごく大雑把に言うと今まで画像編集ソフトでやっていた、角を丸くするとか背景をグラデーションにするなどという作業をCSSでやってしまおうというお話。もちろんCSSでできないことは多くあるので万能というわけではないが、できることに限って言えば数行のCSSコードでスクリーンショットのような効果を柔軟に適用することができる。 Demo: Design icon with CSS ul li a { display: block; width: 32px; height: 32px; background-image: url("icons-w.png"); background-repeat: no-repeat; text-indent: -10000px; } 各アイコンになるa要素へのスタイルは以上のような単純なものがベースになる。icons-w.pngがアイコンの前景をつなげたスプライ
結局どうすればいいの？ - Dive Into HTML5
Translation of: What Does It All Mean? - Dive Into HTML5 Diving In The Doctype The Root Element The <head> Element Character Encoding Friends & (Link) Relations rel = stylesheet rel = alternate Other Link Relations in HTML5 New Semantic Elements in HTML5 A long digression into how browsers handle unknown elements Headers Articles Dates and Times Navigation Footers Further Reading 訳注 Diving In この章で
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
