スクロールで色相を変化
秒数ごとに変えていた背景色を、スクロールするとランダムに変わるようにした。雑記ページやスタイル・ガイドで、思う存分試せる。背景色の明るさは変わらないので、そんなに目に負担はかからないと想像しているが、本当のところはわからない。 スクロールに応じて変えるので、素直にやるならonscrollイベントを使うところだが、間引いても重いことがあるだろうし、Intersection Observerを利用した。トリガーをどうしようかと悩んだが、p要素ほど出てこず、たまに出てくる要素をすべて観察させると、どのページでもいい感じになった。 hr要素 pre要素 blockquote要素 li要素直下ではないol要素 li要素直下ではないul要素 figure要素 table要素 h2 + .metaline 対象はこれらの要素だ。見出しやセクショニング要素でも良さそうだが、それだと雑記記事であまり変わらな
template要素内のimg要素
大量の画像を一気に読み込ませないように写真や書棚のページではログ・ページを別に作っていたが、やはり統一したい。CSSなどで隠すとHTTPリクエストが発行されてしまうし、遅延読み込みはせめてネイティブ実装が揃わないと落ち着かない。実装とユーザー操作、転送量においてコストの低い方法を模索し、template要素内に書かれたimg要素ではHTTPリクエストが発行されないことがわかったので、これを利用した。 最初の36枚以外は、月ごとにセクション分けし、それをtemplate要素で括っておく。つまりHTMLファイルのサイズはかなり増える。あとはユーザーが明示的に押す読み込むためのボタンを置き、それを押すとmain要素へコピーするだけの数行のJavaScriptを読んでおく。 document.querySelector("button").addEventListener("click", eve
個人ウェブサイトへ
TwitterやInstagram、Pinboardのアカウントを消したので、それらでやっていたことを自前でやりはじめている。それぞれの過去の投稿をインポートし、RSSもそれぞれ作った。あとは/feedを全部入りにするつもりだが、ちょうど1年くらい前に購読先を変えさせたので、ちょっとやりづらい。でももう少ししたら変える。こうして個人ウェブサイトへと回帰した。 ポートフォリオではない個人ウェブサイトが、どういうものだったか、はっきりと思い出せない。カウンターとかリンク集があったとか、フレームで作られていたとか、ウェブリングとか、些末なことは思い出せる。しかし、どういう雰囲気だったのかまったく思い出せない。 外に放つというより、内に向かうものだったような気はする。そういう感じが出していけるとうれしい。 コンテンツが大きく追加された関係上、ホーム・ページや完全なログのページなどをいじっている。ま
あなたのアカウントは正常に削除されました
色々なアカウントを消した。SNS疲れの類いを感じない程度にしか利用していなかったので、依存もしていないのだろう。そういった使い方ならば、やめてもあまり変わらないし、下位互換風に自前でやるだけでも事足りるはずだ。 また、そういうユーザーは各サービスの主要な層から外れている。自然とその施策に残念な思いをすることが多く、とりまく環境にも落ち着かない。サービス提供者とそのユーザーとして、お互いがまったく噛み合っていない。 新しくやり直すことはいつでもできるはずなので、まずは噛み合っていなそうなサービスのアカウントを消していった。その過程で勢いあまって……。 Adobe Amazon.com Cloudflare Dropbox IFTTT Instagram LINE npm Pinboard Tumblr Twitter Wunderlist ZOZOTOWN 他にも消したような気もするが、覚え
普通のHTMLの書き方
保守しやすく、規模に依存しないHTML文書のために 一般 DOCTYPEで始める 置き換えられるべきまたは旧式のDOCTYPEを使わない XML宣言を使用しない 文字参照はできる限り使わない &と<、>、"、'は名前文字参照を使ってエスケープする 制御文字や不可視文字は数値文字参照を使う コメントではその内容の前後へ空白文字を置く 終了タグを省略しない 空要素の書き方を混ぜない タグや属性値の前後へ空白文字を置かない 大文字・小文字を混ぜない 引用符を混ぜない 属性を2文字以上の空白文字で区切らない 真偽値を取る属性の値は省略する 名前空間は省略する XML属性は使わない data-*とMicrodata、RDFa Lite用の属性と通常の属性を混ぜない デフォルトの暗黙のARIAセマンティックスを尊重する 文書要素 lang属性を追加する lang属性の値はできる限り短くする できる限り
ウェブページにおけるバーティカル・リズム
いわゆるバーティカル・リズム(vertical rhythm)がウェブページでも重要なのではないかと言われてから随分と経つ。僕の記憶が確かなら10年にはなるだろう。しかし当初から僕は懐疑的だった。もちろん一貫性のある余白は重要だが、バーティカル・リズムにまでなるとウェブページでは思うように機能しないのではないだろうか。 バーティカル・リズムはページ単位でどのようにコンテンツが美しく、そして読みやすくレイアウトされるかというための概念だ。それは紙媒体のような固定寸法にコンテンツを流し込む時には非常に有効に働く。常に一定のリズムで視線を動かしていけばスラスラと読んでいけるからだ。 しかし、ウェブページは横に制限があるが、縦には制限がない。そのためスクロールという機能がカギとなっている。古くはスクロールバーをクリックやドラッグすることでしかその機能を使うことはできなかったが、ホイール・マウスによ
バターなし！ 牛乳なし！ のヨーグルトを使ったスコーン
この分量で7個分として焼いたところ、こぶし大より一回りくらい小さいサイズに焼きあがった。バターなし！ 牛乳なし！ 小麦粉から塩までを一旦混ぜあわせ、そこにヨーグルトクリームを加えて更に混ぜ、最後にホエーから溶き卵までを混ぜると生地がまとまる。ゴルフボールくらいに丸めただけで焼いたところ、ポワンとパンみたいにふっくらしてしまったので、ちゃんとのばして型抜きした方が良いのかもしれない。 サクフワで普通のスコーンとは違ったおいしさだった。まわりはカリッと焼きあがることもあって、甘食とかの食感に近い。甘みが強めだったので、砂糖はもうちょっと減らしても良いかもしれないけれど、それだと今度はヨーグルトクリームの酸味やベーキングパウダーの苦味が出てしまいそうだ。 スコーンのサクサクではないサックリ感みたいなのはやはりバターなようだ。ちょくちょくバターをなたね油などで代用したお菓子レシピとか見かけるが、あ
クラス名の命名規定
pixivのCSSで使われるクラス名ルールという命名規則の記事を読んでいた。初見では大規模だとBEMの衝突が絶対に起きない書き方の方が優れているように思えた。しかし衝突するであろうことに警報を出すという形にゆるくすることで、開発者たちに自由を与えるというような目的でこうなっているようだ。ちょっと興味深い。 規模が大きくなると制約を厳しくして安定性を重視する一辺倒だったが、こういう自由さをうまく提供しようという考え方をすることはあまりなかった。具体的にも、変更されることがあまりない、またはわかっている人だけが行うひとまとまりのルートにのみ特殊な命名(_で始める)というのはバランスが良さそうに思える。 コードだけを見てみるとうまくいっているというのは少し驚く。_で始まるところはあまり触らない人と_で始まるところを触る人、と人的リソースが能力や職掌に応じてうまく振り分けられているのかなと想像して
ウェブ・フォントの読み込み - Weblog - Hail2u.net
ウェブ・フォントも完全に行き渡り、今はどう効率的に配信するかについて多くの時間を割くようになった。Google Fontsの低め安定路線を見限り、TypeKitやFonts.comへ鞍替えする人々も増えた。それと同時に自前でホスティングする人々も徐々にその数を増やしており、どれが最適解なのか一応の結論が出るにはもう少しかかるだろう。まず、ウェブ・フォントの読み込みにおいてどのようなアプローチがあり、どのようなメリット、そしてデメリットがあるのだろうか。 TypeKit等に頼るにしろ、自前でホスティングするにしろ、もちろん最終的にはウェブ・フォントをブラウザーに送りつける必要がある。読み込みとはまさにその部分の話だ。話がややこしくなるので、多様な実装を意識した安全な書き方などについては触れない。 普通に@font-face定義を利用 @font-face定義をただ普通に書く場合のメリットは、
透過PNGをSVGを利用して軽くするテクニック
透過PNGは現状では唯一に近いフルカラーの透過画像を作成する手段だが、ファイル・サイズが大きくなりがちだ。対してJPGはファイル・サイズという点で大きく優るが、透過することは出来ない。このあちらを立てればこちらが立たずの問題をSVGのマスク機能を使って透過だけを受け持つPNGとJPGを組み合わせることで両立させるテクニックを知った。 透過させた画像をまず普通に作る。それから透過してないJPG画像と、透過を反転させてマスクに使うPNG画像を生成する。それらをHTMLでSVGのmask要素をインラインに書くことで組み合わせる。ベースとなるJPG画像が一般的にファイル・サイズに優れ、マスクに使うPNGは空白が多いこと、SVGの記述はごく短いもの、というわけで最終的に低ファイル・サイズが実現できる。 SVGのセキュリティ上の制限により、HTMLにインラインで記述するケースでしか使えないのでCSSの
wildfire.vimでVim力を下げる
wildfire.vimという、カーソルがある辺りのテキストオブジェクトをなんとなく選択してくれるVimプラグインを使い始めた。Vim力が下がる代わりに魂の平穏が得られる。ような気がする。 デフォルトではノーマル・モードで<Enter>を押すとカーソルのある辺りのテキストオブジェクトを選択してくれる。HTMLファイルを編集中なら属性値の上で発動させると、クオートの間を選択してくれる。その状態でもう一回<Enter>を押すとその上位にあるテキストオブジェクトをなんとなく選択してくれる。属性値のクオートの間を選択した状態だと、HTMLタグで括られた全体(など)まで拡大される。 逆方向に縮小することも出来るので、適当にタカタカ<Enter>を押して拡大しつつ、広げ過ぎたら<BS>で狭めるみたいな感じで使えて、とてもいい加減に使える。僕は狭める方だけを<S-Enter>に変えて、サクサク感を上乗せ
BreakpointTesterとish.
少し前にBreakpointTesterというツールを知った。任意のページでそのブックマークレットを起動すると、参照されているCSSファイルをスキャンしてMedia Queriesのブレークポイントを探し、そのブレークポイント全てを使ってiframe要素で表示しなおしてくれるというもの。また、ほぼ同時期にish.というツールがBrad Frostにより公開された。こちらは大中小でチェックでき、リサイズも可能というもの。こちらもデバイスを特に意識はしていない。しかし、両者は似ているようで少し違う。 ish.はメジャーなデバイスを強く意識することをやめ、あらゆるデバイスでコンテンツが機能するようにしようというコンテンツ側からの視点で作られているように思う。対してBreakpointTesterはビジュアル・デザイン側からの視点で作られており、どのようなビジュアル・デザインを作成したのかをチェッ
ファビコン・カンニング・ペーパー
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 -
grunt-task-helperが良さそう
grunt-task-helperというGruntプラグインを使っている。ざっと言うとsrcとdestを比較してフィルターをかけた結果を他のタスクで使えるようになったりするもの。例えばビルトインの比較機能であるnewFileを使うと、更新されたファイルがあった場合にだけ走るタスクと似たようなものが簡単に作れる。 grunt-contrib-concatを使っているとして、そのタスク設定が以下のようになっているとする。 concat: { options: { seperator: ';' }, prettify: { src: [ 'scripts/prettify/prettify.js', 'scripts/prettify/lang-config.js', 'scripts/prettify/lang-css.js', 'scripts/prettify/lang-scss.js',
流行って欲しいくない
流行るイコール消費され尽くすみたいなことが多いので、流行らないけど狭い世界では評価が高いみたいなのが良いのかなーと思う。ただ、ユーザーの場合はそれで満足できそうだけど、アーティストや開発者の場合はそれでは満足できるほどにはやっていけない。そこに金を簡単にやり取りする仕組みがあれば良い的なのがだいたいこういった話の落とし所なんだけど、狭い世界での金のやり取りって人間関係が崩壊しそうなイメージしかない。本来、こういうところに活躍の場があるのが広告なんだと思う。 インターネットの広告は「スポンサー」や「PR」みたいな変な感じのものが主流で、どっちかというと広告主の要望と欲望が最大限に反映されたものがほとんど。あたかも閲覧者に一定の配慮をしたように見せかけるコンテンツマッチやインタレストマッチみたいなものもあるけど、閲覧者のためというのはその理由の半分くらいな気がする。そして広告主と閲覧者の間にい
SVGよりアイコン・フォント！ な理由
両者は共にスケーラブルなもの(にできるもの)なのでその点では互角だけど、様々なプロパティーを持ち多彩な表現が可能なSVGの方がフォーマット的には優位にあると言って良い。が、なかなか利用が広まらないSVGに対して、アイコン・フォントの利用は急速に拡大している。単に流行りとみなす向きもあるけど、やっぱりそれなりに理由があるのではないかと思う。 CSSとの親和性 特に以下の3つのCSSプロパティーは効果的に使える。 font-size color text-shadow PNGで作られたアイコンの色を変更するには編集が必要だけど、アイコン・フォントはCSSファイルで自由に色を調整することができる。独自実装も含めるなら-webkit-maskプロパティーもとても(想像以上に)効果的に使うことができる。他にもちょっとした位置の調整やなんかも慣れ親しんだCSSで普通に可能。更にこれらをHTMLファイル
SCSSファイルの整理
SCSSファイルの整理をしてた。Sass 3.2を使い始めて以降、%セレクターをとりあえず使ってみる感じが多かったけど、ようやくどういうものに使うべきでどういうものに使うべきではないのかがわかってきたような気がする。というわけで現在のこのWebサイトのスタイルの構成のメモ。 関数 変数 Webフォント プレースホルダー・セレクター IDやクラス指定のないHTML要素 normalize.css ページを構成する要素のデコレーション ページを構成する要素のレイアウト その他ウィジェット 印刷向け 関数はどこで使われるかわからずプライオリティが高いので最初にインポート。それから変数を定義して、それを使ってスタイルを書いていく。Webフォントは変数のところでインポートして定義するようにした。Sass 3.2ではCSSの@importディレクティブを自動的に先頭に移動してコンパイルしてくれる機能が
テ・クス・チャ
ロゴと本文とフッターに貼っているテクスチャを更新した。全部シームレスで透過にしたので結構大変だった。でも別にどんな色にでも使えるとかそういう完成度の高いものではないので自己満足の域を出ていない。 こういう境界だけ修正すれば比較的簡単にシームレスになるテクスチャは、普通にPhotoshopのスクロール・フィルターを使ってから境界線を適当なブラシ(はねやチョーク)で修正する方法でよくやる。その後、画像の濃淡をそのまま黒の透明度に変換するアクションを使って、透過させる。元画像によっては結果が安定しないので、アクションを実行する前にグラデーションマップでざっと調整するとけっこう手軽にキレイになると思う。 たまに存在を忘れかけるけどスパムで思い出すWufooによるフィードバック・フォームのスタイルも更新してテクスチャを貼り直した。たまに誤字ツッコミとか感想とかtypo指摘とか貰えるので外すに外せない
スクロールすると固定に切り替わるヘッダー
最初は普通に表示されているけど、スクロールしてヘッダーが画面の外になると上端固定に切り替わる奴の話。今年になって異様に増殖してる。別に嫌いではないし、なんとか的にアレ……みたいなところもない(と思う)んだけど、実装するとなると結構色々気になるところがある。というかうまく作れる気がしない。 固定したヘッダーが使用する数十ピクセルの価値 まずは上端に固定したヘッダーが占有する画面領域の価値という問題がある。モバイル機器のブラウザーではそもそも固定するのがまだちょっと不安な状況なのでそれらにおいてでの話ではないけど、モバイル機器ではより考慮すべき問題にはなりそう。横長のディスプレイが主流になり、ウィンドウの最大化という呪縛から解き放たれつつある昨今、各ブラウザーベンダーが死ぬ気で削った価値ある数十ピクセルを、たかがWebサイトのグローバル・ナビゲーション程度に割く理由はあるのか？ 例えばこのWe
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
https://hail2u.net/statuses/log.html