Site Navigation

Thursday, September 27, 2007

Apple Safari on Windows

Apple Safari on Windows:

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!

Tuesday, September 25, 2007

bug 204 - getElementsByTagName doesn't always work in IE

Issue: #204
Affects: (IE6 unconfirmed), IE7, IE8 Beta 1, IE8 Beta 2, IE8 PR1, IE8 RC1

{element}.getElementsByTagName('*');

Should return all child elements, regardless of nodeName, however it fails under the following scenarios.

Example:

<object id="myObj">
<param name="foo" value="37"/>
<param name="bar" value="75"/>
<param name="baz" value="99"/>
</object>
<script type="text/javascript">
var objTag = document.getElementById('myObj');
alert(objTag.getElementsByTagName('*').length);
</script>


The alert, should indicate a length of 3 child elements, but in IE7 it returns 0 (zero). This bug only occurs with an object element, and child param elements.


Known Workarounds: One. You will need to query specifically for 'param' tag elements.

Example Workaround Code:

<object id="myObj">
<param name="foo" value="37"/>
<param name="bar" value="75"/>
<param name="baz" value="99"/>
</object>
<script type="text/javascript">
var objTag = document.getElementById('myObj');
alert(objTag.getElementsByTagName('param').length);
</script>



Related Issues: None.

bug 237 - type is a readonly attribute in IE

Issue: #237
Affects: IE5, IE5.5, IE6, IE7, IE8, IE9 PP4
MSIE Feedback ID: 332453
Status: Microsoft has confirmed this will NOT be fixed in IE8 RTM
Partially Fixed In: IE9 Platform Preview 6 (only when rendering in IE9 Standards Document Mode)

Update: There are partial fixes for this in IE9 Platform Preview 4. For example you can change an input element from text to hidden and back to text and it works. However changing any input type to a password, then back to any other type deletes the value attribute contents (e.g. erases the set value)

In a world of Web 2.0 shininess, being able to work your JavaScript-Foo on the DOM is critical. A typical, yet simple example of this, would be to change an input type="text" element on a form, to a type="hidden" field, or visa versa.

Example:

<input type="text" id="userid" value=""/>
<script type="text/javascript">
var userIDField = document.getElementById('userid');
var userID = userIDField .value;
//do some fancy ajax stuff...
userIDField.setAttribute('type', 'hidden');
</script>


In a DOM compliant browser, this is a piece of cake. However in IE (msdn article), the type attribute is read-only... except for a small window of time before you add an element to the DOM (e.g. if you are using createElement() )


Known Workarounds: None. If you copy all the information for a given node, into JS variables, then remove the existing element, and create a brand new one in its place, then you are set.

However the sheer complexity of this task makes it rather troublesome even to attempt. Keep in mind, any workaround should handle all attributes set on the element, including custom attributes and attributes in specialized namespaces. Also remember that any event handlers attached to the element need to be copied over to the new element. If you think you have an ideal workaround, drop us a line!


Related Issues: (bug 242).

bug 154 - getElementById is NOT case sensitive in IE

Issue: #154
Affects: IE6, IE7
Fixed In: IE8

MSIE Feedback ID: 333979

"Just when you thought it was safe to go back in the water"! (credit to JAWS the movie) IE's getElementById( id ) throws another curve ball!

Although it should be according to the (spec), IE performs a case-insensitive search for IDs. This isn't likely as bad as (bug 152), but still a concern, if you have 2 IDs with different cases.

Example:

<form id="userInfo">
<input id="userid" value="grovermonster"/>
<input id="userfirst" value="Grover"/>
<input id="userlast" value="Monster"/>
<textarea id="userinfo">
Cute and cuddly and Blue!
</textarea>
<form>
<script type="text/javascript">
var infoForUser = document.getElementById('userinfo').value;
alert('Info for this user:\n\n' + infoForUser);
</script>


In IE, this won't return the "Cute and cuddly and Blue!" line you would expect. Instead, IE tries to return the value of the form itself.


Known Workarounds: One. Use the fix for (bug 152)


Related Issues: (bug 152).

bug 162 - global namespace pollution in IE

Issue: #162
Affects: IE5, IE5.5, IE6, IE7

Every element on a page in IE with an ID or a NAME creates (cough, pollutes!) the global JavaScript namespace. Not only is this bad practice, but it is highly prone to errors down the road.

Example:

<div id="myfoo"></div>
<div id="mybar"></div>
.
.
.
<script type="text/javascript">
myfooStr = 'Hello World';
myfoo = document.getElementById('myfoo');
myfoo.innerHTML = myfooStr;
</script>


In IE, the above code will cause errors... in any other browser it will simply set the content of the div to "Hello World". Why an error? Well since IE creates a global variable in the JavaScript namespace for each element on the page, with an ID, before the script even executes, myfoo is already defined. In the script, attempting to reference it to something (even in this case the same element), IE throws a script error.


Known Workarounds: One. Watch the scope of variables. (e.g. use 'var', inside functions to keep the scope local)

Example Workaround Code:

<div id="myfoo"></div>
<div id="mybar"></div>
.
.
.
<script type="text/javascript">
function doStuff(){
var myfooStr = 'Hello World';
var myfoo = document.getElementById('myfoo');
myfoo.innerHTML = myfooStr;
}
</script>



Related Issues: None.

Sunday, September 16, 2007

bug 116 - for attribute woes in IE6

Issue: #116
Affects: IE6
Trackers:MSKB Tracker: 314279


The for attribute on a label element will give focus to the related form option, and in the case of radio/checkbox elements, it will select/unselect them. However in IE6, a label with a for attribute linked to a select list will cause a re-selection of the first option instead of just giving focus.

Example:

<label for="colorOptions">Color:</label>
<select name="color" id="colorOptions">
<option value="1">Blue</option>
<option value="2">Green</option>
<option value="3" selected="selected">Red</option>
</select>





Clicking on "Color:" should put focus on the selected value "Red" in the select box. However IE6 will give it focus, but select another option, in this case "Blue".


Known Workarounds: One. IE has a proprietary event called "onfocusin" if you attach code to this, you can reset the correct value. However most advise that you try to avoid using the label element for a select list with a pre-selected value in IE6.

Example Workaround Code:
See MSKB Article: #314279


Related Issues: None.

Saturday, September 15, 2007

bug 223 - Magical HTTP Get Requests in IE6

Issue: #223
Affects: IE6 (& possibly earlier)
Fixed in: IE7

In IE6, it is possible to send an HTTP Get Request, without using ActiveX, XMLHTTPRequests, AND not have the user know that a request was sent, nor return a rendered response to the user! Welcome to "Magical HTTP Get Requests"!

The trick, is the result of a bug. There should be a visual clue that the request was sent, and also a rendered response.

So what do you need to make these "magical" requests?


  1. A hyperlink with an onclick attribute that calls...

  2. A JavaScript function that sets the location.href value...

  3. and an href attribute with a javascript: protocol value that does nothing



Example:

<script type="text/javascript>
function doThis(){
//do any logic you want... then try to go somewhere...
if(confirm('Do you want to silently go to a Naughty site?')){
//go there, silently!
document.location.href = 'http://www.someNaughtyUrl.com/';
}
}
</script>
<p>Click the following link in IE6. You won't go anywhere... visually, but you will send an HTTP Request!
<p>
<a href="javascript:;" onclick="doThis();">Magic Request</a>


If you try this out, you won't see IE6 leave the page you are on. In fact, you won't even see the throbber spin! Best of all, you won't even see the page in your History! but then again, you won't even see the page!

So you might wonder when you would ever encounter such a scenario? Very simple. If you want your link to be properly styled as a link using CSS, you need the href attribute, or it won't look right, show the right pointer cursor, animate on hover, or be tab-able via the keyboard etc. However, you may need to get confirmation before continuing (e.g. "do you want to save your changes?"), other JavaScript logic, or simply create an un-cancel-able request (see web design sidenote #3).


Known Workarounds: One. Change the href link to not include the javascript: protocol.

Example Workaround Code:
Use the hash anchor naming option. If you use a non-existent value, then the browser won't scroll either! ;-)

<a href="#none" onclick="doThis();">This works</a>



Related Issues: None. This issue is also fixed in IE7.