Issue: #333 Affects: IE8 Beta 1 - IE8 RTM? StatusTo be Fixed in: IE8 RTM (not the CSS3 opacity... likely a return to filter:alpha()) MSIE Feedback ID: 331735
According to blogs around the 'Net and the IE Feedback site Microsoft has dropped all support for CSS opacity in IE8.
This includes the CSS3 property:
opacity: 0.25; AND filter:alpha(opacity=25);
Apparently this is "By Design". As a developer I seriously hope they reconsider this. The filter hack wasn't the best, but no method to set opacity is certainly not "innovation".
In our last poll, we asked if you felt that IE8 would fix their DOM Support? The poll was live long before the IE8 Beta 1 came out and thus nothing was known about the new version since Microsoft isn't very forthcoming with sharing a road map with developers.
Regardless, the mood of the development community was reflected in the results that came in before the beta release, and was only slightly different after developers got some first hand experiences.
Results: Yes Completely - 4% Not A Thing - 16% Minor Fixes Only - 15% Mostly Fixed - 3% Fix Some, Break Some - 30% I Don't Care Anymore - 5% Don't Make Me Laugh - 27%
To be honest, most were taken back by Microsoft's commitment towards standards, and actually taking the (correct) brave step to render in Standards Mode by default.
Many of the long standing bugs DOM Bugs were fixed, although there were many that didn't see any attention at all. New features were added, but the overall UI was hardly improved upon at all (from legacy chrome/usability bugs, to the un-movable toolbar issues).
If history of IE7 development is to repeat itself, expect a few more betas for IE8, then an RC (Release Candidate), and a final RTM (Release To Market) date sometime late in Q4, 2008 or Q1, 2009 if they continue to fix ignored issues.
As noted here day 1, we promised to link into the public bug tracking systems for each browser, when and where they became available (and we certainly have done so - if you find a bug listed here that doesn't reference the IE Feedback bug number, please let us know!). When IE8 Beta 1 was released, Microsoft re-opened their "IE Feedback" site at Microsoft Connect, so that developers could view and track bugs with input from Microsoft. It isn't a full public bug tracking site, but it has been dearly missed since it was dismantled after the IE7 release, in fact one of the reasons that this Blog started! ;-)
We wish the IE Team the best of luck on shipping IE8 with great DOM Support to an eager developer base, lets just hope we can close a bunch more issues before it is shipped out the door!
What!? you say? "They added this in IE7!" - Well yes, no, not quite!
Microsoft did add a non-ActiveX version of XMLHttpRequest ("XHR") so that if a user had turned off ActiveX for security reasons, AJAX would still work (this was a good thing).
However there is a key feature of JavaScript Objects that makes them so useful is that you can Prototype on them to add properties, methods, expando properties, or even subclasses. In addition it doesn't extend from Object, thus any prototyping done there won't be available on XHR, and none of the methods on XHR are exposed.
In IE6, the XHR Object was an ActiveX control only, in IE7 they added a "native" one, but it was just access to the XHR Object that didn't require ActiveX. In IE8 Beta 1 there are no changes, but In IE8 RTM, will we see a true native XMLHTTPRequest Object?
Example:
Lets say you wanted to improve the user experience when an AJAX request is sent to the server.
You might want to set a timeout that a response is expected by, and if it isn't cleared, automatically call an error handler.
You might want to queue up/discard duplicate requests if the browser has already sent a request in, and is waiting for a response.
You might want to add some debug capabilities to trace the progress of your AJAX Requests
Since an AJAX request might be very expensive on your server, you might want to add the ability to pass in a "cancellation" request, that is "tied" to the original request... this way if the user closes a window, or runs another query, you could send a quick "one-way" request to the server to cancel the first request.
In any of these cases, being able to store applicable info on the XHR object is ideal, and adding methods would enable callbacks to be self-contained.
<script type="text/javascript"> var myXHR = new XMLHttpRequest(); myXHR.lastAccess = null; myXHR.requestTimeout = 15000; myXHR.requestTimeoutHandler = myTimoutHandler; </script>
The above will fail in IE, since expando's and prototypes are not an option.
Want to see what Properties/Methods are exposed on XMLHttpRequest in your browser? Click the button to find out! (check in other browsers too)
(PS If you subscribe to this Blog via RSS/Atom, please try the button on the Blog site as we needed to update the sample several times to overcome some Blogger auto-line-break issues. - thanks)
The #1 rule in OOP (Object Oriented Programing) is that you don't prototype on native objects. This is why many developers do not like the Prototype.js and similar JS Libraries, and where designing for expected behavior of objects is key.
Lets say you want to subclass the Array object, so that you can enjoy using an .each() method on an Array, in browsers before Firefox 3 etc.
No problem, just add this:
Example:
<script type="text/javascript"> XArray = function(){ //define your "class" }; MyArray.prototype = new Array; //now add your method... MyArray.prototype.each = function(ref){ //do your magic... } </script>
This will work perfectly fine in all browsers, except IE. IE will not update the MyArray instances properly to return the correct length when requested. This of course is rather catastrophic, as it is the only way to know how "big" the array is when iterating over it!
Curious as to why it doesn't work? Well the folks at Microsoft's JScript team let the cat out of the bag and it turns out, that internally it isn't an Array, but rather a HashTable, thus explaining why the performance (pre IE8) was horribly slow, and sub classing just wasn't an option.
Known Workarounds: None. Well, this isn't entirely true. If you "steal" an array from another frame, you can cater it to your needs, but it gets quite involved and it still isn't a true sublass (e.g. you can't re-subclass it) See Dean Edwards Blog post here for more info.
Issue: #329 Affects: IE8 Beta 1 Also Affects: IE6, IE7
The setAttribute() method was reported fixed in IE8 (whitepaper Pg.5), however some tests have indicated otherwise.
In particular, attempting to set the 'style' attribute on an element in IE8 Beta 1 still fails as it did in IE6, & IE7.
Please note that for any IE8 related bugs, all tests are done in "IE8 Standards Mode".
Example:
<script type="text/javascript"> var obj = document.getElementById('myObj'); //the following call will fail in IE8 Beta 1 obj.setAttribute('style','border:2px solid #ff0000;color:#00ff00;'); </script>
Known Workarounds: One. Although you can set: obj.style.setAttribute('cssText','...'); as outlined in (bug 245) IE8 was supposed to fix this, thus this is not an ideal workaround.
Microsoft is well underway with development of their new Web Browser Internet Explorer 8. As development moves ahead into the Alpha/Beta testing stages this post will attempt to condense the knowns and the unknowns to give you a better idea of what to expect in IE8.
The button element in HTML, just like an input element (of type button) is designed (by spec) to submit the contents of the value attribute when it is pressed to submit a form. However in Internet Explorer, this functionality is broken as it submits the innerHTML of the button element rather than the contents of the value attribute.
If a user clicked this button, the server should get a parameter called "doAction" with a value of "true_content". IE on the other hand, will return the same parameter, with the value ' <span style="font-weight:bold;">Please</span> click <em>Me</em>!'.
Known Workarounds: None. See MSDN for the latest news on when the button element will be fixed.
The ECMAScript specification for the DOM provides a set list of element types or nodeTypes... Text Elements, Node Elements, Comments, etc. They are numbered integers, with a Constant defined for easy to read comparison purposes. The only problem is, that they are not Constants at all, in IE or Opera.
NodeTypes:
interface Node { // NodeType const unsigned short ELEMENT_NODE = 1; const unsigned short ATTRIBUTE_NODE = 2; const unsigned short TEXT_NODE = 3; const unsigned short CDATA_SECTION_NODE = 4; const unsigned short ENTITY_REFERENCE_NODE = 5; const unsigned short ENTITY_NODE = 6; const unsigned short PROCESSING_INSTRUCTION_NODE = 7; const unsigned short COMMENT_NODE = 8; const unsigned short DOCUMENT_NODE = 9; const unsigned short DOCUMENT_TYPE_NODE = 10; const unsigned short DOCUMENT_FRAGMENT_NODE = 11; const unsigned short NOTATION_NODE = 12; //... }
Example:
<script type="text/javascript"> var obj = document.getElementById('someID'); var textContent []; for(var i=0;i<obj.childNodes.length;i++){ if(obj.childNodes.item(i).nodeType == TEXT_NODE){ textContent.push( obj.childNodes.item(i) ); } } alert('The inner text without HTML tags is: ' + textContent.join(', ')); </script>
In a spec compliant browser, the code should be able to test against the TEXT_NODE constant.
Known Workarounds: One. It is extra processing, but each element type can be defined as globals at the begining of every page.
For those familiar with the MacOS platform, Safari is likely your native tongue.
However Safari on Windows, is relatively new, and brings another great browser to the Windows world with all its shiny aqua goodness.
As a new browser on the Windows platform, it has some excellent features, and a few bugs that I'll point out below.
Features: 1.) It is Fast, blazing Fast! 2.) It has a built in JavaScript Console 3.) Built on the WebKit codebase (same as Konqueror), it is one of the most standards compliant browsers out there! 4.) Fancy shmancy form field highlighting 5.) Built in resizable textareas 6.) Built in bug submission. Right into the browser! Simply give some brief details (the url of the page you are on is sent automatically) and submit! All browsers could use this feature!
Bugs: 1.) It doesn't respond to the windows command [WinKey]+ M or [WinKey] + D to minimize all windows and display the desktop. 2.) You can only resize the window, by the bottom right corner, or double-clicking th e title bar.
If you haven't tried this browser out yet, I'd highly recommend it!
Opera is an interesting browser, that was first on the scene for many advanced features in the browser (tabs, zooming, security), but didn't gain a lot of traction because it was distributed on a "shareware"-like model when competing directly against IE. It's since been offered for free (since Firefox became very popular), and has had a significant increase in users.
Pros: Its fast, blazing fast! Has every feature you'll ever need Follows most spec items very well
Cons: Has a legacy of mimicking IE, including many of IE's bugs Doesn't allow [Tab] navigation of hyperlinks :-(
Drag/Right-Click and save to your Bookmarks
View generated source of a page in IE View Source
Show Rendering Mode for IE6/7 Render Mode
Show Rendering Mode for IE8 IE8 Render Mode
About Me
xyz
Web Developer - Dealing with the quirks and pains of Browser Bugs.
