の直下）に置かれている .trajectory-webgl-stage（z-index:1）とは一切競合できなかった。結果、.night 全体（背景も z:2 に持ち上げたはずの本文も丸ごと）が、.night 自身のスタック値（position:relative・z-index:auto＝stack level 0）でしか外側と比較されず、 canvas側の明示的な正のz-index(1)に対して常に負ける＝News/Contest Info/Divisions配下の本文（.shell）にヨーヨーが乗って見えていた（過去ラウンドで .division__card だけに z-index:2を追加で足す対症療法を試みたが、そもそも .night の isolation がある限りどんな子孫にz-indexを足しても外へは絶対に効かないため根治しなかった）。 isolation を外すことで、.night 配下の「.night .shell」z:2 ルールが .trajectory-webgl-stage と同じ祖先スタッキングコンテキストで直接競合できるようになり、SCHEDULE/VISIT/SPONSORS （.night の外＝もともとこの isolation の影響を受けておらず、個別のz:2ルールが機能していた帯）と同じ仕組みで自然に解決する。mix-blend-mode を使うレイヤー（.hero__bg-layer等）は個別に isolation:isolate を持っているため、この撤去による副作用はない（別途確認済み）。 */ .night { position: relative; background: radial-gradient(120% 60% at 78% 8%, rgb(24 60 120 / 0.35) 0%, transparent 55%), linear-gradient(180deg, var(--night-sky-top) 0%, var(--night-sky) 22%, var(--night-0) 60%, var(--night-1) 100%); /* G4: 夜バンドの view progress を名前付きタイムラインとして公開。軌跡繊維の描き進み（SDA）が参照する。 app.js のヨーヨー進行式（cover 6%〜80%）とレンジを一致させてある。 */ view-timeline-name: --wyyc-night; view-timeline-axis: block; } /* 極淡い青海波テクスチャ＋粒状感で「布の夜」を出す（B案の全面テクスチャは持ち込まない）。 F7（2026-07-11）: 以前は mix-blend-mode:screen を使っていたが、ブレンドは背後が変わるたびに再合成が要る＝スクロール中ずっと合成コストがかかる。opacity 0.09 の極淡テクスチャでは通常合成でも見た目はほぼ同じなので、ブレンドをやめて静的レイヤーとして焼く（合成負荷を削る）。 */ .night::before { content: ''; position: absolute; inset: 0; z-index: 0; background-image: url(../images/pattern_seigaiha_dark.webp); background-size: 300px 300px; opacity: 0.08; pointer-events: none; } /* 金の S 字光跡（セクション跨ぎ・#P7-3で復活）。ヒーロー背景の一枚絵には光跡が焼き込まれているので、 * ヒーロー領域だけをマスクで伏せて二重を避け、その下の News→入口→HEADLINERS→DIVISIONS を貫く * 連続した金の軌跡として見せる（原案「軌跡の夜」の核）。svh でヒーロー(min-height:100svh)の下端に合わせて * フェードインさせる。.section-arc は各セクション入口の補助アクセントに格下げ。 */ .trajectory { display: block; position: absolute; inset: 0; width: 100%; height: 100%; z-index: 1; pointer-events: none; overflow: visible; -webkit-mask-image: linear-gradient(to bottom, transparent calc(100svh - 260px), #000 calc(100svh + 40px)); mask-image: linear-gradient(to bottom, transparent calc(100svh - 260px), #000 calc(100svh + 40px)); } /* ================= G3: 束なる光の繊維（2026-07-11b） ================= * 一本線でなく、共通のS字（#trajBase）をで数本引いた「束なる光の線」。glow は drop-shadow * フィルタを使わず、太幅faint（halo）×細幅bright（core）の重ね描きで表現する。フィルタが無いので、 * 描き進み中に stroke-dashoffset が動いても paint が軽い＝F7で根治したカクつきを再発させない。 */ .trajectory__fiber { fill: none; stroke-linecap: round; stroke-dasharray: 1; /* pathLength=1 正規化 */ stroke-dashoffset: 0; /* 既定（JS無効・SDA非対応・reduced）は全描画 */ } .trajectory__fiber--halo { stroke: var(--color-gold); stroke-width: 5.4; opacity: 0.14; } .trajectory__fiber--core { stroke: var(--color-gold-light); stroke-width: 1.5; opacity: 0.88; } /* ================= FB0712 V1〜V3: WebGL版軌跡+3Dヨーヨー・ステージ ================= * 旧SVG光跡（.trajectory）＋旧CSSヨーヨー（.trajectory-yoyo）は「WebGL不可・JS無効・ * reduced-motion」時の静的フォールバック（V5）としてそのまま残す。WebGLが実際に初期化に * 成功したときだけ app.js がに .wyyc-webgl-active を付け、このブロックで旧2系統を * 非表示にして新WebGL系統（1系統のみ）へ完全に切り替える（V1: 二本立て駆動の廃止）。 * * FB0715ラウンド3（mos「白背景でヨーヨーが止まっている・フッターまで続いてほしい」）: * ステージ(.trajectory-webgl-stage)の絶対配置の基準を .night から

* （ヒーロー〜SPONSORS帯の末尾まで＝front-page.php参照）へ拡張した。実体のcanvasはその内側で * position:sticky; top:0; height:100vh とし、「data-traj-range を縦断してスクロールする間は * ビューポートに固定されたキャンバスの中で3Dシーンだけが進む」古典的なピン留め * スクローリーテリング構成にする。これにより、 * - canvasの実サイズは常にビューポート相当（data-traj-rangeの全高ぶんの巨大canvasにしない）＝ * 大きなWebGLフレームバッファを毎フレーム再ラスタライズするコストを避け、CWV予算を守る。 * - 「data-traj-rangeがビューポートにある間は必ずヨーヨーが画面内にある」がジオメトリの * 都合でなく構造そのもので保証される（V2）。 */ .front { position: relative; /* .trajectory-webgl-stage の inset:0 の基準（.trajectory-webgl-stageが positionを持つ最も近い祖先になるようにする）。 */ } /* FB0715ラウンド3 キュー17再差し戻し（team-lead実機検証: 「差が一定＝いつまでも縮まらない」の指摘。sticky解除後はcanvas（＝ヨーヨーの画面位置）とfooter上端が同速で上昇するため、注視点Yのオフセットだけではギャップは絶対に0にならず、遮蔽は幾何学的に起こり得ない）: 根治は「stickyの解除自体をfooterの高さぶん遅らせる」こと。.trajectory-webgl-stage （sticky canvasの containing block）の下端を、mainの下端からfooterの実高さぶん（--wyyc-footer-h・app.jsがResizeObserverで実測してセット）だけ下へ延長する。これにより、footerがビューポートを下から上がってくる間もcanvasはstickyのまま画面に固定され続け（ヨーヨーはp=1クランプで停留したまま動かない）、footer（z:2・不透明背景、 canvasのz:1より手前）が画面下から通過する間、本当にヨーヨーの上に重なって覆い隠す。 stageのこの延長ぶん（footer背面に隠れる領域）はz-index的にfooterの奥（z:1 の極小scriptで必ず先に付くため、app.js自体が読み込み失敗すると revealHeadline() が一度も走らず見出しが永久に非表示のままになる（sightedユーザーの情報欠落）。[data-reveal] と同じ0.8s/1.6s遅延の自動開示フォールバックで最終防御する。app.js が正常な場合は revealHeadline() の gsap.set(headline,{opacity:1}) が 1.6sより先に走るため見た目は変わらない。 */ animation: wyyc-headline-reveal-fallback 0.8s var(--ease-out-expo) 1.6s forwards; } .hero__date { display: flex; align-items: baseline; flex-wrap: wrap; gap: 0.5rem; font-family: var(--font-jp-serif); font-size: var(--text-lead); letter-spacing: 0.08em; color: color-mix(in srgb, var(--color-kinari) 88%, transparent); } .hero__date-en { font-family: var(--font-display); letter-spacing: 0.14em; color: var(--color-gold-light); } .hero__date-dot { color: var(--color-gold); } /* カウントダウン（概念画像: ベタ塗りボックスでなくヘアライン罫線の区画） */ .countdown { margin-top: 0.75rem; padding: 0.75rem 0; background: transparent; border-top: 1px solid var(--hairline-strong); border-bottom: 1px solid var(--hairline-strong); } .countdown__label { font-family: var(--font-display); font-size: 0.68rem; /* FB0712 総重量削減: 500はZen Kaku Gothic Newの中間ウェイトのためだけに1ウェイト丸ごと配信する必要が生じる（このJA countdownラベルが唯一の実使用箇所の1つ）。700（既存の見出し等で使用済み・追加コストなし）へ寄せてウェイト数を400/700の2種へ絞る。 */ font-weight: 700; letter-spacing: 0.28em; text-transform: uppercase; color: color-mix(in srgb, var(--color-kinari) 74%, transparent); margin-bottom: 0.7rem; text-align: center; } .countdown__grid { display: flex; } .countdown__unit { flex: 1; display: flex; flex-direction: column; align-items: center; gap: 0.3rem; padding-inline: clamp(0.6rem, 2vw, 1.4rem); border-left: 1px solid var(--hairline); } .countdown__unit:first-child { border-left: 0; } .countdown__num { /* F2（2026-07-11）: 桁変動での位置カクつき根治。数字ブロックを「最大桁基準の固定幅」にして、残り日時がどんな数字（1桁/2桁、EN/JA）でも幅が1pxも変わらないようにする。 tabular-nums はサブセット由来で効かない可能性があるため、幅の担保は em ベースの固定幅（display:block + 中央寄せ）で行い、字幅差があってもセル幅が動かないようにする（保険の多重化）。各セル幅が定数 → .countdown__unit(flex:1) が等幅 → .countdown 全体の内在幅が定数 → 中央寄せの「開幕までの残り」ラベルも一切動かない。 */ display: block; min-width: 1.6em; /* Oswald の2桁ぶんに十分な固定幅（1桁でも中央寄せで位置不変） */ text-align: center; font-family: var(--font-display); font-weight: 600; font-size: var(--text-countdown); line-height: 1; color: var(--color-kinari); font-variant-numeric: tabular-nums; font-feature-settings: 'tnum'; } .countdown__cap { font-family: var(--font-display); font-size: 0.6rem; letter-spacing: 0.2em; text-transform: uppercase; color: color-mix(in srgb, var(--color-kinari) 72%, transparent); } .countdown--live, .countdown--closed { display: flex; align-items: center; gap: 0.85rem; } .countdown__now { font-family: var(--font-jp-serif); font-size: var(--text-lead); color: var(--color-kinari); } /* スクロールインジケーター */ .hero__scroll { position: absolute; z-index: 2; left: 50%; bottom: clamp(1.25rem, 3vh, 2rem); transform: translateX(-50%); display: flex; flex-direction: column; align-items: center; gap: 0.5rem; color: var(--color-kinari); opacity: 0.7; transition: opacity var(--duration-normal) var(--ease-out-expo); } /* FB0715ラウンド2追加（mos「SCROLLと、下にスクロールすると落下するヨーヨーの表現を合体させたい」）: 演出の意味は1行で＝「SCROLLの糸を、ヨーヨーの開始位置（マストヘッドのチケットボタン右端＝FB0715ラウンド2で校正したDESKTOP_LOOKAT_X_OFFSET_STARTの落ち着き先）に真上から重ねることで、この糸を手繰るとそのままヨーヨーが投げ出される軌跡につながって見える」。軌跡（ヨーヨーのthrow）が唯一の比喩という規律を守り、新しい比喩は持ち込まない。位置合わせは WebGLのprojectToScreen実行タイミング（初回スクロール後まで遅延＝CWV対応）を待たずに済むよう、 masthead__inner と同じ shell-max/shell-pad のボックス計算をCSSだけで再現する（JS非依存・静的なleft値なのでtransform/opacity/clip-path縛りにも抵触しない）。モバイル/タブレット（<1024px）はヨーヨー自体が中央固定のオフセットなし配置のままなので、 SCROLLインジケーターも従来通り中央のまま変更しない。 FB0716-R5追記: 上記は書かれた時点（FB0715ラウンド2）の前提であり、その後FB0715ラウンド3 キュー22でモバイル幅のヨーヨーも中央固定をやめ、.to-top（ページトップへ戻るボタン）付近へ右寄せする設計（MOBILE_LOOKAT_X_OFFSET、trajectory-webgl.js）に変わったため、この段落の「モバイルは中央のまま」は実態と食い違っていた。SCROLLインジケーターの真上にヨーヨーの出現位置を揃えるため、下の@media (max-width:1024px)でモバイルも.to-topと同じx位置（right基準）へ寄せる。 */ /* min-width:1025px（1024pxではない）: header.php側の `@media (max-width:1024px)` が masthead__nav を隠しnav-toggle（ハンバーガー）を出す境界と噛み合わせている。1024px幅ではまだハンバーガーが出てチケットボタンの右にスペースが空くため、そのままだとhero__scrollがボタン右端より右へずれてしまう（Playwright実機検証で発覚）。デスクトップフルナビ表示時（≥1025px）だけこの位置合わせを適用し、1024px以下は中央のまま安全側にする。 */ @media (min-width: 1025px) { .hero__scroll { left: calc((100% + var(--shell-max)) / 2 - var(--shell-pad)); } } /* team-lead FB「スクロール案内の見切れ解消」（PC限定）: .hero__scroll は .hero（position:relative）基準の絶対配置で、従来は bottom（.heroの下端からの距離）で位置決めしていた。.heroはmin-height （100svh - masthead-h）を持つだけでheightは固定していないため、見出し・カウントダウン等の内容が高さ不足の狭いビューポート（実測: 幅1440でも高さ750px以下・幅1366で高さ657px等、ブラウザのツールバー分だけ画面が縮んだ実利用時に相当）でheroの実際のボックスが min-heightを超えて伸び、bottom基準の.hero__scrollがその伸びた分だけ押し下げられてビューポート外へ見切れていた（Playwright実測: 1440×750で9px・1366×657で83px超過）。 heroの伸び幅に左右されない位置にするため、bottom基準をやめ、hero自身の上端（＝masthead-h ぶん下がった位置＝ビューポート上端からは常に一定）を基準にしたtopへ切り替える。 104pxはインジケーター本体の実測高さ（22+8+46+8+17≈101pxに安全マージンを足した値）で、ビューポート幅に依存しない固定値。SP/タブレット（≤1024px）は元のbottom基準のまま変更しない（挙動を変える指示はPC限定のため）。 */ @media (min-width: 1025px) { .hero__scroll { top: calc(100svh - var(--masthead-h) - 104px - clamp(1.25rem, 3vh, 2rem)); bottom: auto; } } /* FB0716-R5追記: モバイル/タブレット（≤1024px）は.to-top（global.css）と同じx位置（right: clamp(1rem,3vw,2rem)・width:48pxの中心＝右端からclamp+24px）に寄せる。 MOBILE_LOOKAT_X_OFFSET（trajectory-webgl.js）がこの.to-top位置を狙って校正されているため、SCROLLインジケーターもここに揃えることで「この場所からヨーヨーがトスされる」の位置合わせがモバイルでも成立する。 */ @media (max-width: 1024px) { .hero__scroll { left: calc(100% - (clamp(1rem, 3vw, 2rem) + 24px)); } } .hero__scroll:hover { opacity: 1; } /* FB0715ラウンド3 追加FB（キュー13 mos「SCROLLの案内をもうちょっと大きめに、ヨーヨーをトスするかのような雰囲気の演出に」）: 素朴なリング(border円)は一回り大きくし（7px→11px）、トスの気配としてごくわずかに左右へ揺れる（品よく・過剰装飾にならない範囲の振幅6°）アニメーションを足していた。 FB0716-R5追記（team-lead依頼: 3Dヨーヨーと同じ手車の意匠に）: そのリングを、3Dヨーヨー本体（trajectory-yoyo__ballの同心円ブルズアイ・朱/生成り/深緑の配色）と同一パターンのSVGへ置き換えた（front-page.php参照）。要素は糸(hero__scroll-line)の下にぶら下がる配置に変わったため、揺れの支点(transform-origin)も「輪の下」から「ヨーヨー本体の上端（糸の付け根）」へ付け替えている。視認しやすいよう一回り大きく（11px→22px）した。 */ .hero__scroll-loop { display: block; width: 22px; height: 22px; animation: loop-sway 2.8s ease-in-out infinite; transform-origin: 50% -8%; /* ヨーヨー本体の上端（糸の付け根）を支点に振れる */ } @keyframes loop-sway { 0%, 100% { transform: rotate(-6deg); } 50% { transform: rotate(6deg); } } .hero__scroll-line { width: 1.5px; height: 46px; background: linear-gradient(180deg, transparent, var(--color-gold-light)); animation: scroll-pulse 2.4s var(--ease-out-expo) infinite; } .hero__scroll-cap { font-family: var(--font-display); font-size: 0.72rem; letter-spacing: 0.32em; text-transform: uppercase; } @keyframes scroll-pulse { 0%, 100% { opacity: 0.3; transform: scaleY(0.7); transform-origin: top; } 50% { opacity: 1; transform: scaleY(1); transform-origin: top; } } @media (prefers-reduced-motion: reduce) { .hero__scroll-loop { animation: none; } } /* FB0715ラウンド2追加: スクロールが実際に進んだら「SCROLL」の役目は終わり、同じ場所から下りていく軌跡・ヨーヨー本体へ主役を渡す（フェードで退場）。既存のG4（軌跡の描き進み・ hero.css:107-130）と同じ view timeline（--wyyc-night）・同じ手法（opacityのみのSDA）を使い、ページ全体で「動いている系統は1つ」の作法を踏襲する。 */ @supports (animation-timeline: view()) { @media (prefers-reduced-motion: no-preference) { .wyyc-js .hero__scroll { animation: wyyc-hero-scroll-fade linear both; animation-timeline: --wyyc-night; /* "cover" は要素が画面に入り始めてから抜けきるまでの進行率。ページ先頭にある巨大な .night (高さ数千px) は読み込み直後（スクロール0）の時点で既にcover進行率が17〜20%前後まで進んでいる（G4の.trajectory__fiber--core・cover 6%〜80%のdashoffset実測値から逆算。 6%という数字自体はこの逆算値と無関係で、そちらは別の目的で経験的に決められた値）。この読み込み時点の進行率はビューポート幅ごとに.nightの実高さが変わるぶん微妙にズレる（320px:17.0%・768px:20.2%・1024px:19.5%・1440/1920px:18.8%、Playwright実機で実測）。 0%起点や実測値ギリギリで組むと、幅によっては読み込み直後から既にフェード済み扱いになりSCROLLがほぼ見えない不具合を実機検証で確認したため、実測した最大値（768pxの 20.2%）にさらに余裕を足した21%を起点にし、そこから軽くホイールした程度で消えきる幅（24%）にした。 */ animation-range: cover 21% cover 24%; } /* FB0715ラウンド3 追加FB: 単純なフェードでなく、わずかに下方向へ動きながら消えることで「トスされて手を離れ、軌跡（3Dヨーヨー）へ主役を渡す」感触を足す。transform(translateY)+ opacityのみ＝コンポジタ完結でperformance.md準拠。移動量はごく小さく（8px）品よく留めた。 */ @keyframes wyyc-hero-scroll-fade { from { opacity: 0.7; transform: translateX(-50%) translateY(0); } to { opacity: 0; transform: translateX(-50%) translateY(8px); } } } } /* FB 2026-07-17（mos「SCROLLのフェードアウトと3Dヨーヨーのフェードインを同時に」）: 基準単位が異なる2つの独立したフェード（このview-timeline animationのcover%と、 REVEAL_START_P基準のJS制御）を同じフレームで駆動し直すため、WebGL演出が実際に起動した（＝JSがREVEAL_START_P基準でopacity/transformを直接制御し始める）ときはこのCSS駆動のフェードを止める。docEl(.wyyc-webgl-active)はtrajectory-webgl.js起動成功時のみ付与される（app.js参照）ので、フォールバック時（WebGL非対応・reduced-motion等）は従来のCSSフェードがそのまま残る＝V5フォールバック方針を崩さない。 */ .wyyc-webgl-active .hero__scroll { animation: none; transition: none; /* 毎フレームのJS制御にopacity transitionが遅延をかけないよう無効化 */ } /* ================= reduced-motion ================= */ @media (prefers-reduced-motion: reduce) { /* カルーセルは切替せず先頭スライドを静止表示（急変防止でトランジションも切る）。 app.js の initHeroCarousel も reduced では自動送りしないので二重で担保する。 */ .hero__slide { transition: none; } /* .wyyc-js .section-arc__path（seam方式の初期非表示）より詳細度で上回らせて reduced を優先させる */ .wyyc-js .section-arc__path { stroke-dashoffset: 0; transition: none; } .hero__scroll-line { animation: none; opacity: 0.6; } /* D-3: revealHeadline() は reduce で早期returnし親の opacity を戻さないため、常時表示で固定する。懸念③の自動開示フォールバックもモーションなので reduced では止める。 */ .wyyc-js [data-hero-headline] { opacity: 1; animation: none; } } /* ================= レスポンシブ ================= */ @media (max-width: 768px) { .hero__content { align-items: flex-start; } } @media (max-width: 420px) { .countdown { padding: 0.9rem 1rem; width: 100%; } .countdown__grid { justify-content: space-between; } /* FB0715ラウンド2追加（狭幅で秒("42")が右端で見切れる既存不具合の修正）: .countdown__unit は flex:1 だが、子の .countdown__num（min-width:1.6em・--text-countdown由来のfont-size）と左右padding-inlineの合計が「収縮不可な最小内容サイズ」を作ってしまい、320px幅ではグリッドの内在幅305pxに対して利用可能幅が248pxしかなく57pxはみ出していた（Playwright実測）。この幅だけpadding-inlineと数字のfont-sizeを縮め、内在幅を約223pxまで落として収める（他の幅・トークン本体には触れない最小の手当て）。 */ .countdown__unit { padding-inline: 0.3rem; } .countdown__num { font-size: 1.9rem; } }