Our development team recently took on the task of refactoring our enormous CSS file so that it will be more manageable in the future. I came up with a small list of subtasks, one of which is:
Remove the styles that aren't in use.
The problem is, I don't know how to identify which styles are being used. Some styles don't appear to be coded anywhere, such as those found in third party controls. A solution-wide search does not find these third party styles (like the default styles that come with Telerik controls). We appear to have overridden some of these third party styles.
Short of deleting stuff and then checking every page to make sure that it looks identical, I do not know what to do. Is there a solid method for determining when a CSS class is in use?
In addition to the other online services, for local or privately stored projects you might find Helium.js useful.
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.
We all know that we're supposed to combine our CSS into one file, but per site or per page? I've found pro's and cons to both.
Here's the scenario:
Large site
CSS files broken out into one file for global styles and many for modules
Solution A: Combine ALL the CSS files for the whole site into one file:
Best part is that the one file would be cached on every page after the initial hit! The downside is that naming convention for your selectors (classes and id's) becomes more important as the chance for a namespace collision increases. You also need a system for styling the same module differently on separate pages. This leads to extra selectors in your CSS which is more work for the browser. This can cause problems on mobile devices like the iPad that don't have as much memory and processing power. If you're using media queries for responsive design, you're troubles compound even further as you add in the extra styles.
Solution B: Combine one CSS file per page template:
(By page template I mean one layout, but many different pages, like an article page)
In this scenario, you lose most of the issues with selecting described above, but you also lose some of the cache advantages. The worst part of this technique is that if you have the same styles on 2 different page templates then they'll be download twice, once for each page! For instance, this would happen with all your global files. :(
Summary:
So, as is common in programming, neither solution is perfect, but if anyone has run into this and found an answer I'd love to hear it! Especially, if you know of any techniques that help with the selector issue of Solution A.
Of course, combine and minify all the global styles, like your site template, typography, forms, etc. I would also consider combining the most important and most frequently used module styles into the global stylesheet, certainly the ones that you plan to use on the home page or entry point.
Solution B isn't a good one: the user ends up downloading the same content for each unique layout/page when you could have just loaded parts of it from the last page's cache. There is no advantage whatsoever to this method.
For the rest, I would leave them separate (and minified) and just load them individually as needed. You can use any of the preloading techniques described on the Yahoo! Developer network's "Best Practices for Speeding Up Your Web Site" guide to load the user's cache beforehand:
Preload Components
By preloading components you can take advantage
of the time the browser is idle and request components (like images,
styles and scripts) you'll need in the future. This way when the user
visits the next page, you could have most of the components already in
the cache and your page will load much faster for the user. There are actually several types of preloading:
Unconditional preload - as soon as onload fires, you go ahead and fetch some extra components. Check google.com for an example of how a
sprite image is requested onload. This sprite image is not needed on
the google.com homepage, but it is needed on the consecutive search
result page.
Conditional preload - based on a user action you make an educated guess where the user is headed next and preload accordingly. On
search.yahoo.com you can see how some extra components are requested
after you start typing in the input box.
As far as the conflicting selectors go: combining all the files and doing it any other way should not make a difference, this is a problem with your design. If possible, have all modules "namespaced" somehow, perhaps by using a common prefix for classes specific to the module, like blog-header or storefront-title. There is a concept called "Object-oriented CSS" that might reduce the need for lots of redundant CSS and module-specific class names, but this is normally done during the design phase, not something you can "tack on" to an existing project.
Less HTTP requests is better, but you have to take file size into consideration as well as user behavior and activity. The initial download time of the entry page is the most important thing, so you don't want to bog it down with stuff you won't use until later. If you really want to crunch the numbers, try a few different things and profile your site with Firebug or Chrome's developer tools.
i think you can make global.css that store style that need every template.
And you could make css in each template.
Or simply use css framework like lescss
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
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.
DotNetNuke uses quite a few preset classes like .Normal, .Head, .SubHead, etc. in spans inside other classless spans etc. that I find really annoying and rather than figuring out how to work with them I'm considering overriding them by having them all inherit their styles from their parent, but I'm curious if others have already given this a try and have stories to tell of success or fallen foul of something on the module / admin end that makes this a fruitless task?
Thanks,
Steve
This really depends on your project. If you're developing a commercial product, my recommendation is to learn how to work with the styles so that you have high compatibility with the DotNetNuke core as well as third party extensions (skins & modules).
I would say if you have complete control over the site it may well be worth it to you to follow your own conventions and bypass the DNN selectors altogether.
That approach would be to create skins and containers that define regions with specific class names. You could then define styles for elements within those regions based on what the element actually is rather than what class is applied to it.
You will probably want to clean up or remove the contents of the default.css file as well (\portals_default\default.css).
I would add another stylesheet that appends or overrides the default styles. This way, you can recast the default styles without editing the default stylesheet.
Use the cascading nature of CSS to your favor!
In cases where styles are new, make sure to namespace them with an outside container.