如何说服你的团队采用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极大地简化了以前布局需要大量hackpolyfill)的过程。 如果你需要使用较旧的布局方法破解复杂设计,那么你将浪费宝贵的时间。 当然,你还需要为旧版浏览器提供可用的后备方案,但通常不需要花费大量时间。

如果你的团队使用较旧的布局技术编写自己的网格框架,那么这一切也需要很多时间和精力。

拥抱创造力

如果设计师、开发人员和团队想要突破界限并构建真正富有创意的现代布局,从人群中中脱颖而出并拥抱网页设计思维的新时代,那么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代码包装在其中,还是仅限于严格要求的地方? 你做个研究并提供一个计划。 你的策略可能会随着时间的推移而发生变化,但你需要证明自己已经考虑过这个问题,以便为你的团队提供最顺畅的过渡策略。

提出方案

尝试并抓住机会向你的团队或领导提交你的方案。 如果你能让别人觉得他们也是讨论方案的一份子,他们就更有可能加入。 此外,可能还有一些你没有想过的陷阱,他们可以指出,你们可以一起克服。

在组织内推动变革通常很难。 你最好的选择是突出好东西,确保你考虑任何缺点,试着抢先发现并解决问题。 最后,你会得到一些盟友! 一起促进变革会容易得多!

results matching ""

    No results matching ""