Chrome 88やEdge 88でのfont-size: calc(2ch)
利用しているフォントの「0」のグリフ幅によって変わるch単位は、実装されて久しい。これを、font-sizeプロパティーでcalc()やclamp()など計算するCSS関数を通して使うと、Chrome 88やEdge 88で想定より大きくなってしまうバグがあるようだ。Firefox 85やSafari 14では問題なく、またwidthプロパティーなどでなら発生しない。 .test .raw { font-size: 2ch; } .test .calc { font-size: calc(2ch); } このようなコードで再現する。同じ大きさ(16px前後)になるはずだが、Chrome 88やEdge 88で.calcの方が倍の大きさになってしまう。例えばNoto Sans CJK JPだと、17.76pxのはずが35.52pxになった。 2度計算してしまっているような気がするが、3chに
JavaScriptがなくなった
もう相対日時にするやつとutm_*を削除するやつしか動かしてなかったので、JavaScriptをなくした。再構築したので消えている。 最近はデフォルトでJavaScript無効でも生きていけるようなインターネットになってきた気がする。HTML Living Standardのおかげかなって思ったけど、どちらかというとSVGやFlexboxやなんやのおかげなのかもしれない。 話題の遅延読み込み(loading属性)もそういうやつっぽいけど、挙動としてどうにもならない問題があるような気がしてならない。回線が安定していて、無制限で、マシンパワーも余っているなら、遅延読み込みする必要はないけど、それをブラウザーが知ることは難しそう、というような話。「多分あと10分くらいはハードウェアやインフラをこれくらいまで使えますよ～」みたいなのがOSがブラウザーへ教えないといけないのかな。 遅延読み込みはペー
スクロールは制御するな - Weblog - Hail2u.net
WWD Japanのウェブサイトがリニューアルして、スッキリした見やすそうな印象のものに変わった。しかし実際のところ見やすさは見せかけだけで、ナビゲーションをクリックしても見当違いのタブに切り替わったり、ニュース一覧からニュースをクリックしたら、要約ページへ移動するだけで、本文へはもう一度クリックしなければならなかったりする。中でもひどいのがMobile Safariでの閲覧だ。 このウェブサイトではスクロールをほぼ自前で制御しようとしているため、常にこのようにMobile SafariのURLバーとツールバーが上下にそれぞれ表示され続ける。その上、最上端にロゴとグローバル・ナビゲーション、最下端に広告がそれぞれ固定位置であるので、コンテンツの領域がかなり制限されている。iPhone 5SやSEどころか6+や7+でさえも致命的なのではないかと感じられる狭さだ。 とにかく文書を読ませようとい
Uptime RobotからiOSの通知へ
URLではイベントとしてuptimerobotなどを指定しておく(落ちた時と復活した時の両方で送られると思うので、website_downとかは付けないほうが良い)。また最後に?をつける必要がありそう。Makerチャンネルには3つまでしか値を渡せないので、モニターの名前(monitorFriendlyName)とエラーの詳細(alertDetails)が確定だろう。後で修正することはできないので、間違えた場合は消して作りなおす必要がある。 作り終わったら忘れずに各モニターの設定から通知先でIFTTT Makerにチェックを入れておく。 IFTTTレシピはトリガーがMakerチャンネルでアクションがIF Notificationsチャンネル(最近iOSとAndroidの通知チャンネルが統合された)になる。Makerチャンネル側では先ほどAlert ContactのURLで指定したイベント名u
CSS Transformによるセンタリングのベスト・プラクティス
上下左右のセンタリングには様々な手法が編み出されてきた。最近はCSS Transformを使う方法がメジャーになりつつある。コンテナーとセンタリングしたい要素のサイズが共に不明でもうまくいくところなど、そこそこ万能感があるのがポイントだろうか。このCSS Transformによるセンタリングは左下に動かしてから右上に戻すパターンと、その逆の右上に動かしてから左下に動かすパターンがある。どちらでも理論的には上手くいくが、ベスト・プラクティスとなりうるのは後者だけだろう。 Demo: Centering Unknown with CSS Transform (top/left) このデモは実際に不具合が起こりうるパターンになっている。センタリングする要素をtopとleftプロパティーで動かした後、transform: translate(-50%, -50%)で元に戻しているわけだが、Inte
Mobile Safari 8でposition: fixedした擬似要素が完全に位置が固定されない
Style GuideをMobile Safari 8で確認していて気づいたのだけど、擬似要素をposition: fixedした場合、スクロールしている最中は位置が変化しないようだ。つまりスクロールを止めた後で位置がアップデートされるので、他のブラウザーのように完全に位置が固定されない。 Demo: Fixed Pseudo Element on Mobile Safari 8 デモでは見出しと概要に続く「Lorem Ipsum」という文字列が擬似要素として仕込んである。これを同時にposition: fixedで位置固定しているが、Mobile Safari 8ではスクロール中は位置が変化しないので、画面外にスクロールアウトしてしまう。スクロールを止めると位置固定で期待される位置に改めて描画される。 擬似要素ではない場合は今まで通り完全に位置が固定される。 パフォーマンスの向上を受けて
StatusCake
was it up?が停止してからウェブサイトの死活監視にはUptime Robotsを使っていたんだけど、StatusCakeをここ1か月程併用している。無料で無限の死活監視が行え、通知先もメールだけでなくTwitterや特定のURLへのPOST等などに複数設定できたり、DNSの不達なんかもテストできたり多機能。まだ落ちてないのでちゃんと通知来るかわからない！ このウェブサイトの読み込み時間のグラフ 死活監視と同時にパフォーマンス・チェックとして読み込み時間のチェックも行ってくれ、テスト結果は主にそのグラフで表示される。一応普通のブラウザーでパフォーマンスを測ってくれるようにできたりするけど、無料版ではテストを行うサーバーがランダムにしか設定できないので数字はあんまり役に立たなそう。他テスト設定で特徴的なのはエラーとみなすステータスコードを細かく設定できるところくらい。 ウェブUIはちょ
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. つまりユニークなため再利用できないというマイナスの面がある、と。確かに再利用できない。でもこれはマイナス
あなたのサービスが落ちた時にユーザーになんと言うべきでしょうか？
Translation of: What should you tell your users when your service is down? by David McKenney つい最近、私達は多くの有名なサービスが完全に停止するという状況に遭遇しました。この出来事は、こういった何か不具合が起きた時にユーザーとどうコミュニケーションをとるかについて学ぶ良い機会なのではないかと思います。あの時InstagramとAirbnb、IFTTT、Vineがユーザーに送った通知は以下のようなものでした: これらから何を学べるのでしょうか？ これらすべてのツイートは、何か不具合が起きた時のコミュニケーション方法として一般的なパターンを採用しています: 技術的な専門用語を避け、ユーザーに簡潔に、そしてフレンドリーに伝えること みなさんの多くが不具合に遭遇していることを確認しました。 問題に気づいた
フロートした要素に続くリスト
通常フロートした要素とデフォルトの文書フローで配置された要素は重なります。CSS 2.1仕様書のフロートの解説にある図Dがその例です。なので、通常フロートした要素に続くリストはそのブレット(や数字等)がフロートした要素の下に隠れてしまいます。この挙動には結構困らされることが多いですが、実はoverflow: autoとすると簡単に回避できます。 Demo: ul after floated element デモのようにリストにoverflow: autoするだけで、キレイにリストが配置されるようになります。overflow: autoを使った場合と使わなかった場合でどう重なりに違いが出るかわかるように、outlineプロパティーでピンクの線を引いておきました。 これはブラウザの挙動がたまたまそうなったということではなく、実にさり気なくCSS 2.1仕様書にも記述があります。 The bor
:targetでpadding-top
ちょっと何を言っているのかよくわからないですね。つまり:target擬似クラスでpadding-topを使うことによって、アンカーでページ内ジャンプ(<a href="#foo">...</a>とかで飛ぶやつです)した時に上部に余白をとってやろうというアイディアです。こうすることによって上部にメニューを固定していても重ならなくすることができるでしょうし、そうでなくても多くの場合ジャンプした先のコンテンツに対してキレイに余白が確保できるんではないかと。 Demo: Refine Anchor Jump with :target Section #4に飛ぶリンクはデフォルトのもので、描画領域の上端に見出しが来てしまっています。Section #7に飛ぶリンクが:targetを使って改良したもので、上部に少し余白が確保されていることと思います。 #test7:target { padding-t
rotate(360deg)
WindowsのGoogle ChromeでWebフォントを使うと、その縁がギザギザになることが多い(もちろん非ClearTypeのフォントならローカルフォントでも)。今まではそれの解消のためにtext-shadowプロパティで軽く文字色と同じ影をつけてやって誤魔化していたが、-webkit-transformプロパティでrotate(360deg)として一周回すといい感じにフォントにアンチエイリアスっぽいぼかしがかかることを発見した。少し前に書いたCSS3のtransformを使ったフォントの変形の派生。テクニックというよりもハック寄り。 Demo: Beautify MS PMincho on Google Chrome デモではWebフォントではなく、常にギザギザで悲しいＭＳ Ｐ明朝を使ってさしあげた(グリフが細かいためぼかしのかかり方がよく見え、わかりやすいので)。 scaleY(
リスト項目内に見出し
2つ前のエントリで書いてしまったウェブページ全体の見出しをli要素にぶち込むという案に関してTwitterで言及されていた。これについてはエントリを書いた後ちょっと考えたので、返答がてら(簡単にリプライしといたけど)エントリにする。 まずTwitterでの言及について。HTML 4.01においてdt要素は、 <!ELEMENT DT - O (%inline;)* -- definition term --> なので、インライン要素しか含めることが出来ない。つまり、そもそも見出しを入れることは許可されていない。対してli要素だと、 <!ELEMENT LI - O (%flow;)* -- list item --> なので、だいたい何でも入れることが出来る。つまり文法的な話だとli要素ならOKで、dt要素だとよろしくないとなる。これはHTML5でも似たような話で、dt要素の内容モデルはフ
リデザインからの……
公開後の調整をまとめておく。備忘録。と書いておけばだいたい許される法則。 「h」が「n」に見えると不評だったロゴの変更 lelim Lightからlelim 300で、製作した人は同じ。Lightの矩形に収まる感じが好きだったけど、これはこれで好き。 ロゴのスライド方向を下方向(パチスロとかと同じ)に変更 こちらの方が自然な気がする。ロゴのスライドはCSS TransitionとFlicker Free (Flickerless) Image Replacementとか呼ばれているテクニックの組み合わせで簡単に実現できる。元画像の配置を工夫すれば横にも斜めにもスライドできる。 Reset CSSの微調整 プロパティをまとめたりとかいらなそうなものを削除したりとか。一から書き直した方の使用は保留。 overflow: auto;はやっぱり安定しないのでhiddenに変更 Firefox 3.
リデザイン @ 2011-02-07
へるべちかにゅ～！ CSSが20KBオーバーと肥大化してきたのでダイエットしようと思ったらいつの間にか全部書き換えていた。でも頑張っても13KBにしかならなかった。 以下、覚書。 Reset CSSの変更 リクエストの削減のためにYUIのCSS ResetとCSS Fontsを使うのをやめ、CSSファイルにEric MeyerのReset CSSを参考にしたものをベタに書くことにした。Reset部分はパブリック・ドメイン。欲しかったらCSSのソースからコピペでどうぞ。meyerwebのReset CSSとの違いは、 address, caption, cite, code, dfn, em, strong, th, var { font-style: inherit; font-weight: inherit; } h1, h2, h3, h4, h5, h6 { font-size: 1
結局どうすればいいの？ - Dive Into HTML5
Translation of: What Does It All Mean? - Dive Into HTML5 Diving In The Doctype The Root Element The <head> Element Character Encoding Friends & (Link) Relations rel = stylesheet rel = alternate Other Link Relations in HTML5 New Semantic Elements in HTML5 A long digression into how browsers handle unknown elements Headers Articles Dates and Times Navigation Footers Further Reading 訳注 Diving In この章で
安全な@font-faceの書き方(抄訳)
Internet Explorerではかなり昔からあった埋め込みフォント(@font-faceによるフォントの参照)の機能は、Safari 3とFirefox 3.5で有効になったことから急速に話題になることが増えた。ようやく時代がMicrosoftに追いついてきた感じですね。その書き方は大筋では一緒なのだが、細かな仕様の違い、というかIEがEmbedded OpenTypeしかサポートしていないことから工夫が必要になる。その工夫をBulletproof、つまり将来にわたって安全であろうという観点で短くまとめたBulletproof @font-face syntaxというすごく参考になったエントリがあったので訳しておく。語調などは超訳なので、原文とニュアンスが変わっているかもしれない。 安全な@font-faceの書き方 以下は訳注と私見。 条件付コメント 面倒くさいというのはわからなく
hail2u.net - Weblog - 圧縮フォルダを使わないようにするとエクスプローラがキビキビ動く
Windows XPの圧縮フォルダというほとんどの人が使っていないと思われる機能(私見)を解除したら、エクスプローラがキビキビ動くようになった気がする。というようなことを某所で言ったら、試した人が「すげぇかるくなった kyo++」とかインクリメントしてくれたので、エントリにしておこうとか。 圧縮フォルダ機能の解除の方法は、コマンド プロンプトで、 regsvr32 /u zipfldr.dll regsvr32 /u cabview.dll と、入力してやるだけ。多分再起動は必要ない。 これにより特にエクスプローラのツリー表示なんかが高速化する気がする。エクスプローラ以外ではファイラーっぽいので特に高速化する感じで、僕の環境ではACDSeeのツリー表示がとんでもなく高速化した。 また、デフォルトの検索機能が圧縮フォルダ内を探さなくなるため高速化し、いつまでたっても終わらないということは少な
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
fixed in relative