/* Кросс-документный @view-transition{navigation:auto} — УБРАН 29.08 (был тут короткое время). Причина: настоящую "перезагрузку" при переходе Практики↔Блог решает soft-nav.js (same-document JS-роутинг, не покидает документ вообще — см. этот файл). Кросс-документный API нужен был только как подстраховка на случай, когда soft-nav не сработал (fallback/первый холодный заход) — но именно там он и подвёл: на реальном мобильном Chrome владельца переход после него не просто не был плавным, а иногда вовсе зависал ("Практики не переходит") — известный класс проблем у этого ещё не устоявшегося API на части Android-сборок. Раз soft-nav.js закрывает реальный кейс (Практики<->Блог внутри уже загруженной сессии), а кросс-документный API нужен только для холодных переходов, где он больше вредит, чем помогает — отключаем совсем. view-transition-name на топбаре/ луне/тумане (см. .topbar в этом файле) не удалялись — они безвредны и продолжают работать для SPA-варианта API, который вызывает soft-nav.js (document.startViewTransition — другой, куда более стабильный путь). */ * { box-sizing: border-box; } html, body { margin: 0; padding: 0; min-height: 100%; /* Глубокое ночное небо чуть темнее var(--bg) — видно по краям, пока/если картинка body::before ещё не покрыла всю область. Панели всё равно рисуются непрозрачно на var(--panel). */ background: #07040e; color: var(--text); font-family: -apple-system, BlinkMacSystemFont, 'Segoe UI', sans-serif; } /* overflow-x:hidden — ТОЛЬКО на html, не на body тоже (было и там, и там до 29.08). Классический баг: если overflow (в т.ч. только overflow-x) задан сразу на html И на body, оба становятся потенциальными "scroll-контейнерами" по спеке, а реально скроллится только html — из-за этого все .topbar (position:sticky) внутри переставали прилипать при скролле (проверено headless-браузером: .topbar уезжал вместе со страницей вместо прилипания). Оставлена только на html — единственном реальном скролл-контейнере. */ html { overflow-x: hidden; } body { position: relative; } /* КРИТИЧНОЕ ОГРАНИЧЕНИЕ ЭТОЙ СТРАНИЦЫ (воспроизводимо в headless Chromium+WebKit): отрицательный z-index на position:fixed-слое красится НИЖЕ фона, который html/body пропагируют на canvas — слой становится физически невидимым независимо от цвета/альфы. Поэтому НИ ОДНОМУ fixed-слою здесь нельзя ставить отрицательный z-index. Все фоновые слои (body::before, .sky-twinkle-*, .sky-meteor) идут первыми в DOM и НЕ имеют z-index (auto); реальный контент поднят через `.screen { position: relative; z-index: 1 }` ниже — это единственный источник правды по стекингу. Соблюдать и для любых новых слоёв. Фон — снова оригинальное референсное фото дизайнера testdis (sky.jpeg, 1195×896, "верни фото звёздного неба :4300", 29.08, третий заход). История: сначала это же фото и пробовали — владелец забраковал детализацию (апскейл низкого исходника под большой размер = размыто/пиксельно). Откатили на процедурную генерацию (multi-octave value-noise FBM + domain warp + ridged dust-маска) — не фото, значит никакого апскейла/пиксельности, но и не настоящее небо. Потом владелец сам прогнал тот же кадр через апскейл нейросетью, пробовал два варианта (`001.jpg`/`002.jpg`, другие кадры/обработка) — и в итоге попросил вернуть оригинал референса как есть. Никакого апскейла на этот раз: десктоп — родное разрешение 1195×896, просто пересжато в webp (40KB); мобильный — уменьшенная копия (700px, downscale безопасен, апскейла нет). background-position — те же значения, что в CSS референса (`[_nghost-...]`): по умолчанию верхний левый угол (0% 0%, ничего не задано — это дефолт), на их мобильном брейкпоинте `center center`. Луна — отдельный крутящийся 3D-слой, см. .moon-canvas ниже, на самом фото её нет. Звёзды на самом растре статичны — мерцание добавляют слои .sky-twinkle-* ниже. Файлы локальные, обычный background-image, без сетевых запросов. */ body::before { content: ""; position: fixed; /* inset:0 фоллбэк для браузеров без lvh, затем перекрывается 100lvh ниже. top/left:0 остаются нужны сами по себе — inset задаёт и их тоже, но явные top/left ничего не портят, дублирование безвредно. */ inset: 0; top: 0; left: 0; width: 100%; /* 30.08, консультация Opus по багу "небо скачет на мобильном скролле": мобильная адресная строка сворачивается/разворачивается при скролле, меняя высоту layout-viewport, а inset:0/vh пересчитывают fixed-слой СКАЧКОМ в конце анимации тулбара — это и есть видимый рывок. 100lvh (large viewport height) — стабильная величина, не меняющаяся с тулбаром (в отличие от dvh, который как раз следует за ним) — фон перестаёт ре-скейлиться на каждый скролл. Небольшое "перекрытие" ниже фолда безвредно для декоративного cover-фона. Поддержка lvh: все актуальные мобильные браузеры (iOS Safari 15.4+, Chrome/Android современные) — фоллбэк на inset:0 выше для древних. */ height: 100vh; height: 100lvh; pointer-events: none; background-image: url('night-sky-desktop.webp'); background-size: cover; background-position: 0% 0%; background-repeat: no-repeat; transform: translateZ(0) scale(1); -webkit-transform: translateZ(0) scale(1); will-change: transform; } @media (max-width: 700px) { body::before { background-image: url('night-sky-mobile.webp'); background-position: center center; } /* Баланс налезал на "Astromag" в шапке на узких экранах — мельче и без фонового пилюли-обрамления, просто цветная цифра. */ .topbar { padding: 12px 14px; gap: 8px; } .topbar .logo { font-size: 18.7px; } .topbar .right { gap: 8px; } .balance-badge { font-size: 13.2px; } #user-name { display: none; } /* Мало места на мобильном — прячем текст бренда "Astromag". Раньше (2026-08-29, утро) тут же ужимали padding/gap/шрифт у "Практики"/"Блог", сохраняя подписи текстом — владелец тогда явно отверг "только иконки" после живой проверки на телефоне. С тех пор в шапку добавился 3-й пункт "О проекте" ("Что внутри"/Блог/О проекте — итого 4 hdr-link + "Войти"), и даже ужатый текст перестал помещаться на узких телефонах (375px) — "Войти" физически обрезался за край экрана, реальный баг. Владелец 29.08 (повторно, тем же днём) сам пересмотрел решение: "если на мобильном не помещается — сделай в виде иконок" — теперь подписи прячутся текстом (не DOM), title= на остаётся тултипом/для скринридера. Затрагивает и SPA-topbar (index.html), и общую шапку блога (_header.html) — оба используют .logo/.hdr-link. */ .topbar .logo span { display: none; } .topbar .hdr-link span { display: none; } .topbar .hdr-link { padding: 10px !important; gap: 0 !important; } .topbar .hdr-link svg { width: 18px; height: 18px; } /* Иконки в шапке "мерцают/подрагивают" на мобильном (владелец 29.08) — реальная причина: .topbar sticky + backdrop-filter (добавлен этим же днём, см. комментарий у .topbar ниже) сидит ПРЯМО НАД постоянно вращающейся WebGL-луной (.moon-canvas теперь fixed, всегда в кадре, см. выше) — браузер обязан пересчитывать блюр backdrop-filter КАЖДЫЙ кадр анимации, что на мобильных GPU реально роняет кадры и читается как дрожание/мерцание элементов внутри шапки. На десктопе GPU мощнее, заметной проблемы не было — отключаем блюр только на мобильном, подняв непрозрачность фона взамен (чтобы шапка не стала прозрачнее на вид без блюра). Тот же приём — у .about-card:nth-child(-n+2) ниже (те же две карточки на "О проекте" тоже сидят поверх луны). */ .topbar { backdrop-filter: none; -webkit-backdrop-filter: none; background: linear-gradient(180deg, rgba(8,5,20,0.78), rgba(8,5,20,0.7) 340%); } } /* Едва заметный дрейф-приближение всей сцены — только transform (дёшево для GPU), полностью отключается при prefers-reduced-motion. 30.08: владелец пожаловался "сайт плывёт на мобильном в личном кабинете" — на десктопе дрейф действительно почти незаметен (весь фон целиком чуть увеличивается за 150 секунд), но на маленьком мобильном экране, ближе к глазам, тот же самый едва заметный на десктопе сдвиг читается как настоящее "плавание" картинки. Отключаем анимацию на мобильном (≤700px, тот же брейкпоинт, что у мобильного фото/шапки выше) — на десктопе поведение не меняется. */ @media (prefers-reduced-motion: no-preference) and (min-width: 701px) { body::before { animation: mag-sky-drift 150s ease-in-out infinite alternate; } } @keyframes mag-sky-drift { from { transform: translateZ(0) scale(1) translate(0, 0); } to { transform: translateZ(0) scale(1.045) translate(-0.6%, 0.3%); } } /* Луна — ОДНО поведение на всём сайте, теперь "точь в точь" референс :4300 ВЕЗДЕ, включая /main (29.08, владелец: сначала "точь в точь" сделали только на "/"+блоге, /main специально не трогали — консультация Opus предупреждала, что диск ~65% высоты экрана налезет на калькуляторы; но владелец, увидев результат на "/", прямо попросил "делай луну на всех страницах такую как на главной" — включая /main. Разница page-about/page-blog vs page-app, которая была в этом файле и в moon3d.js, убрана — единое поведение, никакой развилки). До этого была ещё более старая история: маленький диск в углу (28.08, referal дизайнера testdis, чтобы не перекрывать формы кабинета) → потом единая, но маленькая центрированная луна на весь сайт (`--moon-size`/`--moon-top`, ~9 раундов правок под размер/позицию) → теперь единая БОЛЬШАЯ луна везде, сама CSS-механика (`--moon-size`/`--moon-top`/`--moon-opacity`/`--moon-glow`) больше не нужна и убрана — canvas просто на весь вьюпорт, camera fov/z и адаптивный scale в moon3d.js делают саму "картинку" такой большой. position:fixed (владелец прямым текстом: "луна... должна при скролле не скрываться") — canvas виден на любой прокрутке, а не только в первом экране. pointer-events:none и z-index:0 (ниже .screen) — луна не мешает кликам/чтению. */ .moon-canvas { position: fixed; /* — заменяемый элемент (как ): в отличие от обычных block- боксов, left:0+right:0 БЕЗ явного width его не растягивают — браузер берёт "родной" размер канваса (по умолчанию 300×150) и прижимает к левому верхнему краю (реальный баг 29.08: "луна ушла в левую часть и стала маленькой" — именно из-за пропущенного width здесь). width/height ниже явные и через calc(), а не голый top+bottom auto — та же причина, auto-высота у заменяемых элементов ненадёжна тем же способом. */ top: 3em; left: 0; width: 100%; /* 30.08, тот же фикс "тулбар скачет" что и у body::before выше — 100lvh вместо 100vh, чтобы адресная строка на скролле не порождала resize геометрии canvas (а значит и лишних вызовов resize() в moon3d.js). */ height: calc(100vh - 3em); height: calc(100lvh - 3em); pointer-events: none; z-index: 0; } @media (min-width: 1024px) { .moon-canvas { top: 5em; height: calc(100vh - 5em); height: calc(100lvh - 5em); } } /* prefers-reduced-motion: reduce — вращение не глушится совсем (замедляется в JS, moon3d.js), не через CSS: анимация тут rAF/rotation.y, не CSS-animation. */ /* Текстовый блок "О проекте" — вплотную к шапке, лежит поверх верхней части луны (владелец 29.08, 2-я правка: "блок с текстом должен быть ближе к шапке, блок с 6 вкладками должен начинаться на луне в нижней части"). Раньше тут был искусственный min-height:100vh, уводивший карточки НИЖЕ диска целиком — владелец явно попросил обратное, см. about.html. */ .about-hero-top { padding: 22px 0 0; } /* Стандартный visually-hidden — виден скринридерам/поисковым роботам, не виден на экране. Заведён 29.08 для h1 на about.html (владелец убрал видимый текст "ASTROMAG" из блока — лого и так в шапке — но сам h1 как структурный заголовок страницы остаётся, просто без дублирующего текста на экране). Первое использование класса на сайте — утилита общая, не привязана конкретно к about.html. */ .sr-only { position: absolute; width: 1px; height: 1px; padding: 0; margin: -1px; overflow: hidden; clip: rect(0, 0, 0, 0); white-space: nowrap; border: 0; } /* Статичный CSS-двойник луны для блога — УДАЛЁН 29.08. Раньше жил здесь как body.page-blog::after (moon-static.webp), чтобы не тащить WebGL на SEO- страницы. Проблема: WebGL-сфера крутится непрерывно (rotation.y накопительно растёт), а статика — застывший кадр, расхождение с каждой секундой просмотра только росло — сколько ни подгоняли размер/цвет/угол, ощущение "разные луны" не уходило. Владелец явно расставил приоритет: "хочу единый сайт, а не разные" — важнее декоративной экономии веса. Теперь на блоге (article.html/articles_index.html) стоит тот же + тот же moon3d.js, что на главной — просто грузится через requestIdleCallback, а не сразу, чтобы не спорить с LCP статьи (см.