Why no namespacing on CSS classes?

[DougPuchalski]

Was hoping for an alternative to bootstrap, but yet another library that doesn't co-exist nicely with other libraries and/or existing application code. Why not prefix css classes with zurb- or even just z-?

While it might be possible to refactor app code, not so easily true with other CSS libraries. This is a given with any ruby, and most other language, libraries. Prohibiting non-disruptive integration prohibits consideration for use.

[smileyj68]

We might consider a prefixing option in the customizer in the future. I'll tag this to that effect.

[DougPuchalski]

Great! More receptive than the bootstrap team!

[dennisfrank]

yep, prefixing would be great. I had troubles because of identical class names a few times width Foundation (v2)

[hatefulcrawdad]

We'll look into adding this as an optional add-on in the future, but no plans for it just yet.

[mhayes]

I'm going to close this issue at this time. We'll keep this in mind as we're developing Foundation 4, thanks for the feedback!

[lopezdonaque]

What about this? Is it in the roadmap?

[chrisjlee]

+1. I like the idea of namespacing. I think Zurb Foundation should namespace it's classes. Preferably using smacss naming conventions.

[vinayraghu]

Name spacing would add a lot of overhead but I think it can be a boolean option that defaults to false. Whoever wants to override it should be able to override it

[vladcosorg]

I hoped so much it would be in F5 as an option, no BC break, everyone is happy ...

[cjmyles]

This is a must need feature for us. Is it in the roadmap for a future release?

[adamyocum]

If you're using SASS to build foundation yourself you can achieve this with SASS nesting. I've just done it so I can style a certain area of our site with the foundation form styles while keeping everything else unaffected. You could include other components of foundation or the entire set I think, I'll be doing more of this soon.

Here is the SASS code I use...

// disable body html and other core elements styling in foundation
$include-html-global-classes: false;


// wrap all with id to scope down the effects of foundation form styling using SASS nesting
#external-app {
    @import "includes/foundation-settings";
    @import "../../zurb-foundation/scss/foundation/components/forms";
    @import "includes/foundation-extras.scss";
}


// since the id nesting with SASS seems to not work with the moz-document code, 
// it is re-added here to fix select boxes
@-moz-document url-prefix() {
    #external-app select {
      background: #fafafa;
    }

    #external-app select:hover {
      background: #f2f2f2;
    }
}

This generates a nice CSS file for me that looks like this...

...
#external-app button:hover, #external-app button:focus, #external-app .button:hover, #external-app .button:focus {
  background-color: #304861;
}
#external-app button:hover, #external-app button:focus, #external-app .button:hover, #external-app .button:focus {
  color: white;
}
#external-app button.secondary, #external-app .button.secondary {
  background-color: #e7e7e7;
  border-color: #dadada;
  color: #333333;
}
...

Notice how all rules are namespaced with 'external-app' :D

Hope that helps!

[chrisjlee]

@adamyocum Respectfully, by creating a namespace the way you have you have essentially written code that is reduces the code quality for the following reasons:

1. You're using an id for every single class. ID's are efficient selectors but don't work well to when you need to override them.
2. You've generated more parent selectors for every selector.
3. In many cases, the selectors are overqualified as well.

What we all are looking for are classes that use OOCSS conventions:

• Prefix classes to improve modularity and framework interopolarity.
• Use an agreed namespacing convention that allows for categorization of rules. Like SMACSS
• Allow for high code reuse.

Example classes:

.l-large-6 { /**/ }
.utility-left { float: left } /* Utility Class */
.is-hidden { } /* Utilize state classes */

[adamyocum]

@chrisjlee I totally agree that using an ID is not best practice and plan on changing that to a class in the near future.

I also agree that it's a little heavy handed with the selectors, but sometimes you have to do what you have to do to get things working, and for me it is a maintainable small wrapper that makes foundation play nice wherever I want to use it.

I found this issue while searching for ideas on ways of using foundation inside established sites, and thought based on the original poster that was what he was asking for, I think what you are wanting this for and what I am doing may be different things.

The site I am working on has a large code base and a lot of styling already that can't be easily updated to be compatible with Foundation. So I'm doing this to get the benefit of some of the styling in small areas of the site, while not interfering with any other areas of the sites pages. In the long run I'd like to use Foundation as our sites base styling framework, but for now I can use this technique to gain some of the benefits without re-factoring our current code.

You may know that foundation does have some utility classes already, but if not, some are here... https://github.com/zurb/foundation/blob/master/scss/foundation/components/_global.scss#L354

I find foundation to be very OO in it's approach, and I also prefer using CSS in that way, so we are on the same page I think, perhaps with just different use cases in mind. Either way I appreciate the discussion and hope it will help others as they look into the finer details of using Foundation.

Best Regards.

[DougPuchalski]

I'm not sure I've read any reasons why namespacing is a bad idea, other than it's a change.

Existing designs that want to take advantage of foundation, bootstrap, etc. may require significant work. It's not trivial to replace the likely collisions. Even if this is not the case, a framework such as this is only one use of CSS classes, i.e. other libraries both visual and functional, semantics, etc. Adding a short prefix to all classes to a framework seems a very minimal impact on a single, contained codebase, when not doing so can have a large impact on a large number of projects for a large number of people.

[vinayraghu]

I am on board with namespacing CSS classes. I have tried implementing foundation into an existing project and it was not pleasant to say the least.

Classes like .table and .form are so common, it is inevitably bound to clash with your existing code.

Namespacing reduces the barrier for using foundation with existing sites.

At the same time, we don't need to bloat everyone's code for that reason.

If we add a flag and enable namespacing for those who want it, I am pretty sure we can save a lot of dev efforts. Especially for people trying to use foundation within existing projects.

[adamyocum]

I agree a boolean build variable and namespace variable would be cool, something like below, override them and you're good to go...

$use-custom-namespace: false !default;
$custom-namespace: zurb !default;

The way I am doing it works good enough for me to get some work done and improve things on my site now, but native support would be great and probably more stable. I've found just wrapping the project in a nested css rule gave me some trouble on the moz-document url-prefix() code. Perhaps it is a bug in SASS (the version I use at least) and could be fixed or worked around, but I bet there may be some problems with other edge cases if trying to use the whole framework. It would be nice if it worked out since it would be simpler to implement and maintain than adding if statements everywhere in the library (probably not an option really, if I were zurb at least). If it could be made to work, it would just be another build file. In my comment above's example I'm starting small and just including a single component, the zurb forms style, and I'm using an ID which is a hot issue in the CSS world lately, (lets not go there right now) but, you could use a class just as simply, something like...

.zurb {
       @import "foundation";
}

While this might add some bloat to the zurb code generated, that is what I need, it has the added benefit of greater specificity and that can be a big help overcoming the barrier of using something like zurb on a already live site.

Here's a screen shot of my site with the bibliographies search styled with foundation, while the site search in the header area remains un-affected. Eventually I would like to use zurb as a base and override rules where needed, but this is cool that I can get some instant gratification and start using it without going all-in (impossible for me right now).

anyways, just sharing, everybody go about their business how ever they please :)

[milesj]

There are other libraries besides Foundation that allow for namespacing. Use those?

[adamyocum]

For me it's been worth any trouble I've had so far, it wasn't hard to implement the namespace wrapper myself, but yes, there is always the option of not using foundation.

I have found it useful, but it wasn't exactly obvious to me how I would namespace it the first day I saw foundation. It might be cool if newcomers saw an example of how to use it inside an already established site.

[DougPuchalski]

@adamyocum Wrapping all of the rules in a top-level class is not what I would call namespacing. Each and every selector in the CSS should have a prefix, i.e. .fdn-table as opposed to .table.

[vinayraghu]

@aceofspades While wrapping all rules in a top-level class is not beneficial or the best of CSS, I think its okay for people who are just getting started with foundation and want to use it in an existing project.

.your-class-name .table is also easier to implement code wise.

I think jQuery UI does a similar wrapping of a custom-build with a classname of your choice.
jQuery UI is not the best example of CSS code out there.

[adamyocum]

@aceofspades

Well, I'm not sure on the terminology. Maybe what I'm doing has another name, not sure what it would be called. I think we have the same goal of making foundation play nice with others. Your example uses the class name syntax, while mine relies on the cascading of CSS. I'm not sure how to use your method on element level rules that apply to things like select, form or label. I'm curious how you would 'namespace' those kind of rules? There are lots of element level rules defined in foundation.

[DougPuchalski]

@adamyocum I have used your example, what I might call encapsulation, in the past. Per foundation that works if you have only certain DOM hierarchies where you want those styles or behaviors applied.

I appreciate that you've offered a solution that may benefit some, but fear it may distract from the purpose of the original request.

Too many frameworks expect to be the ultimate authority in the larger scope of an application, and that prohibits a friendly ecosystem where different tools can work well together. A big question I ask myself before adopting a framework is whether or not it will negatively affect other tools that might be better behaved. Bootstrap and foundation are quite similar in this regard, and am baffled why this would be shrugged off by the maintainers.

[adamyocum]

@aceofspades I see now that there are some big differences between the ability to easily encapsulate and name spacing by using a unique prefix. With the power of sass nesting, anything css can be fairly easily encapsulated and used alone. While offering namespacing would help a library to work with others simultaneously. Helping to avoid collisions with other code using popular css class names like panel, button, etc.

I hope our discussion doesn't negatively affect the request, it sounds like a useful feature.

[chrisjlee]

Thought i'd link some interesting discussion from sass issues.

Looks like there's potential for the possibility of a different way of creating namespaced OOCSS named variables via Sass:
http://thechangelog.com/namespace-support-is-being-added-to-sass/
https://gist.github.com/chriseppstein/5649985#comment-836787

[DougPuchalski]

@chrisjlee Thanks for the links. Looks like that syntax still requires editing the original stylesheets, am I right?

[numediaweb]

I think this is a high priority feature as it will allow Foundation to coexist with styles from other host applications; like the WordPress admin for example.

[vinayraghu]

Inuit CSS takes namespacing into consideration and I think the implementation is done pretty neatly. https://github.com/csswizardry/inuit.css/blob/c737cf1694e9db4d597f8d081091b8529614e370/generic/_widths.scss#L17

[numediaweb]

Looking at the date of this issue (Jun 30, 2012) I don't think this will be implemented soon.. But let's hope it will :)

[milesj]

@rvinay88 Toolkit uses a similar approach: https://github.com/titon/toolkit/blob/master/scss/toolkit/components/button.scss#L9

[samueljseay]

Is this still something that will get implemented any time soon? This would be useful to my company if we considered taking Zurb foundation as our UI toolkit.

[rickcurran]

I realise that this is an old thread but I would also like to add my +1 to being able to have some kind of name spacing support for Foundation. Being able to add a custom prefix for CSS classes so that both the CSS and JS can use them without clashing with any CSS / JS on existing sites. Whilst most of my work involves new sites I do at times have to add code to existing sites that don't use Foundation at all so this would be a very useful feature. I do also use Foundation with WordPress a lot and there is always the risk to potential overlap with CSS / JS with plugins that use identical classnames, so namespacing / prefixing would help avoid this issue.

[ncoden]

I'm going to close this issue at this time. We'll keep this in mind as we're developing Foundation 4, thanks for the feedback!
-- @mhayes, 11 Dec 2012

Thank you for the +1 @rickcurran, this issue is so old that no one would have thought to give here some news.

So, namespace and BEM naming are planned for v7. It is some of the breaking changes that are currently in discussion in the Yetinauts/Core Team, with the objective to make Foundation evolving to the latest CSS best practice.

We will soon give more informations about this.

[rickcurran]

Thanks @ncoden for the update. Is there any kind of mailing list / group to follow any of the discussion for V7? Thanks again!

[ncoden]

@rickcurran For now, everything public is on GitHub. But we are working on making our decision-making process more open. (poke @kball)

[irongaze]

Necro-post, incoming. I run a company with a 12 year old legacy product with thousands of hand-coded PHP pages. We're trying to use Foundation to incrementally upgrade various segments of our product (as a complete rewrite would sink our business), and came across this issue in our search for solutions that don't require us to prefix our thousands of legacy CSS rules to resolve conflicts. So +1 from us, massively, for adding a flag to enable a global namespace prefix on Foundation classes.

Heck, make it a +2.