JavaScriptがなくなった
もう相対日時にするやつとutm_*を削除するやつしか動かしてなかったので、JavaScriptをなくした。再構築したので消えている。 最近はデフォルトでJavaScript無効でも生きていけるようなインターネットになってきた気がする。HTML Living Standardのおかげかなって思ったけど、どちらかというとSVGやFlexboxやなんやのおかげなのかもしれない。 話題の遅延読み込み(loading属性)もそういうやつっぽいけど、挙動としてどうにもならない問題があるような気がしてならない。回線が安定していて、無制限で、マシンパワーも余っているなら、遅延読み込みする必要はないけど、それをブラウザーが知ることは難しそう、というような話。「多分あと10分くらいはハードウェアやインフラをこれくらいまで使えますよ～」みたいなのがOSがブラウザーへ教えないといけないのかな。 遅延読み込みはペー
あなたのアカウントは正常に削除されました
色々なアカウントを消した。SNS疲れの類いを感じない程度にしか利用していなかったので、依存もしていないのだろう。そういった使い方ならば、やめてもあまり変わらないし、下位互換風に自前でやるだけでも事足りるはずだ。 また、そういうユーザーは各サービスの主要な層から外れている。自然とその施策に残念な思いをすることが多く、とりまく環境にも落ち着かない。サービス提供者とそのユーザーとして、お互いがまったく噛み合っていない。 新しくやり直すことはいつでもできるはずなので、まずは噛み合っていなそうなサービスのアカウントを消していった。その過程で勢いあまって……。 Adobe Amazon.com Cloudflare Dropbox IFTTT Instagram LINE npm Pinboard Tumblr Twitter Wunderlist ZOZOTOWN 他にも消したような気もするが、覚え
メモ(2018年9月12日)
近所のスーパーでは、ほぼ毎週水曜日に明治のおいしい牛乳が安売りされる。安売り自体はあったものの、チラシに記載がなかったり、数がものすごく少なかったり、不穏な気配がする。今月に入って野菜は安くなりつつあったが、今度は乳製品となると辛い。今年は、何かしらがずっと高いまま終わりそうだ。 豚コレラは「とんこれら」で、鳥インフルエンザは「とりいんふるえんざ」のようだ。「ぶたこれら」でも「ちょういんふるえんざ」でもない。豚肉も値上がりしかねない。 色々なものがおいしい季節なので、それらをパクパク食べる。健やかに過ごしたい。
普通のHTMLの書き方
保守しやすく、規模に依存しないHTML文書のために 一般 DOCTYPEで始める 置き換えられるべきまたは旧式のDOCTYPEを使わない XML宣言を使用しない 文字参照はできる限り使わない &と<、>、"、'は名前文字参照を使ってエスケープする 制御文字や不可視文字は数値文字参照を使う コメントではその内容の前後へ空白文字を置く 終了タグを省略しない 空要素の書き方を混ぜない タグや属性値の前後へ空白文字を置かない 大文字・小文字を混ぜない 引用符を混ぜない 属性を2文字以上の空白文字で区切らない 真偽値を取る属性の値は省略する 名前空間は省略する XML属性は使わない data-*とMicrodata、RDFa Lite用の属性と通常の属性を混ぜない デフォルトの暗黙のARIAセマンティックスを尊重する 文書要素 lang属性を追加する lang属性の値はできる限り短くする できる限り
3000記事目ほか
この記事で3000本目だ。そしてこれがBlosxomで生成される最後の記事になる。キリのいい数でやめようと前々から決めていた。思いおこせば……(中略)……色々な意味で良いソフトウェアであったし、今もその仕組みは尊敬できる。 やめた理由を強いて挙げるなら、環境を再構築する時の負担だ。 Perl自体はインストールしてもいいし、Git for Windowsに入っているものをそのまま利用しても良いが、今は亡きCGIモジュールをインストールするのが非常に面倒くさい。当然まともにインストールしようとすると茨の道だし、配布されているTarボールを展開してコピーという不安がつきまとう方法はできうる限り避けたい。最近は特に開発でPerlが必要でもないため、モチベーションがゼロに近い。 blosxom.exeのようなものを作ってしまっても良かったが、それについて調べたり考えたりする気力はなかった。自動生成に
落ちている手袋
道端に落ちている手袋を写真に撮っている。たまにInstagramに上げるくらいでまとめたりはしていない。撮っていて気づくのは、急に寒くなるあたりで突然落ち始め、寒いピークにはあまり落ちていなくなるということだ。手袋の取り扱われ方を想像するとなんとなく理解できる。もうひとつは月曜日によく見つかることだ。日曜日に楽しくお出かけしている時は落としても気づかないのだろうか。 落ちているといっても、地面にはあまり落ちていない。通りすがりの人の優しさなのか、塀の上やフェンスに差し込んである。しかし探している人はほとんど地面を見ているので、実はそのままにしておいた方が見つけやすいのではないかと考えている。 今日は3つくらい見つけてちょっと楽しい。
HTMLは開発者たちのために
昔からよく「HTMLの正しさ」というような表現を見る。少し前はHTMLの構造的な完全さや文法的な正確さなどにウェブページの表示やCSS、そしてJavaScriptが依存していたので、そういった点を強く意識する必要があった。Firefoxが親切に教えてくださっていたXMLパースエラーのことを思い出すとわかりやすい。僕も良くそれに類する表現を使っていた。 今はブラウザーとウェブ標準技術が共に進化したので、そういった形式的な正しさはさほど重要ではない。かろうじてハイパーリンクだけがまともな壊れたHTMLでもなんとか修復して解釈してくれる。命名規則ベースのCSSならばHTMLがどうあれうまくスタイルが当たってくれるだろう。足りない機能はDOMツリーの状況をほとんど無視できるShadow DOMでどうにでもできるというわけだ。 HTMLにCSSとJavaScriptを生やしてウェブページが出来ていた
@supportsとIE11
Internet Explorer 11以下では@supportsがサポートされていない。そのおかげで実装ベースで(CSSハックなどというものなしに)安全にCSSの新機能を試せるようになった。しかしそうなるとIE11などというもののために大量の@supportsが出てくることになり、精神衛生上良くない。実装がある方を優先させCSS全体を適当な@supportsで括ってしまえば良さそうだ。 View Demo: Ban <=IE11 with @supports デモの段落は@supportsをサポートしている安定ブラウザーでは緑になり、IE11ではちゃんと赤になる。不明なAt規則とその子は無視されるようになっていることが確認できる。CSS仕様でもそうだが、IE11以下を含めおおよそすべてのブラウザーでこういう実装になっているはずだ。 CSS全体を括るのは雑過ぎるので、実際にはFlexbox
ホーム画面のアプリ
1日に1回以上使わないアプリはフォルダーに片付けることにした。定期的に話題になるライフハック的な処方だ。アプリが9つ残り、ホーム画面にはそれらとフォルダーだけになった。やりづらい。 僕は目に入るものを無視できないので、モノがない方が性に合っている。モノを減らすと安心する。Inboxゼロとかもやっている。便利ではないけれど快適にはなった。 スポットライトで「settings」で設定アプリがヒットするので、アプリの起動はスポットライトを酷使している。以前はヒットしなかったがために挫折したような記憶がある。Siriのおすすめアプリもそこそこ役に立っている。 衣替えの時期はむやみにモノを片づけたくなる。
さんぽのしゃしん(表参道〜外苑前〜新宿御苑)
ずっと曇っていた。少し雨も降った。それほど寒くはなかった。 代々木上原駅 ホーム先頭の外壁に駅名が英語でペイントされていた。代々木上原ではいつもすぐ乗り換えるだけだったので気づかなかった。この日は千代田線がちょうどいなかったため、フラフラしてたら目に入った。 手しごと展のポスター オープンまで少しあったので、表参道の最も西の出口から出て少し歩いていた。大判のポスターや暖簾が至る所にあり、盛り上がってくる。表参道ヒルズに地下3階なんてあったんだと驚いたりもした。 東郷ホールの外壁 次の目的地が千駄ヶ谷に近いところにあるようなので、東郷神社の敷地内を抜けていくことにした。結婚式場から神社、幼稚園、区立図書館と通り、最後に東郷ホールを見ていく。 Labour and Wait 狭かったが良い狭さだった。万年筆や画鋲が少し欲しくなったが買わなかった。 Swiss Design Kiosk アバウト
:target擬似クラスとHistory API
:target擬似クラスではフラグメント識別子と一致する要素に対してスタイルを当てることができる。これを利用するとCSSだけでインタラクティブにデザインを変更することが可能になる。一方History APIではページの遷移なくフラグメント識別子を含め、アクセス中のURLを書き換えることができる。では:target擬似クラスで有効になっているスタイルは、History APIでフラグメント識別子を変更した場合に動的に切り替わってくれるだろうか。 Demo: :target and history.replaceState() デモ・ページではEnable #test:targetをクリックするとURLに#testというフラグメント識別子が追加される。#test:targetセレクターを通して、文字色を緑にするようにしてあるので、クリック後文章が緑になることだろう。Disable #test:
夢(2017年1月29日)
寝ているがトイレに起きる。トイレに入ると便器がない。窓の外で男が便器を抱えており、驚いて「ドロボー？」と半疑問形で尋ねる。男が口を開きかけたところで目が覚める。 すぐにトイレに行ったが、ちゃんと便器あった。
選りすぐりの文書
これらの文書にはかなり古い（10年以上前）ものもあり、現在はあまり役に立たないかもしれません。更新日時に気をつけて読んでください。 HTMLを書くのは難しくありませんが、その仕様そのものや、ウェブを取り巻く環境と共に、その書き方も変わり続けています。新しい機能や、歴史的事情による落としどころを踏まえて、普通にHTMLを書くと、保守しやすく、規模に依存しない安定したHTML文書になるでしょう。 インターネットの普及に伴い、ユーザーのフィードバックを得る敷居は格段に低くなりました。しかし、そのことはあまり良くない結果をもたらしたと言えるでしょう。 HTMLを適切な要素を使って書いていくことは実はそれほど難しくはない。しかし過剰に要素を使わずに、かつスタイリングすることも意識して、と適切に“マークアップ”するのはなかなかの修練を必要とする。いったい“マークアップ”するということはどういうことなの
夢(2016年2月2日)
ブランコとシーソーが合体しているものにのっている。前後に揺れながら上下にも動く、大人なのですごく怖い。向かいにのっている(シーソーなので)子供にバカにされる。イラッとしたので立ちこぎしてブランコの振れ幅を大きくすると子供が泣きはじめる。そろそろ止めようとしたところで、ブランコの止め方ってどうやるんだっけ……となり、自分も怖くなったところで目が覚める。 近所の公園の遊具が撤去され、土台が掘り起こされていた。老朽化で直すようだ。昔はシーソーもあったが、木が腐って撤去された。他にも何かあったような気がするけれども思い出せない。違う公園にあった木のピラミッドみたいなのも腐って撤去されていた。木は腐る。
夢(2015年12月13日)
某卵かけご飯のアイコンの人にすごく似てる人が電車で向かいの席へ座る。「すごい似てるなー」とTwitterでつぶやいたり、Instagramへ写真をアップロードしたりした。一通り遊んでしばらくすると、この人と会ったことがなく、まったく顔を知らないことを思い出した、というところで目が覚めた。 顔を知らない人まで夢に出てくるようになった。しかしどの人もどういう顔で出てきたのかまったく思い出せない。
サブディレクトリ－をgh-pagesへ向ける運用
gh-pagesブランチの管理にはいくつか手法はあると思うのだけど、決定版はなさそうに思える。まともにやるとするとsubtreeを使うのが良さそうだが、パワフルすぎて役不足な印象だ。僕は公開するファイル群を吐くサブディレクトリーをmasterからは無視しつつ、gh-pagesブランチではそのサブディレクトリーをルートにするみたいな運用に落ち着きつつある。 example.com/ ├ dist/ │ └ index.html ├ src/ │ └ index.mustache ├ .gitignore ├ index.js └ package.json Node.jsでindex.jsを使ってsrc/index.mustacheを処理し、dist/index.htmlを吐くという形だ。ルートでは.gitignoreでdist/を無視し、普通にoriginを追加しておく。dist/で改めてg
レスポンシブ・タイポグラフィーなど
ウィンドウや画面のサイズに合わせて文字の大きさを自動的に変更するテクニックは、俗にレスポンシブ・タイポグラフィーまたはフルイド・タイプと呼ばれている。当初は僕も良いアイディアだと思い多用していたが、重要なのはビューポートの大きさではなくデバイスとの距離だろうと思い直したためもうほとんど使うことはない。当初から嫌いといっていた人はこの辺にしっかりとした意識があったのだろう。 使うことをやめた理由は、単純に技術的制約によってユーザーとデバイスの距離を知るすべがないからに過ぎない。レスポンシブ・タイポグラフィーが目指す、適切な文字の大きさを環境ごとに提示することそのものについては正しい考え方であると思う。ただ今利用されている「ビューポートが768px以下なら文字を小さめにする」というようなアバウトな実装だと問題がある。もちろんvw単位を使ったフォント・サイズ指定でも同じだ。 なぜならばデスクトッ
相対命名ルール
スケールしていく変数のバリエーションを作る際の命名規則を変えていた。今まではalphaから始めて下にどんどん増やせるようにしていたのだけど、調整コストがかかる。plus1やminus3などとすると無限にスケールできそうだが読みづらい。下に3レベル、上に5レベルくらいまででだいたい足りそうな気がするので、全部で9レベルまで作った。 Minimal Tiny Small (Medium) Large Huge Gargantuan Enormous Maximal Mediumは省略するかDefaultにする。下に3レベル、上に5レベルというのは、タイプフェイスのウェイトにおけるバリエーション(100から900)を参考にしている。 こういう相対的な命名は一般に悪だと考えられている。実際コーディングにおいて、多くの場合はその通りだ。しかしビジュアル・デザインをコントロールすることになるCSSでだ
SVGフィルターの利用
SVGフィルターの参照はCSSからurl()関数で行うことができるわけだが、やはりそのフィルターが定義されたSVGファイルが外部ファイルというのは使い勝手が悪い。今のところCSSとして書けるようになる予定はなさそうなので、どうやってSVGファイルを他のファイルへ埋め込んでやるかということになりそうだ。具体的には、HTMLドキュメントへインラインSVGとして埋め込んでも、CSSファイルへData URLとして埋め込んでも可能なようだ。 インラインSVG SVGはそのままインラインでHTMLドキュメントへ埋め込むことができるので、特に問題はない。Chrome 42とFirefox 37では共に正常に反映されているようだ。 Demo: Inline SVG .test { filter: url('#foo'); } フィルターへの参照はファイル名なしのURL識別子のみで行う。こちらも特に難しい
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
赤いやつ
