With new browser enhancements such as CSS3 animations, gradients, SVG backgrounds, etc... it becomes unnecessary for newer browsers to have to download legacy CSS code and for legacy browsers to have to download advanced CSS code. So on a HTTP level (no server-side programming approach) how could you deal with such an issue? Should you have base.css file which is served to both groups of browsers and then have an additional CSS file served afterwards based on which browser group is requesting it? Is there a way to include a CSS file that simply redirects the browser to the browser group specific rewrite? Or is this something that should be figured out and downloaded on the client-side first?
Fully embracing the concepts of graceful degradation and progressive enhancement would allow you to use the same css for all target browsers - in a nutshell, if a browser does not support css3 rounded corners - give it vendor-prefixed rule; if it doesn't support that either - no biggie, the site would still be usable with square corners.
The overhead of downloading rules with vendor-specific prefixes as well as standard ones would be minimal compared to an extra http request and would improve maintainability as well as save you trouble by not having to rely on browser detection.
Layout-specific hacks would commonly have to be applied to IE family only which can be targeted by html conditional comments.
I've found that there are three ways to do this.
Use a big file for each of the stylesheet and javascript assets and then use something like modernizr and feature sniffing to weed out which browser does what. Or just make all the browsers do the same thing. This is better for development input and testing.
Use two files (one called ancient.css and another called modern.css) and use a server-side HTTP sniffer operation to check to see the version of the browser and then provide it with the appropriate file. Set the HTTP caching to expire in the far future to prevent it from accessing the server each time to check to see which file to download. To generate the files, simply just create one file with all of the core stuff shared between all browsers and another with the emulated stuff for the older browsers. The benefit is that you get to use all the new CSS3 and HTML5-JavaScript stuff, but the downside is that you need to test to make sure the modern-browser code stuff works the same as the ancient stuff.
Have two asset files (modern + ancient) and have modern download first. Then have the browser see if it supports something via modernizr and, if not, then have it download the ancient file. The benefit here is that you don't need to have any extra server-side stuff developed, but the downside is that your website will render slower and you may have multiple downloads of the same resource happen at the same time.
Related
It seems there are two ways to show WebP images to browsers that support it.
Use the HTML Picture element
<picture>
<source srcset="image.webp" type="image/webp">
<img src="image.jpg">
</picture>
Detect on the HTTP server. So request /image and the server detects through the http request headers if the client supports webp or not, if it does serve the webp image, if it doesn't serve the jpg image.
Which approach is better, what are the pros and cons of each?
Update Answer (based on comments to the answer):
All-in-all, both approaches would yield similar performance benefits. Which of the two is better depends on your situation (detailed below):
Approach #1 (<picture> tag)
The benefit of using <picture> tag approach is that no change on server side is needed. So, in setups where changing server / CDN configuration is an issue - this should do the trick.
The issue with this approach is it's need of updating existing code. So, for sites with a lot of existing pages - this can be cumbersome.
Approach #2 (Change image format delivered based on http headers)
The major benefit of this approach is no code change within your HTML.
One thing to be careful about with this approach is - you'll have to be sure your server environment and CDN support delivering different image formats based on HTTP header.
Performance wise - there is no difference between the two approaches. The additional CPU consumed on the server side to detect the header and respond accordingly is generally minimal.
For more details, check out https://www.tezify.com/how-to/using_webp_images/
Original Answer:
Approach #1 (using element) makes better sense. Primarily because as browser's support for webp will improve, the newer browsers will download webp images.
In case of approach #2 (using server side detection via user-agent-string), you'll either have to update the detection code OR improved webp support will not reflect in your image loading solution.
HTML5 <picture> solution or JavaScript soulution Detecting WebP support is better because fetching website is faster (less requests). JavaScript solution is possibly the best solution considering the fact for performance reasons frameworks like React or Vue populate dynamic fragments of website via JS and HTML is only "page skeleton" what allows all resources to be cached for even better performance (so only API has to be downloaded and updated). Bad side of HTML solution is <picture> in an older browser can be displayed not as expected. You may also find this article helpful.
I'd say if it makes sense for your application, it's better to detect it server side by examining the 'Accept' header, as it is doesn't depend on the support for the <picture> tag, which can be consulted here. Most modern browsers support it, but older versions don't.
The reason I can think of for doing it client side is because its a static app or you have no control over the server.
I've been reading up about responsive design and am going to start implementing a new CSS set-up on my site. This has lead me to thinking about the best way to call all these different CSS files. I'll have a different CSS for different screen widths.
I am debating two options:
connecting to all the files from each web page with LINK tags. My only problem with this is the ongoing maintenance (and having to add all these links to start with); I know this isn't the end of the world but seems a little bit intensive on the maintenance side.
the other way would to have just one LINK tag on each web page, pointing at a 'feeder' CSS. This 'feeder' CSS file would include all the links to my other CSS files using #imports. This would mean maintenance would be a breeze. I could add/re-order/delete the CSS files in just one place for the entire site. Great!
However this leads on to compatibility of the #import function [or lack of it in older browsers].
I've looked around and the articles I've seen have been at least a couple of years old.
So, to get to the nub: what percentage of browsers that are being used now [July 2013] support this and can I safely forget about the browsers that wont be able to interpret #import?
If not, what can I do to keep maintenance of CSS files down to a minimum. (Something more elegant than "find and replace on current site").
Instead of worrying about #imports, you should just combine and minify all of your CSS files that cannot be served via a CDN:
<link rel="stylesheet" href="styles-84e599dcbd6c60fa0af76aaa18a5d75f.css" />
It'll load faster, use up less bandwidth, and will work on any browser that supports stylesheets.
There are many ways to do this. If you're not using any web framework (or are using Node.js), take a look at Grunt.
As for your actual question, unless you're planning to support browsers older than IE5.5, #import will work just fine. But I strongly recommend the minified stylesheet approach.
I'm going to actually say that the accepted answer, now in 2016, is not necessarily the correct one-- for a couple of reasons:
1) HTTP 2.0 is becoming the majority-used protocol version in industrialized countries outside of China (thanks, old IE), and will soon be considered the industry standard (if it's not already). This means that support for connection multiplexing and header caching eliminates the need to combine files into one; in fact, at the Fluent Conference in SFO last year the HTTP2 presenter actually argued that splitting things like CSS and images into multiple files will actually be better due to HTTP's superior ability to utilize more bandwidth due to longer connection times.
2) Because of all this front-end automation in CSS like SASS and LESS, you end up much more likely to break the IE 5-9 4095 selector limitation. This is a little known bug because until now people rarely exceeded that number of selectors in a single sheet; however, on enterprise sites this is becoming a common thing. Basically, any sheet with more than 4095 selectors will still be read in, however the browsers will simply silently fail to render any rules after that.
This isn't to say that minifying into one file is bad, however, the other approach of splitting is actually no longer bad either, and in fact, in certain cases is either necessary or even better depending on project needs.
Here are some stats about browsers http://www.w3schools.com/browsers/browsers_stats.asp
For responsive css I would use media queries, it wont affect older browsers, and work great for devices that are going to need the responsive css (mobile devices)
http://css-tricks.com/css-media-queries/
Once upon a time I was thought by more advanced web developers (gee, when was it again? ;)) that we should avoid managing multiple CSS files and stick to one per project. It helped to improve page load speed and avoid silly mistakes when dealing with a lot overlapping CSS rules.
My question is - is this approach still valid?
Argument about page load performance doesn't seem to hold that much nowadays with awesome broadband Internet and clever web browsers with even more awesome caching capabilities.
CSS cascading can indeed be error prone, but just for inexperienced developer and having one CSS style sheet doesn't really make us bullet-proof.
I think that I would prefer to have a set of default style sheets neatly separated by components, then wire them up into one single rule by CSS #import. This would also allow me to include reset style sheet by default.
Anyone is with me?
It's not about bandwidth speed but number of http requests, this makes a lot of sense for a mobile connection.
However the approach of having different css files to keep the project modular is solid, as it helps you keeping your css organized the way you want it without having all the code in one file only. Then you can benefit of css preprocessors / minifiers to concatenate and compress all your css files in a single one for production.
this article http://www.igvita.com/2012/06/14/debunking-responsive-css-performance-myths/
has a paragraph about mobile that explains well why this is a good practice:
you are much better off downloading all of the CSS content in one shot over the initial, warmed up connection. By doing so, you will also help the user extend their battery life. If there is one optimization to be made here then it is simply: concatenate and compress.
Yes, that approach is still valid. There are dozens of articles about load optimization out there, but the general idea is as follows
Less files = less http requests made to server = better load performance
Main thing that changed over time is that now there are many tools that support merging multiple files into single at runtime. So you have separate stylesheets for better organization, debugging at development time, and those tools merge, minify and set correct caching headers at production.
I agree with you, I find no reason to keep only a single css sheet anymore, nowadays, I do exactly what you just stated, separation by component, along with lazy loading :) (php if statements etc).
I separate stuff with comments. For example divs goes to /* Divs start*/ div#somediv /* Divs end*/ /* Animations start*/ /* Animations end*/. For me this is easier than merging different css files once i've completed the project
I know that there are several very similarly-related questions on this website, however after reviewing the play, I believe this question is unique in its own right. If someone can find and provide evidence of an exact dupe of my question, I will withdraw it myself (so please just don't downvote this!).
I am a Java developer, not a web developer. But, as is the case in so many families where there is one person who becomes the designated family "computer guy", my Java development skills have been mistaken for web development skills, and I somehow got roped into building a website for my parents to help them sell their house.
So, like any web development newbie, I wrote the HTML/CSS myself (by hand, sans editor like DW or Expression, etc.) and tested it against FireFox 3.x. All looked great, and we deployed/launched.
Now we're getting negative feedback from everyone and their dog stating that the site isn't rendering properly in other browsers, browser versions, or on FireFox installations running on different operating systems. Similarly, the site is apparently a total mess when being viewed through a smart phone or tablet device.
Now I could dive in and write a whole bunch of messy, nasty, painstakingly-tedious edits to my CSS rules, that basically say: do X when browser is Y, etc. But I am hoping that out there is a tool that can put all my fears to rest.
What I'm looking for is a tool that could take my valid CSS files, and use them to generate CSS rules that will be compatible with a high percentage of all common browsers/versions.
Alternatively, if I have to re-write my CSS from scratch, it would be nice to have a tool that allows me to write/design once, deploy many, so that I only have to focus on the design of a single CSS file, but the code that gets generated is multi-browser compatible.
It sounds like DreamWeaver kind of does this, but you have to choose from one of 16 pre-existing templates.
My wife is a graphic designer, and made the website pretty sweet (not cookie cutter). It was a nightmare trying to figure out what CSS rules to use to implement her design. So any tool that forces you to choose between templates is not an option.
Is there any hope for me, or do I banish myself from my family in shame right now?
css is a mess, no way to automatically doing it right. saying that I would say there are tools that would walk with you the proper way.
1. use the meta tag:
http-equiv="X-UA-Compatible" content="IE=8" (encpsulate as a meta tag - SO won't display if I wrote it as a valid tag)
to force IE to render with it's most modern engine, that would solve some problems.
2.begin your css with normalize.css - that would eliminate some of the cross browser problems - because it resets your css (better and more modern the reset.css)
I'll second the GWT if you come from the java dev world. although It's a framework to learn with it's own quirks. another possible web framework is Grails - a nice java/groovy port of the mighty Ror.
Less or Scss won't automatically solve your basic problem - which is browser compatibily - but are a better and simpler way to write css
remember that most css3 properties aren't support equally in all browsers (and in IE almost not supported) - use them only with graceful downgrade option with supported js or css -when Modernizr js library can give you pretty good property support detection for various browsers
don't go dreamweaver - it produces terrible code
use csslint to check for valid css and common css pitfalls
If you must use cutting edge web rendering with html5+css3 elements you should look into chrome frame -that would enable older browser better support of your site - although I believe this may be an overkill for a simple sell-my-house kind of site.
use a css framework to prototype- it would give you better css, good basics and resets and good boilerplate - maybe bootstrap or something similiar (didn't try most of them but the internet is crowded with those.
good luck
Check out modernizr. http://www.modernizr.com/docs/
You want to get into the position of checking for features and not browsers.
Here's an excellent site to check your site with alternative browsers:
http://www.browserstack.com/
Less (http://lesscss.org/) will help you with a lot of CSS3 functions.
However, good CSS code simply works on all browsers. There are some CSS concepts that must always be avoided as much as possible (absolute positioning, excessive floats, using the wrong elements for a task, etc) and your code will work better.
In the many years I have programmed I only needed browser-specific code in the first two years. Then I grew up and learned which CSS code not to use and when it was possible to use them. It has been my experience that properly written CSS code works on all browsers, and if it doesn't it will at least get the basic concepts right (eg. a few pixels may be wrong or some effects, but the site still works well).
Several things come to mind that may help your case:
Forget about IE6, that one will give you trouble no matter how much effort you put into the site.
Make sure you have a good doctype (html5 or xhtml would be good).
Try out html5 reset, it tries to make sure all browsers behave the same.
The aforementioned reset also includes modernizr to bring older browsers up to speed
Finally: accept (some even say "embrace") that different browsers render things slightly different. Getting every pixel exactly the same in each browser will be near impossible.
I hate to put this into the world, but it sounds like you need Adobe Muse.
There is no equal to a good developer who will write clean cross browser code, but if you just want to get the site done check out the beta: http://labs.adobe.com/technologies/muse/
What I'm looking for is a tool that could take my valid CSS files, and
use them to generate CSS rules that will be compatible with a high
percentage of all common browsers/versions.
Unfortunately there's no such a tool and you have to debug and test your website for cross-browser compatibility manually. The best way i've found for cross-browser testing it to install and test different versions of browsers in several virtual machines.
You will also find the following helpful:
Modernizr
Google Web Toolkit
Short version: What is the cleanest and most maintainable technique for consistant presentation and AJAX function across all browsers used by both web developers and web developers' end-users?
IE 6, 7, 8
Firefox 2, 3
Safari
Google Chrome
Opera
Long version: I wrote a web app aimed at other web developers. I want my app to support the major web browsers (plus Google Chrome) in both presentation and AJAX behavior.
I began on Firefox/Firebug, then added conditional comments for a consistent styling under IE 6 and 7. Next, to my amazement, I discovered that jQuery does not behave identically in IE; so I changed my Javascript to be portable on FF and IE using conditionals and less pure jQuery.
Today, I started testing on Webkit and Google Chrome and discovered that, not only are the styles inconsistant with both FF and IE, but Javascript is not executing at all, probably due to a syntax or parse error. I expected some CSS work, but now I have more Javascript debugging to do! At this point, I want to step back and think before writing piles of special cases for all situations.
I am not looking for a silver bullet, just best practices to keep things as understandable and maintainable as possible. I prefer if this works with no server-side intelligence; however if there is a advantage to, for example, check the user-agent and then return different files to different browsers, that is fine if the total comprehensibility and maintainability of the web app is lower. Thank you all very much!
I am in a similar situation, working on a web app that is targeted at IT professionals, and required to support the same set of browsers, minus Opera.
Some general things I've learned so far:
Test often, in as many of your target browsers as you can. Make sure you have time for this in your development schedule.
Toolkits can get you part of the way to cross-browser support, but will eventually miss something on some browser. Plan some time for debugging and researching fixes for specific browsers.
If you need something that's not in a toolkit and can't find a free code snippet, invest some time to write utility functions that encapsulate the browser-dependent behavior.
Educate yourself about known browser bugs, so that you can steer your implementation around them.
A few more-specific things I've learned:
Use conditional code based on the user-agent only as a last resort, because different generations of the "same" browser may have different features. Instead, test for standards-compliant behavior first — e.g., if(node.addEventListener)..., then common non-standard functions — e.g., if(window.attachEvent)..., and then, if you must, look at the user-agent for a specific browser type & version number.
Knowing when the DOM is 'ready' for script access is different in just about every browser. A good toolkit will abstract this for you.
Event handlers are different in just about every browser. A good toolkit will abstract this for you.
Creating DOM elements, particularly form controls or elements with attributes, can be tricky with document.createElement and element.setAttribute. While not standard (and kinda yucky), using node.innerHTML with strings that contain bits of HTML seems to be more reliable across browser types. I have yet to find a toolkit that will let you use element.setAttribute to add a 'name' to a form element in IE.
CSS differences (and bugs) are just as important as JS differences.
The 'core' Javascript features (String, Date, RegExp, Array functions) seem to be pretty reliable and consistent across browsers, especially relative to the DOM/CSS/Window functions. There's some small joy in the fact that the language isn't entirely different on every platform. :-)
I haven't really run into any Chrome-specific JS bugs, but it's always one of the first browsers I test.
HTH
Chrome is actually a little different to Safari, it uses a completely different javascript implementation and problems have been reported with both prototype and jquery. I wouldn't worry about it too much for now, it's still an early beta version of the browser and such inconsistencies will probably be treated as bugs. Here's the bug report.
One "silver bullet" you may consider turning to is Google Web Toolkit (GWT).
I believe it supports all the browsers you are interested in, and gives you the ability to code your UI in a Java-compatible IDE such as Eclipse. The advantage of this is you can use IDE tools for code completion and compile-time error checking, which greatly improves development on large-scale UI projects.
If you use GWT UI components, it will hide a lot of browser-specific nastiness from having to be dealt with, but when you compile, will create a compact, deploy file for each browser platform. This way you never download any IE-specific code if you are viewing the app in Firefox. You will also have a client-side stub generated which will load the appropriate compiled bundle of JS. To sweeten the deal, these files are cacheable, so perceived performance is generally improved for returning visitors.
The landscape has evolved considerably to accommodate cross-browser development. jQuery, Prototype and other frameworks exist for cross-browser Javascript. CSS resets are good for starting on a common blank canvas for all browsers. BluePrint and 960 are both CSS frameworks to help with layouts using CSS grid layouts techniques that seems to be getting very popular these days.
As for other CSS quirks across the different browsers, there is no holy grail here and the only option is to test you website across different browsers and use this awesome resource and definitely join a mailing list to save up soem time.
If you are working on high volume production site then you can use a service like browsercam.com in the end game to ensure the site doesn't break horribly in some browser.
Lastly, don't try to make the site look the same in every browser. Your primary design should target IE/FF and you should be okay with reasonable compromises on others. Use the graded browser chart to narrow in on browser support.
As for best practices, starting using wireframes on blank paper or a service like Balsamiq mockups. I am still surprised how many developers start with an editor instead of a wireframe but then again I only switched a year back before realizing how big a time saver it is. Have clean seperation of layout (HTML), presentation (CSS) and behaviors (Javascript). There should be no styling elements in HTML, no presenation in Javascript (use .addClass('highlight') instead of .css({'background-color': 'red'});).
If you are not familiar with any of the bold terms in this post, Googling them should be fruitful for your web development career and productivity.
If you're starting from a base reset or framework and have accounted for IE and it's still all freaky, you may want to recheck the following:
Everything validates? CSS and HTML?
Any broken links to an included file (js, css, etc?). In Chrome/Safari, if your stylesheet link is busted, all of your links might end up red. (something to do with the default 404 styling I think)
Any odd requirements of your js plugins that you might be using? (does the css file have to come before the js file, like with jquery.thickbox?)
For UI, check out Ext.
It's great as a standalone library, though it can also be used with jQuery, YUI, Prototype and GWT.
Samples: http://extjs.com/deploy/dev/examples/samples.html
I've found four things helpful in developing JavaScript applications:
Feature detection
Libraries
Iterative Development using Virtualization
JavaScript: The Definitive Guide, Douglas Crockford & John Resig
Feature Detection
Use reflection to ask if the browser supports the desired feature. If you want to know what event handling a browser supports, you can if(el.addEventHandler) for W3C compliance, if(el.attachEvent) for the IE-type, and finally fall back on el.['onSomeEvent'].
ONE BIG BUT!
Browsers sometimes lie about what features they support. I can't remember, but I ran into an issues where Firefox implemented a DOM feature, but would return false if you tested for that feature!
Libraries
Since you're already working with jQuery, I'll save the explanation. But if you're running into problems you may want to consider YUI for it's wonderful cross-browser compatibility. They even work together.
Iterative Development with Virtualization
Perhaps my best advice: Run all your test environment's at once. Get a Linux distro, Compiz Fusion and a bunch of RAM. Download a copy of either VMWare's VMWare Server or Sun's Virtual Box and install a few operating systems. Get images for Windows XP, Windows Vista and Mac OS X.
The basic idea is this: Compiz Fusion gives you 4 Desktops mapped onto a Cube. 1 of these desktops is your Linux computer, the next your Virtutual Windows XP box, the one after that Vista, the last Mac OS X. After writing some code, you alt-tab into virtual computer and check out your work. Plus it looks awesome.
JavaScript: The Definitive Guide, Douglas Crockford & John Resig
These three sources provide most of my information for JavaScript development. The Definitive guide is perhaps the best reference book for JavaScript.
Douglas Crockford is a JavaScript guru (I hate the word) at Yahoo. Lookup his series "Douglas Crockford Theory of the DOM", "Douglas Crockford Advanced JavaScript", "Douglas Crockford Theory of the Dom", and ""Douglas Crockford The Good Parts" on Yahoo! Videos.
John Resig (as you know) wrote jQuery. His website at ejohn.org contains a wealth of JavaScript information, and if you dig around on Google you'll find he's given a number of presentations on defensive JavaScript techniques.
... Good luck!
Just so you've got one less browser to worry about, Chrome uses the same rendering engine as Safari. So if it works in Safari, it should work exactly the same in Chrome.
See this post on Matt Cutts' blog.
Google Chrome uses WebKit for rendering, which is the same rendering engine as Apple’s Safari browser, so if your site is compatible with Safari it should work great in Chrome.
Update: Looks like this is now out-dated info. Please see Vox's comment on this answer.
If your very top priority is exactly consistent presentation on all the browsers listed with no disparities, you should probably be looking at AS3 and Flex.
Personally, I use Mootools as a simple lightweight javascript framework. It is simple to use and supports all the browsers above (except Chrome, but that seems to work too as far as I can tell).
Also, to ensure consistency across the browsers, I get a feature/style/behaviour/etc. to work in one browser first (usually Firefox 3 with firebug), then immediately check to make sure it works in all the other browsers (leaving IE6 for last). If it doesn't, I inveset the time to fix it right away, because otherwise I know I won't have time later (in my experience, getting things to work cross-browser takes about 50% of my dev. time ;-) )
Validating your javascript with a "good parts" + browser on JsLint.com makes it less likely to have JavaScripts behaving differently in FF, Safari etc.
Otherwise - using standards and validating your code as well as building on existing techniques like jQuery should make your site behave the same in all browsers except IE - and there's no magic recipe for IE - it's just bugs everywhere...