从理论到实践的距离—由两个元素引发的思考

前两天看到这样一个话题:“如果 div 内只有一行文字,到底要不要插入 p 标签?”

乍一看,这个问题很简单,有人从“语义”和“规范”层面展开了学究式的探讨,还有人说要看具体业务和代码。说得都没有错,可就是觉得少了点什么?

这些答案对提问者有实质性的帮助么?换句话说,作者为什么会提出这样一个问题,他的困惑点在哪里?

简单剖析如下:

1、div就是一个容器,它可以用来放任何东西,就一行字而已,我还需要用多余的标签来放它妈?

2、一行文字应该算一个段落,应该用p来包裹?所以,div里面再来一层p标签吧。

3、既然要用p标签,我还要div干嘛?直接用p就是了。

4、那么,p是放在某一个大的容器当中呢?还是跟那些大的盒子并列?

5、我需要给p加个类再定义样式妈?

6、慢着,这里用p真的是最合适的吗?它是一段文字,但有更适合这个使用场景的标签么?

假如我是抱着这些疑问来提的问题,那么从以上两个层面给的答案就没多大意义了,第一类是基本的概念定义,第二类太笼统。

也就是说,技术正确并不能保证写出经得起考验的代码。

为什么需要考虑这么多?初学者通常不会考虑什么,但随着项目经验的增多,见识的增长,对自己要求的提高,或者来自同行的建议等等,就会不自觉的考虑这些,以免给自己挖坑。

如果你的项目足够大,改动也可能随时发生,那么代码就不再是写一遍之后万事大吉的,它可能面临着上线前的不断改动,上线后的不断迭代,以及本地页面和线上用户实际应用场景之间那些未曾预料的不一致。

举最常见的两个例子:

文字溢出 增加提示性文字/图标/动画

大家常说代码的健壮性、灵活性和可维护性,那就不仅仅是正确的代码,而是更好的代码,要想写出更好的代码,设计师不会教你,产品经理不会教你,通常情况下,只有在遇到问题的时候,你才会问“怎么还会这样?”,他们才会说“是的,这里要处理一下”。

为什么不提前说?一个项目从最初的idea,到大框架形成,到各种细节的优化,没人能把所有需要注意的点都告诉你,并且,事情充满不确定性,新的问题也随时会出现,所以,只有自己吃一堑长一智,踩过坑才会明白,“知道”和“有意识”运用到每天的工作中,是两回事。

比如还是文章开头那个问题,你想,要不要p标签都可以,干脆就不要了,那么,如果遇到如下场景怎么办:

1、需要新加一行字,并且二者样式不同,大小、颜色或其他;

2、需要新加一行文字,并且这两行字需要放置在两行;

3、需要新加其他任意内容,且需要重新定义很多样式,而这些样式是最初的p不需要的;

4、需要新加一条内容,比如按钮,之前的p有10px的左右边距,按钮需要撑满屏;

5、文字前面需要新加入一个图标,它的高度超过文字的高度,但是需要二者垂直居中或其他种种,但是你之前已经把样式定义在了div上。

….

所以,div只是一个通用型、框架型的盒子,为什么要让它和具体的细节样式紧紧绑定?有时候真的不是一句简单的“适不适合、要不要”就可以判定优劣,考虑到它内部的内容、它和外部结构之间的关系,多提几个如果,怎样做更好就不是那么纠结的选择了。

我以前曾写过一篇文章,从前到后的叙述了自己从业至今对UI开发的理解,有提到一些定义公共组件和公用样式需要注意的点,命名要怎样做,需要更通用化而不是具体化,然后怎样合理的划分粒度和利用继承,来做到一定程度的复用又能够避免过度耦合,又可以放置在需要它的地方,不产生样式冲突,这都需要项目历练才能知晓。

我常常会有点后怕,那些看完了某篇“最佳实践”文章或者听了某位前辈简单指导的朋友就确信自己获得的和运用的就是最好的了么,通用的方法论和技巧是有,但放之四海而皆准的方案并没人能提供,它只能来自于我们每个人的思考、积累和沉淀。