string and objects
spa...@corbetteer.co.uk
I have a range of anchors with "id" from "er0" to "er250"
now I have some script that positions a layer next to these anchors,
this script works well when i specify the variable like
var aPos = er234
this works perfectly
however the code that I am using is arriving as a string so I am
getting
var aPos = 'er234'
which fails, "is null or not an object"!
I am guessing here that
er234
is an object and
'er234'
is a string
how do i convert the string into an object??
Jeremy J Starcher
Without seeing code, I can only take a few guesses.
If you are running in IE, that particular browser has the mis-feature of
creating variables for (IIRC) named and ID'd elements.
The cross-browser and correct way is to use document.getElementById
(string).
spa...@corbetteer.co.uk
>
> - Show quoted text -
here is the function
z arrives as a string
I have got the whole thing working with the "eval" statement, still
think there could be a beter way to turn the string nto an object
function conectAnalyse(z){
var el = eval(z)
if (el !== null) {
var xVal = el.offsetLeft;
var yVal = el.offsetTop;
var oP = el.offsetParent;
var pN = el.parentNode;
while (oP !== null){
xVal += oP.offsetLeft;
yVal += oP.offsetTop;
if (oP != document.body && oP != document.documentElement){
xVal -= oP.scrollLeft;
yVal -= oP.scrollTop;
}
//firefox adj
if (ff){
while (oP != pN && pN !== null){
xVal -= pN.scrollLeft;
yVal -= pN.scrollTop;
pN = pN.parentNode;
}
}
pN = oP.parentNode;
oP = oP.offsetParent;
}
}
document.getElementById("lnk").style.top = yVal + 12 + "px"
}
Thomas 'PointedEars' Lahn
> Jeremy J Starcher wrote:
>> spamme wrote:
>>> [...]
>>> however the code that I am using is arriving as a string so I am getting
>>> var aPos = 'er234'
>>> which fails, "is null or not an object"!
>>> I am guessing here that
>>> er234
>>> is an object and
>>> 'er234'
>>> is a string
>>> how do i convert the string into an object??
>> Without seeing code, I can only take a few guesses.
>>
>> If you are running in IE, that particular browser has the mis-feature of
>> creating variables for (IIRC) named and ID'd elements.
>>
>> The cross-browser and correct way is to use document.getElementById
>> (string).
>
> z arrives as a string
> I have got the whole thing working with the "eval" statement, still
> think there could be a beter way to turn the string nto an object
>
> function conectAnalyse(z){
> var el = eval(z)
> if (el !== null) {
> var xVal = el.offsetLeft;
This madness is the reason why it does not work in many non-IEs: there is no
`er234' etc. property, and the result of untested access to it is a
ReferenceError.
Do as Jeremy said, use the document.getElementById() method instead of
eval(). Also use document.all[...] as a fallback for the former (necessary
only for IE 4 and older).
Because of the universal wrapper method required for providing the fallback,
you are better off with
function conectAnalyse(el)
{
if (el)
{
...
}
...
}
Then you can simply pass the return value of the wrapper method for the `el'
argument. See also <http://PointedEars.de/scripts/dhtml.js>, dhtml.gEBI() &
friends.
Please get a real name.
PointedEars
spa...@corbetteer.co.uk
>
> - Show quoted text -
It all works well, thankyou.
But, is my understanding of it correct ?
function conectAnalyse(z){
var el = document.getElementById(z)
if(el){
If the browser supports getElementbyId, "el" becomes the correctly
named object and the code is sucessful if it dosnt support
getElementById then "el" remains null, the code does not run and no
error is created ?
Browser compatability is a bit of an unknown for me, I only have IE6
and FireFox to test on, is there any online utility that can show what
platforms script will run on ???
Thomas 'PointedEars' Lahn
> Thomas 'PointedEars' Lahn wrote:
>> Do as Jeremy said, use the document.getElementById() method instead of
>> eval(). Also use document.all[...] as a fallback for the former (necessary
>> only for IE 4 and older).
>>
>> Because of the universal wrapper method required for providing the fallback,
>> you are better off with
>>
>> function conectAnalyse(el)
>> {
>> if (el)
>> {
>> ...
>> }
>> ...
>> }
>>
>> Then you can simply pass the return value of the wrapper method for the `el'
>> argument. See also <http://PointedEars.de/scripts/dhtml.js>, dhtml.gEBI() &
>> friends.
>>
>> Please get a real name.
>
> It all works well, thankyou.
> But, is my understanding of it correct ?
Not quite. You should *pass* the return value of the wrapper method
to conectAnalyse() for the single argument of conectAnalyse():
conectAnalyse(gEBI("foo"));
> function conectAnalyse(z){
> var el = document.getElementById(z)
> if(el){
Then you can make `el' the name of the argument, and lose the superfluous
`z' along with the first line of conectAnalyse().
> If the browser supports getElementbyId, "el" becomes the correctly
> named object and the code is sucessful if it dosnt support
> getElementById then "el" remains null, the code does not run and no
> error is created ?
No, if document.getElementById() is not supported, calling anyway throws a
TypeError exception (or worse). That is why you need a wrapper method that
determines if that feature is available an if not, uses another feature or
returns a false-value (optimally here: null). In its simplest, most
inefficient and most error-prone form:
function gEBI(id)
{
if (document.getElementById)
{
return document.getElementById(id);
}
else if (document.all)
{
return document.all[id];
}
return null;
}
I have already referred you to my dhtml.js, which uses a more sophisticated,
most efficient, and least error-prone approach. UTSL.
> Browser compatability is a bit of an unknown for me, I only have IE6
> and FireFox to test on, is there any online utility that can show what
> platforms script will run on ???
I know of none.
Please trim parts you are not referring to (and reply using Google Groups'
"More options" Reply instead if you must use GG), and get a real name.
PointedEars
kangax
[...]
> I have already referred you to my dhtml.js, which uses a more sophisticated,
> most efficient, and least error-prone approach. UTSL.
A bit off-topic here, but looking at your dhtml.js [1], why does `gEBCN`
use `new RegExp("\\b" + s + "\\b");`? I'm sure you know that this
matches wrong values (e.g. "catching" class="foo-bar" elements when
asked for class="foo" ones). On a side note, is there a reason why
native `document.getElementsByClassName` is not used in clients where it
is available (and behaves as expected)?
[...]
[1] http://pointedears.de/scripts/dhtml.js
--
kangax
Laurent vilday
> Thomas 'PointedEars' Lahn :
>
>> I have already referred you to my dhtml.js, which uses a more
>> sophisticated,
>> most efficient, and least error-prone approach. UTSL.
>
> A bit off-topic here, but looking at your dhtml.js [1]
Don't get too worry about what you can found in this file. This dhtml.js
file (among most, if not all, of the others files at this german URL)
must *not* be used or even looked after.
It is :
- full of useless documentation (I think I get it, this stuff is totally
(C) 2002-2008 Lans, he can keep it anyway)
- provided with the viral GPL licence... sigh.
- full of typos (+ + in ligne 365, or using "," when ";" *is* needed in
line 1188, but many more all over every required files)
- relying sometimes on automatic semi colon insertion and is missing
some open and close braces. A *very* bad practice from a library
perspective.
- not coherent with it's use of dot notation, sometimes yes and
sometimes nope.
- providing *NOT* tested code (for instance the getFirstChild() function
is funny, it will not give the same result *at* *all* with different
user agent, the proof at the end [1])
- linking to many 404 (http://pointedears.de/scripts/JSdoc/ for instance)
- using a *LOT* of globals functions, which is once again not a very
good practice from a library perspective (globals from dhtml.js = DHTML,
DHTMLException, _addEventListener, _addEventListenerCapture,
_replaceEventListener, addOption, createElement, dhtml,
disableElementGroup, disableElements, display, getAbsPos, getAttr,
getCheckedRadio, getCont, getElem, getElementsByTabIndex, getFirstChild,
getParent, getStyleProperty, getTextContent, hasStyleProperty, hoverImg,
loadScript, removeOptions, selectRadioBtn, setAttr, setCont,
setStyleProperty, setTextContent, setValue, visibility, visible)
- full of very funny tests like this one for instance :
this.isIE4DOM = typeof document.all == "object" && !this.isOpera;
this.IE4DOM = 2;
this.DOM = this.supported && (this.isIE4DOM && this.IE4DOM);
- using "x == null" or "x == 0" when the author keeps arguing here it
should be "x === null" and "x === 0" (it is a funny "do what I say not
what I do" situation)
- ...
And so on all over every files, types.js and object.js, which are
required, got their load of funny javascript errors and typos too (the
not filtered "for in" are so funny to remember when I hear the author
yelling about it on others people).
Well in my opinion - which worth nothing I know it very well - noone
should use or even look at it, this utter crap *never* used in real
situation. And it is absolutly not a surprise to me !
[1] Here is the proof :
* IE :
- "YES"
- "YES"
* FF, Opéra and probably the rest of the world :
- "undefined"
- then got an error (o.firstChild is null in line 482 dhtml.js)
Doesn't looks very cross-browser to me.
The author of this weird javascript code is giving me good laugh
everytime he is sending someone to his library.
<!DOCTYPE
HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<title>Full of errors</title>
<script type="text/javascript"
src="http://pointedears.de/scripts/object.js"></script>
<script type="text/javascript"
src="http://pointedears.de/scripts/types.js"></script>
<script type="text/javascript"
src="http://pointedears.de/scripts/dhtml.js"></script>
</head>
<body>
<ul id="myul">
<li>YES</li>
</ul>
<script type="text/javascript">
var ul = dhtml.gEBI('myul');
var li = dhtml.getFirstChild(ul);
alert(li.innerHTML);
alert(dhtml.getCont(li));
</script>
</body>
</html>
--
laurent
Thomas 'PointedEars' Lahn
> Thomas 'PointedEars' Lahn wrote:
>> sophisticated, most efficient, and least error-prone approach. UTSL.
>
> A bit off-topic here,
I don't think so.
> but looking at your dhtml.js [1], why does `gEBCN` use `new RegExp("\\b"
> + s + "\\b");`? I'm sure you know that this matches wrong values (e.g.
> "catching" class="foo-bar" elements when asked for class="foo" ones).
Good catch, I wasn't aware of that at the time. Will be changed in the next
release.
> On a side note, is there a reason why native
> `document.getElementsByClassName` is not used in clients where it is
> available (and behaves as expected)?
document.gEBCN() is a fairly new feature, the implementation of the WHATWG
Web Applications 1.0 (HTML 5) Working Draft. It was not implemented at the
time the online version of the library was last updated (see the build
version). I became aware of it only a month or so ago, through postings
here. However, given that I have not done sufficient testing of it yet, and
the Working Draft status of its specification, I don't think it will be used
in the next release.
PointedEars
spa...@corbetteer.co.uk
>>Also use document.all[...] as a fallback for the former (necessary
>>only for IE 4 and older).
is this really nesisary, as far as i can tell not many people must use
this browser. In fact looking at the stats for my site, I have had NO
visitors with this browser over the past 12 months. (unless its the
unknown)
Looking at the list below which shows visits to my site over the past
12 months, is there any point in not just assuming that all browsers
are "getElementById" browsers. Seems to me that i would have to put in
a lot of effort to accomodate someone who may never visit.
Internet Explorer 6.x------157088
Internet Explorer 7.x-------42384
web bots--------------------15544
Firefox 2.0x-----------------7976
Mozilla/5.0------------------4952
Internet Explorer 8.x--------2136
(unknown) ---------------------912
Mozilla/4.0-------------------440
Firefox 3.1x------------------320
Fedora/2.0.0.18---------------280
Opera 9.x ---------------------264
Charlotte/1.1-----------------194
Firefox 1.5x------------------176
Konqueror 2.x-----------------144
Firefox 1.0x-------------------24
Opera 6.x ----------------------18
voyager/2.0--------------------16
Opera 7.x ----------------------13
PycURL/7.18.0-------------------5
SonyEricssonK800i---------------3
Charlotte/1.0t------------------2
Internet Explorer 5.5-----------2
the webbots are largely made up by yahoo slurp, presumably they
download all the pictures as well, what a waste of bandwidth, I may
configure some php to just let webots have a one byte image.
Thomas 'PointedEars' Lahn
>>> pointedEars wrote
>>> Also use document.all[...] as a fallback for the former (necessary
>>> only for IE 4 and older).
>
> is this really nesisary,
Depends.
> as far as i can tell not many people must use this browser.
It is not the browser but the layout engine of it that counts. How can
you know in which applications the MSHTML Browser Component (MSHTML.dll),
version 4.0 is used?
> In fact looking at the stats for my site, I have had NO
> visitors with this browser over the past 12 months. (unless its the
> unknown)
>
> Looking at the list below which shows visits to my site over the past
> 12 months, is there any point in not just assuming that all browsers
> are "getElementById" browsers. Seems to me that i would have to put in
> a lot of effort to accomodate someone who may never visit.
>
> Internet Explorer 6.x------157088
> Internet Explorer 7.x-------42384
To begin with, your "statistics" contradicts a current, more reliable market
analysis which says that IE 7 has greater a market share than IE 6 by now:
<http://marketshare.hitslink.com/>
<http://marketshare.hitslink.com/browser-market-share.aspx?qprid=3>
<http://marketshare.hitslink.com/browser-market-share.aspx?qprid=3&qpdt=1&qpct=4&qptimeframe=M&qpsp=108&qpnp=11>
If you really have more visitors with IE 6 than IE 7 (which is doubtful),
maybe it is because you have optimized your code for IE 6 and ignored the
changes in IE 7.
And, of course, all IEs have "Mozilla/4.0" in their User-Agent header.
> web bots--------------------15544
> Firefox 2.0x-----------------7976
> Mozilla/5.0------------------4952
Firefox 2.0.x *is* a Mozilla/5.0 browser.
> Internet Explorer 8.x--------2136
Still beta.
> (unknown) ---------------------912
Pardon?
> Mozilla/4.0-------------------440
That would be Netscape 4.x and might be other browsers that have
"Mozilla/4.0" in their User-Agent header but cannot be identified as a
specific browser.
> Firefox 3.1x------------------320
Firefox 3.1.x is beta, but a Mozilla/5.0 browser.
> Fedora/2.0.0.18---------------280
> Opera 9.x ---------------------264
Opera can have "Mozilla/4.0" in its UA header.
> Charlotte/1.1-----------------194
> Firefox 1.5x------------------176
Firefox 1.5.x is a Mozilla/5.0 browser.
> Konqueror 2.x-----------------144
> Firefox 1.0x-------------------24
Firefox 1.0.x is a Mozilla/5.0 browser.
> Opera 6.x ----------------------18
> voyager/2.0--------------------16
> Opera 7.x ----------------------13
See above.
> PycURL/7.18.0-------------------5
> SonyEricssonK800i---------------3
> Charlotte/1.0t------------------2
> Internet Explorer 5.5-----------2
>
> the webbots are largely made up by yahoo slurp, presumably they
> download all the pictures as well, what a waste of bandwidth, I may
> configure some php to just let webots have a one byte image.
Your "statistics" of the past are obviously flawed, and also bear no meaning
regarding present or future use. STFW.
<http://PointedEars.de/scripts/test/whatami>
PointedEars
Conrad Lender
>>>pointedEars wrote
>>>Also use document.all[...] as a fallback for the former (necessary
>>>only for IE 4 and older).
>
> is this really nesisary, as far as i can tell not many people must use
> this browser. In fact looking at the stats for my site, I have had NO
> visitors with this browser over the past 12 months. (unless its the
> unknown)
If it's your site, it's your call. If you don't mind alienating users
with old browsers, you can choose not to support them. Personally, I
draw the line even later, and won't support IE < 5.5 unless that's
explicitly required. Others here may disagree; for me, the additional
testing and workarounds are just not worth my time anymore. I think
users can be expected to upgrade their browsers once every ten years...
> the webbots are largely made up by yahoo slurp, presumably they
> download all the pictures as well, what a waste of bandwidth, I may
> configure some php to just let webots have a one byte image.
That's easier done with a robots.txt file.
- Conrad
dhtml
> kangax :
>> Thomas 'PointedEars' Lahn :
>>
>>> I have already referred you to my dhtml.js, which uses a more
>>> sophisticated,
>>> most efficient, and least error-prone approach. UTSL.
>>
>> A bit off-topic here, but looking at your dhtml.js [1]
>> [1] http://pointedears.de/scripts/dhtml.js
>
> Don't get too worry about what you can found in this file. This dhtml.js
> file (among most, if not all, of the others files at this german URL)
> must *not* be used or even looked after.
>
> It is :
>
It is crap. Anyone with half a clue who visited that site already noticed.
You pointed out the obvious shortcomings in the crap that Thomas
attempts to pass off as code. This speaks to the nature of Thomas.
Thomas Lahn is hyper-critical of others and unable (or unwilling) to see
his own shortcomings.
Thomas Lahn tries to make the appearance that he is knowledgeable. He
does this by imparting knowledge he has accrued over the years and by
talking down others in his very frequent posts.
It just shows how worthless Thomas Lahn thinks he really is.
More from a post from 2006:
http://groups.google.com/group/comp.lang.javascript/msg/c81bd16ffd734a20?dmode=source
Garrett Smith
--
comp.lang.javascript FAQ <URL: http://jibbering.com/faq/ >
spa...@corbetteer.co.uk
>
> > Internet Explorer 6.x------157088
> > Internet Explorer 7.x-------42384
>
> To begin with, your "statistics" contradicts a current, more reliable market
> analysis which says that IE 7 has greater a market share than IE 6 by now:
>
>
> PointedEars
Just looking at the past month IE6 62% IE7 9%
Maybe its more to do with the people that are looking at my site,
hillwalkers don't go in for new browsers :-) who knows
> If you really have more visitors with IE 6 than IE 7 (which is doubtful),
> maybe it is because you have optimized your code for IE 6 and ignored the
> changes in IE 7
I doubt people are taking one look, declaring this boy has made this
for IE6 and switch off in disgust!
spa...@corbetteer.co.uk
> That's easier done with a robots.txt file.
>
O' Explain more, that sounds interesting
stuart
Thomas 'PointedEars' Lahn
> 'PointedEars' wrote:
>>> Internet Explorer 6.x------157088
>>> Internet Explorer 7.x-------42384
>> To begin with, your "statistics" contradicts a current, more reliable market
>> analysis which says that IE 7 has greater a market share than IE 6 by now:
>
> Just looking at the past month IE6 62% IE7 9%
>
> Maybe its more to do with the people that are looking at my site,
> hillwalkers don't go in for new browsers :-) who knows
If your numbers were based on fact, for *now* that might be so. But imagine
what could happen if you designed your site usable for visitors with IE 7
too, let alone for visitors with other user agents. They don't need to get
all the eye-candy, I'm talking about pure accessibility (in double sense).
>> If you really have more visitors with IE 6 than IE 7 (which is doubtful),
>> maybe it is because you have optimized your code for IE 6 and ignored the
>> changes in IE 7
>
> I doubt people are taking one look, declaring this boy has made this
> for IE6 and switch off in disgust!
You miss the point. Visitors will seldom be experienced enough *why* it
does not work, only *that* it does not work. And they will blame you first,
not their program (of which they may not do anything about, especially in
the IE 6 vs. 7 case) and go on to the competition. That's why it's
(commercial) suicide to optimize a Web site for one browser or a subset of
browsers without apparent need.
PointedEars, with a fitting random signature
--
Anyone who slaps a 'this page is best viewed with Browser X' label on
a Web page appears to be yearning for the bad old days, before the Web,
when you had very little chance of reading a document written on another
computer, another word processor, or another network. -- Tim Berners-Lee
Thomas 'PointedEars' Lahn
> Laurent vilday wrote:
>> kangax :
>>> Thomas 'PointedEars' Lahn :
>>>> I have already referred you to my dhtml.js, which uses a more
>>>> sophisticated,
>>>> most efficient, and least error-prone approach. UTSL.
>>> A bit off-topic here, but looking at your dhtml.js [1]
>>> [1] http://pointedears.de/scripts/dhtml.js
>> Don't get too worry about what you can found in this file. This dhtml.js
>> file (among most, if not all, of the others files at this german URL)
>> must *not* be used or even looked after.
>>
>> It is :
>
> It is crap. Anyone with half a clue who visited that site already noticed.
Both my Web site and my script libraries are in part a bit outdated for
sure. (As you know, I am still working on the next release of dhtml.js,
personal and business life made it rather hard for me to keep pace last
year.) The method I use in dhtml.js and recommended to
spa...@corbetteer.co.uk for solving (t)his problem, is still a good one, though.
> You pointed out the obvious shortcomings in the crap that Thomas
> attempts to pass off as code. This speaks to the nature of Thomas.
>
> Thomas Lahn is hyper-critical of others and unable (or unwilling) to see
> his own shortcomings.
As you can see in e.g. <news:49608BA7...@PointedEars.de>, I am *always*
open to *constructive* criticism. The rest goes to /dev/null, and so can
you. FOAD.
PointedEars
spa...@corbetteer.co.uk
> >> If you really have more visitors with IE 6 than IE 7 (which is doubtful),
> >> maybe it is because you have optimized your code for IE 6 and ignored the
> >> changes in IE 7
>
> > I doubt people are taking one look, declaring this boy has made this
> > for IE6 and switch off in disgust!
>
> You miss the point. Visitors will seldom be experienced enough *why* it
> does not work, only *that* it does not work. And they will blame you first,
> not their program (of which they may not do anything about, especially in
> the IE 6 vs. 7 case)
You have me paranoid now, maybe my stuff don't work in IE7 ! I only
have IE6 myself so wouldnt know!
Maybe somebody could go and try it for me. The only place where there
is any real scripting is on http://www.corbetteer.co.uk/munros/map/game/munrogame.php
and the associated leaderboard, it is on the leaderboard where you
have helped me in positioning the little green bar that links the
score to the table when you click on "analyse" (and very proud of it
I am) So thank You. I am sure you will blow a fuse if you look at my
scripting, it will undoubtably be full of bad practise and browser
incompatability! but hey, it works (just) and I have learned loads
writing it
thanks again
Thomas 'PointedEars' Lahn
> Thomas 'PointedEars' Lahn wrote:
>>>> If you really have more visitors with IE 6 than IE 7 (which is doubtful),
>>>> maybe it is because you have optimized your code for IE 6 and ignored the
>>>> changes in IE 7
>>> I doubt people are taking one look, declaring this boy has made this
>>> for IE6 and switch off in disgust!
>> You miss the point. Visitors will seldom be experienced enough *why* it
>> does not work, only *that* it does not work. And they will blame you first,
>> not their program (of which they may not do anything about, especially in
>> the IE 6 vs. 7 case)
>
> You have me paranoid now,
However, that wasn't my intention. You should only be aware of the issue.
> maybe my stuff don't work in IE7 ! I only have IE6 myself so wouldnt know!
(It's getting slightly off-topic, but back on-topic later:)
For successful Web authoring, I recommend you have at least a handful of
different user agents handy. Most of them can be downloaded for free, for
various operating systems, so that shouldn't be much of a problem.
If you have Windows XP or later, I suggest you update to IE 7 [1]; then you
can set up virtualization (e.g. Microsoft Virtual PC which can be downloaded
for free [2]) where you can still run IE 6 (IE 6 Standalone as provided by
the evolt.org archive [3], with IE 7 installed, seems to work for detecting
problems with script language features and the DOM, but it does not provide
the full layout engine [4]).
For another example, I am mostly on Debian GNU/Linux again [5], and even
though IE is rather Windows software, I can run the standalone versions 4.0
to 6.0 from the evolt.org archive through Wine, the Windows emulator [6], so
that I don't have to reboot to Windows XP.[7]
QEMU [8] is another free open-source possibility for emulation. (I had it
run my Linux system, on the other partition, in Windows XP before.[9])
> Maybe somebody could go and try it for me. The only place where there
> is any real scripting is on http://www.corbetteer.co.uk/munros/map/game/munrogame.php
I don't think native JScript objects will be much of a problem [10], but DOM
scripting, CSS, and standards compliance as a whole. In our company, we
frequently have to use stylesheet workarounds powered by
Conditional-Comments and style expressions for IE 6 in Web sites that are
otherwise standards-compliant and display properly in IE 7; sometimes
vice-versa.[11]
Also observe the changes in the security model in IE 7, especially if you
use SSL/TLS-encrypted HTTP connections as it can happen that a secure Web
site that displays fine in IE 6 won't display in IE 7; instead, a warning
will be displayed.[12]
BTW, in order to use your real name when posting with Google Groups, you
only have to subscribe to this newsgroup and update your profile
accordingly. BTDT.
HTH
PointedEars
___________
[1] <http://windowsupdate.microsoft.com/>
[2]
<http://www.microsoft.com/downloads/details.aspx?displaylang=en&familyid=04d26402-3199-48a3-afa2-2dc0b40a73b6>
[3] <http://browsers.evolt.org/?ie/>
[4] e.g. the workaround for transparent PNGs does not work then
[5] <http://www.debian.org/>
[6] <http://www.winehq.org/>
[7] <http://www.tatanka.com.br/ies4linux/page/Main_Page>
[8] <http://bellard.org/qemu/>
[9] <http://www.h7.dion.ne.jp/~qemu-win/>
[10] <http://pointedears.de/es-matrix/>
[11] <http://msdn.microsoft.com/en-us/library/ms537512.aspx>
[12] <http://blogs.msdn.com/ie/archive/2005/12/07/501075.aspx> pp.
SteveYoungTbird
>
> For successful Web authoring, I recommend you have at least a handful of
> different user agents handy. Most of them can be downloaded for free, for
> various operating systems, so that shouldn't be much of a problem.
>
> If you have Windows XP or later, I suggest you update to IE 7 [1]; then you
> can set up virtualization (e.g. Microsoft Virtual PC which can be downloaded
> for free [2]) where you can still run IE 6 (IE 6 Standalone as provided by
> the evolt.org archive [3], with IE 7 installed, seems to work for detecting
> problems with script language features and the DOM, but it does not provide
> the full layout engine [4]).
>
> For another example, I am mostly on Debian GNU/Linux again [5], and even
> though IE is rather Windows software, I can run the standalone versions 4.0
> to 6.0 from the evolt.org archive through Wine, the Windows emulator [6], so
> that I don't have to reboot to Windows XP.[7]
IEs4Linux at http://www.tatanka.com.br/ies4linux/page/Installation have
Internet Explorer 6, 5.5, 5 and a Beta version of IE7 that run on Wine.
I have all including IE7 installed on my Ubuntu Hardy system and have
not had any problems testing javascript code with them. I wouldn't use
the to surf with mind you.
Regards, Steve.
Conrad Lender
That's a little off-topic for this group. There's a good introduction on
Wikipedia: http://en.wikipedia.org/wiki/Robots.txt
- Conrad
kangax
[...]
> document.gEBCN() is a fairly new feature, the implementation of the WHATWG
> Web Applications 1.0 (HTML 5) Working Draft. It was not implemented at the
> time the online version of the library was last updated (see the build
> version). I became aware of it only a month or so ago, through postings
> here. However, given that I have not done sufficient testing of it yet, and
> the Working Draft status of its specification, I don't think it will be used
> in the next release.
I don't have time to check this myself right now, but as per google's
doctype (which serves nicely as a basic reference) [1] it looks like
`document.getElementsByClassName` is implemented in quite few of the
"modern" clients (including FF3 , Safari 3, Opera 9 and Chrome).
It's not clear how compliant these implementations are, of course, but I
don't think there should be major glitches (given trivial specification
and a relatively widespread usage).
[1]
http://code.google.com/p/doctype/wiki/DocumentGetElementsByClassNameMethod
--
kangax
RobG
> 'PointedEars' wrote:
>
> > > Internet Explorer 6.x------157088
> > > Internet Explorer 7.x-------42384
>
> > To begin with, your "statistics" contradicts a current, more reliable market
> > analysis which says that IE 7 has greater a market share than IE 6 by now:
>
> > PointedEars
>
> Just looking at the past month IE6 62% IE7 9%
>
> Maybe its more to do with the people that are looking at my site,
> hillwalkers don't go in for new browsers :-) who knows
It is also a bit suspect that some reasonably popular browsers are not
represented at all, such as Safari and Chrome, which should have 1% to
5% representation. Perhaps they are in the "Unkonwn" basket.
> > If you really have more visitors with IE 6 than IE 7 (which is doubtful),
> > maybe it is because you have optimized your code for IE 6 and ignored the
> > changes in IE 7
>
> I doubt people are taking one look, declaring this boy has made this
> for IE6 and switch off in disgust!
So do I, more likely your statistics software is miscounting
"visits". You might find the following article interesting:
<URL: http://virtuelvis.com/archives/2005/05/statistics-nonsense >
Incidentally, your sites seems to work in Safari 3.2.1, check your log
to see if my visit figures in your stats. It is pretty much unusable
in Mobile Safari and I suspect any other mobile browser.
Put your script into an external script file, then validate at:
<URL: http://validator.w3.org/ >
(putting the script in an external file will get rid of many spurious
validation errors so you can find the real ones).
--
Rob
Jeremy J Starcher
> IEs4Linux at http://www.tatanka.com.br/ies4linux/page/Installation have
> Internet Explorer 6, 5.5, 5 and a Beta version of IE7 that run on Wine.
> I have all including IE7 installed on my Ubuntu Hardy system and have
> not had any problems testing javascript code with them. I wouldn't use
> the to surf with mind you.
I'm a big fan of IEs4Linux, even have their easter-egg version installed
(Hint: Use the Source, Luke).
However, I have run across one instance where it was using slightly
different DLLs than "Real" install of IE6. I /think/ the real version of
IE6 was behind a patch level for something, but its been long enough I
don't recall.
Its a valuable tool, but sometimes nothing beats a virtual machine and a
retail CD.
kangax
[...]
> As you can see in e.g. <news:49608BA7...@PointedEars.de>, I am *always*
> open to *constructive* criticism. [...]
Looking further at your dhtml.js, I'm a bit surprised to see named
function expressions used throughout the library. I try to stay away
from those due to a well-known JScript bug (which, as I'm sure you know,
leads to named function expressions being interpreted as function
declarations).
IIRC, Cornford, some time ago, demonstrated how actually *2* different
Function objects are created when named function expression is
encountered by an engine.
I just ran a simple test which somewhat replicates the structure you use
in dhtml.js:
(function(){
var fnOuter = (function(){
// assign to `fnInner` property of a global object for comparison
this.fnInner = F;
if (/* feature test 1 */ true) {
return function F() {
return 1;
};
}
else if (/* feature test 2 */ false) {
return function F() {
return 2;
};
}
else {
return function F() {
return 3;
};
}
})();
document.write([fnInner, fnOuter].join("<br>"));
})();
I can't tell if IE creates *3* function objects in this case, but it's
clearly visible that at least *2* distinct objects are indeed there.
Moreover, a closure is formed with a reference to function #3 in the
scope of function #1 (and others, for that matter). One can observe this
by simply changing body of a function #1 to `return F;` and seeing how
`F` indeed resolves to function #3 (when `fnOuter` is called). Returned
function clearly carries a burden of other ones (that it closes over) -
at least the last named function expression that is parsed as a function
declaration is constantly present in memory after expression evaluation.
Were you ever concerned about such "memory hog"? Have you, perhaps,
performed any tests on this matter? I'm curious if this issue is
significant enough to worry about.
--
kangax
spa...@corbetteer.co.uk
> > I doubt people are taking one look, declaring this boy has made this
> > for IE6 and switch off in disgust!
>
> So do I, more likely your statistics software is miscounting
> "visits". You might find the following article interesting:
>
> <URL:http://virtuelvis.com/archives/2005/05/statistics-nonsense>
My stats come from my web space provider, they collate all this stuff
FOC, so thats why its probably dodgy :-)
still, it keeps me entertained looking at it!
> Put your script into an external script file, then validate at:
>
> <URL:http://validator.w3.org/>
>
Thanks for that, showed up quite a few errors.
Thomas 'PointedEars' Lahn
> SteveYoungTbird wrote:
> > IEs4Linux athttp://www.tatanka.com.br/ies4linux/page/Installationhave
> > Internet Explorer 6, 5.5, 5 and a Beta version of IE7 that run on Wine.
> > I have all including IE7 installed on my Ubuntu Hardy system and have
> > not had any problems testing javascript code with them. I wouldn't use
> > the to surf with mind you.
>
> I'm a big fan of IEs4Linux, even have their easter-egg version installed
> (Hint: Use the Source, Luke).
>
> However, I have run across one instance where it was using slightly
> different DLLs than "Real" install of IE6. I /think/ the real version of
> IE6 was behind a patch level for something, but its been long enough I
> don't recall.
ACK. I have the particular problem that my IE 7.0 from IEs4Linux
runs, but it just doesn't navigate. Loading a Web site takes forever,
and nothing is displayed in the viewport at all. I tried reinstalling
the newest beta, tried even the IE6 proxy settings hack, but to no
avail. If anyone solved this problem, please help. TIA.
PointedEars
Jeremy J Starcher
> ACK. I have the particular problem that my IE 7.0 from IEs4Linux runs,
> but it just doesn't navigate. Loading a Web site takes forever, and
> nothing is displayed in the viewport at all. I tried reinstalling the
> newest beta, tried even the IE6 proxy settings hack, but to no avail.
> If anyone solved this problem, please help. TIA.
Hmmm... I just checked my IE4Linux IE7 and have the same problem on an
installation that *was* working.
I'll blame it on a change in WINE till a better idea comes alone.
Thomas 'PointedEars' Lahn
> Thomas 'PointedEars' Lahn wrote:
>> open to *constructive* criticism. [...]
>
> Looking further at your dhtml.js, I'm a bit surprised to see named
> function expressions used throughout the library. I try to stay away
> from those due to a well-known JScript bug (which, as I'm sure you know,
> leads to named function expressions being interpreted as function
> declarations).
Yes, I know. There are several reasons for this:
Once upon a time, when this library was conceived, I thought there were
implementations to consider that did not support anonymous function
expressions but that did support named function expressions, so I was very
careful not to use the former in any piece of script code I wrote (this was
well before the ECMAScript Support Matrix was conceived). In addition, the
identifier caused and still causes each the corresponding expression to be
visible in the Outline View of my IDE, Eclipse (formerly with JSEclipse, now
with JSDT) which makes maintainance a lot easier.
Then I read about the issue here, but was unsure about what to do about it
in my code. Did I involuntarily spoil the enclosing scope with this?
Undoubtedly. Was that an issue? No, the enclosing scope was that of the
DHTML() constructor.
If I removed the identifier to avoid this JScript bug, editing would become
harder, but what could be the benefit I would get for the hassle? The
Function object would be referred to in either case, and so would stay in
memory.
And finally, a question of principle: Why should I accomodate JScript bugs
that are not fatal? Would I not help this bug to survive then?
So I have not done anything serious about it yet.
> IIRC, Cornford, some time ago, demonstrated how actually *2* different
> Function objects are created when named function expression is
> encountered by an engine.
>
> I just ran a simple test which somewhat replicates the structure you use
> in dhtml.js:
>
> (function(){
> var fnOuter = (function(){
>
> // assign to `fnInner` property of a global object for comparison
> this.fnInner = F;
>
> if (/* feature test 1 */ true) {
> return function F() {
> return 1;
> };
> }
> else if (/* feature test 2 */ false) {
> return function F() {
> return 2;
> };
> }
> else {
> return function F() {
> return 3;
> };
> }
> })();
>
> document.write([fnInner, fnOuter].join("<br>"));
>
> })();
>
> I can't tell if IE creates *3* function objects in this case, but it's
> clearly visible that at least *2* distinct objects are indeed there.
I think this is in part a Mark II Heisenbug, though. IOW, if you explicitly
refer to the objects, they cannot be garbage-collected and so they must be
still there.
Since JScript evaluates the expressions like declaration-statements, I am
pretty sure there are 2 Function objects here (that are not going to be
garbage-collected anytime soon) at most; the second "statement" overwrites
the reference created by the first, and so forth. That would explain why
`fnInner' refers to the Function object that, when called, returned 3, while
`fnOuter' refers to the Function object that, when called, returned 1: the
wrong variable instantiation would happen after control entered the local
execution context of the outer (anonymous) function, before the execution of
statements; on execution the assignments would take place, and then the
Function object reference would be returned.
> Moreover, a closure is formed with a reference to function #3 in the
> scope of function #1 (and others, for that matter). One can observe this
> by simply changing body of a function #1 to `return F;` and seeing how
> `F` indeed resolves to function #3 (when `fnOuter` is called). Returned
> function clearly carries a burden of other ones (that it closes over) -
> at least the last named function expression that is parsed as a function
> declaration is constantly present in memory after expression evaluation.
Please forgive my ignorance, but isn't a closure formed here anyway?
> Were you ever concerned about such "memory hog"?
No, as I think of these Function objects as rather small in memory. But I
might be mistaken.
> Have you, perhaps, performed any tests on this matter?
No.
> I'm curious if this issue is significant enough to worry about.
Add me. But how does one *reliably* detect if there are memory issues?
PointedEars
kangax
Fair enough. I actually wasn't concerned about identifier leaking onto
enclosing scope (since, IIRC, there was a separate "wrapper" around
every such forking in dhtml.js or at least a library-global wrapper).
>
>> IIRC, Cornford, some time ago, demonstrated how actually *2* different
>> Function objects are created when named function expression is
>> encountered by an engine.
>>
>> I just ran a simple test which somewhat replicates the structure you use
>> in dhtml.js:
[snip test]
>> I can't tell if IE creates *3* function objects in this case, but it's
>> clearly visible that at least *2* distinct objects are indeed there.
>
> I think this is in part a Mark II Heisenbug, though. IOW, if you explicitly
> refer to the objects, they cannot be garbage-collected and so they must be
> still there.
>
> Since JScript evaluates the expressions like declaration-statements, I am
> pretty sure there are 2 Function objects here (that are not going to be
> garbage-collected anytime soon) at most; the second "statement" overwrites
> the reference created by the first, and so forth. That would explain why
> `fnInner' refers to the Function object that, when called, returned 3, while
> `fnOuter' refers to the Function object that, when called, returned 1: the
> wrong variable instantiation would happen after control entered the local
> execution context of the outer (anonymous) function, before the execution of
> statements; on execution the assignments would take place, and then the
> Function object reference would be returned.
Right. From what we can observe, it makes sense to assume that using
named function expressions leads to an additional function object being
"trapped" in a closure of returning function. An object that wouldn't be
created if named function expression wasn't used and so JScript bug
wouldn't have been triggered. As I'm sure you understand, the increased
memory consumption (of such "trapped" functions) is what my main concern
was. It's a trade off between debugging convenience and presumably
higher memory consumption.
>
>> Moreover, a closure is formed with a reference to function #3 in the
>> scope of function #1 (and others, for that matter). One can observe this
>> by simply changing body of a function #1 to `return F;` and seeing how
>> `F` indeed resolves to function #3 (when `fnOuter` is called). Returned
>> function clearly carries a burden of other ones (that it closes over) -
>> at least the last named function expression that is parsed as a function
>> declaration is constantly present in memory after expression evaluation.
>
> Please forgive my ignorance, but isn't a closure formed here anyway?
Yes, it is always formed, of course. I just wanted to clarify what and
why things stay present in memory after execution context of outer
function exits.
>
>> Were you ever concerned about such "memory hog"?
>
> No, as I think of these Function objects as rather small in memory. But I
> might be mistaken.
>
>> Have you, perhaps, performed any tests on this matter?
>
> No.
>
>> I'm curious if this issue is significant enough to worry about.
>
> Add me. But how does one *reliably* detect if there are memory issues?
I'm thinking of making a test, comparing memory use of both "types" of
outer functions. One such function would use named function expressions;
another one wouldn't. I'm curious to see the difference in memory use
(perhaps, using Process Explorer [1] on Windows).
On the other hand, I have a feeling that in real life this memory
increase can be safely ignored; After all, such offending functions are
hardly meant to be created in large amounts : )
[1] http://technet.microsoft.com/en-us/sysinternals/bb896653.aspx
--
kangax
kangax
> Thomas 'PointedEars' Lahn wrote:
>> Add me. But how does one *reliably* detect if there are memory issues?
>
> I'm thinking of making a test, comparing memory use of both "types" of
> outer functions. One such function would use named function expressions;
> another one wouldn't. I'm curious to see the difference in memory use
> (perhaps, using Process Explorer [1] on Windows).
>
> On the other hand, I have a feeling that in real life this memory
> increase can be safely ignored; After all, such offending functions are
> hardly meant to be created in large amounts : )
Just realized that we can use the following pattern to have a
descriptive identifier at no cost (as it seems):
var fnOuter = (function(){
var f;
if (true) {
f = function F() {
return 1;
};
}
else if (false) {
f = function F() {
return 2;
};
}
else {
f = function F() {
return 3;
};
}
F = null;
return f;
})();
What do you think?
--
kangax
jdalton
I think your `F = null;` should be `var F = null;` so you don't create
a property on the global object in environments
that don't have this bug.
- JDD
kangax
Thanks. I missed that.
--
kangax
kangax
> kangax wrote:
>> Were you ever concerned about such "memory hog"?
>
> No, as I think of these Function objects as rather small in memory. But I
> might be mistaken.
>
>> Have you, perhaps, performed any tests on this matter?
>
> No.
>
>> I'm curious if this issue is significant enough to worry about.
>
> Add me. But how does one *reliably* detect if there are memory issues?
I published an article on a subject of named function expressions a
couple of days ago
<http://yura.thinkweb2.com/named-function-expressions/>. There are some
tests related to JScript issue we discuss here. You might be
interested to look at them.
I'm also open to any suggestions/corrections, of course.
--
kangax
Garrett Smith
There is no need to use an empty statement following a FunctionDeclaration.
You've taken APE.dom.contains[1], renamed it to "contans" and did not
mention where the code came from and you know exactly where it came from
and we have discussed that in email from about 6 weeks ago.
http://github.com/GarrettS/ape-javascript-library/blob/2709314ccf088f94fd293bc2400b1212d8297e76/src/dom/traversal-f.js#L22
Thats copyright violation.
I don't feel like reviewing much more of that, for reasons which should
be obvious.
I'm not quite sure what your problem is. You seem to want to keep it a
secret.
Garrett
--
The official comp.lang.javascript FAQ:
http://jibbering.com/faq/
kangax
> kangax wrote:
[...]
>> I'm also open to any suggestions/corrections, of course.
>>
>
> There is no need to use an empty statement following a FunctionDeclaration.
>
> You've taken APE.dom.contains[1], renamed it to "contans" and did not
> mention where the code came from and you know exactly where it came from
Garrett, I did not rename anything. I did take `contains` "as is" from
APE of course. I should have mentioned where it is taken from but
apparently overlooked it. I apologize for that; the article is now
updated with a mention of `contains` being part of APE.
> and we have discussed that in email from about 6 weeks ago.
> http://github.com/GarrettS/ape-javascript-library/blob/2709314ccf088f94fd293bc2400b1212d8297e76/src/dom/traversal-f.js#L22
>
> Thats copyright violation.
>
> I don't feel like reviewing much more of that, for reasons which should
> be obvious.
>
> I'm not quite sure what your problem is. You seem to want to keep it a
> secret.
I'm not quite sure which problem are you talking about. I certainly
don't have any problems that I am keeping in secret.
Please, let me know if there are any other oversights.
--
kangax
Garrett Smith
> Garrett Smith wrote:
>> kangax wrote:
> [...]
>>> I'm also open to any suggestions/corrections, of course.
>>>
>>
>> There is no need to use an empty statement following a
>> FunctionDeclaration.
>>
>> You've taken APE.dom.contains[1], renamed it to "contans" and did not
>> mention where the code came from and you know exactly where it came from
>
> Garrett, I did not rename anything. I did take `contains` "as is" from
> APE of course. I should have mentioned where it is taken from but
Yes.
// (GS) contans?
var contans = (function() {
var docEl = document.documentElement;
if (typeof docEl.compareDocumentPosition != 'undefined') {
return function(el, b) {
return (el.compareDocumentPosition(b) & 16) !== 0;
}
}
else if (typeof docEl.contains != 'undefined') {
return function(el, b) {
return el !== b && el.contains(b);
}
}
return function(el, b) {
if (el === b) return false;
// (GS) Should use !==.
while (el != b && (b = b.parentNode) != null);
return el === b;
}
})() // (GS) don't rely on automatic semicolon insertion.
[...]
>
> Please, let me know if there are any other oversights.
>
Time to go the the gym.
Richard Cornford
<snip>
> The official comp.lang.javascript FAQ:
<snip>^^^^^^^^
This reads as if there is an unofficial group FAQ somewhere.
Richard.
Andrew Poulos
How do know there isn't?
Andrew Poulos