This question already has answers here:
Closed 11 years ago.
Possible Duplicate:
Cross-browser CSS
Ok, so the question might be somehow a little confusing.
I'm gonna try to put it in a much simpler way so "you" can understand my
point of view.
All browsers are different. Every browser interprets the CSS rules
diferent, which drives to different results. Some times the results are good
other times and much often results are totaly unexpected. The case of IE can lead to the worst scenario possible!
Many often, developers are forced to detect the browser to apply a
specific css style!
This can be achieved with javascript support. Anyhow, some people say
that this method it's not enough to prevent disasters... others
think that the best way to deal with this problem it's to rely on
Object detection instead.
Well, I don't know which one is best...
Please feel free to give you opinion based on examples.
As always, thank you.
UPDATE
The case of IE can be very simple to deal with conditional statments but, safari can't be treated the same way! So I leave this link: http://quirksmode.org/js/support.html to clarify my point of view...
I personally don't believe in browsers sensing for CSS. In my opinion, it's a waste of time. It takes extra time to code, extra time to change, and creates an extra layer of headaches. Plus, when do you stop? AOL browser? Some random flavor of the day for a 15 year old version of linux used by 12 people in Iceland?
I also don't do hacks. Some will make their way in via Jquery's CSS or outside code I incorporate, but I don't personally write them. They don't validate, so they weren't meant to be in my mind. Javascript tricks are nice, but for styling I don't rely on them because they're not 100% reliable. If it's not gracefully degradable, it's not an option.
So, to combat the issues I do the following:
Clean, valid CSS
Reset (some of the time)
Grids (often, via Blueprint or 960.gs)
Dead reckoning of elements. This means avoiding the graphic designer mentality of 100% pixel perfection and designing for elements that can change as the web often does. Forget box model for a minute, fonts render differently too, and that will never change.
I avoid absolute elements like the plague. 99.5% of everything can be done relative if you try.
Cutting Edge...not bleeding edge. The cool new hacks are nice, but they aren't supported yet. So, they are last case scenario for me. It HAS to be this way for my large (well paying) corporate clients.
Intelligent design. Let's face it folks, if you design FOR THE WEB, you'll have an easier time making it so. If a designer converts a print design for the web, it's nearly always going to have --issues--. Can they be worked through? Sure, and it's profitable for us. But intelligent design in the first place solves all sorts of issues.
The name of the game is progressive enhancement, folks. If IE doesn't support rounded corners, they get square corners. After all, the standard rounded corners are valid HTML. If they have a problem with it, they can upgrade or change. Sound harsh? Sure it is. But we have a very clear standard (set by w3c) to maintain, and it's our job to do it. It's the only way to hit the mark on this moving target.
Two things. First, make sure you include a DOCTYPE. If you don't, browsers will default to quirks mode, and their interpretation of styles will be different. This way, you can minimize the different CSS interpretations of your page.
Second, I'll point out that IE (the big offender, in my experience) supports conditional comments, so you can include styles for specific IE versions like this:
<!--[if lt IE 8]>
<link rel="stylesheet" href="iehacks.css" type="text/css" />
<![endif]-->
All browsers are different. Every
browser interprets the CSS rules
diferent, which drives to different
results. Some times the results are
good other times and much often
results are totaly unexpected. The
case of IE can lead to the worst
scenario possible!
You should be able provide the exact same CSS to all browsers (I'm talking about CSS 2.1 here) and get consistent display, with the exception of IE6 and IE7 (and that's because they have too many bugs).
For those browsers, a common practise is to include a new stylesheet using conditional comments with specific fixes:
<link href="forAllBrowers.css" rel="stylesheet" type="text/css" />
<!--[if IE 7]><link href="ie7.css" rel="stylesheet" type="text/css" /><![endif]-->
<!--[if IE 6]><link href="ie6.css" rel="stylesheet" type="text/css" /><![endif]-->
The other scenario is when you're willingly using things that are only available in newer browsers.
In those cases, it's a good idea to use Modernizr to detect support for the shiny new feature you're using.
That way, you can provide a sane fallback for browsers which do not support the feature.
For singling out IE, particularly IE7 and 6 you can use conditional comments to load IE specific styles and or stylesheets.
Most bugs do have viable workarounds. Well formed and standards compliant html/css should display properly in all modern browsers.
IE Conditional Styles can help you work around imperfections in Internet Explorer.
Excluding JavaScript, there's basically two solutions to this problem. You can mix and match both.
The first solution is to determine the user's browser based on the header in the HTTP request. (Different platforms will allow you to do this in different ways - for example in ASP.NET, the Request object contains this information). You can then serve different physical CSS files depending on the user's browser.
The second way is to use a single CSS file that contains different rules for different browsers. The right rules are applied to the right browsers using various browser-specific hacks. Effectively, this means using CSS rules that only certain browsers understand. More information on this technique can be found here.
Well, for inline CSS, you can do specific hacks such as:
.myclass {
height: 100px; /* all browsers */
#height: 100px; /* MSIE browsers */
_height: 100px; /* MSIE >= v6.0 */
}
Alternatively, you can use comment style conditions within the page and include optional style sheets:
<!--[if gt IE 5]>
<style type="text/css">
.mystyle { height: 100px; }
</style>
<![endif]-->
Actually all current, modern browsers interpret CSS very similarly based on the standards. It's usally only IE (6, 7, 8) that make problems, especially if your HTML documents don't trigger Standards-Mode, thus:
Write your pages based on current HTML and CSS standards with a DOCTYPE.
For support of older IE, give them separate style sheets using Conditional Comments.
If there are differences between other browsers, there are usually workarounds. Ask abotu specific problems here or in your favorite CSS forum/group/list.
Just one word: Modernizr.
You should never change the styles based on user's browser, but based on the browser's resource allowed or not.
Related
I've been curious for a while with this now.
The css3 properties are not yet standardized, yet can be implemented by browsers, using a prefix for the particular browser.
For example, border-radius can be used, and it works fine on modern browsers. However, for previous versions of the browser vendors, we can use the vendor specific properties like -moz, -webkit, etc. prefixes to work.
Now, for my page, I have used gradients and border-radius, made a couple of classes that use them and applied these classes throught.
Which of the following is better to do?
Using javascript to find whether the support is there, and use the properties if they are supported, if above is false, check the user agent and apply vendor specific properties accordingly.
Using all the browser prefixes in the classes and let the browser use whichever suits it.
What I am curious and concerned about, is the performance and time for DOM loading.
Which of the following is better to do?
Using javascript to find whether the support is there, and use the properties if they are supported, if above is false, check the user agent and apply vendor specific properties accordingly.
Using all the browser prefixes in the classes and let the browser use whichever suits it.
Option 1 consists of using JavaScript to detect support, then conditionally writing out the CSS code with or without the prefixes and letting the browser apply the styles.
Option 2 consists of simply using CSS and relying on the browser to ignore prefixes/declarations it doesn’t understand.
As you can see, option 1 introduces an extra layer (JavaScript) which is not necessary if you just want to use some CSS3 features where possible. Option 2 will be the most performant solution.
As always with this kind of question, the answer is - it depends. It depends on which prefixes you're using, how often they occur in the HTML, which browser you're testing against, etc.
The solution is to write the code, profile it, and find out. Very often, you will find that the performance is acceptable either way.
I use option 2 - add all the browser prefixes (as well as the non-prefixed version) to the CSS:
-webkit-border-radius: 10px;
-moz-border-radius: 10px;
border-radius: 10px;
Browsers will skip declarations they don't understand without any problems (although your CSS won't validate) while still applying the styles. It's probably best to use a CSS generator to avoid having to type out every prefix.
You should avoid using Javscript to detect CSS features since this breaks separation of concerns - CSS is for presentation and Javascript is for behaviour.
Where do I place this script in my HTML for it to work? And what changes do I have to make to it?
<script type="text/javascript">
var browser=navigator.appName;
if(browser="Microsoft Internet Explorer")
{
document.getElementById("html").innerHTML="\
<body><p>Your browser is IE.</p></body>";
}
</script>
Could I make a slightly alternate suggestion, skipping the spoofable UA string, and using a Microsoft-implemented (and standards-compliant) strategy:
<!--[if ie]>
<script type="text/javascript">
document.getElementyId("html").innerHTML = "<body><p>Your browser is IE.</p></body>";
</script>
<![endif]-->
To use this put it in the head of the document. I don't think it can be placed inside script tags (since it's based on html comment syntax, not JavaScript).
This uses conditional comments (Quirksmode.org link).
If at all possible, I would suggest avoiding direct browser detection.
Almost every case where someone wants to detect a specific browser (usually IE), it is because there is a particular feature that they want to use which isn't available in that browser, or has bugs.
But browser detection fails as a strategy here for a number of reasons:
You don't know whether a future version of that browser may correct the problem, in which case your code to fix the issue may itself cause problems.
If another browser also has a problem with that feature, you would have to detect that browser as well. Taken to the logical extreme, since no two browsers have exactly the same set of features, you end up having to detect every possible combination of browser, version and operating system.
Browser detection is virtually impossible to guarantee to be accurate. Most browser detection scripts are based on hacks that trigger quirks that only affect a particular browser, and most are pretty un-reliable.
Even just IE detecting isn't good enough. There is a big difference between IE6, IE7 and IE8. And IE9 is just around the corner, which will be massively different again.
So what should you do instead of browser detection?
Detect the feature. There are a number of ways of doing this, but the best solution I know of is a script called Modernizr. Place this script in your site, and your page will be given a bunch of CSS classes and Javascript properties which you can use to determine whether a given feature is available or not.For example, if you want to use gradients on your site, most browsers can use CSS for this, but IE and older versions of other browsers cannot. For these browsers you easily can use a background image instead. Modernizr will give you a CSS class of either cssgradients or no-cssgradients, and you can style these two classes accordingly.
Add the missing features to the browser. This is more tricky, but for certain features it can be done, particularly for IE. A good example is CSS3Pie which is a hack that allows IE to use the CSS border-radius feature (and one or two other features too) which is available in all other browsers. There are whole range of other little scripts like this which can improve the functionality of IE.
Use a library like JQuery which does all this work for you. With JQuery, you can be much more confident that most of your Javascript code is going to work across all browsers.
If you must use browser detection to tell if the user is running IE (and I accept that there are some occasions when it is necessary), then use conditional comments, as per #David Thomas's answer. But do so sparingly, after considering any other ways around it.
if(browser=="Microsoft Internet Explorer")
== for comparison, = for assignment
Place it in the head tags.
i have built a beautiful website that works very fast in all of the latest browsers but many of the users are forced to use ie6. If i can't get around this problem. Is there anything to do to optimize some of the inefficiencies of ie6 when building my site to lessen the pain.? its an asp.net mvc site with heavy use of jquery.
You don't mention any specific issues with the site, but you can pass scripts, styles, even content just to IE6 by using conditional comments.
<!--[if IE 6]>
IE6 only stuff goes here
<![endif]-->
Apart from that, learn the many, many quirks of IE6 and the fixes for these problems. There is certainly plenty of resources on this out there, we've had to deal with it for quite some time!
If you need help with something specific, perhaps edit your question with further details.
Retroactively, i don't know if there's an exact answer other than troubleshooting the problems one at a time. The correct way would be to code proactively for all browsers until IE6 is finally put to rest as it should be :)
jQuery works pretty well with IE6, so you should be ok on that front. You will most likely run into some CSS quirks, but once you learn what to avoid it's really not bad coding for IE6. The main thing I keep running into is when you float something, you always need to put a display type of relative or absolute on it otherwise it will just disappear from the screen in many cases.
First of all, it should be considered in the beginning of a project whether IE6 needs to be supported or not. Designing for it requires a bit different approach - some things just tend to break down. My advice is you should probably make the experience on IE6 only "sufficient" and just make sure the site can be used as intended. Making it look flashy is just not going to work with any reasonable amount of effort.
Is Chrome frame an option? It could be positioned as a something similar to java which less people have a problem with.
http://code.google.com/chrome/chromeframe/
If I'm already using Dean Edwards's IE7.js for IE6 then do i need to use Whatever:Hover htc and javascript(which we use only for IE6 hover) for Son of Suckerfish menu
Well according to the feature list, IE7.js adds support for the :hover pseudo-selector for all elements in IE6. This means that Whatever:Hover htc is not needed since it provides the same type of functionality.
As far is whether you'll need too keep the Suckerfish JavaScript for your CSS menus or not, I don't know. However, since all of the features needed for CSS menus to work are included with IE7.js, I don't think it would be necessary.
Your best option would be to remove those 2 scripts from your site and see what happens.
There are so many edge cases that eventually these scripts designed to pick up the slack for IE6 will miss some small area that was somehow missed. You'll need to do good QA no matter what option you go with. If you use just IE7.js, at least it will be easy to narrow down bugs to 1 JavaScript file, rather than 2-3.
I am looking at the custom attributes feature of html 5 here at this link
http://ejohn.org/blog/html-5-data-attributes/
This look like the perfect thing for when I am using jquery/javascript.
My question, Is HTML 5 supported by all the main browsers?
example
<li class="user" data-name="John Resig" data-city="Boston"
data-lang="js" data-food="Bacon">
<b>John says:</b> <span>Hello, how are you?</span>
</li>
Various portions of HTML5 are supported by the different browsers, for various definitions of 'supported'.
Several parts work right now, reliably. The data-* attributes you ask about in your question work just fine in every browser, even IE6; however, nobody yet supports the fun "dataset" method to access them. As long as you're fine with just grabbing them by the full attr name, you're golden. I use them to store state all the time in my webapps, as they're the officially blessed method for doing so.
Wikipedia has a good summary of the various support levels across browsers: http://en.wikipedia.org/wiki/Comparison_of_layout_engines_(HTML_5)
Parts of HTML 5 are supported by Safari, Firefox and Opera, but they are not necessarily incorporating the same parts.
It seems that Firefox is the most ahead, from my experience, but it will be years before the majority of browsers users use will support it.
So, until then we will need to continue trying to use it when we can, in browsers that support the new features, and having workarounds for users that haven't updated yet, or continue to use IE.
Use some services like
http://caniuse.com/
For example for your question - http://caniuse.com/dataset
As you can see all modern browsers support it
Also you can use something like http://modernizr.com/ in your code (it's already included in http://html5boilerplate.com/)
PS: just notified that this question is too old, but it was linked to some other question i checked before
No.
The Wikipedia page "Comparison of layout engines (HTML 5)" does a good job of listing which engines have implemented which parts of HTML5.
There is currently a lot of red boxes on those tables, and that is based on the latest development version, not the version most users will be using.
Full support of HTML 5 is a way off BUT...
Creating custom attributes is nothing new and is likely to work in all the main browsers - but test to be sure that it will work in your case.
We can use HTML 5 now, just not all of it. A lot of HTML 5 is about formalising the way that HTML is currently used and ensuring backwards compatibility - so if a feature works in browsers now, use it.
Almost no web technology is completely supported by any browser; no bugs, quirks or issues.
HTML5 is designed for backwards compatibility, and it will hardly break your site (take <input type=url> for instance - non-supporting browsers show an ordinary text box, Opera lets you select an URL from history/bookmarks). I'd go by the approach: develop, try in the browsers you need to support - if it works, awesome. If not, don't use it. Just like with other specs.
HTML5 isn't even close to being completely supported on any browser yet, and some browsers (notably the IE's) have no intention of supporting it at this time.
no, not yet. wait at least until gecko and webkit support it.
ps: you could use html 5 with data attributes anyway, if you need it for javascript purposes. or choose some other unused attributes (title, abbr, ...others?)
As of August 25, HTML 5 is still a working draft.
http://dev.w3.org/html5/spec/Overview.html