我正在寻找人们的策略来处理不可避免的需要改变或以其他方式调整CSS类以适应新的HTML元素。我经常发现自己处于这种情况,所以我希望其他人分享我的痛苦并在此提出建议。
想象一下,你有一个产品表,其中包含很好的语义类名products
。这在样式表中适当地设置了样式。几个月后,您的老板要求您在网站上创建一个员工列表,"样式与产品列表完全相同"。
这立即提出了一个重要问题:什么叫新员工表。我能想到的唯一选择是:
products
。这是最快的解决方案,但破坏了语义。这个命名对于未来的开发人员来说毫无意义。.products { ... }
变为.products, .staff { ... }
,.products thead th.number { font-weight: bold }
变为.products thead th.number, .staff thead th.number { font-weight: bold }
等。另一个丑陋的解决方案只会变得更加复杂随着时间的推移。这里采取的最佳行动是什么?
N.B。我确信使用像LESS这样的框架很容易解决这个问题(我没有亲自使用它),但是这个解决方案更像是一个掩盖'而不是实际的补救措施。
答案 0 :(得分:3)
如果你不得不把你的风格用几句话,那会是什么?我尝试使用它来命名我在多个地方使用的样式。然后我知道如果我使用这个类会是什么样子。
示例:
。表条纹{}
答案 1 :(得分:2)
选项4怎么样:
将“产品”复制为“员工”,并随着时间的推移继续单独处理。
答案 2 :(得分:2)
这里基本上有两种思想流派。
1)标记后面的样式 2)遵循风格的标记。
你必须弄清楚你想做哪一个,并试着坚持一个或另一个。如果你混合得太多,那就毫无意义了,你只是一团糟。
在第一个中,您有一个不会改变的设置标记。你想出风格,使它看起来像你想要的方式。这是css zen花园的脉络。它要求您的标记具有极高的语义。缺点是你经常会有很多重复的样式,因为在使用这种方法时并不总是可以干净地设置样式。
在第二种情况下,您可以创建许多常见样式,然后调整标记以适应样式。例如,您可能有一个“float”,“thinBorder”,“bold”类,然后将这些样式应用于您的标记。这里的缺点是,如果您的样式需要更改,那么您必须更改HTML(或使粗体不是粗体,或一些这样)。积极的是你的CSS更干净,更易于维护。
很糟糕,但你必须做出权衡。
答案 3 :(得分:1)
嗯...
根本问题在于,您创建第一个样式类(.products
)的原始想法命名太狭窄。并不总是可以知道您将需要在以后重复使用CSS定义的重要部分,但根据您的问题,您似乎处于该业务范围内。
核心CSS框架没有办法说“让我的新风格(.staff
)与另一种样式(.products
)相同”这些覆盖“
但我相信LESS框架确实能让你定义一个包含所有属性的类(.coolTable
),并在多个其他类定义中重用这些属性(.products
和{{ 1}})很快。
LESS框架不是对'CSS功能的扩展'的'掩盖'。
答案 4 :(得分:0)
这是我真正不喜欢CSS的事情之一。有了我们可以使用的所有强大的语言,这一个似乎从一开始就瘫痪,以处理像你这样的非常常见的场景。我一直都在努力解决这个问题,最后将所有.product相关的类defs复制到我的新类或者将我的新类添加到.product类。他们可以稍后退出。
我也需要研究预处理器,因为我喜欢做的事情是OOP-y - 定义b'基类',即.product和.mynewone继承并从那里继续。
但#3是你最好的选择IMO。
答案 5 :(得分:0)
我要和first option
一起去,因为如果一切都相同&内容只是一个变化。因此,最好将以前的products
课程用于工作人员。您可以在HTML页面内的评论<-- staff plan-->
的帮助下单独定义您的员工面板。
答案 6 :(得分:0)
我会选择第一个选项,让products
使用此块...或者可能像class="products staff"
这样我就不会有重复的样式(即使从未来的角度来看,当代码/样式可能会发生很大变化时),产品的任何特定样式都可以通过新类(或其他使用方式)完成样式中的父类,以赋予样式更多的特异性。)
是的,product
类词在这里没有多大意义,但即使对于未来的开发人员,它仍然意味着你使用的是员工类的样式,与逻辑无关。 ..
但仍然可以,如果可以轻松地将标记从product
修改为其他单词,我会这样做......但在这些情况下不是这样的主要要求......
答案 7 :(得分:0)
为新类型的内容引入个别类名称可能是正确的解决方案。但不幸的是,当前的CSS语法远非完美,因此通过逐个列出完整的选择器,迫使我们在CSS中过于冗长。
所以在实践中,大多数可维护的解决方案通常是尝试找到相同风格的不同内容的通用名称。