Namespaces and collisions of BP CSS classnames

[GoogleCodeExporter]

I am wondering if it will be possible to namespace the classes that you
define in BP.  The very common names used (such as container and box),
while easy to remember when used in isolation, also have a much higher
tendency to conflict with other CSS definitions that already exist.  When
this happens you end up with errors due to the CSS cascade that can be a
bit tricky to track down.  Users of your framework are very likely to be
including a number of other CSS files and the chances of collision grow.

For example.  I use another CSS/JS tool called NiftyCube.  Your 'container'
class conflicts with their 'container' class of the same name in
NiftyLayout.css.  So my choice will be to modify either the original css
files of that tool or yours in order for both to work together.  I hate to
do this as I like to leave the original source CSS intact and override
anything I want changed in my own CSS class file called application.css
which is a best practice.  This makes it trivial, in theory, to update
those CSS 'libraries' without fear of overwriting customizations that I
have made by simply doing an SVN update.

What I am suggesting is a namespace that looks something like:

'bp_container' or 'bp-container' instead of 'container'
'bp_box' instead of 'box' (What happened to box in the trunk code BTW?)
'bp_span-1' instead of 'span-1'
[etc.  do this for all bp classes]

This way your toolset will play very nicely with other existing or yet to
be developed CSS with limited fear of conflict.  Making this change early
in your dev cycle will limit developer impact.

Thoughts?

Thanks

Original issue reported on code.google.com by glenn.re...@gmail.com on 16 Aug 2007 at 12:06

[GoogleCodeExporter]

Thats true... I would request for this too..

Original comment by gigaprom...@gmail.com on 17 Aug 2007 at 7:01

[GoogleCodeExporter]

If Blueprint ends up including a generator for custom grid sizes (in whatever 
form
that took), one of the inputs could be a CSS declaration prefix.

Outside of that, I'm OK with using simple, bare class names in Blueprint, with 
the
expectation that I have to edit it manually to fit with my other site work.

Original comment by fla...@gmail.com on 21 Aug 2007 at 5:52

[GoogleCodeExporter]

Good idea, I'll look into it.

Original comment by ola...@gmail.com on 22 Aug 2007 at 12:06

• Changed state: Fixed

[GoogleCodeExporter]

Re-opening.  Would like to discuss this.

Original comment by glenn.re...@gmail.com on 9 Sep 2007 at 10:48

• Changed state: New

[GoogleCodeExporter]

Good idea, let's discuss. ;)

* I agree that the name "bp-container" might be a good idea, since "container" 
is used a lot. 
* I don't see the need for bp-span-x, which is a fairly specific name.

Also, the point of the class .box and such, is that you override them if 
necessary, do we really need a name 
like bp-box? :)

Olav

Original comment by ola...@gmail.com on 10 Sep 2007 at 12:31

[GoogleCodeExporter]

I am not the owner. I am the reporter.  Marked with Olav as owner.

Original comment by glenn.re...@gmail.com on 16 Oct 2007 at 7:08

[GoogleCodeExporter]

I believe it's a good idea to have a prefix in all the the BP framework 
classes, this
would give a little more flexibility and won't crash with any other possible css
frameworks (who knows).

Also, I think .bp-clear would be way too much, maybe we could add this feature 
to the
"Blueprint Official Generator" and see how the masses react to this.

Just a thought,
cheers.

Original comment by d.ne...@gmail.com on 17 Oct 2007 at 4:32

[GoogleCodeExporter]

Just another thought.

I can understand the need to have a namespace, however, if Blueprint is the
foundation for your site, which if your using it to lay out your site--I think 
that
is justifiably so, then any extra functionality or changes to the core should 
be done
through the cascade/override. 

In my mind the whole principle of the project seems to be aimed at laying out a 
site
and having reusable CSS, without having to start from scratch. I can't see 
using two
CSS frameworks side by side for layout, of course it can be done, but is it
realistic? I almost think it would cause more headaches then problems solved 
where
one framework has features the other doesn't and in that case I think the 
designer
should consider starting from scratch.

I'm on the fence as to this issue (new at using Blueprint), but I just wanted to
throw my opinion out.

If Blueprint were to have a namespace prefix to it's classes then they all 
should, if
not then none of them should, just ask yourself what the point of having a 
namespace
is all about not just in CSS but in other mainly object oriented languages.

Original comment by edward.edmonds on 22 Oct 2007 at 9:04

[GoogleCodeExporter]

@edward

You said:

"any extra functionality or changes to the core should be done through the
cascade/override"

I do not disagree.  I would not encourage changes to core BP files and would
recommend extending it via another stylesheet that casacades the changes.

However, that is not the problem I was trying to address with this suggestion.  
You
may be assuming that developers will only be including CSS stylesheets from a 
single
source in their applications.

For example, I do Ruby on Rails development and there are a number of third 
party
plugins and gems that provide drop in interface functionality.  Often these 
tools
come with their own small set of CSS styles so that their code is properly 
styled. 
It is not uncommon for professional developers today to have a number of CSS 
files
that provide styling and are cascaded together.  I may be using BP for my grid, 
or
general typography, but that doesn't mean I don't or shouldn't use other tools 
in
combination with that.  Not to mention my own custom application CSS.  I do not 
want
to have to change core code of BP or any other tool in order to eliminate simple
naming conflicts.

Assuming this to be the case, it is not out of the realm of possibility for CSS
classes from different sources to conflict since they use the same very generic 
names
(e.g. box, container, etc).  This is not an imagined problem.  I have 
encountered
such conflicts with BP and other tools that provide CSS code.  While we cannot
control every tool out there, we can make sure that BP plays nicely by 
namespacing it
properly which will all but eliminate such conflicts.

I would state that if you are using BP for professional development, and not 
just the
most simple use cases, this is an important attribute.

If there is a better way to achieve the same non-conflict results than the 
method I
proposed above I am all ears!  :-)  I think this approach, while requiring a 
slight
change in how developers embed css styling in their presentation code, would
eliminate a potential source of conflict as their application grows and is 
extended.

Does that help to clarify?  Thanks for keeping the conversation open.  Perhaps 
we can
come to some closure on this prior to the next release.  The earlier a change 
such as
this is made the better since it requires modifying presentation code wherever 
it is
styled by BP.

Cheers.

Original comment by glenn.re...@gmail.com on 22 Oct 2007 at 9:26

[GoogleCodeExporter]

I just wanted to throw in my 2 cents...
I actually agree with the original comment by olavfb... The reason to change a 
class name depends on it's 
likelyhood of conflict. 'container' is very likely, 'box' slightly less and 
'span-x' very unlikely imho... spans are 
needed for the grid... no designer is going to use 2 grid systems and it would 
only make life more difficult to 
needlessly put 'bp' in front of everything.
So i'm going with 'bp-container' and (maybe) 'bp-box', but not 'bp-span-x'.

Cheers,
-Adam

Original comment by adam.q.salter@gmail.com on 23 Oct 2007 at 3:20

[GoogleCodeExporter]

@glenn
I definitely understand where you are coming from, especially with larger 
projects.

@adam
I'm in favor of having "bp-" in front of all classes (I know it's a bit much)
however, in the case that a designer is using a bunch of different style sheets 
it
would be important to easily differentiate between what CSS functionality is 
provided
by a framework and "in house" CSS. I also think it would allow for greater
portability in the case that there are multiple designers on a project, in that 
case
a developer would know exactly what CSS is coming from where without having to 
be too
intimate with the framework. 

In my mind no matter how likely or unlikely it is that you'll have a conflict 
with
say ".box" or ".span-x" you have to allow for the possibility that it could 
occur, in
this case it would be very easy to eliminate CSS conflicts arising from using
multiple style sheets because you could completely eliminate the possibility 
that the
conflict is coming from a "namespaced" class without having to really think 
about it.
(Does the class have "bp-" in front of it?)

To put my foot in my mouth, and in a bit of agreement:

I also think that bp- should be prefixed to classes only directly effecting the
"grid", in other words, even though CSS is considered a presentation language I 
would
consider the "grid" a structural mechanism. In my mind when you have a project 
the
raw data that is fed into your template is one thing, the template is another, 
and
the styling of that data (fonts,headings,links, etc...) is another entity.

Think of it like a bookshelf, you have the actual books, the shelf, and the way 
they
are organized on the shelf. In most cases once you have put together your 
bookshelf
it never changes--however, you might have your books organized a certain way 
and at
any point you can take them off the shelf and reorganize them for whatever 
reasons,
but while the books and organization of them may change, the shelf doesn't 
change,
it's a structural entity. 

So all structural classes (the "grid") for page layout should be namespaced, 
anything
else should be considered extra functionality/plugin? (typography, etc.).

In this case I'd have the tendency based upon reading the comment above the 
".box"
class in "grid.css" (and in practice), that really .box has absolutely nothing 
to do
with the grid. 

So in other words what classes/"supporting classes" are completely necessary to 
the
grid functionality and what ones aren't; those two things should be separate 
from
each other and perhaps used as "plugins" or completely separate; so the "grid" 
would
be namespaced and the rest not. 

So I'm disagreeing to agree:

To sum it up, the actual core or what makes Blueprint, blueprint--those classes
should be namespaced, as it is the bookshelf. The "books" (in the loosest sense 
:-) )
that change colors or move around inside the bookshelf should be 
"namespace-less".

I hope I communicated my opinion clearly.

Tschüs,
Edward

Original comment by edward.edmonds on 23 Oct 2007 at 6:46

[GoogleCodeExporter]

Great discussion, guys. I definitely see both sides of this issue, and while I 
don't 
have the need for namespaces, others probably will. 

I'll keep this issue open for more discussion, and if anyone has suggestiosn as 
to 
how this could be solved for both cases, please chime in.

-Olav

Original comment by ola...@gmail.com on 25 Oct 2007 at 1:59

[GoogleCodeExporter]

My two cents: One fo the frew drawbacks I found in YUI Grid was it's hideous
namespace and it's naming protocol, wich ends up in elements with unmeaningful
classes like "bd yui-b yui-ge first" or id's like "yui-t2" or "doc4" that IMHO 
do
nothing for the semantics AND NOTHING for the easy of use neither. When there 
are
time constrains in the real world, with real clients, with real deadlines, 
meaningful
names like plain "container" or "box" are refreshing, simpler and faster to 
work on,
wich is the whole point to use a CSS framework in the first place.
Yahoo developers choose to use such cryptic no-more-than-six-chars class names 
for
many reasons, including performance of websites. That's the main reason for 
compress
css files. Larger class/id names add unnecesary size to the css files.
Besides my personal preference to see meaningful source code, adding an extra 3 
chars
to every class name is a waste of bytes just to save the rare events when 
id/class
names could crash with a lousy php/asp/jscript/ruby code.
Don't get me wrong, I know namespace is one of the most important best practice 
when
writing programs, so let namespace for programers, and simple meaningful class 
names
for designers. In case of conflict, what needs to be changed IS THE CODE.

Original comment by digita...@gmail.com on 10 Nov 2007 at 1:43

[GoogleCodeExporter]

We might need to consider having two versions of BP, one with namespaces and one
without. digitart1 makes a good point, namespaces are annoying when one is 
working by
hand, at the same time they are very useful when building tools that have to 
parse
the class names. As long as the BP core remains lightweight, I don't think it 
would
be too difficult to maintain two different versions. 

Original comment by siro...@gmail.com on 10 Nov 2007 at 3:58

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

I've added a simple option for setting your own namespace in the compressor 
script, which should make it 
really easy to add namespaces for those who need it. The code:

  # To namespace each Blueprint class, set this variable.
  # Example: namespace = 'bp-' gives you: .container => .bp-container
  namespace = ''

It's in the SVN repository, so you can check it out there. If everyone agrees, 
I think we can mark this issue 
"Fixed". :)

Original comment by ola...@gmail.com on 14 Jan 2008 at 11:08

[GoogleCodeExporter]

I like your implementation Olav.  I have two suggestions for what would make it 
perfect. :-)

1)  Allow me to pass in the namespace as an environment variable or parameter 
to the compress.rb script.  
This way I isolate myself from updates to that script down the road (so I don't 
have to re-change that code 
every time BP is released).  Doing it this way lets me run a tiny shell script 
to call the compressor as often as I 
want passing in that param.

2) (harder) Generate a new set of test pages that use the namespaced css names. 
 Or do a gsub on the 
appropriate classes in the test pages from the compressor script modifying them 
to their new namespaced 
version.  This way I can be assured that the namespacing routine is doing 
what's expected.

If you want to add these as feature requests thats cool by me. I would suggest 
marking the new namespace 
feature as experimental though unless/until you can view your test pages on 
namespaced css to confirm that 
they still work as expected.

Nice work on the compressor.

Original comment by glenn.re...@gmail.com on 14 Jan 2008 at 11:39

[GoogleCodeExporter]

Thanks glenn, those are great suggestions, and I'll do my best to add them 
both. :)

I suppose updating the test pages with your desired namespace could be a 
command line option as well. 
Example:

$ ruby compress.rb namespace="bp-" namespace_test_files="yes"

Or something - I'm not sure what the standard way of passing such variables 
are, so please enlighten me if 
you do. :)

Original comment by ola...@gmail.com on 15 Jan 2008 at 10:25

[GoogleCodeExporter]

The first argument passed to the compressor script now becomes the namespace:

  # To namespace each Blueprint class, pass an argument to the script.
  # Example: $ ruby compress.rb bp- => .container becomes .bp-container
  namespace = ARGV[0] ||= ''

This is in the repository, so check it out. If anyone has any ideas on how this 
can be done even better, let me 
know. 

Glenn: I'll implement the updating of test files as soon as I have the time. :)

Original comment by ola...@gmail.com on 15 Jan 2008 at 10:34

[GoogleCodeExporter]

Looks great to me.  Thanks Olav.  Closing.

Original comment by glenn.re...@gmail.com on 15 Jan 2008 at 8:04

• Changed state: Verified

[GoogleCodeExporter]

I've added the namespaceing of test files to the compressor now. It seems to 
work fine, but it still needs a lot of 
polish. Feel free to check it out. :)

Original comment by ola...@gmail.com on 15 Jan 2008 at 8:39

[GoogleCodeExporter]

Closing.  Addressed by generators and no longer applies when using blueprint 
sass.

Original comment by glenn.re...@gmail.com on 14 Aug 2008 at 7:55

• Changed state: WontFix