如何说服你的团队采用CSS Grid
原文地址
作者：CSSInRealLife@创作时间：2019-03-09
翻译&校验：freedom
你是不是想使用CSS Grid布局但又难以说服你的团队其他成员（你的同事或者你的领导）？ 最近有人问我，有什么建议可以说服对CSS Grid持有怀疑态度的团队在他们的工作流中采用CSS Grid。 虽然我自己在这方面没有遇到任何重大障碍， 但我经常听到一个这样的故事。 你已经准备好潜入并使用最新的现代布局技术，却只有更高的权利才能推动。
尽管有点令人沮丧，但是存在即是合理。让我们打破它吧！
作为旁注，这些想法来自我在网络代理商的经验。 我并不是要声称要分享每个人的经验，而其他环境可能需要采用不同的方法。 但是我认为这里有一些普遍而且有效的建议。
他们为什么需要说服力？
浏览器支持
**
不采用Grid的最常见原因是浏览器支持。 虽然Grid在全球范围内拥有大约85％的浏览器支持，但其他15％的浏览器已经停止支持。 这些用户中有很大一部分是在IE上，从IE10开始，它实际上支持CSS Grid的旧语法。 （我将留下你是否想在某天想支持旧语法的问题，但如果你想沿着这条路走下去，这里有一篇好文章。）这些用户需要的布局至少是可用。 这让我想到了第二个问题......
时间成本
**
如果并非所有浏览器都支持CSS属性，则需要提供合理的回退。 在单独使用单个属性的情况下（例如混合模式），编写额外的一行或两行可能相当简单，使用户能够以有用（或者次优）的方式体验你的内容。 这是渐进式增强。
使用像Grid这样的一个完整规范，如果你将其作为主要布局策略，它将不仅影响一个或两个元素，而且影响整个网页。 所以这是一个略有不同的故事。 你需要确保提供合理的回退，无论你使用哪种策略来支持旧版浏览器。 我不会否认有时这需要一点时间。
如果你团队的其他成员还不熟悉Grid，那么在让每个人都熟悉新的布局策略时，还需要考虑时间因素。 需要让大家离开现有项目一天左右投资这项培训，他们可能会感到紧张。
可维护性
**
有些团队可能会担心，当团队中的其他人拿起你的项目进行工作时，他们会发现维护起来比较困难，因为你使用的是不熟悉的CSS，而不是X框架。 与此相关，使用Grid构建布局有很多不同的方法。 例如，如果一个人使用网格线命名而另一个人使用grid-template-areas命名，则可能会产生相当不一致的代码库，并且可能会让需要重新接手该项目的人感到头痛。
所有这些原因归结为时间和金钱的成本。 我们需要做的是让你的团队相信Grid可以为两者提供帮助。
Grid可以解决什么问题？
现在让我们看一下使用Grid如何帮助解决上述问题，甚至解决更多的其他问题：
复杂布局可以节省大量的时间
**
Grid极大地简化了以前布局需要大量hack和polyfill)的过程。 如果你需要使用较旧的布局方法破解复杂设计，那么你将浪费宝贵的时间。 当然，你还需要为旧版浏览器提供可用的后备方案，但通常不需要花费大量时间。
如果你的团队使用较旧的布局技术编写自己的网格框架，那么这一切也需要很多时间和精力。
拥抱创造力
**
如果设计师、开发人员和团队想要突破界限并构建真正富有创意的现代布局，从人群中中脱颖而出并拥抱网页设计思维的新时代，那么Grid就是其中不可或缺的一部分。 Grid使我们能够构建以前用CSS无法实现的布局。
性能更好
**
许多项目为了实现网格系统导入了大型，笨重的CSS框架。即使是最小的类也可能最终添加了许多额外的类，这些都会增加CSS文件的重量。 对于与“标准”列和行不同的复杂布局，你可能需要求助Javascript库。 在我看来，我们几乎肯定在2019年已经不需要借助额外的JS来处理布局（除了极少数例外）。 CSS Grid可以用很少的代码处理许多复杂的情况。
还有一些迹象表明，使用flexbox创建网格设计的性能较差 - 尽管我无法在相同级别的细节上找到更多资源。
更方便维护
**
因为Grid只是原生CSS，所以它不会有被破坏的风险，或者你必须在一年的时间内重构项目的风险。 它本质上是稳定的。 浏览器支持只会变得更强大。 相反，依赖框架或者库会破坏项目。 他们需要维护。 你可能必须在一两年内重新访问一个项目，但却发现它使用的是不再主动维护的旧网格框架，或者你使用的版本已过时而你无法找到文档。 众所周知的像Bootstrap这样的框架可能不太可能出现这个问题，但它们会带来性能权衡。
同样，投资你的团队学习网格是对未来的安全投资。 它不是一个在几年内就会过时的框架，它的CSS基础仍然存在。 这些技能将在未来许多年内发挥作用。
如何说服你的团队？
网站不必在所有浏览器中看起来都一样
**
我相信最大的障碍是有一个对Grid常见的误解，认为广泛采用Grid就是网站在所有浏览器中看起来都一样。 不幸的是，通常领导认为就是这种情况，或者无法与客户沟通清楚。 没有人希望你的客户在运行IE9的古老吱吱作响的机器上打开你漂亮，闪亮的新网站，并立刻大吃一惊，它不能辜负设计。
这意味着你需要将案例提前进行渐进式增强，并确保在更高级别进行通信。 让领导和设计师了解旧浏览器的局限性，以及实现设计在所有浏览器看起来相同所需要的成本。 这不应该是一个一个项目需要考虑的，而是整个组织的策略。
我知道改变整个组织的思维方式听起来很难，而且不太可能在一夜之间发生。 我看到的一个想法是设计师实际设计一个简化版的网站，作为完全支持版本的后退版本呈现给客户端，就像它们呈现移动和平板电脑版本的设计一样。 通过这种方式，客户端意识到某些浏览器将获得更简单的布局，并且没有什么大惊喜。 此外，设计师实际上可以以一种看起来很好的方式设计它，而不是依赖于开发人员的解释。 虽然不可避免地会涉及更多的设计时间，但在开发方面可以节省很多。 我希望看到这种方法变得更加普遍。
现在试试吧！
你不必全力投入Grid - 它不一定是一种全有或全无的方法。 引入Grid的最佳方法之一是从较小的UI模块开始。 这样你就有机会在视觉上展示它的好处，并希望学好它 - 或者至少激起你团队里其他成员的好奇心。 通过展示而不是直接说出来的方式通常更好。
使用网格与现有布局系统并没有什么不妥，而且人们对此感到满意。 这给了你学习下一部分的时间......
制定策略
**
正如我之前提到的，有很多方法可以使用Grid构建布局。 你需要考虑你和你的团队将如何实施制定的策略，以确保一致性，确保维护不会成为问题。 你可能会认为，一旦每个人都学会了基础知识，那么他们可以使用他们喜欢的任何方法来完成工作，或者你可能决定仅仅使用行号进行放置并避免grid-template-areas，例如，为了避免混淆。 你可能决定为最常见的布局需求创建一些实用的程序类，或者你可能决定将网格代码与组件紧密耦合。
你还需要考虑浏览器支持策略。 你应该使用@supports并将所有Grid代码包装在其中，还是仅限于严格要求的地方？ 你做个研究并提供一个计划。 你的策略可能会随着时间的推移而发生变化，但你需要证明自己已经考虑过这个问题，以便为你的团队提供最顺畅的过渡策略。
提出方案
**
尝试并抓住机会向你的团队或领导提交你的方案。 如果你能让别人觉得他们也是讨论方案的一份子，他们就更有可能加入。 此外，可能还有一些你没有想过的陷阱，他们可以指出，你们可以一起克服。
在组织内推动变革通常很难。 你最好的选择是突出好东西，确保你考虑任何缺点，试着抢先发现并解决问题。 最后，你会得到一些盟友！ 一起促进变革会容易得多！