/* Phone-header glue for the JS-free rebuild.
Everything else on the phone comes from the vendor's own rules, re-gated onto a
media query by scripts/gen_mobi_css.py (see mobi.css) and scripts/regate_css.py
(site/assets/**). These are only the states the original expressed through
JavaScript:
 .jz_nav_wrap_active           -> #jz-mobi-nav:checked
 sub_nav_list.style.display    -> .jz_mobi_switch:checked
 closed drawer height          -> 0 (open rule already lives in mobi.css)
 row padding/margin -> 0       -> measured on the live phone render: all 15
                                    home rows carry 0% / 0vw (the desktop
                                    inline values are rewritten by the vendor)
 module width -> auto          -> live modules never carry the desktop
                                    `width:var(--custom-project-width, ...)` */
/* Desktop: the phone-only carousel the injector puts next to the video stays
   hidden (scripts/patch_mobi_banner.py). Specificity has to beat the vendor's own
   `.jz_banner .banner_pic{display:block}`. */
.jz_banner .banner_pic.jz_banner_mobi_pic{display:none}
/* The drawer toggle `input#jz-mobi-nav` that scripts/patch_mobi_nav.py injects before
   #gridHeader must be out of flow at *every* width, not just on phones: a bare
   <input type=checkbox> computes inline-block, so leaving it visible costs 18px of
   flow and shifts the whole desktop page down (measured: #gridHeader at y=18 vs y=0
   on the live render, scrollHeight 5137 vs 5119 at 1440px). It still has to exist in
   the DOM for `#jz-mobi-nav:checked ~ #gridMobiHeader`, so hide it rather than drop it. */
.jz_mobi_switch{height:1px;left:0;margin:0;opacity:0;pointer-events:none;position:absolute;top:0;width:1px}
@media (max-width: 768px) {
	#gridHeader.jz_web_header{display:none!important}
	#gridMobiHeader.jz_mobi_header{display:block}
	/* the phone header logo: the archived inline keeps the desktop `width:153.908px; zoom:.75`,
	   which the vendor's JS replaces with a phone-sized box. Measured on the live phone render
	   at 500px and 768px, on the home and a column page: .logo_wrap is 81.004px wide, zoom 1,
	   and the image inside it scales to that box through the vendor's own max-width:100%. */
	#gridMobiHeader .logo_wrap{width:81.004px!important;zoom:1!important}
	#gridMobiHeader .jz_mobi_nav{height:0;transform:none}
	#jz-mobi-nav:checked ~ #gridMobiHeader .jz_mobi_nav{height:100%}
	.jz_mobi_nav_item > .jz_mobi_switch:checked + .nav_item_text_wrap > .sub_nav_list{display:block}
	.jz_mobi_nav_item > .jz_mobi_switch:checked + .nav_item_text_wrap > .icon_nav_item{transform:rotate(90deg)}
	body:has(#jz-mobi-nav:checked){overflow:hidden}
	.jz_web_row{padding-top:0vw!important;padding-bottom:0vw!important;padding-left:0%!important;padding-right:0%!important;margin-top:0vw!important;margin-bottom:0vw!important;margin-left:0!important;margin-right:0!important}
	/* the vendor's JS strips the desktop column gutters on phones too; measured on the
	  live phone render at 500px and 768px across the home, column, product and news
	  pages, every .jz_web_col computes 0 padding and 0 horizontal margin (only their
	  width differs, 100% stacked or 50% side by side, which the inline keeps) */
	.jz_web_col{padding:0!important;margin-left:0!important;margin-right:0!important}
	.jz_project{width:auto!important}
	/* the phone render drops `is_col_v2`, so the column stops being a flex column
	  and each module becomes a block that fills it (measured: live
	  .web_col_content is inline-block at 375/500px, ours was flex) */
	.jz_web_col.is_col_v2>.web_col_content:not(.free_container):not(.web_col_content_tabpack){display:inline-block!important}
	/* The product photo grid is a <wc-waterfall> custom element: the vendor's own style pins its children to `position:absolute` with px offsets the JS recomputed for the desktop column (358.5px inside a 916px row), which overflows a phone. The live phone render measured at 500px wide is two 234px columns with 14px gutters, items placed shortest-column-first (total 1009px for six photos). That is masonry, and the only static equivalent that reproduces both the column split and the ragged bottom is balanced CSS multi-column, so express every offset as a viewport-relative fraction of the original (46.8% columns, 2.8% gaps) instead of the desktop px. */
	wc-waterfall{height:auto!important;overflow:hidden;-webkit-column-count:2;column-count:2;-webkit-column-gap:2.8vw;column-gap:2.8vw}
	wc-waterfall>*{position:static!important;float:none!important;width:auto!important;left:auto!important;top:auto!important;margin:0 0 2.8vw!important;break-inside:avoid;-webkit-column-break-inside:avoid}
	/* #module569 is the site's only <wc-waterfall>, and balanced multi-column is not the
	  live layout there: measured at 500px and 768px the vendor JS packs the six photos
	  shortest-column-first (416/131/416 + 150/416/131 at 500), while column-count left
	  us with 416/150/416 + 131/416/131 — photos in the wrong column and a 19px taller
	  grid (1028 vs 1009), which drags every module below it. Place them where the live
	  render does. The gutter is a constant 14px and the padding 1.82%, so an item is
	  (100vw - 3.64vw - 14px)/2 wide and every offset is that width times the aspect
	  ratio the live render measured, which keeps the grid exact at any phone width. */
	#module569 .photo_display_area{--wf-w:calc(48.18vw - 7px);height:calc(4.115385*var(--wf-w) + 3.64vw + 28px)!important}
	#module569 .photo_display_area>.photo_item_zero{position:absolute!important;width:var(--wf-w)!important;margin:0!important}
	#module569 .photo_display_area>.photo_item_li0{left:1.82vw!important;top:1.82vw!important}
	#module569 .photo_display_area>.photo_item_li1{left:calc(50vw + 7px)!important;top:1.82vw!important}
	#module569 .photo_display_area>.photo_item_li2{left:calc(50vw + 7px)!important;top:calc(1.82vw + .641026*var(--wf-w) + 14px)!important}
	#module569 .photo_display_area>.photo_item_li3{left:1.82vw!important;top:calc(1.82vw + 1.777778*var(--wf-w) + 14px)!important}
	#module569 .photo_display_area>.photo_item_li4{left:1.82vw!important;top:calc(1.82vw + 2.337607*var(--wf-w) + 28px)!important}
	#module569 .photo_display_area>.photo_item_li5{left:calc(50vw + 7px)!important;top:calc(1.82vw + 2.418804*var(--wf-w) + 28px)!important}
	/* the original swaps the video banner for its image carousel on a phone;
	   scripts/patch_mobi_banner.py injects that carousel, this gates the swap */
	.jz_banner .banner_pic.jz_banner_mobi_pic{display:block!important}
	.jz_banner .banner_flv,.jz_banner .flv_play_btn{display:none!important}
}

/* The sticky bar's background.
   div.header_content.g_header_content carries a frozen inline
   `background-color: rgba(255, 255, 255, 0)`; the vendor's scroll handler rewrites that
   inline value to `rgb(255, 255, 255)` once the page is scrolled (measured on the live
   render at 1440px: y=0 -> rgba(255,255,255,0), y=10/30/60/90/150/300/600/900/2000 ->
   rgb(255,255,255), height and box-shadow unchanged, #gridHeader itself stays
   transparent at every step). Without the JS ours stays transparent and the nav text
   paints straight over whatever scrolls under it (the whole [0,63] band differed in the
   tile diff from tile 01 down, while tile 00 at y=0 was pixel-identical).
   No static selector can observe scroll position, so express it as a scroll-driven
   animation: CSS animations belong to a higher cascade origin than author-normal
   declarations, including the inline style attribute, which is what lets it beat the
   frozen value. `animation-range: 0 10px` reproduces the measured threshold exactly, and
   `both` holds transparent at y=0 and solid past y=10. Where scroll timelines are
   unsupported the rule is inert and the page behaves as before. */
@supports (animation-timeline: scroll()) {
	#gridHeader>.header_content{animation:jz_header_solid linear both;animation-timeline:scroll(root block);animation-range:0 10px}
	@keyframes jz_header_solid{from{background-color:rgba(255, 255, 255, 0)}to{background-color:rgb(255, 255, 255)}}
	/* The 回到顶部 button, same frozen-inline problem.
	   div.back_top_wrapper#jzBackTopCompon is archived with inline `display:none` on all 11
	   templates; the vendor only reveals it once the page is scrolled (measured on the live
	   render at 1440x900: hidden through y=20, `display:block` from y=30, rect 1353,696
	   66x70; at 500 wide: 446,700 38x38). Those rects are exactly what the archived
	   jzBackTop.579e8950.css already computes for an 813px-tall viewport (`bottom:47px;
	   right:21px; width:66px; height:70px` on desktop, `bottom:75px; right:16px` and a 38px
	   icon on phones), so the only missing piece is the reveal itself. `visibility` in the
	   keyframes keeps the invisible button from swallowing clicks above the threshold. */
	.back_top_wrapper{display:block!important;animation:jz_back_top_show linear both;animation-timeline:scroll(root block);animation-range:20px 30px}
	/* scripts/patch_back_top_link.py inserts an empty `<a href="#top">` as the wrapper's
	  first child so the restored button still scrolls with no JavaScript; the wrapper is
	  already position:fixed, so this makes the whole 66x70 (38x38 on phones) box the click
	  target and covers the SVG, whose handler was the Vue code we dropped. */
	.back_top_wrapper>.jz_back_top_link{display:block;inset:0;position:absolute;z-index:1}
	@keyframes jz_back_top_show{from{opacity:0;visibility:hidden}50%{opacity:0;visibility:hidden}to{opacity:1;visibility:visible}}
	/* the original reveals it almost at once on a phone (live at 500px: hidden at y=0,
	   display:block from y=1) versus ~30px on desktop, so shorten the range under the
	   phone gate. Verified here: 0-20px hidden, solid from 30px on desktop at both the
	   live and the rebuilt rect 1353,696 66x70, and 446,700 38x38 at 500px. */
	@media (max-width: 768px){.back_top_wrapper{animation-range:0 5px}}
}