Clip with z-index: -1 silently does not render (snapshot and render); z-index 0 and 1 siblings are fine

クローズ
  • 何か問題がありますか？
#4,366 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

@user-github-me がすでに取り組んでいます。

2026年10月8日 から。

  • #5201 @user-github-me による — オープン

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
48/100
issue の種類
バグ
明瞭さ
おおむね明確
活発さ
活発
技術スタック
css, html, typescript
領域
frontend, web-dev

調査の方向性

Read docs/AGENTS.md first, then verify the plain-browser control and the HyperFrames snapshot/render commands. Inspect docs/concepts/data-attributes.mdx and docs/reference/html-schema.mdx alongside the paint-order guidance; done requires an agreed documentation-versus-diagnostic scope, verified examples, and passing documentation validation and link checks.

索引モデルが issue の本文から書いたものです。

説明

triage/needs-design

Summary

A clip with z-index: -1 does not render. Sibling clips with z-index: 0 and z-index: 1, identical in every other respect, render correctly. The element is silently absent — no warning from lint, validate or render, and the render exits 0.

This affects both snapshot and render, so it is not capture-specific.

Affected

[email protected].

Reproduce

index.html — three absolutely-positioned full-width bands, identical class="clip" attributes, differing only in z-index:

<!doctype html>
<html lang="en">
  <head><meta charset="UTF-8" /><meta name="viewport" content="width=640, height=360" />
    <style>
      * { margin:0; padding:0; box-sizing:border-box; }
      html, body { width:640px; height:360px; overflow:hidden; background:#0a0a0a; }
      #root { width:100%; height:100%; }
      #underA { position:absolute; left:0; top:0;     width:640px; height:180px; background:#f5e6c8; z-index:-1; }
      #underB { position:absolute; left:0; top:180px; width:640px; height:180px; background:#20a0f0; z-index:0;  }
      #over   { position:absolute; left:20px; top:20px; width:60px; height:60px; background:#d02020; z-index:1;  }
    </style>
  </head>
  <body>
    <div id="root" data-composition-id="main" data-start="0" data-duration="1" data-width="640" data-height="360">
      <div id="underA" class="clip" data-start="0" data-duration="1" data-track-index="0"></div>
      <div id="underB" class="clip" data-start="0" data-duration="1" data-track-index="1"></div>
      <div id="over"   class="clip" data-start="0" data-duration="1" data-track-index="2"></div>
    </div>
  </body>
</html>

hyperframes snapshot . --at 0.5 --no-end -o snap --describe false
hyperframes render . -o out.mp4

Measured

Mean RGB sampled inside each band:

element authored snapshot render
z-index: -1 (245,230,200) (10,10,10) (7,9,9)
z-index: 0 (32,160,240) (32,160,240) (29,157,238)
z-index: 1 (208,32,32) (208,32,32) (206,30,27)

(10,10,10) is the bare body background — the band is not drawn at all, rather than drawn and covered. The z-index: 0 and z-index: 1 bands land on their authored values in both paths (the small render deltas are encode rounding).

Expected

Either the band renders, or something says why it does not. Per CSS painting order a negative-z-index child paints above the canvas background and below its parent's content, so on a transparent #root over a dark body the band should be visible.

If clips are composited such that negative z-index is deliberately out of range, that is a reasonable design choice — but it is currently undocumented and silent, and the failure is invisible at every gate: lint passes, validate passes, the render exits 0, and the output is a plausible-looking file with an element missing.

Suggested

Whichever way it is resolved, the valuable half is a diagnostic: flag a negative z-index on a clip at lint time, or warn at render when a declared element contributes zero pixels. Silent omission is the expensive failure mode — an absent element is indistinguishable from one that was authored wrong, so debugging effort goes to the composition rather than to the pipeline.

Workaround for anyone hitting this: express paint order with DOM order (insertBefore) rather than negative z-index. Positive values behave correctly.

Triage follow-up — September 23, 2026

A plain-browser control reproduces the essential symptom without HyperFrames. In Chrome 150.0.7871.24, the supplied negative-z-index band over the opaque body background yields RGB (10,10,10) at (200,80). Adding isolation: isolate to #root changes that pixel to the expected band RGB (245,230,200).

This is evidence of CSS stacking behavior, not by itself evidence that HyperFrames drops an element. The isolated control has not yet been compared across HyperFrames snapshot/render, so this issue is not being closed.

Decision needed

The smallest contribution candidate is documenting negative-z-index stacking and a minimal before/after example beside the paint-order guidance in docs/concepts/data-attributes.mdx and docs/reference/html-schema.mdx. A diagnostic is a separate scope decision: blanket rejection of negative z-index would reject valid CSS.

For a documentation task, verify the example in a plain browser and HyperFrames snapshot/render, explain that track order is not paint order, and run the documentation validation/link checks. Read docs/AGENTS.md first. Difficulty remains unset on this broader issue until the documentation-versus-diagnostic scope is selected.

主要言語
TypeScript
スター
54.1k
フォーク
4.9k
平均マージ
6時間 8分
マージ済み PR（30日）
797

環境構築

このプロジェクトには開発コンテナ、Dockerfile、コントリビューションガイドがありません。まず README を読み、一般的な手順ははじめてのコントリビューションガイドを参照してください。

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

heygen-com/hyperframes のほかの issue

heygen-com/hyperframes の issue をすべて見る

似ている issue

TypeScript の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。