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.
Related
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.
There is a way to remove unused css with uncss https://github.com/giakki/uncss
And an excellent blog post on the subject: http://addyosmani.com/blog/removing-unused-css/
However I fail to see how you would combine this approach dynamic content (for example generated by angular directives or async page loading) which will be missed by the uncss module.
Is there an optimal way to achieve this, I'm not wanting to manually go in and remove all the bootstrap css I'm not using.
My best recommendation would be to create a couple of static pages with examples of all of the markup you anticipate needing, and run uncss against that.
Even if the content is dynamic or asynchronously loaded, you should have a pretty good idea of what content is possible.
For example: you're probably very likely to need basic text formatting, headings, rich text content, lists, links, pictures, etc. Depending on the subject of your site, you'll also know whether you need to display code samples within <code>, <kbd> or <pre> tags.
However, it's not as likely that dynamic content would directly need to utilize the grid / layout system on its own, or would require any extraneous button styles.
Build a test page that includes everything you anticipate using. If you know there's something you want to keep, then throw it in. Otherwise feel confident knowing that uncss is doing it's job cleaning out everything else.
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.
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
Our Dev team had been developing enterprise web page more than 2 years ago. We are curious to know what is the best way to write a contract for CSS usage. For example, if we have a COMP, how we agree on a contract so our developers and our designers agree and we don't have to go back.
Is there a tool that is available for this type of technical writing?
What is the threadhold of information put in the CSS versus on the HTML page? Some of our designers thing that some things should go directly into the HTML page. The general opinion is that everything that is style should go in a CSS and all else in the html.
Thanks for your input.
Well, if a webpage has very specific CSS just for itself, I guess there is an argument for defining the CSS in the page, otherwise I would always have the CSS in an external file.
Try to avoid or at least minimise in-lining the CSS as a style attribute on HTML elements though, that would be a PITA to manage.
Most pages will be template driven with standard content styles, and thus the CSS styles will be defined in external files.
One thing you might want to think about are the number of CSS files - some people suggest that you should minimise this to just one file site-wide or per-template (or area of the site) to minimise HTTP requests to the server and avoid delayed CSS loading and funny looking styling up until that point.
So this "contract for CSS usage" is actually just a coding standard for HTML pages?
I'm a purist, so for me HTML is for content and structure and CSS is for layout & styling. That's really what each of them were created for.
See CSS Zen Garden for a great example of this. Same HTML and hundreds of different layouts & designs.
What are the reasons your designers give for styling to be in the HTML?
Edit: The main goal here is consistency across the site, correct? The more you have abstracted away from each page, the fewer changes you'll have to make.
The idea that the HTML should merely encode information and not style is called semantic markup. It has several advantages that you already know about, like separation of concerns, and a few that you probably haven't thought about.
If you stick to the web standards and separate your style and content you will also end up with a page that is more accessible to those with disabilities.
If you need to have some things styled differently for a specific page, use separate CSS include file for that page only and then use a CSS class on the element you want to style.
If I have style that is for a one time, single use page, I will consider putting it in the header of that page, as my templating system allows for that.
However you should never use inline styles. Even if you do a page with a block in it for a one off. That way should you find that you "one time" item becomes a site wide style, you can simply move the CSS into the external CSS file and not edit the content.