SVGをインラインでHTMLに含める場合、SVGOを通した方が良い。HTMLファイルのサイズへ与える影響が大きいからだ。しかしデフォルトの設定だと、色々消えたり消えなかったりするのでそこそこ設定が必要になる。特にimg要素のalt属性に近いtitle要素のid属性とそれを参照するaria-labelledby属性は残さなければならない。 SVGOの設定はYAMLで書き、CLIに--configオプションでそのファイル名を渡して実行する。 $ svgo --config=.svgo.yml -o - src/img/logo.svg YAMLでの設定は以下のようにした。 plugins: - cleanupIDs: false - removeUnknownsAndDefaults: unknownAttrs: false - removeXMLNS: true SVGの要素から参照されてい

日本語の文章の場合、両端が揃っているとおさまりが良い。CSSではその両端揃えを行うためにtext-alignプロパティーにjustifyという値が用意されている。完全に日本語だけの段落ならほぼ100%、和欧混在の段落でも9割以上の段落で想定通り機能するが、まれに無残な結果になる。それは自動折り返しで長めの英単語が行頭に来る場合だ。 両端揃えは文字と文字の間を開けることで行われる。日本語だけの段落の場合、ほとんどどこでも改行することができる上、行送りの禁則処理が起こっても最大2文字分なので、行の長さが十分にあればその調整は認識されないだろう。問題は和欧混在の段落だ。 Demo: Justifying Problem この「contemporary」くらいの長さの単語だとまだマシな方で、あまり問題が起こることはない。しかし、このウェブサイトのようにcompareDocumentPosition

OneDriveを特に使うこともなく一年近くになったので消すことにしたが、完全に消すことはできなかった。しかしホーム・ディレクトリーやエクスプローラーのサイドバーからは削除することができたので、まずまずといったところだ。きっとOSの更新時に復活したりするであろうので、記録しておく。 まずは常駐させてしまっているのなら終了させておく。 OneDriveSetup.exe スタートメニューからOneDriveへアクセスできないようにするには、セットアップ・ファイルを使ってアンインストールらしきことを行う。コマンド・プロンプトを管理者権限で起動し、以下のコマンドを実行する。 C:\Windows\SysWOW64>OneDriveSetup.exe /uninstall コマンド・プロンプトを管理者権限で起動する時は、スタート・ボタン(まだこの呼び方でいいのかな？)を右クリックして出てくるメニュ

Sassの変数スコープの仕様では、ローカル・コンテキストからグローバル変数を上書きできていた。LESSでは多くのプログラミング言語と一緒で上書きはできないという素直な仕様になっている。Sass 3.3では上書きしようとすると警告が出るようになり、!globalフラグを使い明示的に上書きしていることを教える必要があるようになった。将来的には仕様が変更され、警告なしでLESSと同じ挙動になるようだ。 Sassではローカル・コンテキストでグローバル変数を上書きでき、そのスコープを抜けてもそのままになる。 $color: #f00; .test-local { $color: #0f0; color: $color; // #0f0 } .test-global { color: $color; // #0f0 } 対してLESSでは上書きされない。 @color: #f00; .test-loc

印刷時には幅制限を解除して、用紙いっぱいに文字が並ぶようにしていた。しかしこのウェブサイトでも採用している45から75文字のルールはそもそも紙媒体での話だし、レスポンシブ・ウェブ・デザインの観点からもディスプレイと紙で折り返し幅を合わせた方が一貫性がありそう。ということでと同じ幅で折り返すように変えた。 $width-content: 36rem; main { max-width: $width-content; } @media print { body { margin-right: auto; margin-left: auto; max-width: $width-content; } main { max-width: none; } } レイアウトがそこそこ複雑なので、main要素に対する幅制限の解除はそのままにして、body要素の幅を制限するようにした。併せて印刷位置をセン

アクティブなナビゲーション項目、つまり現在のページへのナビゲーション項目はclass属性を使ってactiveなどと付けられることが多い。特に間違ってはいないんだけど、いまいちピンとこない。というかしっくりこない。大体は流されてそうしているけど、このウェブサイトではmark要素を使ってる。 HTML5仕様ではmark要素は以下のようになってる。 The mark element represents a run of text in one document marked or highlighted for reference purposes, due to its relevance in another context. mark要素が含まれる要素のコンテキストとは別のコンテキストでの関係性をハイライト等で表したい時に使うと解釈してる(同じコンテキストならemやstrong、そしてb

Gitを叩くGruntプラグインはいくつかあるけど、Grunt管理外のディレクトリにあるGitリポジトリでも気軽に叩けそうなのがなかった。大体GruntのルートとGitのルートが一致していることが想定されている。それでもGruntのルートが下流ならなんとかなるけど、逆の場合はどうにもならない。しょうがないのでファイルを指定してタスクを走らせたら、指定の作業フォルダへ移動してからそのファイルをaddしてcommitするだけのGruntタスクを書いて使うことにした。 Download: grunt-gitcommit.js オプションはcwdとmessageの2つ。cwdでコミットしたいGitリポジトリのルートを、messageでコミット・メッセージのプリフィックスを指定できる。 gitcommit: { options: { cwd: '../../weblog/', }, publish:

grunt-initがファイルをカスタマイズしてコピーするcopyAndProcess()ではgrunt.template.process()を使っていて、それはgrunt.util.normalizelf()を最後に呼んでいる。これによりLFのファイルが環境に合わせてノーマライズされるようになっている。そのためWindowsでは常にCR+LFでファイルが吐かれる。 LFで吐かれるようにするにはgrunt.util.linefeedで\nを設定してやれば良いのだけど、grunt-initにはこの設定を変える方法は用意されていない。Issueも立ってるけどGruntに文句言えみたいに返答されていて、それ違うし！　みたいな。と、いうことでこれをどうにかしてみようと。 View Commit: Set grunt.util.linefeed for copyAndProcess() CR+LFで

blockquote要素における引用元の表記をどうマークアップするかでWHATWGとW3Cの仕様で違いが出たので、俄然盛り上がってきた。昨日公開されたHTML5 Doctorの記事を始め、様々な人が見解を書いている。概ねシンプルなW3C版が優勢な気がする。どう決着するかには関心があるものの、現状どうするべきかについてはよくわからなくなってしまったので、それぞれどういうコードになるのかとその思想の違いをメモだけしておく。 WHATWG版では以下のようにfigure要素を使い、figcaption要素で引用元の表記をマークアップする。このウェブサイトではこっちを採用中。 <figure> <blockquote> <p>引用(いんよう、英語：citation, quotation)とは、広義には、他人の著作を自己の作品のなかで紹介する行為、先人の芸術作品やその要素を自己の作品に取り入れること。

Gruntをよく使うようになったけど、プロジェクトの中心にどっかと存在していると不自由なことが多い気がするなーと感じている。Gruntべったり、つまりプロジェクトをGruntに強く依存させるとポータブルである保証のあるタスクだけを使う(書く)ことを強いられる。Gruntはその雑な自由度が良い所で、そこに何かしらの制限が加わってしまうのはその良さを低減させてしまうと思う。 Node.js自体にクロスプラットフォームだけどさほど書かれるスクリプトのポータビリティを意識した作りになってないような印象を持っている。そのためその上で動くGruntでポータビリティとかなんの冗談だとか思ってしまう。 Gruntの開発チームが公式にメンテナンスしているgrunt-contrib-*は確かに安定して優秀で、大体のことはポータブルなそれらで事足りたりする。だけど簡単なタスクを書いて使いたい時はもちろんあるし、

code要素の内容には途中で折返しされない長い文字列が入ることが多い。例えばinsertAdjacentHTML()であるとか。こういった文字列が行をまたぐ時、その手前にある文字(上記スクリーンショットでは「は」の文字)まで次の行に送られることがある。これはブラウザーにより挙動が違うが、CSSで大体のブラウザーで巻き込まないように調節することができる。 Demo: Force Auto-Breaking Before/After code Element Chrome 29の場合code要素の前の「は」が次の行に送られてしまう。code要素の前に句読点やカギ括弧などが来るとそれらとその前の文字までが次の行に送られたりもするので、場合によってはとても美しくない感じになってしまう。デモを見てもあまり違いがわからない感じではあるが、もっと極端な例を考えるのが面倒だった。 code::before

text-overflow: ellipsisではみ出した文字列を三点リーダーで省略できる。画面サイズのバリエーションが増え続けているので、こういったなんとなくどうにかしてくれることを期待できるCSSプロパティーは積極的に使いたい。のだけど、これとtext-align: center (right)を組み合わせた場合、テキストの開始位置がChrome 28だけ変化する。 Demo: text-overflow: ellipsis and text-align Internet Explorer 10とFirefox 23ではtext-alignプロパティーの値はどれでも同じ。Chrome 28ではcenterで少し、rightでは更にもう少しずれる。三点リーダーによる省略で余った余白をtext-alignプロパティーでどう扱うか、またはtext-alignとtext-overflowプロパ

Windows XPの圧縮フォルダというほとんどの人が使っていないと思われる機能(私見)を解除したら、エクスプローラがキビキビ動くようになった気がする。というようなことを某所で言ったら、試した人が「すげぇかるくなった kyo++」とかインクリメントしてくれたので、エントリにしておこうとか。 圧縮フォルダ機能の解除の方法は、コマンド プロンプトで、 regsvr32 /u zipfldr.dll regsvr32 /u cabview.dll と、入力してやるだけ。多分再起動は必要ない。 これにより特にエクスプローラのツリー表示なんかが高速化する気がする。エクスプローラ以外ではファイラーっぽいので特に高速化する感じで、僕の環境ではACDSeeのツリー表示がとんでもなく高速化した。 また、デフォルトの検索機能が圧縮フォルダ内を探さなくなるため高速化し、いつまでたっても終わらないということは少な

idea * ideaでエントリになっていたので、言及されていることだしうちのサイトのことだけちょっと書こうかなとか考えてみたら結構色々あって、エントリのネタになりそうだったのでまとめてみた。どっかにもちょろっと書いたけど。 実際にスタイル指定を書く前に抑えておくべき知識として以下のようなものが挙げられると思う。 ほとんどのブラウザでpreは等幅フォントで表示される ほとんどのブラウザでpreのwhite-spaceはpreになっている フォント・ファミリを指定する場合は最後にGeneric font familiesが必要になる overflow: scroll;では縦横どちらにあふれた場合でも縦スクロール・バーと横スクロール・バーが両方とも出る overflow: auto;ではあふれた方向にのみスクロール・バーが出る Internet Explorerではoverflow: auto