I am looking to the wisdom of the crowd for views on best practice for implementing CSS.
Our site was initially built using SASS compilers for CSS. Over time as more functionality has been added, each with specific styles, the CSS files and partials have become large. Loading all CSS for the entire site seems a waste of resources and time, particularly when a large percent is not utilised on any given page. However I am still told that this is more efficient than either inline styles or CSS style blocks within the page.
I am currently considering stripping down everything but core CSS to the SASS CSS file and then creating a series of specific CSS files that are loaded as required.
How have others approached this problem. Is there a consensus on the "best practice" when CSS files become large?
Thanks
D
You can write SASS only for specific parts of your site and load styles for specific pages only. For example you don't have to load styles for product list when you are on product page.
In the meantime you can have global stylesheet for something like menu, footer.
Loading styles inline or in block prevents styles from caching and makes your user download it each time they open website.
This is the perfect opportunity to clean up your styles and start fresh. I would reccomend you create layout.scss for styles used in all pages, and component_X.scss for specific component styles.
Related
I'm a web developer, not an CSS expert. We recently started using Angular and I'm wondering what is the best practice applying styles in Angular templates.
Discussion we have at work is whether to use external CSS files or internal style tags. We do not have too many templates and each template mostly has its own unique styles. We are debating between external CSS files and/or internal styles.
Couls someone provide an expert opinion on this subject.
Internal styles are only applicable to the page that includes them. As such, if you want to update common styling (such as a menu) on multiple pages, you'll need to update each page individually.
Considering you'll almost definitely have certain styles apply to elements on more common to more than than one page, you'll definitely want to opt for external stylesheets. This allows pages A and B to both inherit styles from a single style.css or similar file.
This way, you can load all the relevant styles with a single line of code in the <head> of each page:
<link href="style.css" rel="stylesheet">
And you only have to update style.css when you want to update multiple page's styling.
Angular brings scoped CSS from v1.5 up (when components were introduced - I believe). It's a good concept but, in small to medium apps, the difference is hardly noticeable. You should only consider using scoped CSS in conjunction with a tool that knows how to make the best of it (i.e. Webpack).
If you're not using Webpack, just stick to the classic model: one big style-sheet.
Note that technically, regardless of stack, if you want to provide the best possible experience (fastest loading times without FOUC) you want to put all the above-the-fold and general layout-ing styles inline, preferably in a head <style> tag and everything else inside a stylesheet loaded asynchronously.
Read this article about loading CSS async.
So I've recently started making more use of EJS templates in my website and so I've done things like broken out the top nav bar and other things into their own template. Is there a standard practice for how to organize CSS (or more specifically SCSS) with that? Should I just make a matching SCSS for each template with just the styles for that template and add the <link/> in each page that uses the template? Or just I just add <style/> tags to the template itself with the CSS in there. Is there a standard pattern for this?
Good question. I think the answer is "no", there is no universally best or accepted standard.
The advice my "work-mentor" always gives me is good advice: he says "do what will be the easiest to maintain". This would depend on your project. I can think of a couple general strategies:
One stylesheet per template
That is, in a way, the simplest suggestion. Probably the easiest to develop, and each page will bring the minimum needed styles.
However, this makes reusing styles pretty impossible. You won't be able to plunk in a <button class="myclass"> into any template without reincluding the styles for .myclass in every sheet you need them in. Also, if you ever want to automate your style sheets (minifying or concatenating them for production, etc) as is common practice, it won't be very possible from here.
One more downside, you might get some unexpected ordering effects. Like if your "widget.css" ends up being added to the DOM after your "article.css" it may override styles in a different way than it would have if it had appeared earlier in the DOM.
All styles on every page
Again, this is nice and simple. Every page has all stylesheets (or maybe just one giant sheet) included. You can link to it once in your outer layout template. It will be easy to automate minification, etc, and there will never be any surprises related to the order stylesheets are added in.
The obvious downside is lots of unused styles brought to each page. But css is pretty "cheap" in terms of size, so this may not be such a bad downside.
Somewhere in between
Include some styles on every page, and make some either page-specific or template-specific. Realistically, this is probably what most apps end up doing.
You can universally include utility styles meant to be reused (ex button.bigred, form.orderform, etc), as well as dependencies like bootstrap or whatever. I'd also advise including any styles you will need on more than half of your pages (ex styles for your navbar).
Other styles intended for one specific page can be added to that page directly via links.
last note
I try to avoid <style> tags in the html for a couple of reasons:
Lots of js libraries dynamically add or remove <style> tags to your DOM, so leaving that space clear for them avoids possible mistakes or overlaps.
They are a good way to add dynamic or user-managed styles to pages from within your templates. Keep styles that don't change in the stylesheets, to avoid possible mistakes or overlaps with yourself :)
I know that there are questions regarding this same topic, but for HTML. What are some good conventions in regards to using external stylesheets in a Flex app.? How would you break up the stylesheets (names of stylesheets and what they include)?
Flex compiles the external CSS file when you publish your project.
There is a way to load CSS at runtime using Flex; it can be done by compiling CSS files into SWF files and load them at runtime using StyleManager.loadStyleDeclarations.
See the LiveDocs on Stylesheets at Run Time for more info.
Some conventions we use in organizing stylesheets:
Have one main.css stylesheet that holds all of the data for skinning the base application.
Have one fonts.css stylesheet to store all of the fonts in the main app, because these can get quite messy.
The main.css stylesheet is included in the main swf via the <mx:Style source="main.css"/> tag. We load our app with as little as possible, and once everything is loaded, if we need to immediately show some text (sometimes we just have a video playing if it's an advertising site), we fade/tween in the main elements and load the fonts.css via StyleManager.loadStyleDeclarations at runtime.
If we have an admin panel, we have an admin.css stylesheet which we load at runtime because the main app doesn't need it.
We don't need to divide up the CSS anymore than that because we usually create a whole set of skins in a Theme, so the stylesheet is just applying those skins to components and is pretty lean (using Flex 4). I tend not do divide stylesheets into anything smaller (like "pages.css", "comments.css", "popups.css", or even "controls.css", etc.) because it would be overkill and too much to manage for little in return. That's common with HTML, but that's because HTML requires CSS for nice presentation; Flex could do without CSS entirely.
When developing, one of us usually develops most of the skin right away (having a default wireframe setup, like those found on ScaleNine as they do the photoshop/flash/after-effects. There's no way to not have to recompile the css swf if you make changes. But if it is loaded at runtime, you only have to recompile the css file and not the main swf, which is useful but not really useful during hardcore skin development.
I tried keeping the main stylesheet separate during development (in a custom Theme), and it made development a LOT harder, because I had to recompile the css separately every time I made a change and sometimes I had to recompile the main app too, and there were strange and hard-to-track-down bugs, etc. Then I was compiling two different apps. So I recommend keeping the main css file part of the main app.
If you wanted runtime css without having to recompile anything, try Ruben's CSS Loader and check out the source. But that would come at a runtime performance cost.
Flex is not something I've dealt with, but I did some research. It looks like the code to call a remote stylesheet is this:
<mx:Style source="com/example/assets/stylesheet.css" />
Flex Quick Start: Building a simple user interface: Styling your components says this:
Note: You should try to limit the
number of style sheets used in an
application, and set the style sheet
only at the top-level document in the
application (the document that
contains the tag). If
you set a style sheet in a child
document, unexpected results can
occur.
The implication of this seems to be that multiple stylesheets are not really possible. It sounds like what you want to do is organize your stylesheets, check out Organizing Your Stylesheets and Architecting CSS for some ideas for approaches. It looks like you have classes and basic tags, but the W3C stylesheet specifications are different from the Flex stylesheet specification.
As a non-Flex developer, Namespaces looks interesting as a way to organize namespaces: How to use the new CSS syntax in Flex 4.
I have a DotNetNuke skin that has a single CSS file over 3,500 lines long. It contains styles for YUI, Telerik, Cluetip as well as the actual customisation of the site. The old developers just kept adding styles and never cleaned up the old unused ones.
I want to cleanup the file and get it to a more managable size. I first thought about scanning through the code base but this is 5,500 files with a mixture of CSS applied in the .aspx, .ascx and .cs files as well as jQuery aplying styles sometimes from generated code and sometimes from js files. Some styles are applied with class selectors and others with id selectors.
Is there a way I can easily check just which styles the website actually needs across all of its pages? Is there some crawler that could do this?
For firefox there is an add-in called dust-me-selectors. If you provide a sitemap, it will find all unused css styles.
If you run dust-me-selectors, remember to run it in every page of your website so you don't delete any styles that are actually used.
I'd been reading up on themes in my ASP.NET book and thought that it could be a very handy solution, then I met some problems.
The theme picks up every single CSS file in the folder
If you want to use reset styles (where ordering is important) the order of imported stylesheets is not guaranteed
Your master page would not explicitly indicate what style is being used, only the rendered page can tell you that unless you dig into your web.config
Styling web controls using the theme file is... well... stupid? You can simply do this in your stylesheet. Granular control should be at the HTML level, should it not?
How do you specify print stylesheets without having all styles in a single stylesheet?
I'm wondering as to whether they're actually worth using at all. Is there any benefit? Are there any major sites using them?
EDIT
Just to clarify slolife's last point. If I had two stylesheets, one called print.css and one called main.css and I used ASP.NET themes, how would it know that print.css was a print stylesheet? In regular HTML you use the media type in the tag itself (i.e. <link rel= ...>) but the themes wouldn't know this, so it would just get included as a regular stylesheet.
I like using themes, but as Raj pointed out in his answer, URL rewriting can cause problems. My search for some solutions to that is what led me to your question. But I'll add my opinions in anyway.
I'll address some of your bullets from above as to why I think themes are good:
- The theme picks up every single CSS file in the folder
I guess you are looking to apply only certain stylesheet files to certain pages. Yes, themes takes the shotgun approach here, so that's a problem. But you don't have to put all stylesheets in the the theme folder. Put your specialized ones outside of it and they won't be included automatically. But I think it is nice feature to have the common/site wide ones included automagically.
- If you want to use reset styles (where ordering is important) the order of imported stylesheets is not guaranteed
I think you can guarantee the order by the way you name the files, so they are numerically and alphabetically ordered. Maybe not an elegant solution, but not horrible.
Personally, I have a build step that combines and compresses all of the *.css files in my theme folder into one single style.css file, and since I control that build step and the order that the files are combined, that doesn't affect me.
- Your master page would not explicitly indicate what style is being used, only the rendered page can tell you that unless you dig into your web.config
You can change the theme via code and in the <%#Page directive
- Styling web controls using the theme file is... well... stupid? You can simply do this in your stylesheet. Granular control should be at the HTML level, should it not?
I agree that applying style attributes to controls via the theme doesn't seem to be a best practice. But I love the fact that I can define image skins in the theme's skin files and don't have to cut and paste Width,Height,AlternativeText,Align attributes for common images that I use lots of places throughout the site. And if I ever change one of those images, I can fix the attributes in one place, rather than all over. I also can created skinned controls with a certain list of css classes applied, which seems handy to me.
- How do you specify print stylesheets without having all styles in a single stylesheet?
I have a Print.css file that starts with #media print and that defines print styles for my site. Why do you need to put them in one stylesheet?
IMHO, asp.net themes are absolutely USELESS
try implementing url rewriting with an app which uses themes and see them break straight away
basically, you can achieve the same thing writing few lines of code in asp.net and multiple css folders. i am yet to come across any developer / company who has been using themes
when asp.net 2.0 was launched, there was a big hype around themes but my personal opinion is its simply not worth it :-)
Use themes to change control attributes ONLY.
They were bad designed for working with css.