UIの3pxのズレを直すのに、Fable5が4連敗した話 ─ range inputの見えない罠

Posted at 2026-08-11

作りたかったもの

見積もりフォームにスライダーを置き、その下に1〜8時間の目盛りを並べました。つまみを「4」に合わせたら、目盛りの4の真上に来る。そういう当たり前の絵を期待していたわけです。

来ませんでした。3pxほど左にいます。しかも端に近づくほどズレが大きく見える。

「3pxくらいすぐ直る」と思って手を付けたのが運の尽きでした。そこから4回連続で「直しました」と報告しては、実際は直っていないという誤認逮捕を繰り返すことになります。手を動かしていたのは2026年6月に公開されたAIコーディングエージェントの最新世代で、数式もテストハーネスも書ける相手です。目視の勘ではなく数値で詰めているはずなのに、なぜ4回も外したのか。

結論から言うと、真犯人は2人いて、どちらもDOMの座標を見ている限り絶対に見つからない場所に隠れていました。この記事は、その捜査記録です。

この記事について

対象読者

CSSでフォーム部品を自前スタイリングしたことがある中級者

appearance: none を書いて ::-webkit-slider-thumb を触った経験がある方を想定しています。逆にそこを触ったことがない方には、先に一度スライダーを自前で組んでみることをおすすめします。

この記事で得られること

range inputのつまみが動く範囲を、数式で正確に言えるようになる
疑似要素にユニバーサルセレクタのリセットが届かない理由を、仕様の原文で説明できるようになる
位置合わせ系のUIバグを、DOM座標ではなく描画ピクセルで検証する手順が手に入る

この記事で扱わないこと

スライダーのアクセシビリティ設計
Firefox以外のGecko系やレガシーIEへの対応
CSSアニメーションによる装飾

1. 事件の概要 ─ 3pxが4回の誤認逮捕を生んだ

このセクションで分かること: 何が起きていて、なぜ簡単に見えて簡単ではなかったのか。

現場はよくある見積もりフォームです。撮影時間を選ぶスライダーと、納品枚数を選ぶスライダーが2本。それぞれの下に目盛りの数字が並んでいます。

症状はシンプルでした。

つまみの中心と、目盛りの中心が数px〜10pxほどズレる
ズレ幅は選んだ値によって変わる
端に近い値ほどズレが目立つ

この「値によってズレ幅が変わる」という点が、後から振り返れば最大のヒントでした。定数ぶんズレているのではなく、位置の計算式そのものが違うことを示しているからです。にもかかわらず、最初の3回は式ではなく配置手段をいじる方向に捜査が向かいました。

時系列にすると、こうなります。

4回とも「もっともらしい理屈」がありました。理屈があったからこそ、途中で立ち止まれなかったとも言えます。

次のセクションで、まず現場の見取り図を正確に描き直します。ここを飛ばしたことが、そもそもの敗因でした。

2. 現場の見取り図 ─ つまみは端から端まで動かない

このセクションで分かること: range inputのつまみが実際に動く範囲と、その正確な計算式。

ここが全ての基準になります。多くの人が無意識に持っている誤ったモデルはこれです。

つまみはトラックの左端から右端まで動く

違います。つまみには幅があるので、つまみの中心はトラックの端まで届きません。

CSSワーキンググループの議論スレッド¹に、この挙動を正確に説明した記述があります。WebKit系ブラウザについての説明の原文と和訳を引用します。

the border-box of the thumb moves within the limits of the content-box of the track. When the slider is at its minimum value, the left edge of the border-box of the thumb coincides to the left edge of the content-box of the track.

和訳: つまみのborder-boxは、トラックのcontent-boxの内側の範囲で動く。スライダーが最小値のとき、つまみのborder-boxの左端がトラックのcontent-boxの左端に一致する。

Firefoxについては、つまみがトラックの兄弟要素として実装されているため、基準がトラックではなく input[type="range"] 自身のcontent-boxになる、という違いも同じスレッドで説明されています。

つまり、つまみの中心が取りうる範囲はこうです。

左端: トラック左端 + つまみ幅 / 2
右端: トラック右端 - つまみ幅 / 2

値 $v$ のときのつまみ中心 $c(v)$ は次の式になります。トラックの内幅を $W$、つまみの幅を $w$ とします。

c(v) = \frac{w}{2} + \frac{v - v_{\min}}{v_{\max} - v_{\min}} \times (W - w)

この式の $w$ はborder-boxの幅です。width に書いた値ではありません。ここが後で真犯人その1になります。

目盛りをこの式と同じ位置に置かない限り、絶対に一致しません。逆に言えば、目盛り側が別の計算式で配置されている限り、CSSをどう書き換えても一致しません。

現場の見取り図が描けたところで、次はその見取り図を持たずに突入した4回の記録です。

3. 誤認逮捕の記録 ─ 4回の「直しました」

このセクションで分かること: 4回の誤修正それぞれが、なぜもっともらしく見え、なぜ外れたのか。

誤認逮捕1: CSS Gridの均等カラムに任せた

.tick-scale {
    display: grid;
    grid-template-columns: repeat(8, 1fr);
    justify-items: center;
}

一見完璧です。8つの目盛りを8等分して、それぞれの中央に置く。

しかしGridのカラム中心は「全幅を8等分した各区画の中央」です。前節の式が示す点は「両端がつまみ幅の半分だけ内側に寄った区間を7等分した点」です。等分している対象が違うので、一致するはずがありません。

数字で見ると分かりやすいです。トラック幅400px、つまみ22pxとすると、値1の位置は次のようになります。

配置方式	値1の中心位置	値8の中心位置
Grid の 8 等分	25px	375px
つまみの可動モデル	11px	389px

14pxもズレています。しかも中央付近では両者が近づくため、「なんとなく直ったように見える瞬間」がある。これが厄介でした。

誤認逮捕2: flexのspace-betweenで理論値に寄せた

.tick-scale {
    display: flex;
    justify-content: space-between;
    padding: 0 11px;
}

今度は理屈が合っています。両端を11px内側に寄せて、その間をspace-betweenで等分する。前節の式と同じ点になるはずです。

実際、この修正は半分正しかったのです。それでもズレは残りました。そして問題は、この時点で「修正完了」と報告してしまったことです。検証方法が間違っていたので、残っていたズレに気づけませんでした。

誤認逮捕3: 期待値モデルごと間違えた

「まだズレている」という指摘を受けて、今度は逆方向に走りました。paddingを外し、トラックの端から端まで目盛りを均等配置する。

そして検証ハーネスの期待値も「端から端」で書き直しました。テストは当然PASSします。自分で書いた期待値に自分で合わせたのですから。

しかし期待値そのものがつまみの可動モデルと違っていたので、実際のズレは悪化しました。

テストが通っても、前提モデルが間違っていれば無意味です。むしろテストが通ることで「直った」という確信が強化されるぶん、たちが悪くなります。

誤認逮捕4: rect座標だけで「一致」と判定した

ここでようやくパディングを戻し、getBoundingClientRect() で目盛りspanの座標を取り、前節の数式が出す期待値と比較しました。

結果は誤差0.01px以内。完全一致です。勝った、と思いました。

ユーザーの画面では、まだズレていました。orz

これが最大の教訓です。getBoundingClientRect() が返すのはDOM要素の箱の位置であって、実際に描画されたピクセルの位置ではありません。両者の間には、レイアウト計算とラスタライズという別の工程が挟まっています。

箱は正しい場所にあり、中身だけが別の場所に描かれていた。これが真犯人その2の正体です。

4. ここまでのまとめ ─ 捜査本部の中間報告

このセクションで分かること: 前半3セクションの要点を1画面で。

range inputのつまみの中心は、トラックの端からつまみ幅の半分だけ内側の範囲しか動かない
判定基準はつまみの width ではなくborder-boxの幅
目盛り側を別の配置アルゴリズムに任せている限り、式が一致しないのでズレは消えない
getBoundingClientRect() での一致は、描画の一致を意味しない
自分で書いた期待値に自分で合わせたテストは、確信だけを増やして事実を隠す

ここまでが「なぜ4回外したか」の話です。ここから先が「では誰が犯人だったのか」の話になります。

5. 真犯人その1 ─ アスタリスクは疑似要素に届かない

このセクションで分かること: グローバルCSSリセットが効かない範囲と、その仕様上の根拠。

グローバルCSSにこう書いてありました。多くのプロジェクトにあるやつです。

* {
    box-sizing: border-box;
}

そしてつまみのスタイルはこうでした。

input[type="range"]::-webkit-slider-thumb {
    width: 22px;
    height: 22px;
    border: 3px solid #fff;
}

box-sizing: border-box が効いていれば、border込みで22pxです。しかし効いていなければ、22 + 3 × 2 = 28pxになります。

効いていませんでした。

理由はW3CのSelectors Level 4²に明記されています。原文と和訳を引用します。

Pseudo-elements are featureless, and so can’t be matched by any other selector.

和訳: 疑似要素はfeaturelessであり、したがって他のいかなるセレクタにもマッチしない。

featurelessな要素の定義のセクションには、ユニバーサルセレクタについての直接の記述もあります。

For example, * will never match a featureless element.

和訳: 例えば、* はfeaturelessな要素に決してマッチしない。

MDNの解説³でも同じことが注記されています。* は要素にしかマッチせず、::before を狙いたければ *::before と書く必要がある、と。つまり * { box-sizing: border-box; } は疑似要素を一切カバーしていません。

証拠はスクリーンショットのピクセル解析で取れました。つまみの暗色円板部分がちょうど22px、外側の白枠が左右3pxずつ。合計28pxです。

前節の式に戻ります。$w = 28$ なら、可動域の内側マージンは11pxではなく14pxです。目盛りを11px基準で置いていた以上、両端で3pxズレるのは必然でした。

修正は1行です。

  input[type="range"]::-webkit-slider-thumb {
+     box-sizing: border-box;
      width: 22px;
      height: 22px;
      border: 3px solid #fff;
  }

::-webkit-slider-thumb と ::-moz-range-thumb をカンマで並べて1つのルールにまとめてはいけません。ブラウザが知らない疑似要素がセレクタリストに混ざると、ルール全体が無効になります。SCSSのmixinで中身を共有し、セレクタは分けて書くのが安全です。

犯人が1人捕まりました。しかしズレは完全には消えませんでした。共犯者がいます。

6. 真犯人その2 ─ 箱は正しく、描画だけが3pxズレる

このセクションで分かること: flexレイアウトで幅0の要素を並べたときに起きる、rectでは検出できない描画オフセット。

誤認逮捕4のときの構成はこうでした。

<div class="tick-scale">
    <span>1</span><span>2</span><span>3</span><span>4</span>
    <span>5</span><span>6</span><span>7</span><span>8</span>
</div>

.tick-scale {
    display: flex;
    justify-content: space-between;
    padding: 0 11px;
}

getBoundingClientRect() で取った各spanの座標は、数式の期待値と誤差0.01px以内で一致していました。ところが実際に描かれた目盛り線と数字のグリフは、約3px右にオフセットしていたのです。

原因の推定としては、数字テキストの最小コンテンツ幅の影響が濃厚です。ただしここは断定を避けます。確実に言えるのは、rect上の座標と描画位置が一致しないケースが実在するという事実だけです。

そして再現条件が分かれば、対処は決まります。ブラウザのレイアウトアルゴリズムに位置決めを委ねるのをやめる。

flexもgridも、要素を「いい感じに」並べるための仕組みです。いい感じにしてほしいときは最高ですが、今回のように別の要素とピクセル単位で一致させたいときには、そもそも道具の選択が間違っています。

基準となる要素と同じ計算式で、座標を直接指定する。これが答えでした。

7. 事件解決 ─ つまみと同じ数式で座標を打つ

このセクションで分かること: 最終的な実装コード。ここからは調書、つまり実際に送検したソースです。

方針は3つです。

疑似要素に box-sizing: border-box を明示し、つまみの実寸を22pxに固定する
目盛りは絶対配置にし、transform: translateX(-50%) で中心基準にする
left の値を、つまみの可動モデルとまったく同じ式で calc に書く

クリックで最終的なSCSSを展開

// つまみの実寸。box-sizing を明示したので border 込みで 22px
$thumb-size: 22px;
$tick-count: 8;

// DRY: webkit と moz で同じ見た目を使い回す。
// カンマで1つのセレクタにまとめると、未知の疑似要素でルール全体が落ちる。
@mixin range-thumb {
    box-sizing: border-box; // ← * のリセットは疑似要素に届かない
    width: $thumb-size;
    height: $thumb-size;
    border: 3px solid #fff;
    border-radius: 50%;
    background: #1f3a5f;
    cursor: pointer;
}

input[type="range"] {
    appearance: none;
    -webkit-appearance: none;
    width: 100%;

    &::-webkit-slider-thumb {
        -webkit-appearance: none;
        appearance: none;
        @include range-thumb;
    }

    &::-moz-range-thumb {
        @include range-thumb;
    }
}

// 目盛り。つまみの可動モデルと同一の式で座標を直接指定する
.tick-scale {
    position: relative;
    height: 1.5rem;

    span {
        position: absolute;
        transform: translateX(-50%); // 中心基準にそろえる

        @for $index from 1 through $tick-count {
            &:nth-child(#{$index}) {
                left: calc(
                    #{$thumb-size} * 0.5 +
                    (100% - #{$thumb-size}) * #{$index - 1} / #{$tick-count - 1}
                );
            }
        }
    }
}

calc の中身が、第2セクションの数式そのままになっている点に注目してください。$w/2$ が $thumb-size * 0.5、$(W - w)$ が (100% - $thumb-size)、比率が #{$index - 1} / 7 です。

同じ位置を2箇所で計算するなら、式は1つでなければならない。当たり前のことですが、当たり前を守れなかったので4回外しました。

8. 決め手になった鑑識手法3つ

このセクションで分かること: 主観に頼らずズレを数値化するための、再現可能な3つの手順。

手法1: スクリーンショットのピクセル解析

ユーザーから送られてきたスクリーンショットを、Python のPillowとNumPyで解析しました。「なんかズレてる」を「3.1pxズレている」に変換する工程です。

この解析でつまみの円板が22pxだと判明し、つまみの実寸が28pxであるという真犯人その1の物証になりました。

クリックでピクセル解析スクリプトを展開

"""スクリーンショットからつまみと目盛りのズレを数値化する。

責務分割:
    load_gray       : 画像ファイル -> グレースケール配列
    slice_band      : 指定した y 範囲の水平帯を切り出す
    dark_columns    : 帯の中で暗いピクセルを含む x 座標を返す
    cluster_centers : 連続する x 座標をまとめて中心を返す
    SliderGeometry  : 可動モデルから理論上のつまみ中心を計算する
    report          : 実測値と理論値を突き合わせて表示する
"""
from __future__ import annotations

from dataclasses import dataclass
from pathlib import Path

import numpy as np
from PIL import Image

DARK_THRESHOLD = 128  # これより暗いピクセルを線とみなす
CLUSTER_GAP = 3       # この px 以上離れていたら別の線とみなす


@dataclass(frozen=True)
class Band:
    """解析対象の水平帯。y 方向の範囲だけを持つ。"""

    top: int
    bottom: int


@dataclass(frozen=True)
class SliderGeometry:
    """つまみの可動モデル。座標計算の唯一の情報源にする。"""

    track_left: float
    track_width: float
    thumb_width: float  # border-box の幅であることに注意
    v_min: float
    v_max: float

    def center_of(self, value: float) -> float:
        ratio = (value - self.v_min) / (self.v_max - self.v_min)
        inner = self.track_width - self.thumb_width
        return self.track_left + self.thumb_width / 2 + ratio * inner


def load_gray(path: Path) -> np.ndarray:
    return np.asarray(Image.open(path).convert("L"), dtype=np.uint8)


def slice_band(gray: np.ndarray, band: Band) -> np.ndarray:
    return gray[band.top : band.bottom, :]


def dark_columns(pixels: np.ndarray, threshold: int = DARK_THRESHOLD) -> np.ndarray:
    return np.flatnonzero((pixels < threshold).any(axis=0))


def cluster_centers(columns: np.ndarray, gap: int = CLUSTER_GAP) -> list[float]:
    if columns.size == 0:
        return []
    boundaries = np.flatnonzero(np.diff(columns) > gap) + 1
    return [float(chunk.mean()) for chunk in np.split(columns, boundaries)]


def report(measured: list[float], expected: list[float]) -> None:
    for index, (actual, ideal) in enumerate(zip(measured, expected), start=1):
        diff = actual - ideal
        print(f"#{index:>2}  measured={actual:8.2f}  expected={ideal:8.2f}  diff={diff:+6.2f}px")


def main() -> None:
    gray = load_gray(Path("slider.png"))
    ticks = cluster_centers(dark_columns(slice_band(gray, Band(top=120, bottom=140))))

    geometry = SliderGeometry(
        track_left=0.0,
        track_width=float(gray.shape[1]),
        thumb_width=22.0,
        v_min=1.0,
        v_max=8.0,
    )
    expected = [geometry.center_of(value) for value in range(1, 9)]
    report(ticks, expected)


if __name__ == "__main__":
    main()

手法2: ガイド線を重ねて分離計測する

つまみの理論上の中心位置に、赤い1pxのガイド線をJavaScriptで重ね描きし、ヘッドレスChromeで撮影しました。

これが効きました。「つまみとガイド線」「目盛りとガイド線」を別々に測れるので、つまみは正しい、目盛りが+3pxという切り分けが一発でできます。容疑者を2人まとめて調べようとすると、どちらが嘘をついているのか永遠に分かりません。

クリックでガイド線オーバーレイを展開

/**
 * つまみの可動モデルから理論上の中心 x 座標を返す。
 * この関数だけが座標計算の責務を持つ。
 */
function thumbCenterX(slider, value) {
  const rect = slider.getBoundingClientRect();
  const styles = getComputedStyle(slider);
  const thumbWidth = parseFloat(styles.getPropertyValue('--thumb-size')) || 22;

  const min = Number(slider.min);
  const max = Number(slider.max);
  const ratio = (value - min) / (max - min);

  return rect.left + thumbWidth / 2 + ratio * (rect.width - thumbWidth);
}

/** ガイド線を1本引くだけ。座標計算は持たない。 */
function drawGuideLine(x) {
  const line = document.createElement('div');
  line.dataset.guide = 'thumb-center';
  line.style.cssText = [
    'position:fixed',
    'top:0',
    'bottom:0',
    'width:1px',
    'background:red',
    'z-index:9999',
    'pointer-events:none',
  ].join(';');
  line.style.left = `${x}px`;
  document.body.appendChild(line);
}

/** 検証したい値の一覧に対してガイド線を並べる。 */
function overlayThumbGuides(slider, values) {
  document.querySelectorAll('[data-guide="thumb-center"]').forEach((el) => el.remove());
  values.forEach((value) => drawGuideLine(thumbCenterX(slider, value)));
}

手法3: 複数点で検証する

修正後は値1・2・5・8の4点で測り直し、誤差0.5px以内であることを確認しました。アンチエイリアスの誤差レベルです。

1点だけで測ると、その点がたまたま両モデルの交差点だった場合に見逃します。誤認逮捕1のGrid配置がまさにそれで、中央付近だけを見ていたら「直っている」と誤判定しかねない状態でした。

3つの手法をまとめると、こうなります。

手法	何が分かるか	何が分からないか
rect座標の比較	箱の位置が式と合っているか	実際に描かれた位置
ピクセル解析	描画された実寸と位置	なぜそうなったか
ガイド線オーバーレイ	どちらの要素がズレているか	ズレの根本原因

3つとも別々の物証です。1つで足りると思った瞬間に、誤認逮捕が始まります。

9. よく似た手口と初動 ─ トラブルシューティング

このセクションで分かること: 同種のズレに遭遇したときの、症状からの当たりの付け方。

症状	疑うべき容疑者	初動
ズレ幅が値によって変わる	位置の計算式そのものが違う	目盛り側の式をつまみの可動モデルに合わせる
ズレ幅が全ての値で一定	親要素のpaddingやborder、基準座標のオフセット	基準となるトラックのcontent-boxを再確認する
端だけズレて中央は合う	つまみ幅の見積もり違い	疑似要素の `box-sizing` とborderの実寸を測る
Chromeでは合うがFirefoxでズレる	つまみの可動基準がトラックか入力要素かの違い	ブラウザごとに基準要素を確認する
rect検証はPASSするが目視でズレる	描画オフセット	スクリーンショットのピクセルで再検証する
修正したのに何も変わらない	セレクタリストにベンダー疑似要素が混在	疑似要素ごとにルールを分ける

10. 捜査用語集

このセクションで分かること: 本文で使った用語の定義。

用語	意味
つまみ	スライダーの、ユーザーがドラッグする丸い部分。thumbと呼ばれます
トラック	つまみが走る溝の部分。runnable trackとも呼ばれます
可動域	つまみの中心が実際に取りうる x 座標の範囲
border-box	borderとpaddingを含めた要素の外形。`box-sizing` で切り替えます
content-box	borderとpaddingを含めない、中身だけの領域
featureless	仕様上、他のセレクタにマッチしないと定義された要素の性質
疑似要素	`::before` や `::-webkit-slider-thumb` のような、DOMに存在しない仮想要素
ラスタライズ	レイアウト計算後の箱を、実際のピクセルに変換する工程
アンチエイリアス	斜線や曲線のギザギザを中間色でならす処理。0.5px前後の誤差要因になります

11. 捜査の腕を上げる3段階

このセクションで分かること: この手のバグに強くなるための学習順序。

第1段階: 箱のモデルを正確にする

box-sizing の挙動、marginの相殺、getBoundingClientRect() が何を返すか。ブラウザの開発者ツールのLayoutパネルで、実際の要素を選んで数値を読む習慣をつけると早いです。

第2段階: 描画とレイアウトを区別する

レイアウト計算とペイントが別工程であることを理解します。開発者ツールのPerformanceパネルでRecalculate StyleとLayoutとPaintを見比べると、直感が付きます。

第3段階: 視覚回帰テストを導入する

Playwrightの toHaveScreenshot() や、外部のビジュアルリグレッションツールを組み込みます。今回のバグは、スクリーンショット比較が回っていれば誤認逮捕2の時点で止められました。

TypeScript でテストを書くなら、期待値を定数ではなく実装と共有した関数から生成するようにしてください。誤認逮捕3は、期待値を手で書き換えたせいで起きました。

まとめ ─ 捜査マニュアルに書き足した4行

3pxのズレに4回負けて、手元の捜査マニュアルに書き足したのは次の4行です。

rect計算での検証は描画の検証にならない。 位置合わせ系のUIは、最終的にレンダリング結果のピクセルで検証する
テストの期待値モデル自体を疑う。 PASSしても前提が間違っていれば、それは偽陽性でしかない
疑似要素はユニバーサルセレクタのリセット対象外。 box-sizing などは個別に明示する
視覚的な位置合わせはレイアウトアルゴリズムに頼らない。 基準要素と同一の計算式で座標を直接指定する

AIエージェントは数式もテストハーネスも一瞬で書きます。今回もそこは完璧でした。外したのは、その数式が現実と結びついているかを確かめる工程です。そしてそれは、人間が4回見逃した工程でもありました。

「テストが通った」は「正しい」ではありません。今回、それを3pxぶん学びました。

JavaScript の基礎から知りたい方向けの記事です
TypeScript で型を付けながらフロントを書く話はこちらです
Python の入門記事はこちらです
NumPy を使った配列処理の基礎はこちらです

検証プロトコルそのものにフォーカスした実践編をZennに別記事として書きました。AIエージェントに視覚バグを任せるときの手順の話です。

参考文献

input type="range" の仕様と挙動については、MDNのリファレンスに最小値・最大値・stepの扱いがまとまっています。 https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/input/range
range inputのスタイリング標準化については、CSSワーキンググループのIssue 4410で議論が続いています。ベンダー接頭辞なしの疑似要素が将来どうなるかを追うならここです。 https://github.com/w3c/csswg-drafts/issues/4410

最後まで読んでいただきありがとうございました。同じ罠を踏んだ方がいたら、ぜひ何回目で気づいたか教えてください。

CSSワーキンググループの議論スレッド。WebKitとFirefoxそれぞれで、つまみのborder-boxがどの要素のcontent-boxを基準に動くかが図解付きで説明されています。 https://lists.w3.org/Archives/Public/public-css-archive/2022Apr/0049.html ↩
W3C Selectors Level 4 Working Draft、2026年1月22日版。3.6.1節に疑似要素がfeaturelessである旨、3.2.1節に * がfeaturelessな要素にマッチしない旨が記載されています。 https://www.w3.org/TR/selectors-4/ ↩
MDN Web Docsのユニバーサルセレクタの解説。* は要素にのみマッチし、疑似要素を直接マッチしないという注記があります。 https://developer.mozilla.org/en-US/docs/Web/CSS/Universal_selectors ↩

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up