语义化html是响应式与可访问性的根基：必须用等语义标签而非div，配合min-width防flex塌陷、em断点适配字体缩放、设宽高防抖动，并确保源码顺序匹配内容优先级。

直接说结论：结构混乱的HTML，再 fancy 的 CSS 动画或 JS 交互也救不回来；响应式不是“加个 @media 就完事”，它必须从 <header></header>、<main></main>、<nav></nav> 这些语义标签开始扎根。

为什么用 <main></main> 而不是 <div id="main">？ <p>浏览器和读屏软件靠语义标签识别内容优先级。<code><main></main> 明确告诉辅助技术“这是页面唯一主内容区”，而 <div id="main"> 只是普通容器，无语义。SEO 也会更倾向抓取 <code><main></main> 内的标题层级与文本密度。

• 每个页面只能有一个 <main></main>，重复使用会触发 W3C 验证警告
• <main></main> 不能嵌套在 <article></article>、<aside></aside>、<footer></footer>、<header></header> 或 <nav></nav> 内部
• 若用 JS 动态插入内容，记得同步更新 <main></main> 的 aria-live 属性（如 aria-live="polite"），否则屏幕阅读器可能不播报更新

flex 布局中 flex-wrap 和 min-width 的配合陷阱

常见错误：设了 display: flex + flex-wrap: wrap，但子项没设最小宽度，导致小屏下元素被强行压缩变形甚至文字换行错乱。

• 给 flex 子项加 min-width: 280px（或 min-width: 15rem）能防止过度收缩，尤其适用于卡片、按钮组
• 避免对 flex 容器设 width: 100% 同时又设 max-width: 1200px —— 这会导致小屏下容器仍占满视口，但内容却被 max-width 截断
• 移动端慎用 flex-direction: column-reverse，部分安卓 WebView 会忽略该值，造成视觉顺序与 DOM 顺序不一致，影响键盘焦点流

@media 断点别只盯着像素，先看内容撑不撑得住

很多团队按 768px / 992px / 1200px 硬套，结果平板横屏（1024×768）下导航栏文字挤成一团，而某些 1366px 笔记本反而因 DPI 高显示模糊——问题不在分辨率，而在内容密度。

html-to-pptx-converter

使用 PptxGenJS 和 Python 解析，将结构化的 HTML/CSS 幻灯片内容转换为原生、可编辑的 PowerPoint（.pptx）演示文稿。

下载

• 优先用 em 写断点：@media (min-width: 48em)（即 48 × 默认字号 = 768px），比像素值更适配用户自定义字体缩放
• 关键断点应基于内容：比如当导航菜单第 5 项开始换行，就在此宽度设断点改用汉堡菜单；当侧边栏文字行宽超过 85 字符，就触发两列变单列
• 避免嵌套媒体查询，CSS 里写两层 @media 容易漏掉中间状态，统一用移动优先，基础样式写默认（小屏），再用 min-width 逐级增强

<picture></picture> + srcset 不是万能，得配 width 和 height 属性防布局抖动

图片加载前若没预留空间，加载瞬间会把下方内容往下顶，破坏滚动节奏，尤其在列表页或卡片流中明显。

• 必须为 <img> 或 <picture></picture> 设置 width 和 height HTML 属性（不是 CSS），浏览器才能提前计算占位尺寸
• srcset 中的描述要匹配实际设备像素比：比如 image.jpg 1x, image@2x.jpg 2x，而非全写 2x，否则低 DPI 设备也会下高清图
• <picture></picture> 的 <source></source> 用 media 属性时，注意它只匹配媒体查询条件，不参与图片选择逻辑；真正决定加载哪张图的是 srcset + sizes 组合

最常被跳过的其实是内容顺序：视觉上左右并排的两栏，在 HTML 源码里如果把侧边栏写在前面，小屏折叠后它就会跑到主内容上方——这不是 CSS 能修的，得从最初写 <main></main> 和 <aside></aside> 的顺序就开始想清楚。