Simple script works in Firefox but not IE7

G

garey

Hi -

I am trying to write some Javascript that will move both buttons
and selects from far left of the viewport into and out of the
viewport. I present a button that moves in another button. The second
button moves in a select.

All of this works in Firefox. Moving the button in and out works
in IE7, but moving in the select does not, despite the exact same code
being used in both cases. The code is below. Note that I added the
"min-height: 0" style statement to the style because I thought that
this might be a Microsoft "layout" problem, but setting min-height
did not affect the problem.

Any help appreciated;

Garey Mills

<html>
<head>
<style type="text/css">

div.extraout { position: absolute; left: -9999em; min-height: 0 }

</style>

<script language="JavaScript">

function ucbmoveIn(name) {

var elem = document.getElementById(name);
elem.style.position = "static";

}

function ucbmoveOut(name) {

var elem = document.getElementById(name);
elem.style.position = "absolute";

}

</script>
</head>

<body>

<button name="more" value="more" onClick='ucbmoveIn("l");return
false;'>More</button>

<div class="extraout" id="l">
<table>
<tr>
<td><button name="a" value="a" onClick='ucbmoveIn("a");return
false;'>A</button></td>
</tr>
</table>
<button name="less" value="less" onClick='ucbmoveOut("l");return
false;'>Hide</button>
</div>

<div class="extraout" id="a">
<tr><td>As</td><td>

<select name="lA" id="lA" size="10" multiple="multiple">
<option value="ach">acholi</option>
<option value="ada">adangme</option>
<option value="afh">afrihili</option>
</select>
</td></tr></table>
<button name="hideAs" value="hideAs" onClick='ucbmoveOut("a");return
false;'>Hide</button>
</div>

</body>
</html>
 
T

Thomas 'PointedEars' Lahn

garey said:
I am trying to write some Javascript that will move both buttons
and selects from far left of the viewport into and out of the
viewport. I present a button that moves in another button. The second
button moves in a select.

All of this works in Firefox. Moving the button in and out works
in IE7, but moving in the select does not, despite the exact same code
being used in both cases. The code is below. Note that I added the
"min-height: 0" style statement to the style because I thought that
this might be a Microsoft "layout" problem, but setting min-height
did not affect the problem.

Any help appreciated;

Garey Mills

<html>

Not Valid.
<head>
<style type="text/css">

div.extraout { position: absolute; left: -9999em; min-height: 0 }

Smart people hide the element instead of placing it in CSS hell.
</style>

<script language="JavaScript">

Not Valid. HTML 4.01 and the `type' attribute turn 10 years this December;
amazing how long such obsolete nonsense as above keeps floating around the Web.

function ucbmoveIn(name) {

var elem = document.getElementById(name);

The feature test is missing. RTFM, RTFFAQ, STFW.
elem.style.position = "static";

"static" is the default value. Had you not mindlessly moved the element
beyond good and evil in the first place, that operation would have been
unnecessary.
}

function ucbmoveOut(name) {

var elem = document.getElementById(name);

See above.
elem.style.position = "absolute";
No.

}

</script>
</head>

<body>

<button name="more" value="more" onClick='ucbmoveIn("l");return
false;'>More</button>

The less compatible `button' element is unnecessary here, a (dynamically
generated) input[type="button"] suffices.
<div class="extraout" id="l">

Very self-explaining ID, really.
<table>
<tr>
<td><button name="a" value="a" onClick='ucbmoveIn("a");return
false;'>A</button></td>

See above.
</tr>
</table>

You don't need this table at all. Learn HTML and CSS before you try to
learn JS.
<button name="less" value="less" onClick='ucbmoveOut("l");return
false;'>Hide</button>

See above. Forget about `return false'; use type="button" instead and
generate this dynamically. (Did anyone tell you already that you should
learn HTML before you try to learn JS?)
</div>

<div class="extraout" id="a">

See above.
<tr><td>As</td><td>

Not Valid. There is no table for this table row as the one table in the
document ended well before this line.
<select name="lA" id="lA" size="10" multiple="multiple">

See above. Besides, this isn't XHTML, is it? HTML UAs tend to choke on
this boolean syntax, even though SGML allows it. RTFM.
[...]
</td></tr></table>
<button name="hideAs" value="hideAs" onClick='ucbmoveOut("a");return
false;'>Hide</button>

See above.


PointedEars
 
E

Eric Bednarz

Thomas 'PointedEars' Lahn said:
See above. Besides, this isn't XHTML, is it?

Why would that matter?
HTML UAs tend to choke on this

That’s a nice bunch of weasel words.
boolean syntax,

Come again?
even though SGML allows it.

I withdraw my first question.

You seem to know that HTML UAs don’t have any SGML capabilities. Please
explain all those URI references to the W3C validation service to
confirm compliance with a validating SGML system.

Or STFW if you are too cheap to buy the manual that actually matters if
you want to discuss esoterica.
 
T

Thomas 'PointedEars' Lahn

Eric said:
Why would that matter?

In XHTML this is required; in HTML this is recommended against.
That’s a nice bunch of weasel words.


Come again?


I withdraw my first question.

You seem to know that HTML UAs don’t have any SGML capabilities. Please
explain all those URI references to the W3C validation service to
confirm compliance with a validating SGML system.


Or STFW if you are too cheap to buy the manual that actually matters if
you want to discuss esoterica.

Idiot. <http://www.w3.org/TR/html401/appendix/notes.html#h-B.3.4>

<http://jibbering.com/faq/#posting>
<http://www.catb.org/~esr/faqs/smart-questions.html#before>


PointedEars
 
T

Thomas 'PointedEars' Lahn

kangax said:
CSS hell? Please explain another way to "hide" an element in such way
that its content is "picked up" and pronounced by screen readers.

No, because the whole thing is not accessible in the first place.


PointedEars
 
D

David Mark

Thomas said:
garey wrote: [...]
div.extraout { position: absolute; left: -9999em; min-height: 0 }
Smart people hide the element instead of placing it in CSS hell.

CSS hell? Please explain another way to "hide" an element in such way
that its content is "picked up" and pronounced by screen readers.

If an element is hidden, you don't want it to be read by screen
readers. If it is not hidden, you certainly don't want to place it
off-screen so that only blind people will be aware of it.
 
D

David Mark

David said:
Thomas 'PointedEars' Lahn wrote:
garey wrote:
[...]
div.extraout { position: absolute; left: -9999em; min-height: 0 }
Smart people hide the element instead of placing it in CSS hell.
CSS hell? Please explain another way to "hide" an element in such way
that its content is "picked up" and pronounced by screen readers.
If an element is hidden, you don't want it to be read by screen
readers.  If it is not hidden, you certainly don't want to place it
off-screen so that only blind people will be aware of it.

Most of the time not. But there are cases when information can be
perceived fully only visually and some additional content/explanation
needs to be presented to a screen reader. These cases are rare but they
do come up once in a while.

Sure, there are exceptions. I've seen that strategy advocated as a
replacement for hidden visibility though, which it clearly is not.
I suppose this article explains it best (and features actual examples):

<http://www.webaim.org/techniques/css/invisiblecontent/>

No time at the moment, but beware of anything you find on the Web.
Just as with JS, there are lots of people expressing lots of ideas
about how to use CSS on the Web (and most of them are wrong.)
 
D

David Mark

That's true; There's plenty of bizarre explanations and workarounds
floating around. WebAIM, on the other hand, is a quite respected
resource, as far as I know. If you have any objections to the material
from that article, I would be interested to hear them.

I'll check it out when I get a chance.
On a side note, it would be nice if the information one can find in this
newsgroup would get more attention on the web. Cornford's and

More is always better when it comes to attention. Lots of
misconceptions to clear up at this point.
Crockford's articles are good examples of spreading some of the
browser-scripting (or language, overall) techniques, as well as Peter
Michaux's blog (I think one of his feature detection -related articles
is how I found out about comp.lang.javascript in the first place).

Some time ago, I made a naive attempt at releasing a set of examples of
some of the common feature tests one might stumble upon. The funny thing
is that when it got to Ajaxian, some people actually argued about
sniffing being "faster" and supposedly more superior.

Ajaxian is a rag. And that must have been some time ago as I don't
think anyone would argue for browser sniffing at this point.
 
E

Eric Bednarz

[multiple="multiple"]

You are a pompous wannabe-hacker permanently stuck in adolescence.

If you wanna be pragmatic, the HTML 4.01 spec is ten years old, that
section was already in the first HTML 4 spec that is eleven years old,
and if you consider WG speed it is likely that this note is about the
browser landscape twelve years ago or older. So this is supposed to back
up your statement “HTML UAs tend to choke on this�

If you wanna be dogmatic, there are no ‘boolean attributes’ in
SGML. There’s attribute name omission for name token lists, and
historically that was *the* reason to enable SHORTTAG in the quixotic
attempt to retrofit HTML into an SGML application.
So where’s the appendix note that explains how ‘boolean attributes’
enable notation like
<td justify>
? :)
 
T

Thomas 'PointedEars' Lahn

Eric said:
You are a pompous wannabe-hacker permanently stuck in adolescence.

At least I'm not such a luser like you. I've given (you) enough hints on
where to find the relevant information, yet you've been either unable or
unwilling to look it up, and instead engage in pointless quibbling over
words without even trying to back up *your* assertions.
If you wanna be pragmatic, the HTML 4.01 spec is ten years old, that
section was already in the first HTML 4 spec that is eleven years old,
and if you consider WG speed it is likely that this note is about the
browser landscape twelve years ago or older. So this is supposed to back
up your statement “HTML UAs tend to choke on this�

Unless someone can provide sufficient proof to the contrary. Which nobody
can, of course.
If you wanna be dogmatic, there are no ‘boolean attributes’ in
SGML. There’s attribute name omission for name token lists, and
historically that was *the* reason to enable SHORTTAG in the quixotic
attempt to retrofit HTML into an SGML application.

Interesting if true, but entirely irrelevant here. Following the HTML 4.01
Specification, Appendix B, section 3.4, has only potential advantages and no
drawbacks.
So where’s the appendix note that explains how ‘boolean attributes’
enable notation like
<td justify>
? :)

Hush, hush, baby.


PointedEars
 
D

David Mark

You'll be surprised :)

Not really.
Less than a month ago someone created a jQuery plugin to emulate
text-overflow on non-supporting browsers
<http://ajaxian.com/archives/text-overflow-for-firefox-via-jquery>

Nobodies don't count. :)
Then someone in the comments says - "Because of the use of
$.browser.mozilla in the plugin, this won’t work with jQuery 1.3.2+."

Which isn't true (for some definition of "work" that applies to all of
the other plugins as well.)
A response to that comment:

<cite>
@MichaelThompson: this is why feature detection never gets you all the
way there. There’s no way to detect this feature from javascript, as it
is a purely visual feature that doesn’t affect the DOM state in any way..
</cite>

The usual BS. I saw this one (and thousands like it over the last
five years or so.)
Another response made me spill my coffee:

<cite>
It’s not terribly difficult to replace jQuery’s browser detection with
your own.

All old news. The jQuery cult preaches incompetence.
For instance:
var isGecko = (!!window.Array.every || !!window.Iterator ||
!!window.getComputedStyle) && !!document.doctype && !window.opera &&
(!!window.devicePixelRatio && !!window.getMatchedCSSRules);

That's a new one. What do they infer from that?
First group is features Gecko has introduced; second and fourth avoid
confusion with some Safari versions; third is obvious.
</cite>

These are the people building major Websites today. They won't be
around much longer.
I suggested to remove silly inference by testing style of an element and
an author actually did remove an inference from the script (which made
it compatible with new jQuery :))

Please don't help jQuery. As with Prototype, it doesn't deserve your
help.
My "solution" was:

var s = document.documentElement.style;
if (!('textOverflow' in s || 'OTextOverflow' in s)) {
// implement workaround

I assume the second is the proprietary Opera style.
}

which I would now probably replace with something like:

var IS_TEXT_OVERFLOW_SUPPORTED = (function(){
   var docEl = document.documentElement, s;
   if (docEl && (s = docEl.style)) {
     return typeof s.textOverflow == 'string' ||
       typeof s.OTextOverflow == 'string';
   }
   return null;

})();

Something like that. So much for hysterics about browser sniffing
being needed to get "all the way there." Hopefully the readers of
that blog will get this point now.

There are indeed cases where you can't detect (or test) a feature
(e.g. PNG translucency support.) As we know, there are other ways to
make such decisions (e.g. IE conditional comments.) Often the issue
can be designed out of the system (e.g. substitute GIF's for IE < 7 in
a conditionally added style sheet.) General purpose scripts like
jQuery and its plugins don't design anything out as they want to
please as many incapable people as possible.
I'm still not convinced that document.documentElement's style should not
be tested since HTML can not have a style attribute, but if that's a
concern, it's trivial to test an element that supports it. The problem
is that then a test would rely on `document.createElement` being available.

Depends on the context. A recent project I worked on would have FoUC
in IE4 (or browsers that don't support
document.documentElement.style.) I can certainly live with that, so I
wouldn't consider adding a call to createElement.
var IS_TEXT_OVERFLOW_SUPPORTED = (function(){
   if (/^(?:function|object|unknown)$/i.test(document.createElement)){
     var el = document.createElement('div'), s;
     if (el && (s = el.style)) {
       return typeof s.textOverflow == 'string' ||
         typeof s.OTextOverflow == 'string';
     }
   }
   return null;

})();

Why not wait until the body is ready to test this. The only
conceivable reason for this that I can see is to emulate text overflow
with script for browsers that don't support those rules. You wouldn't
do that until the body is ready.

Also, the flag doesn't tell you much. You should create a function
(like setOpacity) rather than a flag.
 
D

David Mark

I don't explicitly help jQuery. In this case, I saw a misconception, as
well as a trivial solution and I thought it made sense to point out more
or less robust replacement. I don't care if it's jQuery or Mootools that
this misconception is employed into; The same way any of us would
recommend a best practice to someone asking for advice in this newsgroup.

I was half-kidding. But you do work on Prototype, which seems like
masochism to me.
I do "help" Prototype.js because my work involves maintaining intranet
based apps that use it quite heavily. Since these apps are not for
general web and are only required to work in a limited set of clients, I
don't see a reason to wipe Prototype out (nor do I have a time to do
so). There's a lot of code and it does what it needs to do just fine
(that is, for people who use it).

You should definitely wipe it out of your projects, rather than try to
keep it up.
I also happen to be a Prototype.js core developer (for a couple of
months now) and am trying to eliminate all of the bogus stuff from the
library. You can probably imagine that it's no easy task;

This is what I'm talking about.
Prototype
happens to penetrate an environment way too much and makes too many bold
actions. Sniffing is another problem. I removed half of it, but some
things are just impossible to get rid of, due to "specific" design of a
library. What's frustrating is that some sniffs don't even have an
explanation; I, for example, still have no idea why Prototype.js
disables element extension when userAgent looks like it's a Mobile
Safari. Changelog is hardly helpful too.

Right. It's a derelict at this point. Abandon ship.
Yes it is.

The problem I see here is that if Mozilla decides to implement
text-overflow via its proprietary version, e.g. - "MozTextOverflow" -
the code would need to be changed. Same could happen with Webkit,
Konqueror or whatever else. This kind of sucks.

I doubt it. The next browser versions will likely support the CSS3
rule.
Do you think it would make sense to include those in a test right away
(as an intelligent guess)?

Not at this time.
It feels sloppy and it's not clear when to "stop". It's quite a mess
with all these proprietary CSS3 patching that browser vendors rush to
implement but are cautious to mess with currently draft CSS3 names.

So why are you trying to mess with it in script? Opacity I can see
(for animations.) Just put the CSS3 rule in your style sheet (along
with the Opera rendition if you must.)
var IS_TEXT_OVERFLOW_SUPPORTED = (function(){
   var docEl = document.documentElement, s;
   if (docEl && (s = docEl.style)) {
     return typeof s.textOverflow == 'string' // CSS3
       || typeof s.OTextOverflow == 'string' // opera
       || typeof s.MozTextOverflow == 'string' // mozilla
       || typeof s.WebkitTextOverflow == 'string' // webkit
       || typeof s.KhtmlTextOverflow == 'string'; // khtml
   }
   return null;

})();

Isn't there also "-ms" and "-icab"? :)

Not that I know of.
True. Visual aspects can not be tested. Iframe shim for IE (needed to
prevent SELECT elements leaking through) is a good example. Then there
are key events discrepancies which are not easy to test either (maybe
only by testing user-generated key event but that could be quite a hassle)



Interesting. So FoUC would occur when `style` property of a
`document.documentElement` was accessed?

No, I was referring to a specific case where the absence of
documentElement.style would result in FoUC and that would be the only
effect on the behavior.
I was also thinking about a more compatible alternative of getting a
"dummy" element for inspection:

function getElement(){
   var el = document.documentElement;
   if (el) return el;
   if (document.createElement) {
     el = document.createElement('div');
     if (el) return el;
   }}

If you absolutely must get a reference to an arbitrary element before
the body is ready, you should use createElement. It is the best bet
anyway as you don't know what documentElement might hold (could have
been modified by other scripts.)
...
var el = getElement();
if (el && el.style) {
   ...

}

or maybe a more specific `getStyle` helper -

function getStyle(){
   var el = document.documentElement, s;
   if (!el && document.createElement) {
     el = document.createElement('div');
   }
   if (el && (s = el.style)) return s;}

Of course, you don't normally need such information until the body is
ready, so you could just use the body instead of the documentElement.
The only common case I can think of is preventing FoUC.
...
var style = getStyle();
if (style) {
   ...



}


That's an option, of course. I just don't like to use `body` when not
absolutely needed (for the reason of making it more compatible and
portable).

How does that make it more compatible or portable? Do you mean
portable to other parts of the document (e.g. the head?)
On the other hand, it's all about context, as you said. If
I'm writing this test inline and body is already available, i would
probably use it.

A load (or DOMContentLoaded) listener is the more likely place to
inspect styles.
Which flag are you talking about?

IS_TEXT_OVERFLOW_SUPPORTED tells me that one of the two styles is
present. What do I do now?
 
D

David Mark

David said:
David Mark wrote:
[...]
I suggested to remove silly inference by testing style of an elementand
an author actually did remove an inference from the script (which made
it compatible with new jQuery :))
Please don't help jQuery.  As with Prototype, it doesn't deserve your
help.
I don't explicitly help jQuery. In this case, I saw a misconception, as
well as a trivial solution and I thought it made sense to point out more
or less robust replacement. I don't care if it's jQuery or Mootools that
this misconception is employed into; The same way any of us would
recommend a best practice to someone asking for advice in this newsgroup.
I was half-kidding.  But you do work on Prototype, which seems like
masochism to me.

I had to make our apps work in IE8. Removing sniffing from Prototype
worked a magic (no surprise there). It was also a fun and useful
exercise that taught me about feature detection a bit more. I made some
mistakes of course but the result is probably better than parsing poor
userAgent string for no apparent reason.

Virtually anything is better than parsing the UA string. The fact
that Prototype still does that, long after IE8 was released (and ten
years since IE changed significantly) should tell you it is over. You
can't keep it up, certainly not if you have to confine your changes to
the needs of whatever is left of the community.
[...]
I doubt it.  The next browser versions will likely support the CSS3
rule.

But there's a chance that CSS3 does not become final before Mozilla (or
any other browser) decides to implement it, isn't there?

It's possible. I just don't see them adding MozTextOverflow without
textOverflow. You could write one generic function to use for all
such on-the-fence styles (e.g. opacity, rounded corners.)
To emulate it in Javascript, as I understand it.

Oh, the OP. I thought you were working on a patch for Prototype.
IE8 switched to vendor-specific names for some names, like infamous
filter <http://msdn.microsoft.com/en-us/library/ms530752(VS.85).aspx>. I
think they actually recommended using "-ms-" prefixed names instead of
their non-standard versions.

Never used them.
It appears that there's "-ms-text-overflow" as well
<https://developer.mozilla.org/en/CSS/text-overflow>

Fair enough. That I would use as there is certainly no text-overflow
in IE.
[...]
No, I was referring to a specific case where the absence of
documentElement.style would result in FoUC and that would be the only
effect on the behavior.

I see.




If you absolutely must get a reference to an arbitrary element before
the body is ready, you should use createElement.  It is the best bet
anyway as you don't know what documentElement might hold (could have
been modified by other scripts.)

Good point, although it again depends on a context, of course. In this
case, for example, it seems unlikely that one of the style properties
was removed or replaced with another value, as in:

document.documentElement.style.textOverflow = 'muahaha';

Although the fact that some browsers allow an arbitrary property to be
assigned to a style object proves that it's a good idea to create a
dummy element from the scratch. Too bad even dummy element can be "evil":

// in Firefox 3.0.10
HTMLDivElement.prototype.filter = 'alpha(opacity=50)';
document.createElement('div').filter; // "alpha(opacity=50)"

Simple enough. Throw out all scripts featuring such patterns (just
like the ones that make inferences based on navigator.userAgent.)
I had a rule about creating an element dynamically only when it (or one
of its properties/attributes) needed to be modified and used
`documentElement` for any "read-only" test.

[...]
How does that make it more compatible or portable?  Do you mean
portable to other parts of the document (e.g. the head?)

Yes, I often don't use "onload" at all (so body is not available), but
assign event handlers globally and use event delegation. This way you
avoid any problems that arise from load/DOMContentLoaded.

I didn't follow that exactly. When do you attach listeners?
You know that it's not supported and emulate it with
jQue^H^H^H^HJavascript, I suppose :)

Right. I forgot what the OP was doing. Still a function makes
sense. One branch sets style properties, the other trims the text
content and adds an ellipsis when needed. ISTM I had to do something
similar recently. I'll have to look into -ms-text-overflow.

Would be nice if they had -ms-border-radius or -ms-transition (instead
of filter.) But what I would really like to see is -moz-transition.
 
T

Thomas 'PointedEars' Lahn

kangax said:
That's a good idea.

JFTR: The Test Suites[1] show that Gecko has partial CSS3 support already
(CSS3 Selectors in particular). As for what is required before CSS3 can
become a Recommendation please see the "Status of this document" sections of
the respective CSS3 modules and the W3C Process Document.

No doubt about that, but I was talking about an uncontrolled
environment.

You mean "controlled"?
The same way you make your scripts work with augmented `Object.prototype`

The same way?
(if I'm not mistaken)

Probably you are.
even though scripts that augment it should be considered dangerous as well.

Not dangerous (there is no danger in a runtime error), but inappropriate
(because either it breaks for-in iteration or it makes it considerably less
efficient), and therefore to be avoided.
To a `document.documentElement` at any time and use event delegation
(for any event that bubbles, of course).

I don't think that is a reasonable or compatible approach.
[..] But what I would really like to see is -moz-transition.

You're certainly not the only one who wants them.
<https://bugzilla.mozilla.org/show_bug.cgi?id=435441> with 19 votes (I
just voted as well)

Thanks for the pointer.


PointedEars
 
D

David Mark

Thomas said:
kangax said:
David Mark wrote:
[...]
But there's a chance that CSS3 does not become final before Mozilla (or
any other browser) decides to implement it, isn't there?
It's possible.  I just don't see them adding MozTextOverflow without
textOverflow.  You could write one generic function to use for all
such on-the-fence styles (e.g. opacity, rounded corners.)
That's a good idea.
JFTR: The Test Suites[1] show that Gecko has partial CSS3 support already
(CSS3 Selectors in particular).  As for what is required before CSS3 can
become a Recommendation please see the "Status of this document" sections of
the respective CSS3 modules and the W3C Process Document.

Good to know. Thanks.


You mean "controlled"?

I mean "uncontrolled"; an environment where you don't "control" all (or
a subset) of the scripts running on a page (i.e. scripts authored by
someone else).


The same way?

Yes.

By using `Object.prototype.hasOwnProperty`, for example; or, more
likely, some form of its emulation. "My Library" uses `isOwnProperty` in
loops, which is implemented as -

var isOwnProperty = function(o, p) {
   return typeof o.constructor.prototype[p] == 'undefined';

};

That's the old one. I updated it recently.
I'm not sure if accessing a property off of `constructor` without first
testing for its existence (given that host objects might not implement
it) is the safest way to go, but apparently it works as it is.

You definitely don't use isOwnProperty with *host* objects. Should be
documented of course.
There's no danger in runtime error? Isn't the main reason for employing
`isHost*` methods is to prevent runtime errors and return silently?

Thomas is talking about augmenting the prototypes of Object objects,
not host objects.

It is a bit odd.
 
T

Thomas 'PointedEars' Lahn

kangax said:
I mean "uncontrolled"; an environment where you don't "control" all (or
a subset) of the scripts running on a page (i.e. scripts authored by
someone else).

The cause of our misunderstanding is that you assume that this possibility
exists. However, IMO it doesn't; neither are you required to run such
scripts nor are you required, if you run them, to keep going with their
augmentation should it turn out that it hinders the efficiency or
effectiveness of your scripts. As David said, when you encounter this
pattern (relying solely on the augmentation of the prototypes of host
objects), you better throw the script out.

Therefore, I understood "controlled" with regard to the user agents that may
be used in that environment: One would use the above code (as it is) only in
a controlled environment, if that; that is, where there are two groups of
UAs: one group that does not support Microsoft filters but supports the
augmentation of the prototypes of host objects, and another group that
supports the augmentation of the prototypes of host objects *and* implements
Microsoft filters. In an uncontrolled environment (AIUI), though, there is
at least a third group to which none of the above applies.
Yes.

By using `Object.prototype.hasOwnProperty`, for example;

That is hardly "the same way" in any sense of the word. You were talking
about the augmentation of the prototypes of host objects, not about how to
deal with it.
or, more likely, some form of its emulation. "My Library" uses
`isOwnProperty` in loops, which is implemented as -

var isOwnProperty = function(o, p) {
return typeof o.constructor.prototype[p] == 'undefined';
};

I'm not sure if accessing a property off of `constructor` without first
testing for its existence (given that host objects might not implement
it) is the safest way to go, but apparently it works as it is.

"Apparently" jQuery < 1.3 "worked" before IE 8. This should give you pause.
There's no danger in runtime error?

Mind your words. What possible *danger* is there? A runtime error is an
avoidable inconvenience, but it poses no danger in and of itself.
Isn't the main reason for employing `isHost*` methods is to prevent runtime
errors and return silently?

Non sequitur.

Proprietary DOM implementations may not consider the root element an event
target for an event, and AIUI even standards-compliant DOM implementations
do not need to. Insofar the "weirdness" of this approach constitutes an
argument against it.

<http://www.w3.org/TR/DOM-Level-3-Events/events.html#Events-EventTypes-complete>


PointedEars
 
T

Thomas 'PointedEars' Lahn

Thomas said:
Mind your words. What possible *danger* is there? A runtime error is an
avoidable inconvenience, but it poses no danger in and of itself.

JFTR: As I can see now that several English idioms starting with "Mind your
...." are intended to be rather impolite, let it be clear that no offense was
meant. Instead, I meant to say "you should take more care of which words
you are using, for they have a certain meaning attached."


PointedEars
 
D

David Mark

On May 7, 4:45 am, Thomas 'PointedEars' Lahn <[email protected]>
wrote:

[snip]
"Apparently" jQuery < 1.3 "worked" before IE 8.  This should give you pause.

I do want to point out that jQuery 1.3x (they are on the third
iteration now) does not work in IE8, IE7, IE6, ... IE3, AOL IE, Mac
IE, IE spoofs or anything that even looks like IE. Not any mode, not
even close and apparently not in this lifetime. Oh well, we never
needed it anyway.

Mozilla could kill these miserable things off for good if they would
just add mozTransition to Firefox. Without (bad) animations, nobody
would have ever heard of jQuery. Somebody tell their evangelist.

[snip]
 
T

Thomas 'PointedEars' Lahn

David said:
I do want to point out that jQuery 1.3x (they are on the third
iteration now) does not work in IE8, IE7, IE6, ... IE3, AOL IE, Mac
IE, IE spoofs or anything that even looks like IE. Not any mode, not
even close and apparently not in this lifetime. Oh well, we never
needed it anyway.

I do know you have been posting a lot about jQuery issues, but I have not
found the time to read all of your postings thoroughly (they are rather long
and it is difficult to find the technical facts among the bickering, even if
justified, now), and I certainly don't remember all of them.

Therefore, would you be so kind to try pointing out and maybe explaining
*concisely*, if possible, why exactly what you describe above is so? That
could provide those who are forced by their uninitiated bosses to use jQuery
for certain graphical gimmicks (because they "look great") a big enough LART
to abandon jQuery eventually. Thank you very much in advance.
Mozilla could kill these miserable things off for good if they would
just add mozTransition to Firefox. Without (bad) animations, nobody
would have ever heard of jQuery. Somebody tell their evangelist.

ACK :)


PointedEars
 
D

David Mark

I do know you have been posting a lot about jQuery issues, but I have not
found the time to read all of your postings thoroughly (they are rather long
and it is difficult to find the technical facts among the bickering, evenif
justified, now), and I certainly don't remember all of them.

Well, as for their length, there were a lot of issues. If you just
read mine, you will skip the follow-up "bickering" which is really
more like endless, repetitive blithering.
Therefore, would you be so kind to try pointing out and maybe explaining
*concisely*, if possible, why exactly what you describe above is so?

With respect to IE?

There's too much to explain concisely. Suffice to say that the
culture revolves around a method called "attr." That method's purpose
is undocumented. The method's code is pure gibberish that adds ten
million (approx.) additional complications to the already complicated
task of cross-browser scripting and its behavior changes across IE
versions (as well as jQuery versions.) That's one critical, low-level
method (most are of similar quality.) Another observation is that
disabling ActiveX in IE causes Ajax calls to unceremoniously throw
exceptions.

If that is not enough, go back and read the rest of it. I'll publish
a summary at some point in the future.
That
could provide those who are forced by their uninitiated bosses to use jQuery
for certain graphical gimmicks (because they "look great") a big enough LART
to abandon jQuery eventually.  Thank you very much in advance.

I've received a lot of queries for more evidence. There's only one of
me, so I tell most of them to do their own homework.

[snip]
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,731
Messages
2,569,432
Members
44,832
Latest member
GlennSmall

Latest Threads

Top