- 原文地址：Your CSS is an interface
- 原文作者：Eric Bailey
- 译文出自：掘金翻译计划
我的室友最近在用多邻国（Duolingo，一款语言学习工具软件）学习日语。从400多天到现在，他们每天都打开这款软件并完成多邻国提供的练习，乐此不疲。几天前，他们分享了多邻国使用时的软件截图给我，如下：
如果我没有猜错的话，软件截图上的多选按钮组件，出现了一个暗黑模式下的颜色逻辑bug。我敢肯定上面出现bug，是因为即使没有考虑设计暗黑模式，一个像多邻国这样成熟的应用软件，颜色管理必然也是一件复杂的事情。
换句话说，上面的bug是一个非常糟糕的颜色比对问题，直到这个bug随着软件更新被修复，它都会让很多人无法使用这款软件（译者注，如视力障碍者）。
第三方应用软件 vs 网页应用
如果不能看清除按钮内容，你就无法使用该应用软件。
而且因为它是一个应用软件，（为了能正常使用该软件）你需要等到：
- 用户发现并反馈了bug，
- 软件测试者鉴别出了该bug
- 软件开发者修复了该bug
- 该软件推出了一次更新，然后
- 用户下载并安装该软件
我们只能寄希望于bug足够重要，不至于让这个bug永远没被软件开发人员发现而沉底。
但是在网页应用上，我们有选择可以改变这一状况。我们能使用浏览器的检查工具，浏览器扩展，以及专门的显示模式（无障碍模式）去修改网页内容并让其方便使用。
你做过这样的事吗：使用浏览器检查工具打开控制台，移除网页上一个密码输入表单的文本粘贴限制？这是个典型的例子，它展示出了浏览器网页应用的弹性和灵活性，网页应用的这些优点源于它与其它软件的构建方式截然不同。
人的素养不同且丰富
每个人的技术素养参差不齐，如同光谱一样，但是不能因此认为，一个不懂相关技术的人，在激励因素足够高的前提下，不会为了他自己需求的东西而进行高技术性的开发操作。
同时，也不能忘记人际关系网络的重要性。你有没有遇到过同事跟你分享如何使用一些公司内部应用的小窍门？或者你帮助家人或朋友解决过他们遇到的技术问题吗？
例子
大多数情况下， CSS的属性和值对一个不懂CSS的外行看来也很好理解。可以看看下面的例子，background-color 以一种语义化地直接方式传达这个属性要达成的效果，而且#f78cd2 不是一个特别难理解的值，特别是在浏览器已经在值旁边展示了一个小方块，用以可视化颜色。
同样地，有些人可能不知道 rem 是什么意思，但是很容易通过将数字值做一些改变从而知道值旁边的属性有何作用，如：改变 margin-top 属性声明旁的值，从 1rem 修改为 2rem 会看到某物顶部的空间增加了。
进一步的讨论，一些人可能不知道BEM方法论 （Block，块；Element，元素；Modifier，修饰符）是什么，但是很容易理解一个被命名为 .c-product__description 的类语义上是对一个产品描述，同理，被命名为 .c-heading--secondary 的类名语义上是副导航的意思。依此类推，一个被命名为 color-text-blue 的工具类的作用是很好判别的。
人性化的CSS类名
一个友好的CSS类名能够保证，当人去修改它们包含的属性值时，他有把握知道自己到底在修改什么。
例如，某人在视查一个卡片组件时，能通过查找类名知晓该类控制的是卡片的标题，然后修改该类中的属性声明以满足自己的需求。
.c-card__title { ... }
统一使用人性化的CSS类名，可以做到很多事情，如构建一套自己的主题。不需要请求第三方服务构建主题，并且自己构建的主题能够随时改变并应用。
程序友好型CSS类
即最小化的CSS类名，如在Twitter， Instagram等应用的CSS类名，是像超高效的优化策略或者React Native 编译等方式生产的结果。
这里有一些例子，通过自动识别多个不相关组件之间共享的属性声明共享，上面的 .c-card__title 类名的各个声明会被分解成更多的原子类。
.jxks-901oao { … }
.jxks-16my406 { … }
.rxq3-poiln3 { … }
.rxq3-bcqeeo { … }
.rxq3-qvutc0 { … }
这些支离的、非对人友好的原子类名虽然能被修改，但是并不能确定到底改变了什么位置。实际上，我们做的事情只不过是把“两个CSS属性凑进一个酒吧“（译者注：比喻声明CSS属性时的操作）然后在把它弄的一团糟（指使用工具最小化类名）。
界面
”界面是我们与计算机一起工作的通道“ —— 尼克·阿恩（Nick Arner）。
有好的界面，也有不好的界面。界面也不总是可视化的（译者注：界面的英文interface有接口的意思）。它可以类似于API 设计的东西，或者，如你所料地，CSS定义了访问你的网站或web应用程序的人如何呈现的方式。
人性化的CSS代码，定义的界面会以人为优先级。它允许用户轻松的修改您的网站或web应用程序。因为我们不知道用户是谁，他有何（视力）情况，所以（编写人性化CSS代码）很重要。
程序友好型CSS代码，定义的界面会以机器为优先级——它们定义的类名是下流效应（以节省流量开支为主）的结果。在React Native的生成的CSS代码中，它会优先考虑CSS的兼容性——多个平台可使用。考虑性能优化情况下生成的CSS代码，它最终的生产版本包会是一个充分优化的结果。同时，二者（react native和性能优化生产的CSS）都会产生无语义且混乱的CSS类名。
计算开销
性能开销这篇文章指出，我们应该从全局视角考虑应该以负载为优先，以及为何如此。考虑性能开销意味着开发者应该熟悉各种开支支配，并思考在使用你的网站或网页应用的人中，那些用户更加重要。
对于展示各种艺术的网站，优先考虑图像加载的加载方式更有意义。协同式的 canvas-style （译者注：HTML的画布功能）白板服务的能力可能（对网站开发）尤其重要。
我们需要权衡，是提供用户相对容易操作的CSS类名重要，还是要节省生产包版本的那几千字节重要，这对CSS类名命名策略很关键。我们也要考虑那些省下来的几千字节的CSS打包版本和最终打包的解压后有12MB的JavaScript代码孰轻孰重。
反对原生
网页应用喜欢假装自己是原生应用，原生应用的想法也是从此而来。但是，混淆类名、阻止缩放、限制复制和粘贴实际上都是在反对原生。
问题的本质就是网络变得不完全实诚了。网络应该是可塑的，这种可塑性是一个有高度意义的设计决策。尊重网络的可塑性对每个人都好。
影响力
代码混淆比较棘手的一点是，大多数情况下，开发者都是无意的，但是也一些有预谋的代码混淆行为。
值得一提的是，我的一个聪明、有才华的朋友为一家流行的大型科技公司（译者注：大概率是facebook）工作。他们被控告在没有使用React Developer工具的情况下，进行了一次令人沮丧和艰苦的开发行为——审核和维护一个代码模糊的web应用程序。后来他们才承认，React developer扩展是存在的，且能正常使用（但是没有使用）（这是一次失败的开发流程，并且更多证据证明，不能单靠技术问题去解决社会问题）。
开发者越是将各种关注点进行抽象化，它们就会变得越来越模糊且难以理解。如果一个普通人能够通过修改写微小的CSS style就能提升自己的体验，现在就会更难以通过修改CSS来实现了（因为代码抽象混淆了）。
开发者的选择和所产生的涓滴效应可能会对现实世界产生影响，而且，我认为开发者在技术选择评估时需要考虑这些影响。
你的应用不是推特
我知道另一家大型的流行技术公司（不是推特）的网站因为使用了React Native编译，它呈现的是代码混淆的CSS类名。
幸运地是，这家公司地IOS和Android应用都是使用原生代码构建地。两个手机版本应用地开发团队都是从React Native迁移过来的，所以web网页应用仍然是使用React Native这个失败方法生产的。
也就是说，如果一个拥有数十亿美元资产和近乎无限资源的公司不再支持这样的方法（使用React Native），那么在跟风之前，你可能要三思——因为大多数网站和web应用的需求并不那么复杂。
请别小题大做
在谷歌网络应用商店里的Stylus(一款谷歌浏览器插件)拥有超过50万的用户。Stylish(也是一款谷歌浏览器插件)也坐拥300万用户。因为有很多人希望修改网页成他们想要的样子。
开发者也能从中（这些人气插件）获取益处。请考虑一下这些人气插件能够帮助一些人改善网页浏览的体验。有些网页迫使人们使用，如工作、医疗门户、政府服务等等（译者注：有些网页设计很不合理，通过插件可以修改样式以达到好看的效果，所以作者希望开发者使用原生方式开发网站）。
如果人们每天被迫在工作中使用8-10小时的网页应用， 并且那些网页的醒目红色标题会让他们产生紧张性头痛，难道他们不应该让这些东西修改这些样式让它变的看起来平滑舒适吗？那些想要阻止自动播放视频来阅读新闻的多动症患者怎么办呢?还有那些前庭神经紊乱的人想在滚动（网页滚动）时不呕吐怎么办?
（通过使用原生的方式开发网站）能够解决你被迫忍受的事情，会给你的网页浏览体验带来立即且明显的改善。这真的很重要的。
