Items tagged ie8 in Jan
Filters: Month: Jan × ie8 × Sorted by date
Ehy IE8, I Can Has Some Clickjacking Protection? (via) IE8 has built-in protection against clickjacking, but it’s opt-in (with a custom HTTP header) and IE only. It turns out the usual defence against clickjacking (using framebusting JavaScript) doesn’t work in IE as it can be worked around with a security=“restricted” attribute on an iframe.
Sunsetting Quirks Mode. Apparently proper standards support in IE (or at least the IE8 renderer) will be triggered by the HTML5 doctype, providing an alternative to those who don’t wish to pollute their markup with an IE-specific meta tag.
Legacy. James Bennett has what I think is the most interesting analysis of the X-UA-Compatible header to date.
If Web authors actually use this feature, and if IE doesn't keep losing market share, then eventually this will cause serious problems for IE's competitors — instead of just having to contend with reverse-engineering IE's quirks mode and making the specs compatible with IE's standards mode, the other browser vendors are going to have to reverse engineer every major IE browser version, and end up implementing these same bug modes themselves.
HTML 5 published as W3C First Public Working Draft! A significant step, almost completely overlooked in the hubbub over IE8.
No matter what great leaps forward the Internet Explorer team make from now on, the majority of developers won’t use them and the majority of users won’t see them. By doing this the Internet Explorer team may have created their own backwater, shot themselves in the foot and left themselves for dead.
<META HTTP-EQUIV="X-BALL-CHAIN">. Mozilla hacker Robert O’Callahan discusses the technical implications of freezing copies of older rendering engines, including the increased footprint and the terrifying prospect of documents in different rendering modes communicating through iframes and the DOM.
Broken. Jeremy highlights the fly in the ointment: if you want IE 8 to behave like IE 8 (and not pretend to be IE 7), you HAVE to include the X-UA-Compatible header.
The versioning switch is not a browser detect. PPK: “In other words, the versioning switch does not have any of the negative effects of a browser detect.”
Like DOCTYPE switching did in 2000, version targeting negates the vendor argument that existing behaviors can't be changed for fear of breaking web sites. If IE8 botches its implementation of some CSS property or DOM method, the mistake can be fixed in IE9 without breaking sites developed in the IE8 era. This actually makes browser vendors more susceptible to pressure to fix their bugs, and less fearful of doing so.
Beyond DOCTYPE: Web Standards, Forward Compatibility, and IE8. This has huge implications for client-side web developers: IE 8 will include the ability to mark a page as “tested and compatible with the IE7 rendering engine” using an X-UA-Compatible HTTP header or http-equiv meta element. It’s already attracting a heated debate in the attached discussion.
IE7.js version 2.0 (beta). Dean Edwards has updated IE7, shifting enhancements that weren’t fixed by the real IE7 in to a new script called IE8. You can also now hotlink the library directly from Google’s servers, though I don’t know how intended Google Code’s subversion repository is for that purpose.