Suggestion: naming prefix (namespace simulation)

[Zerzio]

While using OOCSS in a project I'm facing an usual issue about class name conflicts. There is an obvious approach proposed here: http://meiert.com/en/blog/20070321/css-practice-pseudo-namespaces-in-complex-projects/

I suggest to rename all non semantic classes that belong to the core framework (grid, mod and template) Examples:

• oog-line, oog-unit
• oom-mod, oom-complex

Some would suggest to use a parent selector but it's not that obvious and I must say I'm using top parent selector technique in order to mix html fragments coming from two sources using the same css framework in different version (yes, it means everything is loaded twice but I'm more concerned about maintenance than pure performances here)

[martinklepsch]

good idea i think

[fmcarreiro]

I´m have a problem with yahoo framework in .bd class. These class name are equal. tnks for sugestion

[Zerzio]

I wonder what we can do without forking the project.

[martinklepsch]

whats the problem with forking?

[Zerzio]

Ok, explain me what we can do. Should we: 1> Create a fork 2> Apply the NS extension 3> Submit the fork 4> If fork accepted (by Nicole?) it become mainstream

[martinklepsch]

yeah why not? im sure nicole will accept it.. (im kinda new to github so i dont see any problems doing it that way... just tell me if there are problems and we'll see how to fix them)

[stubbornella]

Namespacing is an interesting idea. I had hesitated to do it just because I thought different people might like to apply a different prefix. It seemed easy to add as part of a build step, so I didn't do it.

If we were to add it, I'd like to just add "oo-" in front of each selector, rather than doing namespacing internally within the project. Maybe that is short sighted, but I'd like the selectors within the project to stay consistent enough that there are no conflicts. What do you think?

It will definitely make sense to require namespacing within the plugins directory, and require that their classes do not conflict with any of the classes in core.

[martinklepsch]

oo- is probably enough to avoid conflicts with other css libraries. Let's do it.

[neonstalwart]

fwiw, i use lessjs to wrap everything in an extra selector

.nameSpace {
    /* original oocss rules */
}

currently i'm in development and i let the browser compile the css but the plan is to generate some static files when it comes time to release.

[aglemann]

Kinda weird the mixing of dashed and camelCase names. OOCSS seems to use camelCase as a naming convention.. shouldn't the NS do the same?

[martinklepsch]

Hey,

there is a pull request by "sams" implementing this. I would like to get some feedback on the camelCase vs. dash topic.

To me it seems quite reasonable to omit the dash.

Martin

[aglemann]

I would suggest going with dashes and removing all camelCase in the framework. Based on conventions established by jQuery UI (.ui-accordion), Apple (.ad-scroll-indicator) and other CSS frameworks like Blueprint (.append-bottom), etc..

[aglemann]

Thought of a couple more: Modernizr (.border-image), modern browsers (-moz-selection, -webkit-box-shadow, etc) and CSS aesthetic (text-align vs textAlign)

[stubbornella]

Martin,

Can you shoot us a link to that pull request?

Nicole

[martinklepsch]

You should see the pull request if you click on "Pull requests" im the project menu. https://github.com/stubbornella/oocss/pull/56

Martin

[mikebranski]

Regarding mklappstuhl's comment about dash/no dash, I'd vote to leave the dash in; I find dashes to be more readable than camelCase or no separator. Personal preference aside, using a dash with the namespace will help further distinguish it from the camelCased classes and improve readability.

.oo-unit {foo:bar;} is cleaner than .ooUnit {foo:bar;}, and easier to read than .oounit {foo:bar;}. Of course, this is all just my opinion. :)

[gmclelland]

I agree, leave the dash in.

[stubbornella]

Ok, so let's implement a build script and handle prefixes via that script. It looks like oo- is a good default, but we should make it a parameter.

[Zerzio]

I did such thing in my company but had no time to share. When the site is online I'll show you but now I'm gonna take my Multistrada and leave for one month of good vibes.

Serge

Le 21 Jul 2011 à 22:13, stubbornella reply@reply.github.com a écrit :

Ok, so let's implement a build script and handle prefixes via that script. It looks like oo- is a good default, but we should make it a parameter.

Reply to this email directly or view it on GitHub: https://github.com/stubbornella/oocss/issues/17#issuecomment-1626577

[hezus]

Forked to add a proper buildscript https://github.com/hezus/oocss got the css prefix sorted, default is oo- and it can also be provided as parameter need to still add another regex to sort renaming of the html files.