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:
Another part of the code is hidden from non-IE browsers with conditional comments:
..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:
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."
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."
WIDGETIZE
Andrew Gregory # 23. July 2006, 07:55
IMO, that's a really good candidate for a new site preference.
João Eiras # 23. July 2006, 21:56
Hallvord R. M. Steen # 23. July 2006, 23:35
Alexey Feldgendler # 24. July 2006, 03:43
...I always wondered what goes on inside the heads of authors of such web sites.
Andrey Petrov # 24. July 2006, 14:57
Hallvord R. M. Steen # 26. July 2006, 19:47
Andrey Petrov # 22. August 2006, 15:31
Probably can be useful.
João Eiras # 16. September 2006, 04:49
document.all must evaluate to false whenever inserted in a boolean expression, yet document.all['foobar'] or document.all.foobar should work, this way not breaking the script, and prevent stupid IE browser sniffing that breaks Opera.
This is the best idea possible regarding document.all
I advise for the same to happen with attachEvent.
Many scripts sniff for attachEvent to clean symbols and stuff defined in scripts (to prevent IE's memory leaks) which break webpages when using the back button.
Alexey Feldgendler # 18. September 2006, 06:27
if (document.all) {
// if document.all is there, use it for quick retrieval
e = document.all['xyzzy'];
} else {
// do some complex traversal
}
It's OK if the script does just this, but it might just refuse to work without document.all because it needs that.
João Eiras # 19. September 2006, 01:49
document.all is mostly used for sniffing.
There are very few, rare, obscure cases of websites relying on this object only, not providing a DOM branch.
Opera would gain more by hiding it, than keeping the object visible.
That's what webkit did.
ale5000 # 19. September 2006, 21:18
João Eiras # 20. September 2006, 02:43
Originally posted by ale5000:
Most user don't have the smallest idea of what document.all is and its implications.It should be hidden by default, and visible only when masking as IE, but always present and supported.
I've seen too many webpages sniffing for document.all and then trying to use ActiveXObject, using setProperty/selectNodes, or providing stupid hacks for lack of hover in other elements besides anchors.
Of interest
https://bugzilla.mozilla.org/show_bug.cgi?id=248549
João Eiras # 25. September 2006, 19:36
http://my.opera.com/community/forums/topic.dml?id=159901