Bootstrap Namespacing
Permalink
I know 5.7 has the ability to add grids via the new layout feature, but I feel the core dashboard/navbar should be namespaced to help prevent conflicts with template CSS,
the elemental theme applies a namespacing to the themes main.less suggesting our themes should be namespaced to avoid overriding the core
I can see the advantage of namespacing the theme CSS especially if you are going to be modifying the bootstrap CSS, however the past few months I have been moving towards Object Orientated CSS with SMACSS/BEM and have been attempting to keep my specificity low the one thing that keeps driving at me with this approach of namespacing the theme is the addition of an extra non-required class. This class keeps a consistant high depth of applicability.
As an example,
This gives a depth of applicability of 5 if we want to edit the button--vibrant class
we could of course reference the just the button--vibrant class but in the current namespace this would be written as the following
However this still has the same depth of applicability 5 as the previous css rule.
In this case and many other the actual classes could just be written as
I may be over thinking this as a rough calculation for the additional bytes in a 2000 selector CSS file is only an additional overhead of 17kb of data. However this feels like something that should be applied to the core files and not to the theme, a user visiting the site that does not need to login or load the admin files/theme does not really need the namespaced CSS just to prevent any styles we have applied from overriding the core theme.
Iv'e noticed a couple of small issues when I attempt to override some of the default bootstrap settings, they then have a knock on effect with the core files.
Have the core team considered a namespaced approach for the bootstrap/css. (I'm aware much of the core dashboard css is specific and already namespaced) I also notice it seems a lot better in 5.7 but am interested to know about the core teams opinion on this (assuming this post makes sense).
ref: CSS is a mess Jonathan Snook -http://vimeo.com/99877232
ref Depth of applicability Jonathan Snook -http://smacss.com/book/applicability...
the elemental theme applies a namespacing to the themes main.less suggesting our themes should be namespaced to avoid overriding the core
div.ccm-page { ... //less imports ... }
I can see the advantage of namespacing the theme CSS especially if you are going to be modifying the bootstrap CSS, however the past few months I have been moving towards Object Orientated CSS with SMACSS/BEM and have been attempting to keep my specificity low the one thing that keeps driving at me with this approach of namespacing the theme is the addition of an extra non-required class. This class keeps a consistant high depth of applicability.
As an example,
//Assuming the following structure //depth of applicability = 5 .ccm-page > .main-content > .pull-out > .button.button--vibrant
This gives a depth of applicability of 5 if we want to edit the button--vibrant class
we could of course reference the just the button--vibrant class but in the current namespace this would be written as the following
//Less css to write, same specificity //depth of applicability = 5 .ccm-page .button--vibrant
However this still has the same depth of applicability 5 as the previous css rule.
In this case and many other the actual classes could just be written as
//depth of applicability = 1 .button--vibrant
I may be over thinking this as a rough calculation for the additional bytes in a 2000 selector CSS file is only an additional overhead of 17kb of data. However this feels like something that should be applied to the core files and not to the theme, a user visiting the site that does not need to login or load the admin files/theme does not really need the namespaced CSS just to prevent any styles we have applied from overriding the core theme.
Iv'e noticed a couple of small issues when I attempt to override some of the default bootstrap settings, they then have a knock on effect with the core files.
Have the core team considered a namespaced approach for the bootstrap/css. (I'm aware much of the core dashboard css is specific and already namespaced) I also notice it seems a lot better in 5.7 but am interested to know about the core teams opinion on this (assuming this post makes sense).
ref: CSS is a mess Jonathan Snook -http://vimeo.com/99877232
ref Depth of applicability Jonathan Snook -http://smacss.com/book/applicability...
I've seen some benchmarks of this with bigger CSS files, like > 10k lines. The actual "overhead" is really a couple of kilo bytes (depending on the CSS of course) if you only transfer the gzipped version through the wire.
So, if it's a repeating string in the CSS, it really doesn't affect the transferred size.
I'm very much in favor of namespacing even the theme CSS. A lot of the "mess" can be solved through sensible separation of the CSS which is possible through LESS, SCSS or SASS.
I'm also very much in favor of avoiding deep definitions or importants in CSS but in my personal opinion, repetition is not a serious problem.
This is all in line of the "modular CSS design" that the first of your links talks about. That's also how bootstrap is built which is great if you use it in custom projects.
Specifically to concrete5, it is really better to enforce the theme developers to namespace their code because you can never create concrete5 specific namespaced CSS that would override all the theme specific stuff if it's not namespaced. That would simply not be possible and it would produce collisions with a 100% probability since you can never override all the possible cases theme developers might come up with. What if there is a deep definition in a theme that targets accidentally a c5 UI element? You simply cannot avoid that if the theme's CSS is not namespaced.