Site Navigation

Monday, November 9, 2009

bug 225 - no support for TBody CSS height or overflow in IE in Quirks or Standards mode

Issue: #225
Affects: IE6, IE7, IE8

The beauty of CSS is that you can take a simple design and enhance it with a style sheet for aesthetics and usability.

A classic enhancement is to wrap table rows in a tbody element that will allow for vertical scrolling when they exceed a certain height.

All you need to do is set 2 or 3 CSS properties.

Example:

<style type="text/css">
tbody{
height:100px;
overflow-x:hidden;
overflow-y:auto;
}
</style>


This works great and thus makes the table headers always visible even when the user has scrolled to the bottom of the table.

However in IE there is a catch. If you don't have a DOCTYPE set and thus are rendering in Quirks Mode - IE decides that your tbody height isn't for the entire table contents but instead should be applied to every single row in your table! In fact IE6 & IE7 do the same thing in Standards Mode too. Only IE8 running in IE8 Standards Mode doesn't alter the TR row height.

Sample screenshot from Firefox:


Sample screenshot from IE8 in Quirks Mode (same result for IE6 and IE7 in Standards Mode):


Sample screenshot from IE8 in Standards Mode:


I'm not entirely sure how or why this implementation would have ever made it past an initial code check-in as it is obviously wrong, serves no useful purpose, and I fail to see how this could possibly be helpful to any developer or end user.

Of course this is really just one stumbling block on the way to another. Even if you do render in Standards Mode - IE still won't render the vertical scrollbar on your tbody nor restrict the height and thus you still can't improve the user experience for IE users.

If you do have a simple technique to make scrollable tables work in IE - please submit feedback indicating how. Outside of very complex hacks I haven't seen any that work in IE.



Known Workarounds: None. IE does not support CSS height, overflow, overflow-x, or overflow-y on a TBody element.



Related Issues: None.


Bug/Site Feedback |
Submit a bug

Thursday, October 29, 2009

bug 361 - Anchors collection in IE contains invalid members

Issue: #361
Affects: IE6, IE7, IE8

In the days before the DOM Methods we have today we only had access to a few special collections for things like forms, anchors, links, images, etc.

They may not be as sexy as document.getElementById(), but they worked, and still do to this day... and depending what you are trying to access may actually be much quicker and easier.

So to the point, the document.anchors collection contains an array of all the anchors defined in the page.

Anchors by definition are <a> tags with a name attribute specified.

Now for the bug.

As disclosed in (bug 152) IE has notoriously had issues with differentiating between id and name attributes, polluting IDs with NAMEs and vica versa.

Thus, if you have hyperlinks with an id attribute set in IE... you will now have a new member in the document.anchors collection even though there is no name attribute specified! Have lots of links with id attributes set? Then you have lots of extra items in your document.anchors collection.

Of course the interesting twist on this is that in modern browsers, any element (div, table, span, img) with an id attribute set can act "like" an anchor in that you can add it as a hash tag in the URL to auto-scroll to a specific spot however keep in mind that by definition only an <a> tag with a name attribute set is a valid element in the document.anchors collection.


Known Workarounds: None.



Related Issues: None.


Bug/Site Feedback |
Submit a bug

Monday, October 19, 2009

bug 234 - showModalDialog Array returnValue now fails

Issue: #234
Affects: IE6, IE7, IE8

We haven't discovered if this bug is exclusive to VBScript or if it affects JavaScript too (but feel free to update us in the comments if you know).

If you downloaded the latest IE Cumulative Security Update for October 2009 security patch, which "fixed" Microsoft Knowledge Base Article 974455 then you may have noticed that the showModalDialog documentation indicates that the window.returnValue accepts an Array.

However after updating KB974455, there was an undocumented change that now Array return values are no longer allowed.

So what can you do if you depend on this non-standard dialog? Well, the workaround is ugly but there hasn't been confirmation from Microsoft that this bug was introduced - nor that a fix is on the way.



Known Workarounds: One. Use something other than an Array and handle the return value accordingly.

Example Workaround Code:

On the Popup window:

<script type="text/vbscript">
//was
window.returnValue = arrayValue;

//now use
arrString = Join(arrayValue, ";");
window.returnValue = arrString;
</script>



On the Calling window (e.g. Opener):

<script type="text/vbscript">
//was
retArray = window.showModalDialog( ... );

//now use
tempRetArray = window.showModalDialog( ... );
retArray = Split(tempRetArray, ";");
</script>



Related Issues: None.



Bug/Site Feedback |
Submit a bug

Tuesday, September 1, 2009

bug 349 - you cant select a radio button in IE if it doesn't have a name

Issue: #349
Affects: IE6, IE7, IE8

This isn't a major bug since it has such a simple workaround but an odd one for sure.

In short it is really simple. If you add a radio button to your page that doesn't have a name attribute, you can't select it... even if it has an id attribute or even if you pair it up with a <label> tag it still won't select.

Example:

<input type="radio" id="foo"/> <label for="foo">Pick Me!</label>
<input type="radio" id="bar"/> <label for="bar">No Pick Me!</label>


Try it out!



If you are using a non-IE browser it should work just fine.


Known Workarounds: One. Add a name attribute and it works just fine in IE.


Related Issues: None.


Bug/Site Feedback |
Submit a bug

Saturday, August 22, 2009

Bug or Feature? - Round Five

Round Five Getting funky with the Cheez whiz!

Other rounds: [One|Two|Three|Four|Five]

We're back again with another round of "Bug or Feature?" highlighting a particular behavior in one or more browsers, that, well, could be a Bug, or it could be a Feature... we'll open up the comments for your vote and opinion.

Alright, what's today's "Bug or Feature"?

Synopsis:
Everyone knows the basic form elements [button|fieldset|input|textarea|select]. Within the [input] element there are several types: [button|checkbox|file|hidden|image|password|radio|reset|submit|text].

However there is a quirk/loophole/bug/feature with the <input> element that some browsers are taking advantage of.

By default, if you don't specify the type attribute, or specify a value that isn't recognized as one of the above types the browser should default to "text" (and every browser does) - however some browsers take advantage of certain key types and then render the field in their own special ways.

For example if you use: <input type="search" value="Keywords..."/> in Safari and Chrome it will render like this:



As you can see a little 'x' is provided automatically to allow users to clear the value with a mouse click.

If you don't specify a value Safari will provide a faded tip in the box indicating what the field is for:



Ok, what about other types? and other browsers?

For example if you use: <input type="email"/> in Opera it will render like this:



The little email icon helps identify the field as being a field expecting an email address as the input value and it also increases the default size of ~20 characters to ~25characters (depending on your font selection)

If you use: <input type="url"/> in Opera it will render like this:



Again Opera adds a little icon and increases the field size to ~28 characters.

Know of any other values for type that one or more browsers treat in a special way? If so, let us know!


So now the Question is...

Is this a Bug? Or a Feature?

Vote "Bug" or "Feature", and add your thoughts.



Update: 100 bonus points for Rafael! As noted in the comments below the "url" and "email" types that Opera rendered uniquely just happen to be 2 of the types specified in Web Forms 2.0 and they happened to be 2 of the less decorated fields. The full set of new field types is supported in Opera and they look and work great! We'll post some screen shots of these fields shortly.



Opera's Web Forms 2.0

Date:



DateTime (local):



DateTime:



Time:



Month:



Week:



Number:



Range: (numbers added for visual aid only)







Bug/Site Feedback |
Submit a bug

Monday, August 17, 2009

bug 231 - noscript elements render when script enabled in IE8 Standards Mode

Issue: #231
Affects: IE8 (Standards Mode)

The <noscript> tag serves 1 basic purpose and that is to provide content when scripting is turned off in the browser.

Years ago the main purpose was to provide alternative content so that your page still worked in browsers without script however these days due to better popup blocking and more interactive content scripting is typically turned on.

Thus the main use of the noscript tag today is to inform the user that JavaScript is turned off and that things won't work until it is turned back on.

[Fake] You need to turn on JavaScript to use the uber cool features on this page. [Fake]


However warnings like this would seem quite out of place when JavaScript is turned on so they are not rendered. Well except that IE8 (Standards Mode) does render the noscript tag container when JavaScript is turned on. This is a regression bug from IE6/7.

Example:

If you are viewing this page in IE8 Standards mode (you'll need to use the IE developer tools [F12] since blogger forces IE7 rendering mode) you will see the outline of noscript tags even when JavaScript is enabled.


Known Workarounds: One. Setting the noscript tag to be display:inline; vs display:block seems to make the container disappear.



Related Issues: None.

Bug/Site Feedback |
Submit a bug

Wednesday, August 12, 2009

bug 179 - .innerHTML love outside the body is hit and miss

Issue: #179
Affects: IE6, IE7, IE8, Safari 4, Chrome 2

As most developers know, setting the .innerHTML of an element is one of the fastest ways to dynamically set the content of an element. However there are a few issues when setting the .innerHTML on some elements in some browsers.

For example trying to set the .innerHTML on a [Table, THead, TFoot, TBody, TR] in IE it will fail as will trying to set it on a Select, Pre, or even a (Div with overflow:auto).

Thinking outside the <body> tag, there's a few more tags that you might want to set the .innerHTML on.

The <html>, <head>, <title> tags. Now we can argue that the title tag doesn't accept HTML, but well, we'll let the results speak for themselves.

<html>.innerHTML:
Firefox: Works
Internet Explorer: Fails
Safari: Works
Chrome: Works
Opera: Works

<head>.innerHTML:
Firefox: Works
Internet Explorer: Fails
Safari: Fails
Chrome: Fails
Opera: Works (Partially) resets the title but doesn't update styles or scripts

<title>.innerHTML:
Firefox: Works
Internet Explorer: Fails
Safari: Fails
Chrome: Fails
Opera: Works



Known Workarounds: Use DOM methods to update the content of various tags, and document.title to reset the title value. Just keep in mind that there are other bugs with setting the contents of the script tag, and style tag in IE.


Related Issues: None.


Bug/Site Feedback |
Submit a bug