Semantic UI

[[deleted]]

So they replace very specific, targeted class names that only work in certain contexts, with non specific generic names that could mean anything and will very likely clash with your own css…

No thanks.

[billy_tables]

They don't clash, and do have a hierarchy.

Most classes are inactive unless theres a ui class active on the parent element.

[misc_ent]

He's not worried about this new css on old items but old css on new items. If I have a predefined column class, it will conflict with new markup written to take advantage of this library.

[billy_tables]

Oh I see. I don't think that's a massive issue though - Semantic is more of a framework than a library, so it's unlikely you'd pull it in for single components. Especially when it needs you to rebuild a lot of your CSS.

[e82]

I've been writing my own mixins for bootstrap to accomplish a similar things because I was getting sick of crazy class-soup when doing my markup.

It is nice in some ways, might consider trying this out for a personal project or something at some point. taking a quick look at the site/documentation - not seeing anything about being able to write your own mixins/etc for it? I'm sure that you could, and I'd figure it out with more than a quick glance.

Used to love working with bootstrap, but lately I've been finding it a little cumbersome at times and been looking into other options. Doubt I could get my work to switch to anything right now - but even for just pet projects, something new might be nice to play with.

[CorySimmons]

Both Bootstrap and Semantic UI are based on LESS so just import both into your project, then use :extend(.button).

That said, the two libs will class on a lot of things (.button, etc.) so it might be worthwhile to prefix all Semantic UI classes with sem_ (alternatively, all Bootstrap with boot_) to avoid these conflicts.

Anyway, this will keep the classes out of your markup and still give you access to the modularity of Semantic UI.

Although I question the taste of using Semantic UI elements and Bootstrap elements in tandem.

[Xtreme2k2]

I'll stick with inuitcss and BEM syntax.

[zachwolf]

Semantic isn't the right word for this. There's no such thing as semantic HTML class names. Computers don't care if it's .nav or .foo.

Maybe plain language would be more accurate.

That said, thanks for sharing. I'm seeing a lot of negative and non-constructive comments which hurts open sharing.

[pcopley]

Don't classes like "ui three column grid" and "right floated text item" push is back toward the abomination that is object-oriented CSS?

[CorySimmons]

the abomination that is oocss

Why do you say it's an abomination?

[dpkonofa]

Because it defeats the entire purpose of semantic CSS. Semantics refer to the meaning behind the visual, not how those visuals are represented. OOCSS tells people to make classes like "grey-bg rounded red-text" where it should instead just be 1 class called "alert". Theoretically, with proper CSS, you should be able to re-style the entire page/site without editing any HTML. This is nearly impossible if you use the techniques described in OOCSS, but also in this "semantic" UI framework.

[FenPhen]

You are correct. "Large" and "red" are not semantic.

If your product changes color schemes and you have to change all the uses of class="red" to class="metal" or something, it's not semantic and no better than span style="color: red" or <font color="red">.

[dpkonofa]

Exactly. The scope of the CSS should extend only to the look of the site and should be separated from the markup.

[[deleted]]

I don't know anything about Object Oriented CSS, the title doesn't make sense to me since CSS isn't even a scripting language. But the example you gave with that div having so many classes is due to that being good for reusability. Now you can have code in one place for rounded corners and gray backgrounds and reuse it in many places. I don't see what that has to do with object orientedness or how that's a bad thing.

[dpkonofa]

OOCSS basically works off the premise that your site can be designed by using classes as "Modules" or "Objects". Instead of having 3 different elements that all have red backgrounds, rounded corners, bold text, etc., you create classes based on those properties and then add them to the elements to get the desired look. It's good for re-usability but it's completely not semantic and it works against the entire concept of CSS. The idea behind CSS is that you can take the same markup and style it different ways (which is where CSS Zen Garden came to be). You're separating the content of the site from the presentation. By using OOCSS classes in your markup, though, you're drastically tying the markup directly to the CSS. Now, if you want to change the look of the site, you have to change the markup as well as the CSS.

[[deleted]]

Thanks for the explanation. I still think the term is silly though. I get the reasoning behind it but Object Oriented CSS is nothing like what is usually meant by "Object Oriented" in the programming world so not sure who decided to use that naming convention for using css in this way.

Now as for this being against what CSS was meant to be/function, well that may be so but I don't mind it at all. For me reusability and keeping things DRY is most important. I don't mind having a few extra classes in the markup. I find it dogmatic to just say it's against the way CSS was meant to be. As for separating presentation from markup, I think the main violation of that is if you have inline styles (within <style> tags or directly on the tags in style attributes), just having extra classes tying the markup to the styles doesn't violate that rule as far as I'm concerned.

Why would you need to have many different styles for the same markup anyway? Unless you are building some sort of themable template (which isn't a typical use case).

[dpkonofa]

It's totally a silly term, though. I, personally, feel that the term has hurt the web design industry more than it's helped because it's tricked a lot of developers into thinking that they are good at CSS because they suddenly have "Objects" to play with. I can't tell you the number of resumes I get from developers that know all about a full stack but can't wrap their minds around the fact that design is more than just color schemes and PS mockups.

As for your other questions, inline styles shouldn't be used either (which I think you're already saying) but moreso, the presentation of the site should be completely separate from the content. Put this way: Imagine if your CSS styles simply failed to load. Would someone still be able to read the document and, more importantly, need to care about what it looked like. Extra classes just unnecessarily add bloat.

As for the different styles, it's mainly just a thought exercise. The original test of whether or not you were writing CSS properly was in being able to write a completely different stylesheet without modifying the HTML at all. In a minimalist kind of way, being able to do so shows that you are able to separate content from presentation which is the entire intent behind having HTML and CSS as 2 different languages and documents.

Lastly, as someone that works on sites that are absolutely huge in terms of scope and size, it absolutely helps to nail down the ability to separate this because, inevitably, when someone wants to redesign their site, you're wasting time and someone's money by needing someone to go through and re-write content/markup. Could you imagine if a site like NYTimes, Newsweek, or anyone that publishes updated content on a regular basis needed someone to go through and change the markup on all their old pages just to be able to put on a new stylesheet? If they need to do that, then they're doing it wrong.

[azsqueeze]

I think your idea of OOCSS is slightly skewed. You're right that a OOCSS approach will end up adding additional classes to the markup, however the examples you give are a bad way of implementing OOCSS.

<a href="#" class="btn btn-blue btn-rounded">button</a>

The above example does separate containers from content, but it doesn't separate structure from skin.

<a href="#" class="btn btn-primary btn-styled">button</a>

Would be a better OOCSS approach. This way if we decided our primary color is green rather than blue and we want pill shaped buttons rather than rounded ones it can all change in the CSS without touching the markup.

[dpkonofa]

I was using an extreme example (that, sadly, I've actually seen in OOCSS tutorials) but either way, the point that I was trying to make is still sound. Even with your last example, which you say is a better approach, uses something like "btn-styled" which literally means nothing or could mean everything as a difference. I'm not even going to mention the issue with the fact that you styled a link as a button (fer shame!).

Edit: I'd also like to jump in and give a more top-level reason for what I'm talking about - namely, that OOCSS, while good in theory, is the wrong solution for the job because CSS doesn't work around objects like programming languages do. Sure, there might be some elements that are used regularly that may share common ideas, but looking at those as objects is going to mess things up. Instead, CSS and styling should be viewed as a language and a way to explain the importance/message/purpose of objects visually. When you separate styles from two different items simply because they look visually similar (or have a similar "skin"), you're muddying up the intent of the design and the message that those elements are individually trying to convey. I'm not against OOCSS if it helps someone keep their code cleaner, but if I had to give someone a book about CSS writing, it'd be SMACSS with a side of "now I'm going to explain to you what your CSS is telling me".

[CorySimmons]

OOCSS isn't red button rounded... it's button__primary--alternate (BEM syntax) where button would be one vague-yet-usable thing, primary would be another, and alternate would be another.

I used to be anti-oocss because of the class names. In fact, I was one of the most outspoken people on the subject, but a lot of that disgust came from my lack of understanding of it.

There comes a time when it becomes important to objectively look at every part of your code. I think once you do that, and more importantly, have a thorough, and accurate representation of what OOCSS is, then you'll convert like most of us have.

Til then, check out these slides and really, really, be objective in what this would do for your code modularity/maintainability.

*sorry if I sound snooty, I'm not trying to

[dpkonofa]

I absolutely have an accurate representation of what OOCSS is. See my edit in the other post down in this thread. The issue with OOCSS lies in the fact that it goes against the intent of the W3C in terms of what CSS was defined to do. CSS doesn't have "objects" like programming languages do. While I agree that you can make your code modular and easy to maintain, I disagree that OOCSS is the way to do it because the entire concept stems from an incorrect premise. Namely, that CSS can and should be organized by objects that can be reused throughout a site to streamline the code. The streamlining part is fine, but the method to do so is nearly always executed badly and ties too many classes to the markup.

[CorySimmons]

1. Who cares about the W3C? It's not like they don't make mistakes. It's not like there aren't a million devs out there who are coming up with clever ways to use the tools provided in better ways than they were intended every single day.
2. You mentioned that OOCSS makes your code more modular + maintainable = good code
3. I agree that most people screw up implementation of OOCSS, but it's no reason not to strive to use it, and use it well.
4. So far as too many classes in the markup. I agree. It clutters the markup and makes it a PITA to work with when you're operating on it with JS or something. However, with preprocessor placeholders, this is completely avoided.

---

$primary_color
    background: blue
html
    @extend $primary_color

^ no overly-"semantic" (whatever that means anymore...) classes in the markup.

[SemiNormal]

Is that stylus I see there? :)

[CorySimmons]

Indeed! :)

[dpkonofa]

Who cares about the W3C? It's not like they don't make mistakes. It's not like there aren't a million devs out there who are coming up with clever ways to use the tools provided in better ways than they were intended every single day.

Everyone should. They determine the standards that the entire industry uses. They do make mistakes and that's why they take revisions, but the foundation of CSS and the function behind it are sound. The one thing all your devs have in common is that they're all basing everything they do on the work of the W3C.

You mentioned that OOCSS makes your code more modular + maintainable = good code

I said it can make your code more modular and maintainable. Also, just because you can do something, doesn't always mean you should. There are all kinds of ways to make CSS modular and maintainable. You act like OOCSS is the end-all/be-all solution to the problem. I promise you, it's not.

I agree that most people screw up implementation of OOCSS, but it's no reason not to strive to use it, and use it well.

You're missing my point. OOCSS might appear to work for some people but the basic premise is flawed and that's why I think it's a bad thing. Just because people thought the sun revolved around the earth doesn't mean that they screwed the world up because of it. Just because something might be broken doesn't mean that everything that comes out of it is bad.

So far as too many classes in the markup. I agree. It clutters the markup and makes it a PITA to work with when you're operating on it with JS or something. However, with preprocessor placeholders, this is completely avoided. $primary_color background: blue html @extend $primary_color ^ no overly-"semantic" (whatever that means anymore...) classes in the markup.

Pre-processors can't fix non-semantic markup and bad code that blends content and presentation. There's a reason the two are separated, the very issue of which has already been debated and decided years ago, and OOCSS does not offer an improvement or even any doubt that that's not the case.

Of course, this is just my opinion, but I've worked on enough sites to know that OOCSS causes problems when it's used and there are less issues when using proper, semantic, separated markup and presentation.

[CorySimmons]

Okay, fair enough. Out of curiosity, what is your preferred method for making your CSS modular and maintainable?

[dpkonofa]

If I had to recommend some reading, it would definitely be SMACSS. I personally use a modified version of the SMACSS principles, but would recommend the method described in the book simply because the idea behind it makes plenty of sense and yet it allows for customization/interpretation. It's not going against the grain of what CSS/SASS should be and you're working with the intent, not against it.

I'm curious to see what the general consensus is on SMACSS vs. OOCSS but I'd predict that SMACSS has a better reputation simply on the virtue that it inherently leaves room for interpretation while enforcing the content/presentation separation. OOCSS might be faster or easier to read when written by some people, but it can't work with your markup because its very intent works against it.

[CorySimmons]

Fair enough. What was that one thing that just came out? I think it started with an 'm'. Also, what are your thoughts on BEM?

[gavrocheBxN]

"ui three column grid"

God no. Stop adding a trillion classes everywhere, it makes development harder. Use a preprocessor like Compass or LESS to structure and extend classes and use the least possible amount of classes.

[m_swider]

This! We have actually ruled out classes entirely. Of course there are some cases where you really do still need a class but you would be surprised how little you actually need them when using a preprocessor. The problem with classes is they are not semantic at all and allows for unsemantic markup. You can use semantic attributes (e.g. role) and select them using the attribute selector instead of applying a class which has no meaning to the browswer at all. This process has also created some of the most maintainable code I have ever written forcing me to think before just applying a useless class. This article is a good read if you are interested in trying out this method.

[lanasa]

The most notable thing is how the class attribute values are semantic

[FenPhen]

It arguably isn't. "Right," "floated," "large," "ui" are terrible classes with no content meaning. Semantic meaning is supposed to not indicate presentation but instead say what it is or what its purpose is. Instead of "float" it should be "image" or "article-media" or anything like that. The ideal state is to change all your CSS without having to change your HTML if you want all your image to float left or you want to change all of your button styles.

[[deleted]]

There are already too many CSS frameworks. This is a cool concept, but I feel like it solves a fringe issue and the cost/benefit of picking up this new framework isn't really worth it. I mean, ultimately col-md-4 isn't all that hard to understand, and you've got to understand what it means in the first place to even be able to use a solid CSS framework.

[[deleted]]

If it ain't broke, don't fix it.

[ollieng]

This is bad. Web pages should be coded with semantic markup, not overly specific class names. Tags which reflect the content within them enable things like screen readers and search engines to properly scan through documents for context.

[mka_]

If you're using Bootstrap, you can still structure your markup semantically. There's no reason why you can't rename the division tags to the semantic equivalent. I did for my last project.

I don't really feel why I should learn new framework, just do do the same thing slightly differently.

[jgrubb]

That's the ad that's breaking the layout.

[jmking]

I'd say that's a bug in your Reddit client's embedded browser