Skip navigation.

miscoded

the web is a hack

Posts tagged with "ie"

my booking form is a secret

Saturday, 22. July 2006, 15:34:29

, , , ...

thomsonfly.com contains a hidden booking form. They don't seem to like bookings.

The reason? The booking form is within a table that is styled to be hidden:

<table class="fullwidth" id="hometable" style="clear: both; visibility:hidden;">


Another part of the code is hidden from non-IE browsers with conditional comments:

<!--[if IE ]>
<div id="loadMessage" style="position: absolute; z-index: 2; top:180px; background: url(/img/elements/anim_please_wait.gif) no-repeat center; width: 100%; text-align: center; height: 17px;" ></div>
<![endif]-->


..and there is some scripting that will remove the "loading" screen and show the search form if UA is IE. Naturally since the "loading" message is hidden with conditional comments, this:

(document.getElementById("loadMessage")).style.display = "none";


fails and stops the script before the table is un-hidden. Also obviously, they don't expect any booking visitors with JavaScript disabled, since then the form would simply never appear.

"Thomsonfly - the low fares airline that goes further to confuse you."

13 comments

IE's scrollHeight logic

Thursday, 5. January 2006, 06:13:23

, , , ...

Element dimension properties is such an unstandardised mess. Do not ask me to be your guide through this maze, but below is at least some documentation of how scrollHeight behaves in IE.

If element does not have "height" specified, scrollHeight returns height of element contents + padding + border (in other words exactly what offsetHeight does).

If height is specified scrollHeight returns height of element contents + padding only.

As for Opera, we seem to have some bugs. The problem with getting it right is that the scrollHeight beast is not in any standard, so we just have to try to do "what IE does" and discover through users reporting problems out there that we actually missed out half of the logic and ended up doing something entirely different and incompatible.

This is why standards are good for you.

What Opera does: scrollHeight returns border-top-width + padding-top + height of element contents (!). How did we get there? Including only half of the border and padding width - top but not bottom values?? I don't have a clue.

2 comments

when live dies and start stops - Opera's problems with the new MS site framework

Monday, 7. November 2005, 23:25:25

, , , ...

Readers will have noticed the news about the new Microsoft portals live.com and start.com not being very interesting pages in Opera. They don't, in fact, do anything at all...

The sites are based on the same set of JavaScript libraries. One of these files is meant to be a "compatibility layer" for non-IE browsers. It basically "emulates" Internet Explorer JScript features so that the rest of the libraries can use such features without worrying about sniffing or browser compatibility.

To emulate JScript in such detail the authors have stated that they need certain browser functionality. They use a Mozilla extension to the ECMAScript standard, the ability to define "getters" and "setters" for object properties. Opera does not support this functionality (mainly because it is non-standard - not in the ECMA specifications - and not widely used.)

On the other hand, Opera has worked hard on being compatible with many of IE's extensions.

The irony! Microsoft's script library basically tells Opera "sorry, but you've spent all those years implementing the wrong standards violations! If you had copied Mozilla's violations rather than IE's we might make live.com and start.com work for you"..


As an aside: if you who are reading this are a FireFox-lover and standards advocate, go ask the mozilla.org crew some serious questions about why it is considered OK to embrace-and-extend ECMAScript. Isn't this a standards violation by another name? Getters and setters are worse than FONT or document.all - there isn't even a backward-compatibility story here. One single getter or setter definition in an object literal and the whole JavaScript library is unusable in other browsers. And you claim you're writing a standards-compliant browser??

6 comments

IE's event transparency logic

Monday, 29. August 2005, 13:40:18

, , , ...

In IE you can sometimes click "through" an element and activate something that is underneath. We've been pondering for a while what the exact behaviour is (and so have the Mozilla devs).

After several test files and experiments, I think I've nailed it - here are IE's event transparency rules. If I have missed anything or you notice a scenario that isn't according to these rules please let me know.

General rules

IE considers an area of an element "transparent" if

a) the computed style of the "background-color" is "transparent"
AND
b) the computed style of "background-image" is "none"
AND
c) it is outside the inline boxes generated by element contents (not counting line-height)
AND
d) it is outside the element's borders (including invisible table borders)

OR

e) it is outside a CSS clip rectangle

OR

f) if "visibility" is "hidden"

Event processing

When a mouse event occurs above a transparent area of the initial target, IE checks the elements in stacking order.

While the current event target area is transparent according to the rules above and is not BODY, IE examines the element below.

If current event target is BODY the topmost element gets the event.

If current event target area is not transparent it will get the event if the event is within a content box or on a border. Otherwise, the event goes to the initial target.



Special cases that are transparent to events:

PNG with alpha channel and the AlphaImageLoader filter applied - the fully transparent areas

IFRAME with attribute allowtransparency and contents with style background: transparent applied

Transparent parts of OBJECT with wmode=transparent

Notes

Clipping does make the clipped region transparent even if the element has backgrounds/background images

Opacity filters and background-position/repeat have no effect on transparency for event handling purposes.

If the event does not reach the BODY element because the target point is positioned outside the BODY, it will go to the bottom-most element, normally HTML.

Line-height does not affect transparency - the extra space inbetween the lines is transparent to events

Table elements are never transparent to events

2 comments

odd IE quirk with IMG id attribute

Wednesday, 17. August 2005, 21:23:02

, ,

IE often creates convenience variables for elements with an ID attribute. For example, if your document contains a

<div id="navigation">

your script can refer to "navigation" without calling getElementById. This is also called polluting the global namespace with element references. It is a non-standard feature and your scripts should use getElementById instead of referring to elements directly with convenience variables.

As this testpage shows, IE will also let you refer to an image element with document.imageid - but only if the IMG tag also has a name attribute! And it does not create global variables for IMG elements with IDs!

That is rather inconsistent..

As we see from that test page, Opera is trying too hard to be IE-compatible, it is supporting more window.id references than IE itself. However, Opera isn't aware of the document.imgID approach - which is why this page fails in Opera.

That webmaster could have used a number of syntaxes that would work -
document.images.imgName
window.imgID
window.imgName
document.imgName
document.getElementById('imgID')

and of those three out of five are supported just to cater for lazy webmasters. Unfortunately, the author happened to pick just about the only option Opera had forgotten to implement. Oh well. Life isn't fair, neither is the web.

4 comments

« Prev 1 2

Showing posts 9 - 13.