I just wanted to get people's take on using the IE7 compatibility meta tag in IE8 to render pages via IE7 rather than IE8?
This topic doesn't seem to have been mentioned for a while, but with the relatively recent news that Microsoft will be implementing automatic updates for IE, this means that IE7 will be phased out soon.
Is it a really really bad move to use the IE7 compatibility tag in a site NOW? The reason being? rounded corners. I have a site which heavily depends on rounded corners, and so rather than using loads of Png's specific for IE, i would love to implement the DD_roundies technique, which seems to only work effectively in IE7, not IE8. (using parallels anyway, which i don't 100% trust).
What are your thoughts people?
Is it a really really bad move to use the IE7 compatibility tag in a site NOW?
Yes, it means your code is broken. Rather than using compatibility hacks, you should fix your code. It's a bug that it ever worked correctly in the first place.
Also, it's worth noting that the compatibility mode switch is there for the user, not for the programmer. The programmer has control over her code, and she can test and fix it to make sure that it works properly. The user can't do this, so he has to resort to hacks like compatibility mode.
...with the relatively recent news that Microsoft will be implementing automatic updates for IE, this means that IE7 will be phased out soon.
IE 7 has already been phased out. Automatic updates may help prod some users into making the leap, but there's no guarantee that it will make a difference for everyone. If you must target the broadest possible base, you'll still need to support IE 7 for a while longer.
And even if IE 7 does go away, IE 8 isn't going to go away for quite a while longer, considering that IE 9 is not supported on Windows XP. You'll need to make your code work in IE 8 then, so why not do it now?
Using IE7 mode means your code is broken. It will be harder to make it work in standard browsers, and of course as time goes on it will just get worse.
DD_Roundies is unsupported by its author and is considered dead. Leave it that way.
Use a more modern library for rounded corners, like CSS 3 Pie
Related
I'm working on adding basic print functionality to a web map application I recently built, and I can't seem to make the printing work properly when using Internet Explorer 8 in standards mode. I was hoping that someone with more CSS experience might be able to help.
I've created a basic example on jsbin that demonstrates what I'm seeing: http://jsbin.com/osepov/16. This example prints properly in most browsers. In Internet Explorer 8 in standards mode, however, the map's tile images run off of the first page and onto a second page when printing. I've tried a bunch of different CSS combinations, and have browsed the web for hours looking for hacks that might solve the problem. I've obviously had no luck thus far.
Being that the print functionality works well in most browsers, I am willing to compromise on a few things, if needed, to get this working in Internet Explorer 8 standards mode:
The map doesn't have to fill the entire page, minus the header. It can have a fixed height.
The header is nice to have, but I'm willing to do without it.
I know it is possible to build a PDF on the server, but I really want to do this with a simple print stylesheet.
Note: Yes, I do have to support IE 8 standards mode. I had a solution that kicked IE8 users to IE7 mode, but this was not acceptable to my client.
UPDATE 2: I was able to resolve the issue by bumping IE8 down to IE7 standards mode. The map is printing correctly now.
UPDATE: Nope, this didn't solve the problem. I'm still seeing the same issue. This seemed to work, but I'm still seeing the problem.
ORIGINAL POST: I think I figured this out. Basically, it seems like the "top" div was causing the entire page to get bumped down and run over to a second page when printing in Internet Explorer 8 standards mode. I'm not sure why this was just happening in IE8 and not in other browsers, but there are all sorts of strange IE-only bugs that I don't understand.
The final fix:
#wrapper {height:100%;left:0px;position:absolute;top:0px;width:100%;}
#top {height:70px;position:relative;width:100%;}
#main {height:785px;overflow:hidden;position:absolute;top:70px;width:100%;}
So positioning the "top" div relatively and assigning a pixel height and "overflow:hidden" to the "main" div seemed to solve the problem.
This isn't a perfect solution, but it meets my current requirements.
Here's the updated solution: http://jsbin.com/osepov/19.
I have several divs on a webpage that use the IE css filter to create a gradient effect for the background.
The page is viewed primarily in IE6 (I have no other choice unfortunatly) and displays fine on my development machine. I have also tried viewing the page using IETester and the page also displays fine in IE 5.5 to IE 8.
However, when viewing the page on the "live" machine, the gradients don't show up at all. The browser on the "live" machine is IE 6 with sp3. I have checked the div's and they all have "hasLayout" so that isn't the problem.
Are there any settings within IE that would stop filters working or could anybody suggest any other reasons why they would not be showing up. I can't work out why they work in one version of IE 6 but not another.
Unfortunatly I can't link to any examples.
Thanks
The filter features of IE are not built into the browser; they are using external libraries (DLLs). This is what the 'progid' part is all about, and also explains why some of them are so clunky.
If those DLLs are not installed on the client machine, then the filter styles won't work. If it works in some IE6 machines but not others, then this is almost certainly the problem you're encountering.
Theoretically it should be possible for you to fix the problem by installing the missing DLLs.
However, the problem for you is that if the client is anal enough not to have upgraded their browser from IE6 yet, then it's pretty certain that they're not going to want to have you fiddling around on their machines installing unknown (to them) libraries. In any case, you would have to do it for every individual machine.
The bottom line is that realistically this is not going to be an option. Your best bet is to give up trying to make IE6 do fancy stuff, and go back to using background images for your gradients. It's not pleasant to write, but there is a reason why everyone used to do it that way when IE6 was the standard browser.
I'm unsure which browser is the best for a web development. I know that Firefox is the most favoured for the common but it also does tolerate programming failures, so it is not 100% strict.
With what browser should I develop my website to have the best result on all other browsers, so I don't have to fix too much in the CSS?
From personal experience.
I use chrome. For me 100% fine on chrome is like 70% on IE, so I switch between the two a lot.
Chrome 100% = 98% FF , 99.9% Safari and 70% IE.
This is what I've noticed from my experience.
I personally use Chrome, as its built-in developer tools work great, and it has the widest HTML5 support. However, that's not necessarily a good thing because even if your website works 100% with the better browsers, it will probably break with IE.
If you need your website to work with IE, you should constantly test with it. Use the lowest common denominator.
At this point, all of the major browsers implement a lot of CSS3 features a little differently (box-shadow vs -moz-box-shadow vs -webkit-box-shadow for instance). Honestly, your best bet is to use IE, Opera, Firefox and Chrome (I'm pretty sure Safari and Chrome both run off of webkit, so they should be the same). As for what to use as your primary browser, it all depends on what you're looking for really. I enjoy using Chrome, but others swear by Firefox (I find it too clunky).
Now as for older browser support, well that's just an entirely different discussion ;)
Simple answer, all the major ones.
When you develop for the web it's best to think from the view point of the user viewing the site. The main issue is that each browser will render a webpage a little different and that is the main problem you need to solve.
To help with this issue, you'll need to work with some cross-browser rending web-apps such as http://browsershots.org/
To more directly answer your question, I'd go with Chrome with Firebug. Asides from that, you should be able to create CSS browser-compliant sites with practice.
Good luck!
Develop in the browser of YOUR choice with the best development tools for YOU (e.g. Firebug, FirePHP in FF or the Developer Tools for Chrome). Try to use standard, crossbrowser compatible framworks for JS, CSS and available templates for HTML like "Boilerplate" HTML 5. And then test everything continously on the mainstream browsers (IE, FF, Chrome, Opera, Safari).
This way you won't waste your time afterwards fixing browser specific bugs...
I prefer using Firefox, simply because there are so many useful tools for it - Firebug, Web Developer's Toolbar and so on - but really it doesn't matter as long as it's not Internet Explorer.
This is because IE has so many quirks that it's best to get it right in all other browsers, then worry about adding workarounds or other fixes to make it look right in IE (getting things right in IE can take a very long time).
With lots of talk and bickering among developers about how IE breaks standards, is it worth supporting mozilla and webkit CSS?
Examples
-moz-border-radius
-webkit-border-radius
Of course there are many more, but I just want to know everyone's thoughts.
Thanks
For IE, we were (are?) using proprietary features in order to eliminate rendering bugs. At least, in the case of FF and WebKit, we're using them to improve the design. It's progressive enhancement in this case. No one suffers if they have no border-radius feature, but we as developers get more satisfaction for using some CSS3 features. Our designs are more pleasing and W3C gets the feedback it needs in order to improve and then approve the CSS3 draft.
Rounded corners are proposed in the W3C CSS3 working draft. The proprietary extensions in Gecko and WebKit are already likely to conform to the working draft.
Given that rounded corners are purely aesthetic, there's no disadvantage to users with browsers who do not support rounded corners.
When the standard becomes final, it's a simple matter of replacing these proprietary rules with the standardised ones.
If you define -moz-border-radius and -webkit-border-radius, make sure and define -khtml-border-radius (Konqueror), -opera-border-radius, and plain old border-radius as well (for future-proofing purposes).
We tend to use the proprietary methods followed by the CSS3 spec version for when the method becomes more widley supported.
http://www.w3.org/TR/css3-background/#the-border-radius
If necessary (which isn't often) we use JQuery + IE conditional tags to render the same for IE.
http://malsup.com/jquery/corner/
http://www.quirksmode.org/css/condcom.html
It really all depends on your target audience, we wouldn't generally use unsupported CSS on a public facing site as 89% of our users are still using IE 6/7 so it would be useless to most of them.
We currently use it on a few admin systems and some internal systems; mostly to give the design team exposure to the new techniques.
Consider your target audience, browser specs based on analytic's and how necessary it really is first.
I'd support both, IE still has a big chunk of the user space, with Firefox and others (opera, safari etc..) occupying a smaller percentage of the browser market.
using mozilla only stuff might be ok if you can control what your clients are using, by recommending it in some way (if you're writing a web app. with a fixed user base) and even then someone will still insist on using IE.
I know its a pain in the backside supporting both, but I don't think web developers have much choice in the matter :(
In the case of border-radius, I'd say use the Mozilla/Webkit syntax if you don't mind IE/Opera users having squared corners.
If you need everyone to see the same thing, it's best to stick with the old techniques for now. Similarly, any non-universal CSS (say, using #font-face to download a custom symbol font) which is going to break the site for some people should stay out.
There's no harm in implementing CSS3 features so long as they degrade gracefully. So long as rounded corners, or what have you, aren't critical to your layout there's no harm having them there for the people who are running bleeding edge web browsers.
I know from personal experience that having those properties(specifically the corner radius ones) are very much a time-saver. Now of course it would be nice if css would just implement it into itself but right now I think that those properties are very helpful. I see no reason why we shouldn't support them. Mozilla's and Safari/Chrome's engines are just trying to make life a little easier.
I don't think this is a good practice. However you'd like that the site you're working on appears the same on every browser. That's why that's not a solution. It's not professional to have different layouts on different browser.
But if you don't care about that, or your application is based on only that browser - so it's completely fine!
I'm having major rendering issues in Safari with the web application I'm working on. Most of the design is done with divs using absolute positioning. This renders fine on Internet Explorer, Firefox, Chrome, Opera, Netscape, and konqueror. In Safari, it's just a jumbled mess.
Does Safari lack support for absolute positioning of div elements?
What is the best way to trouble shoot and find out what is going on with the safari browser?
UPDATE: I'd like to note I did find the issue, and I would like to thank everyone that gave suggestions. It was the WebKit's "Inspect Element" that gave the most useful information. It appears that their were conflicts with inline styles and styles from the CSS. While safari grabed the styles from the .css file, the rest of the browsers were using the inline styles. i was able to see those conflicts with the information in the tool that was suggested.
The problem may lie somewhere in your JavaScript; one of the most noticeable things about Safari is that it likes to stop executing JavaScript after any errors.
CSS is likely not the issue, since Safari has better standards and CSS support than any other browser out there (alright, I said it.)
Use the built-in Web Inspector in a recent nightly build of WebKit to track down your issues.
1. Safari's support?
Safari is actually a decent browser. If it has its flaws, they aren't any worse than those of any other browser, and they aren't of the class of the old IE browsers, which had very serious problems and lacked even basic support for web standards. To answer you question specifically, yes, it does support absolute positioning.
Safari can certainly render modern X/HTML CSS designs, and since your audience is largely using Safari anyway, you may as well forget the notion of dismissing the browser. It's a good browser, and in any case we're powerless to change it. We simply need to take care of these bugs, whatever they are.
2. How to go about debugging?
Without having a specific example, it's not something anyone can really help you to do. It seems fair to say that you're having some issues controlling css-based layouts. You may have some invalid markup, which in some cases could produce the kind of extreme browser-specific abnormalities you've described.
Start with the basics. Validate your markup and CSS.
Markup Validator
CSS Validator
Make sure you're rendering in standards mode.
Seek out answers to specific questions
If everything validates and you're still having problems, you'll have to track them down one by one. Even if you rebuild the page, piece by piece in Safari in order to see where things begin to unwind, it will be worth it to do. If during this process you really don't understand why a certain behavior exists, you'll at least have a specific question that you can use to poke around for answers. It may be answered already on SO, and if it isn't, you can ask it.