So I’m in the middle of fiddling around with a site and I notice it’s full of old code and IE style resets/hacks/polyfills etc. all of which it’s not necessary to support anymore.
Rather than me trawling through thousands of lines of CSS, is there a simple, efficient and safe way to detect and remove old styles from a stylesheet?
I’m talking _background: gray; -ms-filter:; -WebKit-border-radius:; and all the other proprietary things from back in the day.
This site will support modern browsers only, using standard CSS3 selectors and attributes, so if I can find a way to parse and either automatically remove or at least give me line numbers for the antiquated code, that’d save me a huge amount of time (and save me having to start from scratch!!!)
Thanks in advance guys!
I found an incredibly useful tool: https://www.projectwallace.com/
It doesn’t strip CSS, but gives a good overview!!!
Related
It doesn't take long to realise when using css that certain things are not cross-browser friendly.
For example, when I wanted a semi-transparent png I had to give IE something ridiculous like: filter: progid:DXImageTransform.Microsoft.AlphaImageLoader(...);
I've had problems with positioning and pseudo-selectors etc. as anyone who has played around with css for more than 20 minutes will have encountered.
To solve problems sometimes I start out deciding that I will only do what all the browsers support and support in the same (or at least a fairly similar) way.
Other times I just chuck in conditional comments and give IE it's own stylesheet.
And then on other occasions I simply use css hacks to exclude certain browsers from reading particular bits (like the old "* html {}" or "html>/**/body {}")
So my question is, which is the best option. The first is pretty limiting and you end up developing for what IE6 is capable of doing but the other two feel a bit mucky. So which is the bets in terms of programming practices, rendering efficiency etc.?
Short answer:
Do your best to adhere to standards
Be creative
Stop using hacks and start using conditional comments
In the long run, CSS hacks are just going to pollute your stylesheets and make them more difficult to maintain. Avoid them wherever you can, and use conditional comments with IE-specific stylesheets instead (since most hacks cater to IE). I can guarantee that CCs are much less mucky than hacks, if mucky at all.
You do not have to be limited by IE all the time. There's a concept called progressive enhancement, which means you can make your pages look slightly prettier in modern browsers that support advanced styling, and so on. There's nothing wrong with using CSS3 properties like border-radius today, since browser vendors are working (relatively) quickly to bring support for these to their products.
But then there are clients, which would be a different topic of discussion. I would say, though, strike a balance: educate your clients and be creative, but don't try to do anything too smart or fancy. And please, just avoid CSS hacks unless it's half past 4 in the morning and you're downing can after can of beer and just want to get something done in whatever circumstance.
I always prefer conditional comments with IE fixes. The hacks are not consistent with IE fixing the parsing so the hack doesn't work anymore but then not fixing the thing the hack was compensating. Also, they could mess with other CSS parsers.
I am trying to figure out the most efficient way to ensure cross-browser compatibility. I have done a bit of research and learned a few interesting things such as the fact that Mozilla/Firefox can't handle a class that has a name starting with a number. Is there a way to make a CSS work for any browser or is it better to just develop multiple CSS and add code to choose which to use based on the browser being used?
You might consider using a CSS Framework such as Blueprint. It includes a CSS reset that should help.
Also, you might want to look at Yahoo's CSS reset
An aside to clarify a point:
... I have done a bit of research and learned a few interesting things such as the fact that Mozilla/Firefox can't handle a class that has a name starting with a number....
Sorry, but that's not a Mozilla limitation, it's in the CSS spec: class names must not start with a number. Any browser that allows them to isn't enforcing the rules properly.
Answered here on StackOverFlow. The relevant part of the spec is at http://www.w3.org/TR/CSS21/syndata.html#characters (see the 2nd paragraph).
To answer your question: There is no way to make a page using just one universal css and have it displayed equally in all browsers, unless you only use an extremely small sub-set of all available css (selectors, values, etc.).
The way I work is:
Use a css reset
Develop for a browser that adheres to the standards pretty well (Firefox, Chrome, Safari, Opera)
Patch things up for IE using conditional comments (because you'll probably need things that don't validate)
A good starting point would be to use CSS reset such as: http://developer.yahoo.com/yui/reset/
Your goal should be CSS that works on all browsers. If you start out with a CSS file per browser, where do you stop? Mobile Safari? Flock? Konqueror? Every version of every supported browser?
Eventually, you might need to compromise, but you can cross that road when you get there.
Regardless of your infrastructure/framework/etc you should test your code on all major browsers. If possible avoid using style sheets for browser specific problems. Browsers will change and adapt which means you might get stuck having to update a bunch of websites when new browsers come out.
CSS is a fickle beast and I haven't found any solution that covers all the quirks except for a lot of due-diligence and testing.
You might use a framework that does this for you, such as GWT, but keep in mind that you will still have some issues.
Like every web developer, I usually curse the creators of IE6 with foul and untimely deaths at least once a week. Yet my company requires me to keep supporting that most-hated of browsers.
My problem today has been wanting to first use a wildcard in my CSS and then trying to use the "inherit" property instead. Neither of which are supported by IE7-.
I really, REALLY want to have good, well-structured, properly-inheriting CSS (object-oriented CSS, if you like that buzzword) but I have that sinking feeling in the pit of my stomach that sooner or later, it's going to have to be custom-purpose and location-based classes.
This poses the question: given how utterly awful IE is at handling many CSS concepts, is it impossible to adequately support this browser at the same time as having a well-structured CSS document?
Just to clarify: I'm aware that there are plenty of ways (some legitimate, some less so) to get around the bugs and shortcomings found in IE6 and 7. What I'm really asking is "if you want to have a single, well-written stylesheet that inherits correctly, must you choose between that and having a consistent look across all browsers?". Hope that makes sense.
In other words, should I stick to my principles and code a good style sheet or should I accept that IE6 still enjoys a horribly high (20% on last count) market share and bring myself to support it? Or is there some happy medium that allows me to minimise the frankenstein surgery on my HTML and CSS while still achieving some respectable results in IE?
To be fair, you can't blame it all on IE (though Microsoft certainly is by far the worst transgressor). Part of the problem with such large & rapidly-evolving standards is that it's too much of a moving target to be perfectly implemented in a timely fashion. Unfortunately, the release cycles of web browsers do not coincide with the release of new web specifications. So all browser developers can do is try to implement as many features as they can from the latest W3C recommendations, selecting what they think will be the most commonly used features to implement first.
However, things are clearly improving, and it is possible to support IE6/7 and still use proper CSS design. It's just... difficult. Take a look at this comparison of layout engines & CSS support. If you look at the overall trend, you'll see that most browsers (even IE) do tend to comply with established standards in the long-run, it just takes some browsers longer than others to implement a standard after its introduction.
And sometimes it's not that one browser is "less" standards-compliant than another. With new standards the problem is often that different development teams chose to adopt different parts of the new specification. So even though CSS3 is already beginning to be implemented by most browsers, we'll probably have to wait until CSS4 is published before seeing consistent support across all major rendering engines. And if you try to use the latest CSS3 features right now, you'll have a hard time establishing compatibility across all major browsers. But if you're using features introduced in CSS1, it's no problem at all.
Therefore, the only option--aside from using ugly CSS hacks--is to stick with well-established older specifications. Then the problem is no longer trying to conform to web standards while supporting a particular browser. Instead the problem simply becomes trying to resist the urge to use the latest & greatest CSS features.
Aside from that, the only permanent solution I see to this recurring situation is for the W3C to prioritize different parts of newly introduced specifications so that the new features can be implemented in discrete phases synchronized across all the major browsers. So, for instance, grammar rules might be given the highest priority along with a set deadline for its implementation. After that would come the second phase, which could be element & attribute selectors, and so on and so forth.
This would require a tremendous level of cooperation between the W3C and development teams, but it would be worth it. After all, it does users and web developers no good for IE to implement one subset of features from CSS3 while Firefox implements a different subset and the Webkit browsers yet another subset. A "standard" is no good until it's actually standardized across all the major rendering platforms. It's better for each browser to support fewer new features but have them all be the same features, than for them to separately introduce a ton of their own features that aren't universally supported.
Not at all - you can compensate for IE's shortcomings with conditional comments and an IE specific stylesheet, while serving your 'nice' stylesheet to other browsers.
Something else which I find helps is to use a CSS reset. While this isn't going to resolve all of IE's issues, it does give you a good baseline to work from.
The most anoying IE6 feature is it's box model handling. You should stick to margin instead when positioning boxes, and try to use relative font sizes to allow font resizing on IE. The rest of the quirks are well documented.
Using conditional comments is the cleanest way of having both a clean style sheet for well behaving browsers, and still using being beautiful on IE. This is what I use, only needing 1 css file of a few lines to repair my sites look and feel.
The dark path of crossbrowser consistent look & feel are css hacks, but I strongly discourage it's use, specialy now that for some time we'll have to target three different IE (6, 7 & 8)
Normally, if you get the style to work in both FF and Chrome/Safari, IE is only a few corrections away of being correct.
There is a great site Position Is Everything that details how FF, IE and Safari conform to standard CSS. At the site you will find most of the workarounds / cures for IE that will alleviate the need for you to write so much conditional code for your CSS.
You'll also want to check out A List Apart for more on CSS and IE. There are also great articles on tableless layout with CSS, handling the height bug in IE, etc. Good luck - IE 6 really sucks when it comes CSS.
Certainly not. If you ensure that they render the page in "standards" mode as opposed to "quirks" mode many of the common IE CSS issues are resolved. To do this you must provide a valid doctype statement at the top of the page, such as
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
As others have pointed out, another good idea is to start off your stylesheet with a snippet that removes all paddings and margins like so:
*,html {
margin: 0;
padding: 0;
}
Finally, one common problem with CSS based layouts in IE is that clearing of floats doesn't happen when you'd expect. This is to do with a hidden object property in IE called "hasLayout"; only objects that "have layout" will correctly wrap around and enclose floated child objects. It is easy to ensure that your containers "have layout" simply by specifying at least one dimension for them:
height: 1%;
width: 100%;
zoom: 1;
I do not personally use conditional IE stylesheets except for one single thing: to replace PNG backgrounds with GIFs in IE < 7 - there is nothing wrong with using them, I just find it unnescessarily complicates things when you have to define the appearance of the same object in two different places. With the three tips above and a bit of patience you should be able to create CSS based layouts using a single stylesheet that render just as well in IE 6/7 as they do in Mozilla/Webkit.
Happy coding!
IE 6 really does limit what we can do.
It’s the lack of support for advanced selectors (and inherit — IE 7 doesn’t support that either) that gets me. Just having the child selector and attribute selectors would be nice, that’d really cut down the amount of code we have to write and maintain. You can only work around the lack of support for them by duplicating your styles, so you just end up having to code as if they didn’t exist.
Sigh.
Only follow online CSS tutorials that is rendered correctly with IE6 and Chrome (or Webkit). If it looks right in both, it likely looks right in (almost) all browsers.
Is it better to have a different CSS file for each user-agent or is it better to use CSS Hacks that only certain browsers can see?
Neither.
The best is to write code that works in all browsers without the need of browser specific code or css hacks. It's of course not quite as easy to accomplish, which is why many people use the other methods.
The key is to avoid things that some browsers (very often Internet Explorer) has problems with. One such thing is to use padding rather than margin, because IE doesn't handle margin collapsing correctly.
Some methods that is in the border line of being hacks is using code that doesn't affect browsers that work correctly, but fixes problems for a specific browser. That could be things like specifying a height for an element that normally shouldn't need one, or specifying display:inline on a floating element.
The page Position is everything has examples of some bugs and suggested fixes. (Often the fix is some kind of hack, so you should of course also consider if you can avoid the problem altogether.)
It's better to do neither.
A good css-reset and css that works the same cross-browser is a much better solution.
If your design absolutely precludes that, then (and only then) would I try hacks or IE conditional comments.
I haven't yet seen the need for mutliple css files (beyond a few IE6 corrections addressed via a conditional comment).
Neither if possible. Now that the old Netscape, IE <= 6 etc. are not longer really that much in use, I try to use features which work in all those browsers (e.g. FF >= 2, IE >= 7, Chrome, Opera).
Conditional comments for issues with Internet Explorer appear to be the norm. Combined with a little bit of JavaScript, like Dean Edward's ie7.js you can mitigate most cross browser issues without resorting to hacks within your CSS files.
its better to use a different css files for Internet Explorer 6-7 (include them via conditional comments), and a hacks for other browsers.
A sort of follow up is how to develop the single file that works.
The best approach that I've seen work is to start from nothing, slowly building it up and checking change by change that it's still compatible across your core browsers (especially the problematic ones).
When you get it fully working with one browser and then say "time to convert it" is when the pain really starts and where you have to start hacking.
My approach using a PHP class to detect os, browser and browser version. You can target any version of almost any browser on any operating system.
What are the aspects of style sheets (CSS) that can lead to poor performance of web sites?
Anything that can really choke up the CPU?
thanks in advance.
Sesh
IE expressions can be a killer if over used. They're reevaluated each and every time the rule is applied.
CSS? Not so much it's pretty tight, but on older (like gen 4) browsers I've seen problems with:
doing too much on the * selector
using inherit a lot
using the IE expression value abusively
loading a lot of external resources (images, other CSS docs)
applying a lot of what you might call unanchored selectors like div div
Basically anything which would be difficult to cascade through or would cascade a lot.
Browsers are very good at rendering CSS rules quickly.
Probably more important is the size of the CSS file. For most sites, this isn't a problem, but for larger sites it is something to be aware of.
For instance, cnn.com delivers something like 150K of CSS. This will take a few seconds on older modems, so CNN ought to make sure that their CSS is cacheable and gzipped.
I have personally never encountered anything in CSS that would do this. Flash content and exessively large pages are far more likely to slow down a browser. That said I would image over use of expressions or custom IE filters (as are often used for transparency of PNG images) may use a lot of CPU.
Something that chokes not-too-old browsers are huge backgrounds that use "background-position: fixed" a la Complexspiral Redux.
It's hard to affect the CPU (except with IE expressions, like sblundy mentioned), but it's very easy to affect the page-load time.
Try to follow Yahoo client-side performance guidelines, such as:
Put CSS links at the top of the page
Use <link> instead of #import
Combine CSS files
Minify CSS files
I have seen cases where high-resolution tiled background-images (usually jpg or png) cause a major slowdown (choppy effect) when you scroll.
Most likely, the CSS file is not choking the site quite so much as trips to the server, complex calc, etc. might. But if it is:
There's an art to writing a lightweight-but-effective css file system that is ever-evolving, to say the least. Effectively using classes and IDs to take advantage of the cascade, for example, can be tough, especially when the project evolves over time, or if the GUI writing it gets swapped out several times over the course of the lifecycle.
For every legacy browser you have to support, it adds a performance hit, especially if you're using hacks to get it done. Those can be tricky, especially if layered upon one another. Conditional comments are similar - the browser has to decipher which rules it follows, and read through everything before it renders.
Going full-size image when you could tile or set a color on a background is a drag on siteload, as well.
(Gratuitous shot) IE can take a long time to misrender your styles and elements.