minimist→util.parseArgs
Node.js v18.3.0でutilモジュールにparseArgsというものが生えた。コマンドライン引数(のような配列)をパースできる。minimistくらいで済んでいるものは置き換えられそうだ。 例えば以下のような引数と出力のコードを考えてみる。真偽値と、文字列、2語のもの、加えてオプションではない引数が最後に付くものだ。 $ node ./test.js --boolean --string 'Test' --two-words -- 'Rest' '--of' 'Test' true Test true Rest --of Test minimistの場合は以下のように書ける。 import minimist from "minimist"; const { _: rest, boolean, string, "two-words": twoWords } = minimist(
カラーEmojiのテキスト化
Emoji (ユニコード絵文字)はOSやフォントによって色々挙動が変わる。その代表的なものがOS XやiOSでのApple Color Emojiによるフルカラーの画像形式だ。概ねこのカラーで画像形式のEmojiはうまく機能するが、稀にテキスト形式である方が都合が良いこともある。そういった場合は異体字セレクターであるU+FE0Eを使うとテキスト形式に変換できる。 Demo: Can Un-color? デモはEmojiの一部をリスト化したものだ。それぞれのEmojiには全て︎が追加されている。OS XやiOSのブラウザーで見ると、いくつかのEmojiがテキスト化されていることがわかる。しかし、多くのEmojiは対応がほとんどなされておらず、カラーで画像形式のままだ。それだけならまだ良いが、一部のEmojiは元の文字がわからないようなものへと変換されてしまってもいる。 U+FE
Google ChromeでＭＳ ＰゴシックをArial+メイリオに置換する
最近のブラウザではWebフォントの利用を可能にする@font-faceをサポートしており、使われているサイトもよく見かけるようになった。@font-faceはWebフォントの利用に限らず、ローカルのフォントの再定義にも使えるので、ユーザースタイルシートで利用すればＭＳ Ｐゴシックをメイリオに置換することが出来る(Chromeでも)。これに留まらず@font-faceデスクリプターのunicode-rangeプロパティを利用すれば、英数字はArialで日本語部分はメイリオで置換するなどというわがままなことが出来る。 unicode-rangeプロパティはグリフのコードを範囲指定することによってsrcプロパティで指定されているフォントのどの部分を利用するかを決定するもの。つまりArialから英数字(PDF: Basic Latinと呼ばれる範囲)を取ってきてＭＳ Ｐゴシックを置換する場合はGo
メモ(2018年4月8日)
日付けをタイトルにするのもそこそこ面倒なので、Emojiにすることにした。過去記事も変える。夢も🌃にしたい。変えよう。 Emojiはたまにどうやって出せばいいのかわからないものがあるのが困る。IMEの変換頼りだと顕著で、「ベッド」で「🛌」が出でこなかった時は絶望した。iOSのようなEmojiキーボードくらいしか解決方法はないのかもしれない。 Emoji App on Windows 10 日本語のWindows 10では、まずEnglish (United State)の言語パックをインストールする必要がある。そのうえでWin+Spaceで入力方式を「英語 (米国)」に切り替えてからWin+.を押すとEmoji入力補助アプリが出てくる。これを入力方式の切り替えなしにスッと出せると良いのだが、出し方がわからない。
hsl()とcalc()、そしてCustom Propertiesを使った色の生成
CSSでの色については単純な変数だけでは少し足らない。それはCustom Propertiesがあったとしても同じで、論理的に操作したいという欲求があるからだ。少し明るくしたいとか、ここはビビットにとか、補色から30度近づけたい(Triad)とか、計算できるものを計算で生成できると良いわけだ。そこで明るさや鮮やかさをベースに色を定義できるhsl()関数とcalc()関数を組み合わせ、さらにそれをCustom Propertiesを通して合成することで色を生成するというアイディアを考えた。既にChrome 54やSafari 10では実現可能だ。 Demo: Generating Colors hsl()そのものを計算することはできないので、色相・彩度・明度をそれぞれ定義し、それを計算するという方針になる。最終的にCustom Propertiesを駆使してhsl()に合成している(本当はル
ファイル記述子がfs.readFile()等でサポートへ - Weblog - Hail2u.net
Node.js v5のリリース案を見ていたところ、fs.readFile()等の第一引数でファイル記述子(file descriptor)がサポートされるようになるようだ。便利極まりない/dev/stdinなどがない環境(Windowsとか)で標準入出力の読み込みが簡単になるのかなと想像している。 今までは標準入力を一気読みしようとするとこのようなコードを書く必要があった。 var fs = require("fs"); var fd = process.stdin.fd; var len = fs.fstatSync(fd).size; var buf = new Buffer(len); var input = buf.toString("utf8", 0, fs.readSync(fd, buf, 0, len, 0)); もちろんこれと同じことをやってくれる便利パッケージがいっぱい
ドットで始まるファイルのWindowsでの作成方法 - Weblog - Hail2u.net
チャットの類いを見ているとたまに「Windowsでドットで始まるファイルが作れないんだけど」というような発言を見かけることが多くなった。Windows 10のおかげかSurfaceの好調さか、ウェブ開発でWindowsを使っている人が増えつつあるようで、こういう質問が出てくるのかもしれない。簡単に言うと.filename.と最後にもドットを付けると、それが削除されてドット始まりのファイルがWindowsでも簡単に作成できる。 この手法はたいていのケースで利用できる。最後に拡張子の変更を警告するダイアログが出るが、それはだいたいそうなので気にならないだろう。 .bashrc. will become .bashrc これはもう知っているか知らないかの問題にすぎないので、知っていると便利だぞ、という話だ。かなり前のWindowsからこの手法でいけたと思う。僕の記憶が定かならばWindows M
NovaフォントとProフォント他
Windows 10ではデフォルトでもいくつか新しいフォントが加わっているが、欧米向けには特別に新たなフォントが提供されている。それらはオプション機能から機能の追加を選択し、ヨーロッパ各国語追加フォントを探してインストールすると使えるようになる。 Arial Nova Georgia Pro Gill Sans Nova Neue Haas Grotesk Rockwell Nova Verdana Pro 追加されるのは以上の6ファミリーだ。Novaフォントはウェイトの充実はあるものの正直期待外れで、Neue Haas Groteskも高DPI環境下なら……という程度であまり魅力的ではない。 その一方でGeorgia ProとVerdana Proはかなりのクオリティに感じる。Georgia ProはGeorgiaが元々優れていたためあまり違いは感じないが、見やすさを失わずにヒゲ(セリフ
CSS Transformによるセンタリングのベスト・プラクティス
上下左右のセンタリングには様々な手法が編み出されてきた。最近はCSS Transformを使う方法がメジャーになりつつある。コンテナーとセンタリングしたい要素のサイズが共に不明でもうまくいくところなど、そこそこ万能感があるのがポイントだろうか。このCSS Transformによるセンタリングは左下に動かしてから右上に戻すパターンと、その逆の右上に動かしてから左下に動かすパターンがある。どちらでも理論的には上手くいくが、ベスト・プラクティスとなりうるのは後者だけだろう。 Demo: Centering Unknown with CSS Transform (top/left) このデモは実際に不具合が起こりうるパターンになっている。センタリングする要素をtopとleftプロパティーで動かした後、transform: translate(-50%, -50%)で元に戻しているわけだが、Inte
CSS Transitionを使ったスムーズにスクロールしてトップに戻る機能
前に作ったスクロールした時に位置固定のロゴをトップに戻る機能にすり替えるものを少し手直しして再導入した。今回はスムーズにスクロールさせようかと色々考えていたが、やはりJavaScriptでscrollTo()を制御するのはコストが高い。CSSならどうだと試行錯誤したところ、どうやらbody要素への負のマージンをCSS Transitionで滑らかに変化させれば良いようだ。 Demo: Scroll Smoothly with CSS Transition デモのページにはダミーテキストの各セクションの最後にそれぞれ⇑ Back to Topというリンクがある。それをクリックすると1秒かけてスムーズにスクロールしながらトップに戻る。トリガーとスクロール自体はJavaScriptで行っているが、スクロールのアニメーション自体はCSS Transitionで行っている。具体的には以下のような処理
src属性のないimg要素と擬似要素
img要素は置換要素なので、現在の安定仕様では明記されてはいないものの歴史的な事情により::before/::after擬似要素による挿入は行えない。しかしChrome 41で遊んだところ、src属性がない場合は挿入することができるようだ。Internet Explorer 11やFirefox 36、Mobile Safari 8では行えない。 Demo: img element w/o src attribute and pseudo element Chrome 41ではalt属性の値である“img without src”という文字列の前に::before擬似要素で仕込んだ“pseudo element for img!”という文字列が挿入されていることがわかる。Chrome 43でも同様だった。 src属性がないとimg要素がパース・エラーで不明な要素にでもなるのかなと想像したが
MessageFormat
Pluralization for JavaScriptという名詞の複数形についての記事を読んで、MessageFormatという仕組みがあることを初めて知った。複数形や三単現、性別による言葉遣いの違いなどを言語ごとに定義しておき、出力する際にその定義を利用して自然な結果になるようにする仕組みのようだ。 MessageFormatの仕組み自体もわかりやすくて良かったが、記事に書かれているようにちょっとしたローカライズにおいても威力を発揮しそうなのが良さそうに思えた。昨今のウェブサイトやウェブアプリにおいては、完全な国際化やローカライズよりも重要なUIパーツの正確なローカライズがまず必要になっているので、そういう小さなところから使える仕組みであるMessageFormatはポイントが高いだろう。国際化はともかく、完全なローカライズくらいまではスケールすると思えるので、規模によっては使えないと
Polyforest
三角ポリゴンを使ってモザイクっぽい画像を作るブームが結構前から来ていて、長続きしている気がする。そういう画像を作るアプリもあるし、単純な背景パターンとして提供してる人もいる。遅まきながら僕も作る工夫をいろいろ考えておこうかなと、このような画像をヒイコラ作った。SVGで。 作り方はまだ安定していないので、その解説はまた今度。こういった幾何学的な画像はSVGがもっとも得意とする分野なわけだけど、実際に三角ポリゴンを組み合わせるだけだときれいに埋まってくれない。理由は斜めになった辺同士の境界の部分に隙間がどうしても出来てしまうようにレンダリングされてしまうから。 Polyforest (not Optimized) 最初の画像のように隙間を埋めるには、あらかじめ三角ポリゴンを重ねながら作るという手もあるけど、単純にstrokeとstroke-width属性を使って重なりあうようにしてしまうのが手
Segoe UI Mono
Segoe UIに等幅バージョンがあることは前から知っていたのだけど、購入するしか入手方法はないのかなと思っていた。ちょっと調べた所、どうやらXboxのゲームへの同梱を許可する形で再頒布パッケージとして公開されているようだ。 等幅フォントとしては悪くはないけど、全体的に大ぶりで、コーディングにおいてはConsolasの方が全般的に優れているような印象。1ilIあたりは識別可能だけど、0にドットや斜線がなく、大文字のOと区別がほとんどつかないのもマイナス。ウェブページでSegoe UIとセットで使うとするとなかなか良いけど、両者共にそういうためには頒布されてない。 スッキリと見やすい感じではあるので、コードの一部を画像にしてなんかに使うみたいなケースにはうまくマッチしそう。 話題沸騰中のアレを引き合いに出すまでもなく、サンセリフは選択肢がそこそこ増えてきたので、今後はセリフと等幅の充実に期待
飛び出す要素をセンタリング
一年くらい前からtop/right/bottom/leftプロパティーを使った水平・垂直センタリングをよく使うようになった。margin: 0 autoによる水平センタリングと同じように、理解できればわかりやすい手法なので気に入っている。ただrelativeを組み合わせたものと違って、センタリングしたい要素が親要素を飛び出す大きさの場合、左上が揃うように配置されるのがちょっと気になる。センタリングしたい要素の中央と親要素の中央とを合わせたい。 Demo: Centering Overflowed Element デモではとりあえず水平方向に飛び出すケースを考えている。見ればわかるようにセンタリングしたい要素が飛び出す場合、top/right/bottom/leftプロパティーを使った方法の場合は左が揃う。対してrelativeを使った方法の場合はセンタリングしたい要素の中央と親要素の中央が
right: 100%か負のマージンか
これまでCSSにはレイアウト方法があまりなかった。これからはFlexible Box LayoutやMulti-column Layout、Grid Layoutを始め、positionプロパティーに使える値の拡充などもあり柔軟に行えるようになるだろうが、それはけっして既存のレイアウト方法が不必要になるということではない。選択肢が増えると受け止めるべきだ。例えばright: 100%や負のマージンを使って親要素の外側左にレイアウトする手法はそのまま使い続けることになるだろう。 ほとんど同じレイアウトを実現するright: 100%と負のマージンの使い分けを通して、レイアウト方法の選択をどう行うべきかという基本的な思想を解説することにより、今後増えてくるレイアウトの選択肢にどう相対すべきかがわかるのではないかと思う。そしてそれはCSSプロパティーの意図された使い方を理解するということでもある
CSSでフォント・ファミリーのショートカットを作る
最近のブラウザーではlocal()を使ってフォント・ファミリーのショートカット(的なもの)を作ることができる。CSS Fontsモジュール仕様のsrcプロパティーの項にも思いっきり書いてあるんだけど、今まではそんなに必要なかったのであまり使われていない。5ウェイト展開なヒラギノ角ゴのiOS 7へのバンドルと、3ウェイト展開の游ファミリのWindowsへのバンドルにより必要性が少し増えた気がする。 特に游(ゴシック|明朝)はWindows 8.1とOS X 10.9でファミリ名が違う上、少し古いFirefoxでのアレとか、OS Xには細字がないとかもあるので、色々考慮するとfont-familyプロパティーではややこしいフォント指定を行う必要が出てくる。そうやって出来た長いリストのfont-familyは読みづらく、デバッグのしづらさにつながる。local()を使ってフォント名を作り直してや
引用元の表記
blockquote要素における引用元の表記をどうマークアップするかでWHATWGとW3Cの仕様で違いが出たので、俄然盛り上がってきた。昨日公開されたHTML5 Doctorの記事を始め、様々な人が見解を書いている。概ねシンプルなW3C版が優勢な気がする。どう決着するかには関心があるものの、現状どうするべきかについてはよくわからなくなってしまったので、それぞれどういうコードになるのかとその思想の違いをメモだけしておく。 WHATWG版では以下のようにfigure要素を使い、figcaption要素で引用元の表記をマークアップする。このウェブサイトではこっちを採用中。 <figure> <blockquote> <p>引用(いんよう、英語：citation, quotation)とは、広義には、他人の著作を自己の作品のなかで紹介する行為、先人の芸術作品やその要素を自己の作品に取り入れること。
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. つまりユニークなため再利用できないというマイナスの面がある、と。確かに再利用できない。でもこれはマイナス
hail2u.net - Weblog - floatで並べたリストのセンタリング
ページング・ナビゲーションなどでリスト項目をfloat: left;で横に並べるというのは割りと良く使われると思う。並べること自体は特に難しいわけではないが、その並べたリスト全体をセンタリングしようとするとちょっとややこしい。display: inline-block;を使う手法やdisplay: table;を使う手法という黒魔法的(私見)な手法で実現可能だが、position: relative;でもいける。 ややこしい理由は簡単で、センタリングでよく使われるtext-align: center;やmargin: 0 auto;といった手法が通用しないから。検索するとすぐ出てくる比較的メジャーなdisplayで頑張る方法もわかりやすいし悪くはないのだけど、同一セレクタ内で複数のdisplayを駆使する必要があることやzoomマジックなどを併用する必要があることからコードがややこしくなる
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
