Date.parse("2015-02-31")
ES5以降では、Date.parse()に不正な日時を渡した場合、NaNを返す……が、不正な日時の解釈に実装によって違いがあることを今さら知った。タイトルのように2015-02-31を渡すと、Firefox 67はNaNを返すが、Chrome 75などでは良きにはからって、つまり2015-03-03とみなしてくれる。書式そのものの解釈の違いだけでなく、こんなところにも非互換性が埋まっていて、まんまとハマった。 Chrome 75やEdge 18、Node.js v12.0.0では以下のようになる。対してFirefox 67は2番目のみNaNを返す。 console.log(Date.parse("2015-02-28")); // 1425081600000 console.log(Date.parse("2015-02-31")); // 1425340800000 console.lo
プリフェッチ中のリクエスト
特定のリソースをrel=prefetchを使ってプリフェッチしている最中に、何らかの形で新たにリクエストされるような状況になった場合、各ブラウザーはどういう挙動になるのかということを試していた。Firefox 38ではプリフェッチがそのまま続行され、新たなリクエストは発生しないという賢い挙動のようだ。 Demo: Fetching when Prefetching デモではrel=prefetchを使ってhead要素内で画像を先読みさせ、ドキュメントの読み込み完了の1秒後に動的に突っ込んだimg要素によりリクエストしてやろうとしている。開発者ツールなどでネットワーク状況を確認することで、どういう挙動になるか確認できる。 Firefox 38ではプリフェッチがそのまま続行され、新たにリクエストを発生せずに画像が挿入される。対してChrome 43とInternet Explorer 11では
git subtreeの練習
Gitのサブモジュールでは面倒そうな、頻繁に更新される別のリポジトリを取り込む方法としてサブツリーマージを行うラッパーであるgit subtreeコマンドを使う練習を始めた。どちらかというと「参照する」要素の強いサブモジュールに対して、サブツリーは「切り分ける」や「取り込む」という感じなんじゃないかと理解している。全般的に間違ってそうで怖い。 「切り分ける」、つまりリポジトリのサブディレクトリを別のリポジトリにしたい場合は、単純なケースだと親にあたる方で.gitignoreや.git/info/excludeを使ってサブディレクトリを除外してやれば良い。でもこの場合、両方のリポジトリで関連した変更がある時にそれぞれのリポジトリでコミットしてやらないとならないので面倒くさい。 「取り込む」場合はサブモジュールが基本なわけだけど、他で作業して戻ってきてたりする必要があるし、サブモジュールの更新
タクシーとパトカー
当たり前だが、タクシーとパトカーは違うものだ。「タクシーに乗った」と「パトカーに乗った」ではまったく意味合いが変わってくる。しかし、この二つの区別が非常につけにくい文章になる場合がある。それはユニコード絵文字を使った場合だ。 🚕に乗った 🚓に乗った この二つの行はOS XやiOSではフルカラーで表示されるので、この両者は容易に区別が付く。対してユニコード絵文字の実装がフルカラーになっていないSegoe UI Symbolが使われるWindows 7では以下のように表示される。 Taxi and Police Car Emoji on Windows 7 Windows 8では少しグリフは変わるが、おおむねこのような感じだ。まず区別はつかないと言って良いだろう。 絵文字は表現力に富むが、それは表示される機器に強く依存する。極端なケースでは、機器によって違う絵文字になってしまうこともある。
rel=dns-prefetch
そろそろrel=dns-prefetchのことは知っておかなければならない気がする。けど、調べれば調べるほど極々限られたウェブサイトでしか威力を発揮することはなさそうな気がしてくる。どうなんだろう。 Internet Explorerも10から対応しているので、メジャーどころは対応したようだ。そういう意味では使える状態ではある。例えばAdSenseのスクリプトを読む時のドメイン名の解決をさせておきたい場合は、head要素内に以下のように書く。 <link rel="dns-prefetch" href="//pagead2.googlesyndication.com"> これでドメイン名が解決済みになるので、他のページを開いた時にAdSenseのスクリプトの読み込みが高速化されることが期待できる。つまりrel=dns-prefetchを書いたページでは特に高速化しない。 Amazonのよう
CSSポストプロセッサー時代の到来について
Frontrend Advent Calendar 2013の4日目の記事として、「CSSポストプロセッサー時代の到来」というタイトルで寄稿した。このウェブログで書こうかと思ったけど、意識はされていないもののそこそこ浸透している概念の話で、トレンドに関わりがあるもののそれに左右はされない話でもあるので、独立した文書にした。長いかと思ったけどそんなに長くもなかった。 CSSポストプロセッサー時代の到来ではさらっと流した、CSSプリプロセッサーのコードと標準的なCSSのコードとのギャップが大きくなりすぎてることについてちょっとだけ。 これは危険な徴候だなーと思ってる。例えばMedia Queriesを効率的に記述するためにミックスインにするみたいなのはよく見るけど、実装の仕方はSassのバージョンと人によりそれぞれで、意図とどういうコードが吐かれるかを把握するのはかなり大変。 .test {
jsDelivr
オープンソース・ライブラリのCDNなんだけど、GitHubに作ったリポジトリをCDN経由で配信できるようにしてくれるという形のjsDelivrというウェブサービスを知った。無料で、帯域制限は特になく、httpsでも利用可能だったり、バックボーンはMaxCDNとCDN.netの組み合わせでそこそこ信頼できそう、と魅力的な点は多い。 単に最新版をホスティングしてくれるだけでなく、タグごとに別にホスティングしてくれるようになっている。タグごとにユニークなURLが作られるので、使ってたけど突然挙動が変わって死んだとかはない。その代わり常に最新版を使うみたいなのはなさそう。 ちょっと気になるのは、CSSやフォントのアップロードを許可している点。Google FontsにないけどオープンソースなWebフォントのホスティング先として有力な選択肢になりそうかなと。アイコン・フォントなんかにももちろん良さそ
Snapito!
Snapito!は指定したURLのスクリーンショットを撮ってくれるウェブサービス。同様のものは多くあるが、画像がキレイで日本語が通ってAPIがあって……となるとそこそこのお値段する。今のところSnapito!は無料でそれらの条件をクリアしている。良さそう。 APIの利用にはキーの取得が必要。取得に使ったメールアドレスのドメインで使用が制限されるっぽいので、動的なリクエストで使おうと思っている場合は気をつけた方が良さそう。またAPI経由ではスクリーンショットを撮る時にディレイをかけたりはできない(ウェブサイトにあるフォームからは可能)ので、非同期で実行しているJavaScriptによるDOM操作の結果は反映されない可能性が高い。他にもビューポートのサイズを設定できないなど自由度は高くないので、本当に特定のURLのスクリーンショットを撮るだけと考えておくのが良い。 そのうち有料化する模様。こう
ID使っても別に問題ない
CSSでID使うの良くない……どころか、ID使うのはゴミクズカスみたいな風潮で辛い。その根拠はいくつかあり、それらはCSSだけをただそのまま書く場合には納得出来ないこともないかなーと思うので余計に辛い。特にOOCSSのようなアプローチではIDは混ぜるな危険。だからといってIDを使わないのがベスト・プラクティスなわけじゃない。 CSS Lintの利用が広まり、これがID使うなって怒るのも原因の一端な気がする。Disallow IDs in selectorsではIDの問題点として以下のようなものを取り上げている。 However, IDs have a downside: they are completely unique and therefore cannot be reused. つまりユニークなため再利用できないというマイナスの面がある、と。確かに再利用できない。でもこれはマイナス
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
