/* =============================================================================
 * responsive-common.css —— 全局兜底：容器宽度 / 轮播豁免 / 不可断行长串
 *
 * ★ 本文件由 `responsive.css` 拆分而来（2026-09-26），**声明值一字未改**，
 *   只做了「按归属分文件 + 按断点排序 + 章节重编号」。
 *   拆分前的单文件版备份在 `responsive.css.bak`，回滚见该文件头。
 *
 * ★ 断点顺序（全站 4 档，各文件内部顺序一致）：
 *     ≤1199px  小桌面 / 横屏平板
 *     ≤991px   平板竖屏
 *     ≤767px   手机
 *     ≤479px   小屏手机
 *
 * ⚠ 权重：选择器必须 ≥ 原站同名规则。同权重靠后加载即胜出，**尽量不写
 *   强制声明（`!` + `important`）**。会被原站更高特异性规则压掉的，必须带上
 *   与原站相同的祖先前缀（约定 40 / 41）。
 * ========================================================================== */


/* ===========================================================================
 * ≤1199px —— 小桌面 / 横屏平板 —— 容器等比收窄，栅格不变
 * ========================================================================= */

@media (max-width:1199px){


	/* ---- 1. ★★ 通用兜底（本层最重要的一条）----
	   原站有几十个「width:1200px + margin:0 auto」的顶层容器，而且**每个页面
	   的容器类名都不一样**：
	     .MainCont1（模块首页）｜.WeiContent（微分享）｜.Content + .PageNav +
	     .ContBox + .Cont（礼品）｜.content_text + .content_ad + .banner_box（招聘）
	     ｜.MainCont2（列表页）……
	   逐个枚举必漏 —— 实测第一次就漏了 5 个页面，全部表现为
	   `sw=1210 vs vw=390`（横向滚动 820px），而且症状一样、类名不同。

	   `max-width:100%` 能在**不改原 width 声明**的前提下把宽度压回父级
	   （CSS 里 max-width 优先于 width），所以桌面 1200px 基线完全不受影响，
	   只有「比父级还宽」的容器被压回来 —— 正好是我们要的。
	   ⚠ 不要图省事改成 `width:auto`：那会把 992–1199 档的定宽容器也拉满，
	     桌面观感会被改掉。

	   ★★ 2026-09-24 修正：层数从 3 层扩到 **8 层**。
	   原来的注释写「刻意不到第 4 层，再往下会碰到轮播的 ul 轨道」——
	   **这个判断有一半是错的**（iPhone 16 上暴露出来）：
	     ① 首页 `.content_left .piclist_box{width:681px}` 在第 **4** 层，
	        `.content_right .topstories{width:492px}` 在第 **5** 层，
	        `.piclist{width:681px}` / `.newest{width:492px}` 在第 5 层 ——
	        3 层兜底完全够不到，于是它们被 `.content_first{overflow:hidden}`
	        **整块裁掉**（实测裁 328px / 139px）。
	     ② 但**它们不会撑大 `html.scrollWidth`** —— 被祖先裁住了 →
	        `check_responsive.py` 的断言 1（scrollWidth <= innerWidth+1）
	        **全绿**，而内容在视觉上已经被切掉了。这是断言 1 的固有盲区，
	        所以另写了 `diag_hclip_all.py` 专门查「被祖先横向裁掉」的元素。
	     ③ 轮播确实不能被压 —— 但它不是靠「少写几层」来躲的，
	        而是靠**下面的显式豁免**（`.wrap .SlideContThe1 *` 等）。
	        用层数去躲是脆的：容器嵌套一深就漏（本次就是）。

	   ⚠ 安全性：这些写死宽度在桌面 1200px 下**本来就是「正好等于父级宽」**
	     （681 在 681 里、492 在 492 里），所以 `max-width:100%` 在桌面
	     **零影响** —— 只有窄屏「比父级还宽」时才生效。桌面回归已复验。 */
	.wrap,
	.wrap > *,
	.wrap > * > *,
	.wrap > * > * > *,
	.wrap > * > * > * > *,
	.wrap > * > * > * > * > *,
	.wrap > * > * > * > * > * > *,
	.wrap > * > * > * > * > * > * > *,
	.wrap > * > * > * > * > * > * > * > *{
		max-width:100%;
	}


	/* ---- 2. ★★ 轮播豁免（必须在 0 之后，权重更高）----
	   两类轮播的几何**都写死在 JS 里**，只能用 `zoom` 整体等比缩放
	   （见 nav.js 第 5 节），**绝不能被 `max-width:100%` 压**：
	     ① 模块首页 `.SlideContThe1` —— `slidecont1.js`：
	        `slide_minwidth=780`、`width:'830px'`、换页靠 `left:-(780*n)px` 算位移；
	     ② 主站首页 `.slideConts` —— `images/style7.0/index/slide.css`：
	        `width:680px; height:310px; position:relative; overflow:hidden`，
	        每个 `li` 是 `position:absolute; width:680px`，换页动画把 `left`
	        从 760px 移到 0px（**原位淡入式，不是轨道式**）。

	   ⚠ 为什么必须显式豁免而不是「少写几层」：
	     如果同时有 `max-width:100%`(353px) 和 `zoom`(0.519)，
	     会变成 353 × 0.519 = **183px —— 双重压缩**，轮播缩成一条。
	   `.wrap X` (0,2,0) 权重高于 `.wrap > * > …` (0,1,0)，稳定胜出。 */
	.wrap .SlideContThe1,
	.wrap .SlideContThe1 *,
	.wrap .slideConts,
	.wrap .slideConts *,
	.wrap .ShowSlide,
	.wrap .ShowSlide *{
		max-width:none;
	}


	/* ---- 3. 表格里的「不可断行长串」----
	   原站数据里混着一批**百分号编码的 SEO 垃圾标题**
	   （如 `%BC%AB%CB%D9%B5%BC%` —— GBK 转义的「极速导航」、`%E5%A4%A7%E5%8F%91%`
	     = 「大发」），19 个 ASCII 字符中间**没有任何断行点**。
	   → 把所在 `<td>` 的 min-content 撑到 200px+，4 列 × 25% 的表格
	     溢出 `.main_box`，再被 `overflow:hidden` 裁掉（iPhone 16 实测裁 32px）。
	   ★ 用 `anywhere` 而不是 `break-word`：
	     `break-word` **不影响内在尺寸**（只影响渲染），压不住 td 的 min-content；
	     只有 `anywhere` 会把「软换行机会」计入 min-content 宽度，才能真正收窄。
	   ★ `overflow-wrap` 是**继承属性**，写在 `td` 上即可作用于里面的
	     `div[style="float:left"]` 标题盒，不必逐个选。
	   ⚠ 只收在 `.main_box`（首页）—— 它会改变表格的 min-content，
	     进而影响 auto table layout 的列宽分配；在别的页面无差别铺开会
	     让「本来排得好好的」列表表格重新分配列宽。 */
	.main_box table td,
	.main_box table th{
		overflow-wrap:anywhere;
	}

	/* 正文容器自己写死 830px（modules/news/pc/bencandy.css），
	   它比 .Main 深两层，上面的通用兜底够不到。 */
	.InfoContent{
		width:auto;
	}

	/* 首页「书画画家」右栏：原站是绝对定位浮层
	   （`.supermarket_right{position:absolute;width:910px;margin-left:307px}`），
	   且**没有定位祖先 → 包含块是初始包含块**，所以 `.main_box{overflow:hidden}`
	   裁不住它 —— 它会直接撑大 `html.scrollWidth`（实测 1127 vs 390，
	   而 body.scrollWidth 仍是 390，是这个坑的典型指纹）。
	   窄屏下改回普通流，排在左栏名单下面。 */
	.main_box .supermarket .supermarket_right{
		position:static;
		float:none;
		width:auto;
		margin-left:0;
		margin-top:var(--aa-s4);
	}

	/* 主导航降一档字号，保证 16 项尽量少换行。
	   ★ 原站结构是 `dl > dt > span > a`（**不是** li > a），
	     之前写成 `li a` 导致这条规则从未生效过。 */
	.MainMenuBox .MenuList dl > dt > span > a{
		font-size:var(--aa-f-sm);
		padding-left:8px;
		padding-right:8px;
	}

	.Logo_Search .search .types li{
		font-size:var(--aa-f-xs);
	}

	/* 模块首页：左栏 + 右栏按比例收窄（原站 860 + 320） */
	.MainCont1{ width:auto; }
	.MainCont1 .Left{  width:auto; }
	.MainCont1 .Right{ width:280px; }

	/* 栏目列表 / 详情：主栏 + 侧栏（原站 830 + 350） */
	.BencandyCont{
		width:auto;
		max-width:var(--aa-container);
		padding-left:var(--aa-gutter);
		padding-right:var(--aa-gutter);
	}
	.BencandyCont .Main{ width:auto; }
	.BencandyCont .Side{ width:300px; }

	/* 模块首页主体容器 */
	.MainCont2{
		width:auto;
		max-width:var(--aa-container);
		padding-left:var(--aa-gutter);
		padding-right:var(--aa-gutter);
	}

}