北京
你的网站CSS有多脆弱？每新增一个模块，样式就像多米诺骨牌一样接连崩塌。更糟的是，当你试图修复一个bug，另一处却莫名其妙地乱了。我最近在从头构建一个React（一种用于构建用户界面的JavaScript库）导航组件，要求完全无障碍，并且适配移动端。上一篇文章搞定了键盘导航的数据结构，这次轮到了垂直布局——准确说，是让第一行导航项纵向排列，就像手机菜单那样。整个过程里，我意外发现了一套让CSS不再“年久失修”的写法。
第一条经验：别给元素固定宽度，让流控制元素自然占满整行。以往我总是习惯性地随手给块级元素设个width，看着整齐，实际上埋下了布局僵硬的祸根。这次我坚持所有在默认静态定位下会另起一行的元素，默认不给它们自己的宽度限定。配合层层嵌套的CSS选择器，想要实现垂直排列，几乎不用再和宽度、浮动、清除浮动搏斗。代码量变少了，改动不用再小心翼翼地层层试探。
第二条经验：大胆用后代和兄弟选择器，少写class。我受够了维护老项目时，为了不让一个组件的样式污染另一个组件，在class上疯狂加命名空间，或者用一长串类名链式覆盖。查样式问题像拆弹，尤其当某个样式库配置出错，生产环境的类名被混淆之后，完全没法追踪哪个样式在哪生效。改用单类名控制整个组件，内部全靠选择器下的子元素去推导关系，调试时一眼就能看出样式继承链路，不再需要满屏搜索某个class。
第三条经验：单个类名统治全局，组件真正“封装”。看上去是回到了最简单的做法，但配合好的HTML结构，这个类就足够了。以前觉得组件内样式已经够好了，可是随着项目年限增长，内联样式、独立样式表、CSS-in-JS混在一起，互相踩踏的惨剧不断重演。现在只用一层主类，所有内部元素通过嵌套选择器去定义，原本那种“这个按钮怎么突然变蓝色了”的迷茫感消失了。
第四条经验：结构化HTML不只是给屏幕阅读器准备的，它也让样式书写更自由。我这次做的导航组件从根上就用语义化标签，这样不仅辅助技术能更好地理解页面，写CSS时也能利用标签本身的含义去简化选择器。一个干净的结构，让样式更像是在描述，而不是在修补。整个过程没有额外增加为了视觉呈现而多余的容器，布局已经能符合移动端的第一行垂直排列需求。
第五条经验：跑起来的代码才有说服力。这套导航组件的这版实现已经打包发布在GitHub上，版本号0.5.1，可直接下载运行。所有示例代码虽然为了方便展示用了JavaScript（一种脚本语言）片段，实际工程代码全用TypeScript（JavaScript的超集）编写，目标环境是React 19.x，示例跑在Next.js 16.x（一个React框架）上，但导航组件本身不依赖任何特定框架。文章很长，既有完整代码也有解释，你可以直接根据锚点跳转到感兴趣的部分。可以跟着下载版本、运行示例、对照代码库一步步走，也可以点开每个代码片段旁的链接，在GitHub上查看完整文件。这一路从零搭建无障碍导航组件的实验，还远没结束，但至少到现在，移动端的垂直布局已经不再让我抓狂了。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
