Oftentimes in the web development community, you hear people complaining about developing for IE6. However, if you are developing using a robust JavaScript framework like jQuery, is developing for IE6 any different than developing for IE7?
It can display alpha-channel PNGs correctly.
The calculations for box dimensions are not that far away from the standards.
Rendering and JavaScript performance actually allow you to do something fancy without freezing the users machine every now and then.
Some security issues have been addressed.
In relation to the other browsers, it shows no improvement at all because the others have made much bigger progress in the same time. It's still the worst of the major browsers and a pain in the b*tt for developers.
IE7 supports png transparency, which is a massive help in maintaining graphic resources for the site.
I'll add a few points which haven't been listed:
CSS width strictly adhered to: IE7 in standards compliance now mode strictly interprets width styles in CSS. In IE6, if you have a child element that has a width which is greater than the parent element, it would often ignore the width declaration of the parent and expand to fit the child, often requiring hacks of overflow: hidden to make sure the parent didn't expand.
This is mostly a good thing, but unfortunately introduces a number of other quirks, e.g. <table style="width: 100%"> in a scrolled DIV with CSS overflow set to overflow: auto or scroll will expand the table to the width of the scrolled DIV including the width of the vertical scrollbar so some of the table will be cut off by the scroll bar on the right.
Cleartype with DirectX filters disabled: IE7 disables cleartype (font smoothing on LCD monitors) for elements which have DirectX filters such as alpha transparency and gradients. This is good in some ways, as cleartype made elements with filters, especially bolded ones very blurry/fuzzy, but it's bad because it now renders the text blocky and aliased on LCDs.
IE7 I think also now supports alpha: 1.0 as well as filter: alpha(opacity=100)
SELECT z-index bug fixed: IE7 fixed a bug where the SELECT elements have infinite z-index and are always above other elements unless you put an IFRAME in between of the SELECT and the element you want to display above it. This is a problem for menus etc.
CSS pseudo-classes improvements: :hover and some other similar CSS states are now supported outside of hyperlinks.
Performance not necessarily improved: IE7 introduced many bugs in it's VML engine, and in IE8 VML is now 10x slower than in IE7 when in standards compliance mode, so it's not altogether good. In addition, I have test cases which show that finding offsetLeft and offsetTop in mouse events in standards compliance mode in IE7 can also be around 10x slower in my web app.
IE in quirks mode though it's about the same performance for VML and offsetLeft/Top throughout IE6, 7+8. My experience in IE7 standards compliance mode is it's actually much slower than standards compliance mode in IE6, though it is definitely much more compliant.
I think it's a bit of a double-edged sword though, as raw JavaScript performance did improve, so things like working with array methods and for loops did improve even though I think the rendering engine and many of the associated DOM methods became much slower in standards compliance mode in IE7+.
IMO, there is a world of difference between IE6 and IE7.
IE7 supports built-in XMLHTTP whereas in IE6 it requires an ActiveX control.
IE7 supports a couple of additional pseudo classes
IE7 fixed some of the problems with z-order and zoom.
IE7 fixed "a few" of the box model issues.
IE7 added support for > child selector
IE7 added support for adjacent (+) selectors
PNG transparency support
I think most of the improvements to IE7 was performance(javascript) based and trying to get closer to standards compliance for CSS.
Off the top of my head, these were some of the major improvements as I recall:
Fixed the double margins bug
Fixed numerous issues with the box model and positioning inheritance
Inclusion of Developer Toolbar into browser(not a bug fix, but big one for me)
As noted by others, proper PNG handling
It was a much better browser when comparing it to IE6, when you compare it to other browsers out today, not so much.
Hardly; in terms of IE7's gain in standards compliance, it's negligible. All of the versions of Internet Explorer up until today, including IE8, have horrible breaks in JavaScript, CSS and DOM implementation. Most of the hacks you use for IE6 still apply for later versions. However, on the bright side, IE9 is shaping up to be quite good, and big progress has been made (I've never thought I'd actually say that).
The gaps and differences in implementation between the spec, and other browsers like Firefox and Chrome are much smaller.
I'd recommend Mark Wilton-Jones's article on IE's numerous flaws for more info.
Javascript & CSS frameworks minimise the amount of damaged caused by IE6, but there is still a number of bugs & inconsistencies between IE6 and other browsers.
IE7 is better than IE6, but only just.
Personally, the most annoying thing about IE6 is its lack of PNG transparency. This results in requiring use of AlphaImageLoader for images. The implications of this is introduces its own bugs/inabilities. For instance transparent backgrounds using AlphaImageLoader can't repeat.
Also, there are bugs such as the double margin bug, lack of support for min-height and min-width, adding extra line breaks to floated elements, missing css selectors.
Related
I have been searching but have not come to an answer.
Is there a way to detect the event which OpenLayers enters FullScreen/exits FullScreen? In short, i need to toggle classes of some divs. I tried adding events to the buttons, but then it doesn't work if they press escape instead.
Thanks.
The comment suggesting using 'screenfull' is a good option for now. screenfull is just a wrapper that smooths out the cross browser implementation issues of the fairly new 'Fullscreen API'. Until the browsers have fully implemented the standards for these events, that little wrapper is a good way forward.
If you are just wanting to style things differently, there is a CSS pseudo selector for that - :fullscreen. No JavaScript required! You can read the documentation for it on MDN and there is also a great example. Take special note of the need for the vendor prefixes and the fact that some browsers say full-screen rather than the standard fullscreen. The various mix of selectors you'll need seem to currently be:
:-moz-full-screen - Gecko based browsers
:-ms-fullscreen - IE/Edge
:-webkit-full-screen - WebKit based browsers
:fullscreen - Standards compliant browsers
I've used pixels to determine the size of my fonts on a website. All the text resizes fine in Chrome, Firefox etc, using the zoom feature. However in IE7 (and IE6/8, I guess) the fonts don't resize using the Text Size menu, they just stay the same.
Now I'm thinking the only solution to this is switching to ems - but is there any solution I could write in JS to target / fix only IE?
Unless you know otherwise, assume that hardly anyone has IE7 or 6 anyway. IE8 has a zoom feature, so that's OK. On approximately 50 small business sites I have data for, in the last month 0.5% of visitors were using IE6, 4% had IE7 and 12% had IE8.
We don't support IE6 or 7, but we do test and check things look basically right there.
Assuming that you do want to allow this minor feature (assumedly people who need accessibility the most will not be using these notoriously inaccessible browsers!) in IE6 and 7, you do need to use ems rather than px, and you'll really need to use it for everything, not just font-size, as otherwise the boxes won't scale properly either.
in internet explorer 6 & 7 you cannot increase or decrease font-size that is set in pixel in your css.
For that to work you have to use EM's as font-size value.
Read this article
The following code works in all desktop browsers Chrome and Safari on the Desktop as well as recent iPhones and all Android devices I've tested. However, in first-generation iPhones and the iPhone 3G, the top left corner of the <img> is not rounded.
The other CSS I have for rounding corners (on <h1> elements) on the iPhone seems to work fine on these older devices. It's just the rounding for the <img> element that does not work.
Relevant Javascript:
var profilePhoto = document.createElement("img");
profilePhoto.setAttribute("src","http://example.com/photo.jpg");
profilePhoto.setAttribute("alt","");
profilePhoto.setAttribute("class","menu-first");
profilePhoto.setAttribute("style","float:left; border:0; padding:0!important; margin-top:0!important; -webkit-border-top-right-radius:0; -webkit-border-top-left-radius:.5em;");
document.getElementById('menu-container').appendChild(profilePhoto);
Relevant HTML:
<div id="menu-container"></div>
I am aware of the "rounded corners don't show up if the radius is greater than half the image height or width" issue, and that's not what is going on here. The radius is a tiny fraction of the image size.
JSFiddle: http://jsfiddle.net/RaK3T/
(Wow, JSFiddle actually works on iPhone 3G, that's awesome!)
UPDATE: I suppose it very well might be the iOS version that matters more than the phone model. It appears to work fine in iOS v4.3.2, but not in iOS v3.
It sounds like you're running into an issues in certain older browsers, whereby the border is drawn as a logical layer beneath the foreground image.
The effect is that the rounded borders are indeed drawn, but the foreground image is then placed on top of them, and is not clipped. This obviously only affects the <img> tag, since it's the only tag that has foreground images.
This issue was a big deal a few years ago. It afflicted some browsers but not others, but certainly for older versions of Firefox and most Webkit browsers, it was an issue.
The problem was quickly spotted and was fixed (somewhat quicker with Webkit than Firefox, if memory serves), and we all moved on.
But it is still an issue for web developers needing to support older versions of these browsers.
There are three workable solutions:
Use a background-image style instead of a foreground <img>.
Ignore the problem and let older browsers live with square corners (oh the horror!).
Use any one of the old-school rounded corner hacks that draw the corners in manually.
Personally my preference is for option 2, I appreciate it doesn't actually answer the question, but I don't have an issue with it: it's a cosmetic detail on old browsers; you wouldn't try to get this working on IE6, would you? (would you??).
If that isn't good enough for you then option 1 is the typical solution that most people went with at the time. But isn't good semantically, and has issues if you need to scale the image, etc.
And the less said about option 3, the better.
I have a graph made out of simple <div>s and I need to allow users to zoom in and out. It seems that the css zoom rule that fixes so many things in IE doesn't work well or sometimes at all in other browsers. Is there some kind of mechanism or library that I can easily allow visitors to zoom in and out of a <div> that contains many <div>s? I tried -moz-scale for firefox and all kinds of strange things happen as you zoom, z-indexes get out of what, things don't align so well, etc.
I'm happy to make zooming a feature where you're required to use a modern browser, but at least the latest versions of firefox, chrome and IE need to be supported. If there's an html5 feature, that's fine.
For Zooming I have used CSS3 Transforms (scale(1.2) for example). It works pretty well and is supported on IE9, Mozilla and Webkit.
How to put transition on a web page? I have tried, but it doesn't worked on internet explorer. how to add transition during opening page? transitions effects like fades,dissolves etc. same as in ppt's
If you are talking about CSS3 transitions/animations (CSS3Please.com demo here), be aware that IE is lacking in support for these almost entirely - it is unclear but unlikely that the new IE9 will have CSS3 transitions.
This is a good article written about CSS3 transitions/animations this week:
http://www.onextrapixel.com/2010/11/17/a-comprehensive-guide-to-css-3-transitions/.
Decide whether transitions are necessary for IE based on the demographics/browser preferences of your user base, and also knowing that IE users are far less likely to expect such transitions (because fewer developers make the effort). Unless it is truly critical that your site looks gorgeous in IE it's usually acceptable to make IE functional, while implementing transitions for the more advanced browsers.