namespacing or otherwise separating Bootstrap styles? - css

Bootstrap 3 CSS is typically used site-wide or application-wide. Knowing this, I designed a tool that HAPPENS to use Bootstrap in a sample application. This is after going through requirements processes. The explicit design was "It happens to use Bootstrap in this example, but the target user would likely provide their own styling rules."
However, the results looked great and the powers that be have asked, "can this tool be included on any arbitrary page and still look like this?"
The short answer of course is "no". Bootstrap's styles do all kinds of things like using border-sizing: border-box on a wildcard (*) selector. This is going to mess with people's existing CSS if it's not already built on Bootstrap.
Is there a way to encapsulate Bootstrap styles so that they're restricted only within that particular tool/widget? So in the div <div class="bootstrappy">, everything is affected by Bootstrap classes and outside of there, nothing is? The goal is to be able to include my Bootstrap-styled widget on a page that didn't previously include Bootstrap, without modifying what was there previously.
It's OK if I have to do this as part of a build process (I am using Grunt right now, so that'd be the best option for me); what I'm looking to avoid is manually combing through Bootstrap in order to cull or modify element-level rules so that they don't stomp over a whole page.

Related

Is it possible to use bootstrap on your existing code?

I have already built a site using CSS. Now looking back I regret not taking the chance of using Bootstrap. My website is already built and styled. My questions is, is it possible to use bootstrap even though you already have styled you website without having to remove all the CSS?
Bootstrap uses a set of pre-configured classes to implement it's styling rules..
So unless you somehow incorporated the same class names in your site and intended the same styling as was intended by the Bootstrap developers, you are going to have to make the necessary changes on your own.
That said, if your project is intended to be extended in the future, it may still be a good idea do re-work what you did up until now with Bootstrap, in order to save time in the future (I am assuming that the project is not very large in scope).
There are few things you need to know:
Bootstrap uses box-sizing: content-box so if you are not, it will probably impact all your padding/border stuff.
Bootstrap comes with a reset and few helpers with generic names that can interfere with your own style.
That said it's totally ok to add bootstrap to your project and it should be smooth.

Integrating pages into CMS shell

Here's the situation. It can't be changed, I have to deal with what I have.
I have a few pages of which I have styled inside a wrapper, two columns of various content.
I was given (after my pages were done) a shell which I now have to integrate the content. I wasn't to do this in the beginning; I was told to build and style as if these pages lived on their own.
So, now I have to essentially cut-n-paste my code into divs that are already styled as well as the structure to the overall page. All of my style declarations use entirely different names so that's good, but there are many styles that are causing problems.
I keep thinking there is a way to just add a class to the body and then over ride all other styles by the use of that class but I'm not sure about that. My tests haven't proved fruitful.
As there are three other style sheets that are called in the shell, I'm just trying to find the most painless and efficient way to integrate my content....like being able to insert everything into a iframe w/o using an iframe.
I have thought of duping all existing style sheets, renaming them and then just keeping the necessary styles from the cms but there will be a lot of extraneous css left over.
Any other ideas?
If I understand you correctly, you want to style the elements you are inserting without any clashes with the existing document stylesheets. Have you considered using a prefix so that for example '.container' would become '.my_container' e.t.c. This way to easily navigate the html and stylesheets for your elements you can just search for your prefix.

Global, CSS independent bar that developers can include on their sites

I am developing a "bar" like what you see on the top of many default Blogger blogs that acts as a unifying element on otherwise different-looking sites. I want to package the code up into a neat package so that I can give other developers a few simple lines of code that they can paste into the beginning of their <body>.
I know there are many ways to do this, like using PHP includes, AJAX calls, JavaScript and XmlHttpRequest, Google closure templates, etc. BUT I want to make sure the bar is CSS independent, meaning other CSS that is used on the site does not affect my bar.
I am wondering what is the best method to accomplish this? Is inline CSS the only way around this?
Just like JavaScript plugin development, there's no guarantee that CSS classes and IDs wont be overridden later.
If the code needs to be inline, I'd suggest namespacing all of your classes and IDs: pluginname-wrapper, pluginname-container, pluginname-block, etc.
Otherwise, you could use an iframe element to store a miniature page.
I'd suggest sticking to namespacing. If someone includes your plugin and it's off by a bit, they'll be able to manually override the styles to make it look the way they want.
Someone who writes div {float:left;} or anything similarly silly will have problems either way, so don't worry about making it the same for everyone, just make it work with the default styles.

How to manage css of big websites within team environment without mess?

Where multiple people can work on same css. is it possible to follow semantic name rules even in large websites.
If I would write all main css first time with semantic names . then what and how i should guideline/instruction to other developer to maintain css readability, validation . and to know quickly where other are adding their own css if required.
Right now every one just go to down and write required css classes ot IDs at bottom. and most of the time they don't write semantic names.
How to make good documentation/guide with text or with images for other developers on how to use css in whole site and how i wrote and what i used.
Update:
We use only one CSS file. I don't want to divide one css in multiple. Want to keep css managable even using one CSS file for whole site.
A similar question was asked a while ago: How to manage CSS Explosion there is a number of good answers there, and a number of great links (check out those provided by Paul D. Waite for example.)
Your main problem is going to be structuring the CSS file well. You will need clean rules for that: Keep everything grouped within the CSS file. Maybe using a CSS editor that can help you "navigate" through the style sheet is a good idea (similar to a programming IDE's "code explorer" feature). I don't know, however, if such a thing exists.
Other than that:
Using version control is a MUST. I personally am totally happy with centralized versioning using Subversion and TortoiseSVN; others believe in distributed version control like git or hg. For a team of designers, I think the centralized approach of Subversion is good, but that is a discussion in itself.
Maybe it's a good idea to split the style sheet into thematically relevant separate files to avoid chaos, and compile it using a tool like LESS or xCSS.
Define a clear, concise coding style. Use a CSS beautifier like Polystyle ($14 per license but money well spent) or Code Beautifier (based on CSS Tidy, haven't used it but looks interesting) and run it frequently on the file.
Have a number of links handy of pages that use the style sheet. Have people test those pages after they have made a change to the style sheet.
I would break down your css logically into groups and put each of these groups into its own css file. For example: header, footer, sidebar, content groups. Maybe some pages even deserve their own css file if big enough.
Similarly, give ids and classes on pages names that make sense. If it is a css rule for sub headings on a navigation bar, make sure it comes off as that in naming. Similarly to any other coding, don't use any magic numbers, etc. for naming.
See Modularizing web applications, includes specially CSS

What is the advantage of Themes versus CSS in ASP.NET?

Since Themes in ASP.NET are used to style elements of your site, I was just wondering why would you use Themes rather than CSS, or is it common practice to use both? If so, when would you opt for one versus the other and why?
Just seems to me like Themes are kind of unnecessary, so I am just looking on clarification if there really is a good reason to use them, or it's just a part of the framework as an alternative(unnecessary) step to styling your site.
Imagine you have a site that, for whatever reason, uses dozens of asp:Calendar controls.
To style them with CSS alone, you'll have to set loads of properties on each one: DayStyle and TitleStyle and NextPrevStyle and on and on...
Using a theme will allow you to set all of those properties just once, and have it apply to every asp:Calendar on the site. The theme would contain the same CSS, but also the declaration of how to apply that CSS to server controls, which is something you can't easily do otherwise.
Of course, as Brian Hasden already said, you'll probably need some "global" CSS that lives outside of the theme (particularly if your site has multiple themes).
Themes have the benefit of being tightly integrated into the whole .NET environment so that things get themed without needing to specify their styles. It happen automagically like lots of other things in .NET. Based on that I can see the appeal for some people.
That being said, I personally never use the whole themes deal because I feel like it requires you to maintain two different sets of styles. One that's part of the theme and then others that are inevitably needed outside of the whole theming deal.
Maybe I'm just a control freak or dislike themes due to bad usage on previous projects.

Resources