I think so, it's basically putting a name to an approach used by the CSS author, in much the same light as creating styleguides. Is it useful? Yes. Is it easy to inherit someone else's OOCSS work? Probably not.
What are the benefits of OOCSS?
Abstracting style attributes of a certain component is always good for style consistency over the whole of the site. Say you want to change the border style of the components for a fresh new look: You'd typically change a few lines concerning the border-style master style.
An example
I created a UI Developers styleguide (or style vocabulary) concerning all the 'widgets' in our web app. Each widget would be classified according to its intended contents. Each widget could have any number of predefined box-styles, background-styles. Each widget could also lay out its contents different depending on what parent element it was placed under.
This amounted to code like: <div class="free bg_neutral form_search"> being used for each wrapper / container, with each class being: "Box Style, Background Style, Content" respectively. The developers working on the HTML / Views could then easily switch out any of the predefined styles and replace them with more appropriate ones. e.g. replacing bg_neutral with bg_gradient_fff_eee for a gradient background instead.
I think we saved countless lines of CSS code, because we could use interchangeable properties on a few core 'widgets', rather than defining each and every unique incarnation of each 'widget'. It also makes cross-browser fixing much easier, because you can tackle the 'widgets' styles independently. (Most browser bugs are related to box dimensions and position/layout)
In my opinion, more UI folks need to go thru a StyleGuide / Style Vocab exercise when designing and implementing the front-end of their sites. Create consistency in the visual elements used on the site. Consistent visuals usually result in consistent and efficient CSS!
I do not see any benefits to this concept, since the current definition of CSS is somewhat object-oriented already with its cascading, selectors, wildcards, etc.
They mention separating container from the content, which to me is exactly what CSS does already.
The slide show is a great set of standards and guidelines to follow. I use them all the time, looking for patterns and repetition in my designs, then factoring those out to components.
Navigation, Panel, Grid, Repeater, Card, etc. These are all common components I design for each site.
I also have separate CSS files for Utilities, Page and Content. Utilities stores things like my clearfix or margin normalizer, Page stores overall site layout (header, footer, main), and Content is a universal set of rules for headings, paragraphs, links, lists, etc. site-wide.
"Object Oriented" is somewhat of a misnomer here, at least in the strict sense of the term. But the design guidelines that he presents are sound and useful, and goes some way towards alleviating the "brokenness" of the CSS standard.
The problems that he points out - brittle designs, large files, low maintainability and so on, are consequences of a standard that is too loose, too ad hoc-oriented and based on original design goals that are no longer valid. He correctly observes that successful design demands a clear head and great deal of discipline.
On a related note, you may want to look at the compass stylesheet framework. See also the primer. It looks interesting, although I have not had opportunity to use it in a project yet.
I would love to see some form of inheritance in css. Full blown oo? That would probably be overkill but inheritance would shrink the size of my stylesheets exponentially.
看到 .nav_item 和 .nav_link 时不要惊慌。 大多数使用 li 和 a,但我想让它独立于标签。
The benefit is the ability to extend objects and keep code dry and readable. Those that are against it usually either a) hate the name or b) never used it. Let's put it this way...
Example
Every site has different types of navigation. You can have navigation in the header body, in a sidebar. Maybe, you even have tabs or breadcrumbs on your page? You might even need a toolbar for a rich-text editor on a page. This is where the .nav abstraction would come into play.
As Tor Haugen pointed out, the term "Object-oriented CSS" is a misnomer.
"Object-oriented CSS" is really just a design pattern for how to get most out of your CSS and is basicly the same approach Jonathan Snooks calls SMACSS.
Whether you call it OOCSS or SMACSS, the key to the approach is that you create generic UI elements like the nav abstraction. These UI elements can then be enhanced with more specific features by adding extra classes to the element and/or a container element. Or, as an alternative, you can add your own custom CSS rules using the element's ID or semantic classes.
发布评论
评论(10)
相关吗?
我认为是的,它基本上是为 CSS 作者使用的方法命名,与创建样式指南非常相似。 有用吗? 是的。 继承别人的 OOCSS 工作容易吗? 可能不会。
OOCSS 有什么好处?
抽象某个组件的样式属性始终有利于整个站点的样式一致性。 假设您想要更改组件的边框样式以获得全新的外观:您通常会更改有关边框样式主样式的几行。
示例
我创建了一个关于我们网络应用程序中所有“小部件”的 UI 开发人员样式指南(或样式词汇)的 。 每个小部件将根据其预期内容进行分类。 每个小部件可以有任意数量的预定义框样式、背景样式。 每个小部件还可以根据其所在的父元素来布置不同的内容。
这相当于如下代码:
用于每个包装器/容器,每个类分别为:“盒子样式、背景样式、内容”。
然后,处理 HTML/视图的开发人员可以轻松切换任何预定义样式并用更合适的样式替换它们。 例如,将
bg_neutral
替换为bg_gradient_fff_eee
以获得渐变背景。我认为我们节省了无数行 CSS 代码,因为我们可以在几个核心“小部件”上使用可互换的属性,而不是定义每个“小部件”的每个独特的化身。 它还使跨浏览器修复变得更加容易,因为您可以独立处理“小部件”样式。 (大多数浏览器错误与框尺寸和位置/布局有关)
在我看来,更多 UI 人员在设计和实现网站前端时需要进行 StyleGuide / Style Vocab 练习。 创建网站上使用的视觉元素的一致性。 一致的视觉效果通常会产生一致且高效的 CSS!
希望有帮助,
ND
Is it relevant?
I think so, it's basically putting a name to an approach used by the CSS author, in much the same light as creating styleguides. Is it useful? Yes. Is it easy to inherit someone else's OOCSS work? Probably not.
What are the benefits of OOCSS?
Abstracting style attributes of a certain component is always good for style consistency over the whole of the site. Say you want to change the border style of the components for a fresh new look: You'd typically change a few lines concerning the border-style master style.
An example
I created a UI Developers styleguide (or style vocabulary) concerning all the 'widgets' in our web app. Each widget would be classified according to its intended contents. Each widget could have any number of predefined box-styles, background-styles. Each widget could also lay out its contents different depending on what parent element it was placed under.
This amounted to code like:
<div class="free bg_neutral form_search">
being used for each wrapper / container, with each class being: "Box Style, Background Style, Content" respectively.The developers working on the HTML / Views could then easily switch out any of the predefined styles and replace them with more appropriate ones. e.g. replacing
bg_neutral
withbg_gradient_fff_eee
for a gradient background instead.I think we saved countless lines of CSS code, because we could use interchangeable properties on a few core 'widgets', rather than defining each and every unique incarnation of each 'widget'. It also makes cross-browser fixing much easier, because you can tackle the 'widgets' styles independently. (Most browser bugs are related to box dimensions and position/layout)
In my opinion, more UI folks need to go thru a StyleGuide / Style Vocab exercise when designing and implementing the front-end of their sites. Create consistency in the visual elements used on the site. Consistent visuals usually result in consistent and efficient CSS!
Hope that helps,
nd
我没有看到这个概念有任何好处,因为 CSS 的当前定义某种程度上已经是面向对象的,具有级联、选择器、通配符等。
他们提到将容器与内容分开,对我来说这正是 CSS 已经做的事情。
I do not see any benefits to this concept, since the current definition of CSS is somewhat object-oriented already with its cascading, selectors, wildcards, etc.
They mention separating container from the content, which to me is exactly what CSS does already.
问题中链接的演示文稿由雅虎性能工程师 Nicole Sullivan 提供。
雅虎网站上有一个原始演示视频开发者网络站点和 github 上的 OOCSS 项目存储库。
The presentation linked to in the question was given by Nicole Sullivan, a Performance Engineer at Yahoo.
There is a video of the original presentation at the Yahoo Developer Network site and a repository for the OOCSS project on github.
幻灯片放映是一套需要遵循的很好的标准和指南。 我一直在使用它们,在我的设计中寻找模式和重复,然后将它们分解为组件。
导航、面板、网格、中继器、卡片等。这些都是我为每个站点设计的常用组件。
我还有用于实用程序、页面和内容的单独 CSS 文件。 实用程序存储诸如我的clearfix或边距标准化器之类的东西,页面存储整个站点布局(页眉,页脚,主),内容是站点范围内标题,段落,链接,列表等的通用规则集。
The slide show is a great set of standards and guidelines to follow. I use them all the time, looking for patterns and repetition in my designs, then factoring those out to components.
Navigation, Panel, Grid, Repeater, Card, etc. These are all common components I design for each site.
I also have separate CSS files for Utilities, Page and Content. Utilities stores things like my clearfix or margin normalizer, Page stores overall site layout (header, footer, main), and Content is a universal set of rules for headings, paragraphs, links, lists, etc. site-wide.
“面向对象”在这里有点用词不当,至少从该术语的严格意义上来说是这样。 但他提出的设计指南是合理且有用的,并且在一定程度上缓解了 CSS 标准的“缺陷”。
他指出的问题——脆弱的设计、大文件、低可维护性等等,都是标准过于松散、过于临时性和基于不再有效的原始设计目标的结果。 他正确地观察到,成功的设计需要清醒的头脑和严格的纪律。
"Object Oriented" is somewhat of a misnomer here, at least in the strict sense of the term. But the design guidelines that he presents are sound and useful, and goes some way towards alleviating the "brokenness" of the CSS standard.
The problems that he points out - brittle designs, large files, low maintainability and so on, are consequences of a standard that is too loose, too ad hoc-oriented and based on original design goals that are no longer valid. He correctly observes that successful design demands a clear head and great deal of discipline.
听起来就像流行语对我说话。 正如 John Rasch 所说 - CSS 已经有点面向对象了。
Sounds like buzzword talk to me. As John Rasch said - CSS is sorta OO already.
在相关说明中,您可能需要查看 compass 样式表框架。 另请参阅入门。 它看起来很有趣,尽管我还没有机会在项目中使用它。
On a related note, you may want to look at the compass stylesheet framework. See also the primer. It looks interesting, although I have not had opportunity to use it in a project yet.
我很高兴在CSS中看到某种形式的继承。 全面爆发了哦? 这可能有点矫枉过正,但继承会成倍缩小我的样式表的大小。
I would love to see some form of inheritance in css. Full blown oo? That would probably be overkill but inheritance would shrink the size of my stylesheets exponentially.
好处是能够扩展对象并保持代码干燥和可读。 那些反对它的人通常要么 a) 讨厌这个名字,要么 b) 从未使用过它。 让我们这样说...
示例
每个站点都有不同类型的导航。 您可以在标题正文、侧边栏中进行导航。 也许,您的页面上甚至有选项卡或面包屑? 您甚至可能需要页面上的富文本编辑器的工具栏。 这就是 .nav 抽象发挥作用的地方。
这与出现在我的所有控件中的代码相同。 现在,我所要做的就是为它创建一些皮肤。
侧边栏皮肤
选项卡皮肤
主菜单皮肤
将它们放在一起
我所做的就是编写类属性的对象名称和皮肤名称。 这包括两者的属性。
看到 .nav_item 和 .nav_link 时不要惊慌。 大多数使用 li 和 a,但我想让它独立于标签。
The benefit is the ability to extend objects and keep code dry and readable. Those that are against it usually either a) hate the name or b) never used it. Let's put it this way...
Example
Every site has different types of navigation. You can have navigation in the header body, in a sidebar. Maybe, you even have tabs or breadcrumbs on your page? You might even need a toolbar for a rich-text editor on a page. This is where the .nav abstraction would come into play.
This is the same code that would appear in all of my controls. Now, all I have to do is create some skins for it.
Sidebar Skin
Tabs skin
Main Menu Skin
Putting It Together
All I am doing is writing the name of the object and name of the skin for the class attribute. This includes properties of both.
Don't panic seeing .nav_item and .nav_link. Most use li's and a's but I wanted to make it tag independent.
正如 Tor Haugen 指出的那样,“面向对象的 CSS”这个术语是用词不当。
“面向对象的 CSS”实际上只是一种如何充分利用 CSS 的设计模式,基本上与 Jonathan Snooks 调用的方法相同 SMACSS。
无论您将其称为 OOCSS 还是 SMACSS,该方法的关键是创建通用 UI 元素,例如 导航抽象。 然后,可以通过向元素和/或容器元素添加额外的类来增强这些 UI 元素的更具体功能。 或者,作为替代方案,您可以使用元素的 ID 或语义类添加自己的自定义 CSS 规则。
有关 OOCSS 的真实示例,请查看 Cascade Framework、Scally 和 InuitCSS一个>。
进一步阅读:
As Tor Haugen pointed out, the term "Object-oriented CSS" is a misnomer.
"Object-oriented CSS" is really just a design pattern for how to get most out of your CSS and is basicly the same approach Jonathan Snooks calls SMACSS.
Whether you call it OOCSS or SMACSS, the key to the approach is that you create generic UI elements like the nav abstraction. These UI elements can then be enhanced with more specific features by adding extra classes to the element and/or a container element. Or, as an alternative, you can add your own custom CSS rules using the element's ID or semantic classes.
For real world examples of OOCSS, check out frameworks like Cascade Framework, Scally and InuitCSS.
Further reading :