如何在旧版Web应用程序中删除CSS意粉？ [英] How to remove CSS spaghetti in legacy web app?
问题描述
在处理过几个大型网络应用程序，看到没有明确结构的巨大的样式表后，我真的很想知道人们是否已经找到方法来保持他们的CSS清洁大型和复杂的网络应用程序。
如何从旧的，乱七八糟的CSS移动到清理，很好的级联，DRY样式表？
我目前工作的应用程序有12000行的CSS。它有机地生长到这个大小有没有标准或审查的CSS，唯一的规则是使应用程序匹配的设计。我们经常遇到的一些问题：
-
冲突风格：一个开发人员添加.header {font-weight：bold;}
-
层叠问题：Foo小部件有一个.header，但它还包含一个
- 如果我们定义.foo .header {...}和.bar .header {。
- 如果我们定义.foo> .header和.bar> .header，但后来需要修改foo来换行头
-
继承问题，我们不断将小部件字体重新定义为11px /正常，因为某些顶部容器使用一个12px / 18像素的行高。
-
使用dojo / dijit或jquery ui等库来增加大量样式，我们的代码是乱七八糟的地方，我们必须重写图书馆风格，让事情看起来正确。
我们正在考虑实施以下规则：
命名空间所有新窗口小部件类 - 如果您有一个小部件foo所有子类名将是.foo_所以我们得到：.foo，.foo_header，.foo_content，.foo_footer。这使我们的CSS基本上是FLAT，但是我们没有其他方法来组织我们的代码，而不进入遗留的样式或上面提到的级联问题。
警察通用类型 - 有一小部分通用类，只在非常具体的情况下应用。例如.editable - 适用于应该调用编辑器的句子部分 - 只应包含文本节点。
利用css编译器混合在不同的窗口小部件中定义相同的样式，定义和使用mixins。虽然我们担心mixins也会失去控制。
我们如何从css混乱，不断地介绍回归到可维持的东西。
解决方案我们使用简单HTML网页形式的样式指南，其中包含每个 CSS规则的示例样式表。
我喜欢的一个例子： http://getbootstrap.com/components/ （2015年新增）
你从这个方法得到的其他pro是可重用性：你知道你得到什么，你知道你想要的样式指南是尽可能小 - 因此：重用。
当您对已在使用的样式进行更改时：检查样式指南。如果它不改变它可能是好的（如果你刚刚改变了一些东西，包括框模型问题，或宽度，高度，填充，一般边缘）。
如何从旧的，混乱的
css转移到清理，很好的级联，
DRY样式表？
使用样式指南作为单元测试。一旦你有了必要的部分：reduce，refactor和combine（你可能会发现
.campaign_1 span和你的常规规则之间的一些争执，继承可以是你的朋友） 。
冲突风格：一个开发人员添加
a .header {font-weight：bold;}，但
.header已在其他
模块中使用，不应在
中使用粗体。
回复Adriano Varoli Piazza的评论和上面的报价：我不记得这是一个完全属于CSS但更多的HTML标记的问题。无论你做什么，这将是一个重的提升。决定你想要保留的规则，并采取行动清理较少使用的;例如：通过继承：
#news a .header {...}或重命名HTML-类a .stand_out_header {...}。
关于以下想法
新的窗口小部件类 - 如果
你有一个小部件foo所有
子类名称将是.foo_所以我们
获得：.foo，.foo_header，.foo_content，
.foo_footer。这使得我们的css
基本上是FLAT，但我们看不到其他
方式来组织我们的代码向前
没有运行到旧样式
或级联问题我提到
以上。
使用包含元素，这将更容易维护：
< div id =widget_email>
< h2>一种类型的h2< / h2>
< / div>
< div id =widget_twitter>
< h2>另一个h2< / h2>
< / div>
After working on several large web applications, and seeing gigantic style sheets with no clear structure, I'd really love to know if people have found ways to keep their css clean for large and complicated web apps.
How do you move from a legacy, mess of css to cleaned up, nicely cascading, DRY stylesheets?
The app I'm currently working on has 12000 lines of css. It's grown to this size organically as early on there were no standards or review of the css, the only rule was to make the app match the design. Some of the problems we constantly have:
Conflicting styles: one developer adds a .header { font-weight: bold;} but .header was already used in other modules and shouldn't be bold in those.
Cascading problems: Foo widget has a .header but it also contains a list of Bar widgets with .header classes.
- If we define .foo .header { ... } and .bar .header { ... } anything not explicitly overwritten in foo will show up in bar.
- If we define .foo > .header and .bar > .header but later need to modify foo to wrap header in a div, our styles break.
Inheritance problems, we constantly redefine widget fonts to 11px/normal because some top container uses a 12px / 18 px line height.
Fighting against widget libraries, using libraries such as dojo/dijit or jquery ui that add tons of styles to be functional means that our code is littered with places where we have to override the library styles to get things looking just right. There are ~2000 lines of css just for tweaking the builtin dijit styles
We're at a point where we're thinking of implementing the following rules:
Namespace all new widget classes - if you have a widget foo all sub-classnames will be .foo_ so we get: .foo, .foo_header, .foo_content, .foo_footer. This makes our css essentially FLAT, but we see no other way to organize our code going forward without running into the legacy styles or the cascading problems I mentioned above.
Police generic styles - have a small handful of generic classes that are only to be applied in very specific situations. e.g. .editable - apply to portions of a sentence that should invoke an editor - should only contain text nodes.
Leverage css compiler mixins To avoid repeatedly defining the same styles in different widgets, define and use mixins. Although we worry the mixins will get out of control too.
How else can we move from css mess that constantly introduces regressions to something maintainable going forward.
解决方案We're using a style guide in the form of a simple HTML page with examples of every CSS rule in the stylesheet. It's very easy to tell if you add a new, incompatible rule since the examples are aligned on top of eachother.
An example I like: http://getbootstrap.com/components/ (added 2015)
The other pro you get from this method is reusability: you know what you got and you know that you want the style guide to be as small as possible - therefore: reuse.
When you make changes to styles already in use: check the style guide. If it doesn't change it's probably good (you might need to browse around a bit if you've just changed something including box model-issues, or width, height, padding, margin in general).
How do you move from a legacy, mess of css to cleaned up, nicely cascading, DRY stylesheets?
Use the style guide as a unit test. Once you got the essential parts in it: reduce, refactor and combine (you most probably will find some collissions between
.campaign_1 spanand your regular rules, inheritance can be your friend).Conflicting styles: one developer adds a .header { font-weight: bold;} but .header was already used in other modules and shouldn't be bold in those.
In reply to Adriano Varoli Piazza's comment and the quote above: I don't recall this as a problem fully belonging to the CSS but more to the HTML markup. No matter what you do, it will be some heavy lifting. Decide which rule you'd want to keep and take actions towards cleaning out the lesser-used-ones; for example: via inheritance:
#news a .header { ... }or renaming the HTML-classa .stand_out_header { ... }.About the following idea
Namespace all new widget classes - if you have a widget foo all sub-classnames will be .foo_ so we get: .foo, .foo_header, .foo_content, .foo_footer. This makes our css essentially FLAT, but we see no other way to organize our code going forward without running into the legacy styles or the cascading problems I mentioned above.
Use a containing element instead, which will be much more easy to maintain:
<div id="widget_email"> <h2>One type of h2</h2> </div> <div id="widget_twitter"> <h2>Another h2</h2> </div>这篇关于如何在旧版Web应用程序中删除CSS意粉？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
