There are different sites sharing almost identical layout but different styles. Nice example would be considering all sites within stackexchange network. They all have similar layout but different look and feel.
Consider 5 sites and for each site if we have to maintain 3 to 4 stylesheets for different browsers then there are almost 20 different stylesheets we have to manage. Which is difficult to handle especially if we are trying to replicate a similar site with different look and feel.
So Is there are way we can track stylesheets (e.g. storing in database?) and we can dynamically add them?
Or what is an efficient way to handle different stylesheets for growing number of websites?
I was looking at source of office.com and there was goofy url pulling up stylesheet and I believe it has some version number too. Are they storing stylesheets in a central repository? If you view source on stackoverflow you would see a similar url.
Your question addresses several aspects, I'll try to cover two of them here.
Re-usable CSS
If several sites share the same basic layout, it is a good idea to have them share one basic CSS file. You can then make site-specific adjustments on top of that, in smaller CSS files for every site.
In order to make up a good concept for these combined styles, you should read about the CSS cascade hierarchy and CSS specifity. These two things determine which style is applied to an element in the end.
Versioning
The use of version numbers in CSS URLs is mostly related to Cache Busting. It often looks like this: style.css?v=20110326 Normally, you will want your users' browser to cache (keep saved) the style sheet, so it does not have to be reloaded every time a new page is loaded. But if you make a change to the file, the new version must be delivered to all returning visitors. By adding a new, different version string, you make the browser "think" it is a different file and reload it.
The version string is in most cases added automatically by some server side script language, like PHP:
<link href="style.css?v=<?php echo $css_version; ?>" rel="stylesheet" type="text/css" />
The version number (or string) itself is sometimes simply derived from the file's mtime (modified timestamp) or taken from a revision control system like Git or Subversion.
I personally don't know how the trick for "obfuscating" file names and locations is done. I suppose it's some script disguised as a .css file that hands the content specified in the request (all.css?v=e1214b61bb44).. webservers can be set to parse files with extensions other than php or asp as common php or asp files, so I reckon this is what's being done in this case.
As for the stylesheets, you could set a third level domain in which you will store any files in common.
After this, you should design the basic layout in a main stylesheet that will be shared by all your sites. Then you can go on styling up each single site in its own specific stylesheet.
In the page head, you can link them like this:
<link rel="stylesheet" type="text/css" href="http://common.domain.com/style/basic.css" />
<link rel="stylesheet" type="text/css" href="http://common.domain.com/style/sitespecific.css" />
Related
I've been working with the ModX Revolution manager, and was wondering if I can turn my CSS into ModX Resources rather than files. I'd also like to utilize Templates and their variables. Is that possible? What are the drawbacks of doing so? Are there any advantages (aside from the ones I think below)?
The reason I would prefer this is that I use several CSS pages with the #import statement to object orient my CSS a little bit better. If I could do this directly in ModX, it would save me uploads and syncing.
In previous versions of ModX (Evo and Revo), you used to have to go through tricks. Now with 2.2.2pl, it is possible with very few tricks. The information to do this is sparse and inaccurate any more. Here's how you do it:
Create Your Template
Create a new Template. I named mine CSS Stylesheet. (Simple as that)
For the content, simply put [[*content]].
Create Your CSS Page
Create a new resource. Name it whatever you would like.
Add your alias. Make sure you do not add the .css at the end. ModX should do this for you.
Now, make sure your new page is published. You may also want to hide from menus.
Add your CSS code. No funny tricks... Just copy and paste it like you normally would.
Test the Stylesheet
Simply navigate directly to your new page as if it were an html document. Don't forget the .css instead of .html. If you see the CSS code, then you've succeeded.
Add Your CSS to the Templates
This one is the tricky part. You won't be able to use the <link rel=></link>.
Simply go to your <head> element. Add the following code:
<style type="text/css">
#import url("");
</style>
Test the
Inside the url("");, just place the url to your new resource.
Advantages
Aside from the saving the uploading and downloading, you can now edit your CSS using any of the ModX tools. Additionally there are a few other perks:
If you're like me, file names are useful, but often not descriptive enough. You can name them whatever you like! Its the alias that is important anyway.
Handy tool-tips based on the Description of the resource.
You may also utilize the Summary of the resource for other things. I place the important file comments in here, so that my CSS is smaller.
Template Variables! In previous versions of ModX, you couldn't have a Template for your CSS.
Chunks and Snippets, if you so desire. You have to write them as plain text, rather than HTML, but it's still useful if you are creative.
Your CSS is now shared between all of your Contexts if you like. This is due to the nature of the #import statement.
You can edit your CSS from any computer. You may even set up your front-end for the editing.
Drawbacks
There's always trade-offs, and with this technique it is no different. A lot depends on how you have things set up for your site.
Your saving and editing is based on your server performance.
Your URL requests will be based even more on your ModX performance. For some, adding these extra resources could slow things down. Often, its not enough to worry about, but its worth mentioning.
It's now managed by the database, so its subject to database security. This can be good or bad. Even it is good, it probably will require extra set up from you.
Your Templates, Snippets and Plugins can break your CSS, if programmed incorrectly. This is something you really want to be careful with.
Each CSS request is treated as a separate request by ModX. The Template Variables and plugins do not apply to the web page you are viewing. They apply to the CSS content.
Conclusion
The whole process takes about 15 minutes. And ultimately, it's even faster to revert back if it doesn't work for you (just don't delete the raw files until you are sure). The added functionality is worth it to me.
for html, we have index.html, the file thats automatically loaded by the webserver if no filenames are specified. Is there an equivalent for css, either from the webserver point of view, or just by convention? surely it's not "index.css" right?
Thanks.
Update:
I guess I phrased my question a little poorly. I already knew that css files would not be loaded automatically. I was just wondering if there was a strong convention for default css files. Although there exists no strong convention, there are common names, as listed by the people who answered, some of which are:
default.css
main.css
web.css
style.css
site.css
Or you can name the css file with the same filename as the html file that uses it.
No.
There are common names for the main stylesheet for a site, e.g. site.css or main.css, but no strong (or useful) convention.
The name style.css starts to look odd as soon as you have more than one stylesheet. My 2 cents would be:
main.css or myappname.css (e.g. intranet.css) for the app
Something like global.css for a stylesheet shared between apps
For css for individual pages, create subdirectories named after the pages so that you can easily see which css are shared and which are only used on certain pages
If you can, I'd recommend keeping it short and all lowercase without underscores / hyphens as it is less prone to typos.
No there is no such thing. It probably is some "guidelines" to follow when designing templates for e.g. Joomla where you have "template.css" and so on. When I do not have such guidelines I normally name the default css "style.css", but this is a matter of taste.
Can't think of a better default than stylesheet.css to match the value of the rel attribute.
<link rel="stylesheet" type="text/css" href="stylesheet.css">
Since stylesheets can be loaded based on media attribute my file naming convention just follows the available options:
theme-media-all.css - used for all media type devices
theme-media-print.css - used for printers
theme-media-screen.css - used for computers screens, tablets, phones, etc.
theme-media-speech.css - used for screenreaders
You could omit the media- prefix but I like to be explicit both for myself years down the line or new developers coming to the project - plus you get filename grouping when sorted alphabetically.
There is no standard, because it's your HTML that decides which CSS file to reference rather than web server configuration.
With that said, it is a good idea to have a convention, so that your files are better organized.
For example, if you tie a CSS file with each file you might re-use the HTML file's name, but with the CSS extension. (e.g. index.html has index.css or index.html.css.)
You could apply the same concept to directories or URL paths if your code is organized that way. (e.g. /MyApp/MyFeature/MyFeature.css).
It's really up to you to decide, but it is important to be consistent, so others can understand your code more easily.
Hope this helps.
We can write CSS as the following types:
Inline CSS
Embedded CSS
External CSS
I would like to know pros and cons of each.
It's all about where in the pipeline you need the CSS as I see it.
1. inline css
Pros: Great for quick fixes/prototyping and simple tests without having to swap back and forth between the .css document and the actual HTML file.
Pros: Many email clients do NOT allow the use of external .css referencing because of possible spam/abuse. Embedding might help.
Cons: Fills up HTML space/takes bandwidth, not resuable accross pages - not even IFRAMES.
2. embedded css
Pros: Same as above regarding prototype, but easier to cut out of the final prototype and put into an external file when templates are done.
Cons: Some email clients do not allow styles in the [head] as the head-tags are removed by most webmail clients.
3. external css
Pros: Easy to maintain and reuse across websites with more than 1 page.
Pros: Cacheable = less bandwidth = faster page rendering after second page load
Pros: External files including .css can be hosted on CDN's and thereby making less requests the the firewall/webserver hosting the HTML pages (if on different hosts).
Pros: Compilable, you could automatically remove all of the unused space from the final build, just as jQuery has a developer version and a compressed version = faster download = faster user experience + less bandwidth use = faster internet! (we like!!!)
Cons: Normally removed from HTML mails = messy HTML layout.
Cons: Makes an extra HTTP request per file = more resources used in the Firewalls/routers.
I hope you could use some of this?
I'm going to submit the opinion that external style sheets are the only way to go.
inline CSS mixes content with presentation and leads to an awful mess.
embedded CSS gets loaded with every page request, changes cannot be shared across pages, and the content cannot be cached.
I have nothing against either method per se, but if planning a new site or application, you should plan for external style sheets.
Inline
Quick, but very dirty
This is (sadly) also the only really sane option for HTML formatted email as other forms often get discarded by various email clients.
Embedded
Doesn't require an extra HTTP request, but doesn't have the benefits of:
Linked
Can be cached, reused between pages, more easily tested with validators.
You want external css. It's the easiest to maintain, external css also simplifies caching. Embedded means that each separate html file will need to have it's own css, meaning bigger file size and lots of headaches when changing the css. Inline css is even harder to maintain.
External css is the way to go.
Where to start!!??
Say you had a site with 3 pages...
You could get away with Inline CSS (i.e. CSS on the page itself, within tags).
If you had a 100 page website...
You wouldn't want to change the CSS on each page individually (or would you?!)...
So including an external CSS sheet would be the nicer way to go.
Inline CSS is generally bad. It's much easier to modify the style of a page when all the styles are located in one central location, which inline CSS doesn't offer. It's easy for quickly prototyping styles, but shouldn't be used in production, especailly since it often leads to duplicating styles.
Embedded CSS centralizes the styles for the page, but it doesn't allow you to share styles across pages without copying the text of the embedded style and pasting it in each unique page on your site.
External CSS is the way to go, it has all of the advantages of embedded CSS but it allows you to share styles accross multiple pages.
Use external CSS when:
you have a lot of css code that will make your file messy if you put it all inline
you want to maintain a standard
look-and-feel across multiple pages
External CSS makes it a lot easier to manage your CSS and is the accepted way of implementing styles.
If the styles are only needed for one file, and you don't foresee that ever changing to apply to other pages, you can put your css at the top of the file (embedded?).
You should generally only use inline CSS if:
It's a one-time formatting for a specific tag
You want to override the default css (set externally or at the top of the file) for a specific tag
To everyone in the here and now, reading after 2015, with projects like Polymer, Browserify, Webpack, Babel, and many other important participants that I'm probably missing, we have been ushered into a new era of writing HTML applications, with regards to how we modularize large applications, distribute changes and compose related presentation, markup and behavior into self-contained units. Let's not even get started with service workers.
So before anyone forms an opinion on what is and isn't feasible, I would recommend that they investigate the current web ecosystem in their time to see if some issues related to maintainability have been gracefully solved.
Pros:
Allows you to control the layout of the entire site with one file.
Changes affect all documents at the same time.
Can eliminate redundant in-line styling (Font, Bold, Color, Images)
Provide multiple views of the same content for different types of users.
Cons:
Older browsers may not be able to understand CSS.
CSS is not supported by every browser equally.
In this case, the pros far outweigh the cons. In fact, if the site is designed in a specific way, older browsers will display the content much better (on average) than if the site were managed with tables.
If you are using a server side language, why not embed CSS and use conditional programming to display it as necessary? For example, say you're using PHP w/ Wordpress and you want some homepage specific CSS; you could use the is_home() function to show your CSS in the head of the document for that page only. Personally, I have my own template system that works like so:
inc.header.php = all the header stuff, and where page specific CSS would go I put:
if(isset($CSS)) echo $CSS;
Then, in a specific page template (say about.php), I would use a heredoc variable for the page specific CSS, above the line which includes the header:
Contents of about.php:
<?php
$CSS = <<< CSS
.about-us-photo-box{
/* CSS code */
}
.about-us-something-else{
/* more CSS code */
}
CSS;
include "inc.header.php"; // this file includes if(isset($CSS)) echo $CSS; where page-specific CSS would go ...
<body>
<!-- about us html -->
include "inc.footer.php";
?>
Is there something I'm missing that makes this approach inferior?
Pros:
1) I can still cache the page using standard caching techniques (is there a caching method that takes advantage of a CSS only external file??).
2) I can use php for special case conditional formatting in specific class declarations if absolutely necessary (PHP doesn't work in a CSS file, unless I'm missing some server directive I could set).
3) All my page specific CSS is extremely well organized in the actual PHP file in which it's being used.
4) It cuts down on HTTP requests to external files.
5) It cuts down on server requests to external files.
Cons:
1) My IDE program (Komodo IDE) can't follow the Heredoc formatting to properly highlight the CSS, which makes it slightly harder to debug syntax errors in the CSS.
2) I really can't see any other con, please enlighten me!
Which is a better option: to store CSS on a separate file or on the same page?
Let's forget the fact that changing the CSS on a file makes it to apply all HTML pages directly. I am using dynamic languages to generate the whole output - so that does not matter.
A few things I can think of:
CSS on a separate file generates less bandwidth load.
CSS on a separate file needs another HTTP request.
On the other hand, if I compress the data transmission with Zlib, the CSS on the same page should not matter in terms of bandwidth, correct? So, I get one less HTTP request?
The main benefit of an external CSS file is that:
It can be used on multiple pages; and
It can be cached so it doesn't need to be loaded on every page.
So, if there is potential for reuse of the dynamically generated CSS between pages or on multiple views of the same page then an external file could add value.
There are several common patterns for dynamically generated CSS.
1. Generating a subset for a page
I've seen this occasionally. A developer decides to limit the amount of CSS per page by only sending what's necessary. I don't imagine this is the case for you but I'm mentioning it for completeness. This is a misguided effort at optimization. It's cheaper to send the whole lot and just cache it effectively.
2. User-selected theme
If the user selects a particular look for your site, that's what I'm talking about. This implies they might select a whole package of CSS and there might be a limited set to choose from. Usually this will be done by having one or more base CSS files and then oen or more theme CSS files. The best solution here is to send the right combination of external CSS files by dynamically generating the page header with the right <link> elements and then caching those files effectively.
3. User-rolled theme
This goes beyond (2) to where the user can select, say, colours, fonts and sizes to the point where you can't package those choices into a single theme bundle but you have to generate a set of CSS for that user. In this case you will probably still have some common CSS. Send that as an external CSS files (again, caching them effectively).
The dynamic content may be best on the page or you may still be able to make use of external files because there is no reason a <link> can't point to a script instead of a static file. For example:
<link rel="stylesheet" href="/css/custom.php?user=bob" type="text/css">
where the query string is generated dynamically by your header from who is logged in. That script will look up the user preferences and generate a dynamic CSS file. This can be cached effectively whereas putting it directly in the HTML file can't be (unless the whole HTML file can be cached effectively).
4. Rules-based CSS generation
I've written a reporting system before that took a lot of rules specified by either the user or a report writer and a custom report and generated a complete HTML page (based on the tables and/or charts they requested in the custom report definition) and styled them according to the rules. This truly was dynamic CSS. Thing is, there is potential for caching here too. The HTML page generates a dynamic link like this:
<link rel="stylesheet" href="/css/report.annual-sales.0001.css" type="text/css">
where 'annual-sales' is the report ID and 0001 is like a version. When the rules change you create a new version and each version for each report can be cached effectively.
Conclusion
So I can't say definitively whether external CSS files are appropriate or not to you but having seen and developed for each of the scenarios above I have a hard time believing that you can't get some form of caching out of your CSS at which point it should be external.
I've written about the issue of effective CSS in Supercharging CSS in PHP but the principles and techniques apply in any language, not just PHP.
You may also want to refer to the related question Multiple javascript/css files: best practices?
There is a method that both Google and Yahoo apply which benefit's from inline CSS. For the very first time visitors for the sake of fast loading, they embed CSS (and even JavaScript) in the HTML, and then in the background download the separate CSS and JS files for the next time.
Steve Souders (Yahoo!) writes the following:
[...] the best solution generally is
to deploy the JavaScript and CSS as
external files. The only exception
I’ve seen where inlining is preferable
is with home pages, such as Yahoo!'s
front page (http://www.yahoo.com) and
My Yahoo! (http://my.yahoo.com). Home
pages that have few (perhaps only one)
page view per session may find that
inlining JavaScript and CSS results in
faster end-user response times.
If you're generating HTML dynamically (say, from templates), embedding CSS allows you the opportunity to also generate the CSS dynamically using the same context (data, program state) as you have when you're producing the HTML, rather than having to set that same context up again on a subsequent request to generate the CSS.
For example, consider a page that uses one of several hundred images for a background, depending on some state that's expensive to compute. You could
List all of the several hundred images in rules in a seperate, static CSS file, then generate a corresponding class name in your dynamic HTML, or
Generate the HTML with a single class name, then on a subsequent request generate CSS with a rule for that name that uses the desired image, or
Do (2), but generate the CSS embedded in the HTML in a single request
(1) avoids redoing the expensive state computation, but takes a larger hit on traffic (more packets to move a much larger CSS file). (2) Does the state calculation twice, but serves up a smaller CSS file. Only (3) does the state calculation once and serves the result in a single HTTP request.
Browsers can cache the CSS files (unless it changes a lot). The bandwidth should not change, because the information is sent, no matter where you put it.
So unless the css quite static, putting it in the page costs less time to get.
I always use mix of both.
site-wide styles are in separate file (minified & gzipped),
any page-specific styles are put in <style> (I've set up my page templates to make it easy to insert bits of CSS in <head> easily at any time).
Yes and no. Use a .css file for most rules; your site should have a consistent look anyway. For rare, special case, or dynamically generated rules you can use inline 'style=""'. Anything that sticks should move into the .css, if only to make transcluding, mash-ups, etc. easier.
Keep it separate. HTML for centent, CSS for style, JavaScript for logic.
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.