Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

viewing ajax source

65 views
Skip to first unread message

bill

unread,
Aug 9, 2009, 3:57:51 PM8/9/09
to
I just started working with AJAX, using the prototype.js scripts.
All is going well except for a small problem. To debug the
problem I need to see the source that the AJAX script is returning.

I have a debug div that the script returns the data to, but I
can't figure out a way to see exactly what is being returned.

Any suggestions ?

bill

bill

unread,
Aug 9, 2009, 3:59:36 PM8/9/09
to

I forgot to mention:
my environment is:

WinXP/Firefox 3.5.2 client
Ubuntu 9.04 server Apache

Hamish Campbell

unread,
Aug 9, 2009, 4:54:33 PM8/9/09
to

Get Firebug for Firefox, or a debugging proxy like Charles or Burp.

Gregor Kofler

unread,
Aug 9, 2009, 4:57:55 PM8/9/09
to
bill meinte:

Use Firebug and dump prototype.js.

Gregor


--
http://www.gregorkofler.com
http://web.gregorkofler.com - vxJS, a JS lib in progress

bill

unread,
Aug 11, 2009, 6:57:51 AM8/11/09
to
Gregor Kofler wrote:
> bill meinte:
>> I just started working with AJAX, using the prototype.js scripts.
>> All is going well except for a small problem. To debug the problem I
>> need to see the source that the AJAX script is returning.
>>
>> I have a debug div that the script returns the data to, but I can't
>> figure out a way to see exactly what is being returned.
>>
>> Any suggestions ?
>
> Use Firebug and dump prototype.js.
>
> Gregor
>
>

Would I be correct in inferring that you don't like prototype.js ?
why ?

bill

unread,
Aug 11, 2009, 6:58:03 AM8/11/09
to
thank you

Gregor Kofler

unread,
Aug 11, 2009, 1:56:59 PM8/11/09
to
bill meinte:

> Would I be correct in inferring that you don't like prototype.js ?

"Don't like" doesn't nail it. I just wouldn't use it. and I assume I'm
not the only one in this NG.

> why ?

Bloated. Poor code quality. Slow. Superfluous.
The whys have been discussed here numerous times.

bill

unread,
Aug 12, 2009, 5:55:12 AM8/12/09
to
Gregor Kofler wrote:
> bill meinte:
>
>> Would I be correct in inferring that you don't like prototype.js ?
>
> "Don't like" doesn't nail it. I just wouldn't use it. and I assume I'm
> not the only one in this NG.
>
>> why ?
>
> Bloated. Poor code quality. Slow. Superfluous.
> The whys have been discussed here numerous times.
>
> Gregor
>
>
>
THank you. But, it does the job and saves me a lot of time.
Do you have a well written, quick library that does the same ?

bill

Gregor Kofler

unread,
Aug 12, 2009, 3:01:20 PM8/12/09
to
bill meinte:
> Gregor Kofler wrote:

[prototype.js]

>> Bloated. Poor code quality. Slow. Superfluous.
>> The whys have been discussed here numerous times.

> THank you. But, it does the job and saves me a lot of time.

If your customer doesn't care whether it runs on the next browser
generation (or some less popular browser) and/or you don't care about
frequent patching...

> Do you have a well written, quick library that does the same ?

An "AJAX" library? That's pretty laughable, since a working "AJAX"
library is just a mere 100 lines of code. And it will be at least as
good as its prototype.js counterpart.

optimistx

unread,
Aug 12, 2009, 3:05:12 PM8/12/09
to

"Gregor Kofler" <use...@gregorkofler.com> kirjoitti viestiss�:h5v3i1$273

> An "AJAX" library? That's pretty laughable, since a working "AJAX" library
> is just a mere 100 lines of code. And it will be at least as good as its
> prototype.js counterpart.

A link to it?


Gregor Kofler

unread,
Aug 12, 2009, 3:08:16 PM8/12/09
to
optimistx meinte:

Why?

optimistx

unread,
Aug 12, 2009, 3:22:05 PM8/12/09
to

"Gregor Kofler" <use...@gregorkofler.com> kirjoitti
viestiss�:h5v3v0$338$1...@newsreader2.utanet.at...

> optimistx meinte:
>
>> "Gregor Kofler" <use...@gregorkofler.com> kirjoitti viestiss�:h5v3i1$273
>
>>> An "AJAX" library? That's pretty laughable, since a working "AJAX"
>>> library is just a mere 100 lines of code. And it will be at least as
>>> good as its prototype.js counterpart.
>>
>> A link to it?
>
> Why?
I want to learn how 100 lines of good code is written.


Jeremy J Starcher

unread,
Aug 12, 2009, 3:53:28 PM8/12/09
to
On Wed, 12 Aug 2009 05:55:12 -0400, bill wrote:

> Gregor Kofler wrote:
>> bill meinte:
>>
>>> Would I be correct in inferring that you don't like prototype.js ?
>>
>> "Don't like" doesn't nail it. I just wouldn't use it. and I assume I'm
>> not the only one in this NG.

You'll find that there are many people on this newsgroup who wouldn't
touch prototype.js with a ten foot pole (or an eleven foot
Czechoslovakian, for that matter).


>>> why ?

It has been heavily discussed before. Read the archives.

>> Bloated. Poor code quality. Slow. Superfluous. The whys have been
>> discussed here numerous times.
>>

>>

> THank you. But, it does the job and saves me a lot of time. Do you have
> a well written, quick library that does the same ?

It only saves time Right Now(tm) and only them for narrow definitions of
saves time. Again, if you check the archives you will find discussions
about the limitations and troubles of prototype.js and others.

In most software programming, "It works for me" is barely enough of a
credential. In Javascript programming, it isn't at all.

The only pre-written library that I recommend at all is the Fork library,
and even then I simply learned from it and incorporated its ideas into my
own work.

http://forkjavascript.org/

Gregor Kofler

unread,
Aug 12, 2009, 5:18:11 PM8/12/09
to
optimistx meinte:
> "Gregor Kofler" <use...@gregorkofler.com> kirjoitti

>>>> An "AJAX" library? That's pretty laughable, since a working "AJAX"

>>>> library is just a mere 100 lines of code. And it will be at least as
>>>> good as its prototype.js counterpart.

> I want to learn how 100 lines of good code is written.

And you do that by staring at other peoples code, who claim that their
code is good?

Hmmm, I just read on the prototype homepage, that it now features
"official Chrome support, improved IE8 compatibility"

"Improved" - 'nuff said.

optimistx

unread,
Aug 13, 2009, 2:03:40 AM8/13/09
to

"Gregor Kofler" <use...@gregorkofler.com> kirjoitti
viestiss�:h5vbik$pcl$1...@newsreader2.utanet.at...

> optimistx meinte:
>> "Gregor Kofler" <use...@gregorkofler.com> kirjoitti
>
>>>>> An "AJAX" library? That's pretty laughable, since a working "AJAX"
>>>>> library is just a mere 100 lines of code. And it will be at least as
>>>>> good as its prototype.js counterpart.
>
>> I want to learn how 100 lines of good code is written.
>
> And you do that by staring at other peoples code, who claim that their
> code is good?

Yes, I stare at other people's code, who claim that that their code is good.
E.g.
I have been staring fork-library of Peter Michaux
http://forkjavascript.org/download/
version Fork 0.1.1, and experimenting with some parts of it. Some people in
this newsgroup claim that code is code good and the principles behind it are
sound (if I understand correctly). File ajax.js there contains 405 lines
with comments. From the code I estimate that writing that kind of general
purpose library program for my purposes would need several manmonths of work
(and probably be not so good). Even one line there might require days of
work (e.g line 120 with comment starting : 'rumor has it that...'). So I am
interested in staring/learning/using/modifying/... good libraries.

In your comment about 'staring' you might mean that 'staring at other
people's code' might not be a good method and part in learning? A better
method to replace it?

If somebody has written an ajax-library with 100 lines I would be very
interested to compare it with the 405 lines of Peter Michaux.


Gregor Kofler

unread,
Aug 13, 2009, 10:02:26 AM8/13/09
to
optimistx meinte:

> Yes, I stare at other people's code, who claim that that their code is good.

And Outlook Express can't display signatures?

optimistx

unread,
Aug 13, 2009, 10:59:28 AM8/13/09
to

"Gregor Kofler" <use...@gregorkofler.com> kirjoitti
viestiss�:h616di$827$1...@newsreader2.utanet.at...

> optimistx meinte:
>
>> Yes, I stare at other people's code, who claim that that their code is
>> good.
>
> And Outlook Express can't display signatures?

Outlook express has settings to display signatures, but there is an option
to omit them.
Is there something technically incorrect with my messages to this newsgroup?


Jake Jarvis

unread,
Aug 13, 2009, 11:16:20 AM8/13/09
to
optimistx wrote:
> "Gregor Kofler" <use...@gregorkofler.com> kirjoitti
> viestissᅵ:h616di$827$1...@newsreader2.utanet.at...

>> optimistx meinte:
>>
>>> Yes, I stare at other people's code, who claim that that their code is
>>> good.
>> And Outlook Express can't display signatures?
>
> Outlook express has settings to display signatures, but there is an option
> to omit them.
> Is there something technically incorrect with my messages to this newsgroup?
>
>

I believe he is hinting at his (Gregor) own signature.

--
Jake Jarvis

Thomas 'PointedEars' Lahn

unread,
Aug 13, 2009, 11:17:10 AM8/13/09
to
optimistx wrote:
> "Gregor Kofler" [wrote:]

>> optimistx meinte:
>>> Yes, I stare at other people's code, who claim that that their code is
>>> good.
>> And Outlook Express can't display signatures?
>
> Outlook express has settings to display signatures, but there is an option
> to omit them.

Interesting, where exactly? Anyhow, I suggest you disable that as Gregor
and others have pertinent URIs in their sig.

> Is there something technically incorrect with my messages to this newsgroup?

As this is of general interest (there are other people having the same
problem) I post it here:

Yes, you post umlauts (here: in the attribution) but the Content-Type header
that declares the proper encoding (e.g. ISO-8859-10, as you appear to be
Finnish) is missing. (The default is US-ASCII.) There are probably other
issues as well, see <http://insideoe.com/>. You can also use a test
newsgroup where test bots are active (if there are still any).

And I'd rather (as I am used to it from many other people in Usenet) you
kept the attribution to one short line.


PointedEars
--
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

Message has been deleted

Thomas 'PointedEars' Lahn

unread,
Aug 13, 2009, 12:50:24 PM8/13/09
to
Jeremy J Starcher wrote:
> On Wed, 12 Aug 2009 05:55:12 -0400, bill wrote:
>> Gregor Kofler wrote:
>>> bill meinte:
>>>> Would I be correct in inferring that you don't like prototype.js ?
>>> "Don't like" doesn't nail it. I just wouldn't use it. and I assume I'm
>>> not the only one in this NG.
>
> You'll find that there are many people on this newsgroup who wouldn't
> touch prototype.js with a ten foot pole (or an eleven foot
> Czechoslovakian, for that matter).

Truer words were never spoken :)


\\// PointedEars, amused

P.S.
What is .iad the TLD for? I can't seem to find the definition at iana.org
or elsewhere (it's in your Message-ID).
--
Prototype.js was written by people who don't know javascript for people
who don't know javascript. People who don't know javascript are not
the best source of advice on designing systems that use javascript.
-- Richard Cornford, cljs, <f806at$ail$1$8300...@news.demon.co.uk>

Jeremy J Starcher

unread,
Aug 13, 2009, 1:24:15 PM8/13/09
to
On Thu, 13 Aug 2009 18:50:24 +0200, Thomas 'PointedEars' Lahn wrote:

> P.S.
> What is .iad the TLD for? I can't seem to find the definition at
> iana.org or elsewhere (it's in your Message-ID).

Hmm.. good question.

With the death of AT&T's usenet server I ended up going for a mostly-free
NNTP server (TeraNews.com).

Garrett Smith

unread,
Aug 13, 2009, 4:35:28 PM8/13/09
to
Gregor Kofler wrote:
> optimistx meinte:
>> "Gregor Kofler" <use...@gregorkofler.com> kirjoitti
>
>>>>> An "AJAX" library? That's pretty laughable, since a working "AJAX"
>>>>> library is just a mere 100 lines of code. And it will be at least
>>>>> as good as its prototype.js counterpart.
>
>> I want to learn how 100 lines of good code is written.
>
> And you do that by staring at other peoples code, who claim that their
> code is good?
>

Not staring mindlessly, but reading and thinking and testing.

For example, trying to find a better way of reading filter opacity, I
looked at your code:

getOpacity: function(elem) {
var s = elem.style, o;
if(typeof s.opacity === "string") {
return !s.opacity ? 1 : +s.opacity;
}
if(typeof s.filter === "string") {
o = s.filter.match(/opacity=(\d+)/);
return o && o[1] ? o[1]/100 : 1;
}
return 1;
}

- will fail to properly read opacity in some cases. For example, with
this html:

<div id="x" style="filter: alpha( Opacity = 10 );background:red">x</div>

- calling:
var x = document.getElementById("x")
getOpacity(x)

- would not match the whitespace or the capitalization.

It is not as troubled as what is in YUI, not nearly as bad as what I see
in Dojo, and does not make embarrasing mistakes like browser detection
or checking for non-standard "filters" before seeing if opacity is present.

Garrett
--
comp.lang.javascript FAQ: http://jibbering.com/faq/

Gregor Kofler

unread,
Aug 13, 2009, 5:36:41 PM8/13/09
to
Garrett Smith meinte:

[snip]

> - will fail to properly read opacity in some cases. For example, with
> this html:
>
> <div id="x" style="filter: alpha( Opacity = 10 );background:red">x</div>
>
> - calling:
> var x = document.getElementById("x")
> getOpacity(x)
> - would not match the whitespace or the capitalization.

Yes, right. I somehow assumed (completely unfounded), that a set opacity
internally becomes lower case and whitespaceless. As I said: Asumptions
abound. And since I never had any CSS set and JS animated opacity, I
never came across buggy behavior.

And, hey, it's easy to fix. Thanks for pointing out.

Garrett Smith

unread,
Aug 13, 2009, 6:35:21 PM8/13/09
to
Gregor Kofler wrote:
> Garrett Smith meinte:
>
> [snip]
>
>> - will fail to properly read opacity in some cases. For example, with
>> this html:
>>
>> <div id="x" style="filter: alpha( Opacity = 10 );background:red">x</div>
>>
>> - calling:
>> var x = document.getElementById("x")
>> getOpacity(x)
>> - would not match the whitespace or the capitalization.
>
> Yes, right. I somehow assumed (completely unfounded), that a set opacity
> internally becomes lower case and whitespaceless. As I said: Asumptions
> abound. And since I never had any CSS set and JS animated opacity, I
> never came across buggy behavior.
>
> And, hey, it's easy to fix. Thanks for pointing out.

I'd say it is much easier to fix than Dojo.

I've also noticed that Opera rounds the opacity.

>>> var el = document.body
>>> el.style.opacity = ".555"
".555"
>>> el.style.opacity
"0.56"

IE truncates to int, "0-100", but reads decimal values and scientific
notation, too.

optimistx

unread,
Aug 14, 2009, 3:50:41 AM8/14/09
to

"Jake Jarvis" <pig_in...@yahoo.com> kirjoitti
viestissᅵ:7eip20F...@mid.uni-berlin.de...
Thanks for your kind remark. I had assumed that there is a problem with MY
signature (it should be missing).
Yes, Gregor has a link to his library in his signature... interesting code.

Thomas 'PointedEars' Lahn

unread,
Aug 14, 2009, 7:45:07 AM8/14/09
to
Jukka Lahtinen <jtfj...@hotmail.com.invalid> wrote:

> Thomas 'PointedEars' Lahn <Point...@web.de> writes:
>
> > Yes, you post umlauts (here: in the attribution) but the
> > Content-Type header
> > that declares the proper encoding (e.g. ISO-8859-10, as you appear
> > to be
> > Finnish) is missing. (The default is US-ASCII.) There are probably
> > other
>
> ISO-8859-10 is NOT a proper encoding for Finnish.
> ISO-8859-1 or ISO-8859-15 would be proper.

Well, unlike ISO-8859-1(5), ISO-8859-10 is defined especially for North
European languages, so I assumed it to be the best fit for an example.
But maybe Finnish belonging to the Finno-Ugric branch makes it an
exception. Could you list the Finnish characters that are not in
ISO-8859-10 but are in ISO-8859-1(5)? TIA.

BTW, "invalid" is NOT a proper domain for use in address headers of
Usenet messages (test groups aside). See RFCs 1036 and 2606.
--
PointedEars

optimistx

unread,
Aug 14, 2009, 8:05:02 AM8/14/09
to

"Thomas 'PointedEars' Lahn" <Point...@web.de> kirjoitti
viestissä:4A842E76...@PointedEars.de...

> optimistx wrote:
>> "Gregor Kofler" [wrote:]
>>> optimistx meinte:
>>>> Yes, I stare at other people's code, who claim that that their code is
>>>> good.
>>> And Outlook Express can't display signatures?
>>
>> Outlook express has settings to display signatures, but there is an
>> option
>> to omit them.
>
> Interesting, where exactly? Anyhow, I suggest you disable that as Gregor
> and others have pertinent URIs in their sig.
>
>> Is there something technically incorrect with my messages to this
>> newsgroup?
>
> As this is of general interest (there are other people having the same
> problem) I post it here:
>
> Yes, you post umlauts (here: in the attribution) but the Content-Type
> header
> that declares the proper encoding (e.g. ISO-8859-10, as you appear to be
> Finnish) is missing. (The default is US-ASCII.) There are probably other
> issues as well, see <http://insideoe.com/>. You can also use a test
> newsgroup where test bots are active (if there are still any).
>
> And I'd rather (as I am used to it from many other people in Usenet) you
> kept the attribution to one short line.
>
>
> PointedEars

Outlook Express signature option is for the sender, not for readers.

I have been too bored to read the unchanging signatures and have always
tried to skip them... this time too effectively. And the propaganda in the
changing signatures is irritating, when commenting them immediately is
offtopic and thus not recommended.

Thanks for your information about encoding. If one letter a with diaresis in
my messages is for any reader too much to bear , the reader probably has an
option to ignore my messages very easily. I think such an action might
improve the atmosphere here for all parties.

Thomas 'PointedEars' Lahn

unread,
Aug 14, 2009, 8:20:39 AM8/14/09
to
optimistx wrote:
> "Thomas 'PointedEars' Lahn" [...]:

>> optimistx wrote:
>>> "Gregor Kofler" [wrote:]
>>>> optimistx meinte:
>>>>> Yes, I stare at other people's code, who claim that that their code is
>>>>> good.
>>>> And Outlook Express can't display signatures?
>>> Outlook express has settings to display signatures, but there is an
>>> option
>>> to omit them.
>> Interesting, where exactly? Anyhow, I suggest you disable that as Gregor
>> and others have pertinent URIs in their sig.
>>
>>> Is there something technically incorrect with my messages to this
>>> newsgroup?
>> As this is of general interest (there are other people having the same
>> problem) I post it here:
>>
>> Yes, you post umlauts (here: in the attribution) but the Content-Type
>> header
>> that declares the proper encoding (e.g. ISO-8859-10, as you appear to be
>> Finnish) is missing. (The default is US-ASCII.) There are probably other
>> issues as well, see <http://insideoe.com/>. You can also use a test
>> newsgroup where test bots are active (if there are still any).
>>
>> And I'd rather (as I am used to it from many other people in Usenet) you
>> kept the attribution to one short line.
>> [...]

>
> Outlook Express signature option is for the sender, not for readers.

Oh well, OE is junk anyway (just look at the borken quoting it produces).

> I have been too bored to read the unchanging signatures and have always
> tried to skip them... this time too effectively. And the propaganda in the
> changing signatures is irritating, when commenting them immediately is
> offtopic and thus not recommended.
>
> Thanks for your information about encoding. If one letter a with diaresis in
> my messages is for any reader too much to bear ,

There will probably be no character with diæresis without proper encoding
declaration, but simply garbage.

> the reader probably has an option to ignore my messages very easily. I think
> such an action might improve the atmosphere here for all parties.

With that attitude of yours, they probably will. I wonder, if you don't
care about your readers in the first place, why have you asked if anything
were technically wrong at all? You don't seem to want Usenet, but a diary.

Learn to quote; don't quote signatures. <http://jibbering.com/faq/#posting>


Score adjusted

optimistx

unread,
Aug 14, 2009, 8:47:10 AM8/14/09
to

"Thomas 'PointedEars' Lahn" <Point...@web.de>
kirjoitti:4A855697...@PointedEars.de...
> optimistx wrote:
...

>> the reader probably has an option to ignore my messages very easily. I
>> think
>> such an action might improve the atmosphere here for all parties.
>
> With that attitude of yours, they probably will. I wonder, if you don't
> care about your readers in the first place, why have you asked if anything
> were technically wrong at all? You don't seem to want Usenet, but a
> diary.

I try to care some of my readers, but not all of them. If there were a
reader, who
would spend countless hours to enforce his/her
opinions/rules/habits/rudeness
to everyone else, I would not like to care about him/her.

Better that such a person ignores my texts.

Although mostly the contents of your messages has valuable information,
I prefer to get my information in a different style from people.

Could you please totally ignore my texts now and in the future?


Message has been deleted

Dr J R Stockton

unread,
Aug 14, 2009, 12:20:49 PM8/14/09
to
In comp.lang.javascript message <4A842E76...@PointedEars.de>, Thu,
13 Aug 2009 17:17:10, Thomas 'PointedEars' Lahn <Point...@web.de>
posted:

>
>And I'd rather (as I am used to it from many other people in Usenet) you
>kept the attribution to one short line.

The fact that you have seen no reason for an informative attribution is
no satisfactory reason to bully others into omitting useful information
of unimportant size.

--
(c) John Stockton, nr London UK. replyYYWW merlyn demon co uk Turnpike 6.05.
Web <URL:http://www.uwasa.fi/~ts/http/tsfaq.html> -> Timo Salmi: Usenet Q&A.
Web <URL:http://www.merlyn.demon.co.uk/news-use.htm> : about usage of News.
No Encoding. Quotes precede replies. Snip well. Write clearly. Mail no News.

Thomas 'PointedEars' Lahn

unread,
Aug 14, 2009, 7:15:55 PM8/14/09
to
Dr J R Stockton wrote:
> In comp.lang.javascript message <4A842E76...@PointedEars.de>, Thu,
> 13 Aug 2009 17:17:10, Thomas 'PointedEars' Lahn <Point...@web.de>
> posted:
>> And I'd rather (as I am used to it from many other people in Usenet) you
>> kept the attribution to one short line.
>
> The fact that you have seen no reason for an informative attribution is
> no satisfactory reason to bully others into omitting useful information
> of unimportant size.

I wonder, how distorted the perception of a person must be if he understands
the simple expression of a preference, as in "I would rather ...", as
"bullying others into something"; how little self-confidence that person
must have to lash out at others like this for no good reason at all; how
little must he place trust in others to believe that they could be convinced
with such hateful a statement to see that simple expression of preference as
something it clearly is not; how manipulative that person must be;
how lonely.

It would thus not be surprising that this person would describe 3 * N lines
in a newsgroup posting, where N specifies the number of quotation levels in
such a posting, as of unimportant size.


PointedEars
--
var bugRiddenCrashPronePieceOfJunk = (
navigator.userAgent.indexOf('MSIE 5') != -1
&& navigator.userAgent.indexOf('Mac') != -1
) // Plone, register_function.js:16

kangax

unread,
Aug 15, 2009, 9:35:12 PM8/15/09
to

I remember looking at vxJS some time ago. IIRC, it wasn't unit tested at
all (or at least I didn't see any mention of unit and/or functional
tests). Peter's Fork had same "problem" (contrary to your APE, which is
how it stood out among others for me).

Looking at the core file right now, I see that it will definitely fail
in certain versions of Safari 2.x (<2.0.4, to be more precise) due to
reliance on `hasOwnProperty` and String#replace with replacement as a
function.

But then vxJS doesn't claim to support Safari 2, so I guess that's an
expected behavior. On a related note, I'm not sure which versions of
Opera it has been tested with; The home page has an abstract "Opera +" :)

Looking at `merge`, I see that it doesn't take care of an infamous
JScript's DONT_ENUM bug, which I think most of JS libs "fix" nowadays
(as it often creeps up when working with "classes" that utilize
`toString`, `valueOf`, etc. properties).

As a minor nit, I don't like how "self-executing" functions are not
wrapped with parenthesis.

I see that `addListener` abstraction closes element over an event
handler in `attachEvent` and should lead to circular references in IE.
It's also surprising that these leaks are not circumvented by breaking
up references on page unload (perhaps to take advantage of "fast
history", so often advocated by D. Mark). Either I'm missing something
or pages using vxJS will keep eating more and more memory on every refresh.

It uses boolean type-conversion on host methods, such as - `if
(e.preventDefault) ...` - something that's often advised against as well
(although it does use `isHostMethod` in some of the other cases).

It accesses `getComputedStyle` off of a `window`, rather than
`document.defaultView` and if I remember correctly, Richard was once
explaining that this is not really a good idea, as `window` can differ
from `document.defaultView` in some of the clients like IceBrowser.

Then there are other minor things such as `Array#map` implementation not
matching JS1.6 one (now codified in ES5 too); color abstraction not
supporting `rgba`-based values (or `hsl` ones); native objects'
extensions (e.g. Array#create, String#setProp), so often criticized in
Prototype.js; array checks done in cross-frame incompatible manner
(<smth>.constructor == Array); usage of `window` instead of
`global.window`; and others.

Other than that, it seems like a solid set of helpers that probably
serves very well to its author.

--
kangax

David Mark

unread,
Aug 16, 2009, 1:40:58 AM8/16/09
to

Yes, those are currently deal-breakers for cross-browser code (unless
you can tolerate severe degradation in Safari 2.x). You could test
these and exclude methods that need them, but it would be better to
avoid them completely.

>
> But then vxJS doesn't claim to support Safari 2, so I guess that's an
> expected behavior. On a related note, I'm not sure which versions of
> Opera it has been tested with; The home page has an abstract "Opera +" :)
>
> Looking at `merge`, I see that it doesn't take care of an infamous
> JScript's DONT_ENUM bug, which I think most of JS libs "fix" nowadays
> (as it often creeps up when working with "classes" that utilize
> `toString`, `valueOf`, etc. properties).

I think a lot of people skip that as they don't override those
properties. Should at least be documented.

>
> As a minor nit, I don't like how "self-executing" functions are not
> wrapped with parenthesis.

That's more than a minor nit IIRC. I'm pretty sure I've seen at least
one older browser choke on that pattern.

>
> I see that `addListener` abstraction closes element over an event
> handler in `attachEvent` and should lead to circular references in IE.
> It's also surprising that these leaks are not circumvented by breaking
> up references on page unload (perhaps to take advantage of "fast
> history", so often advocated by D. Mark). Either I'm missing something
> or pages using vxJS will keep eating more and more memory on every refresh.

In some IE revisions. Should be updated to avoid circular references,
which will allow for fast history navigation without the leaks (as
discussed in a recent thread.)

>
> It uses boolean type-conversion on host methods, such as - `if
> (e.preventDefault) ...` - something that's often advised against as well
> (although it does use `isHostMethod` in some of the other cases).

I'm sure that's an oversight.

>
> It accesses `getComputedStyle` off of a `window`, rather than
> `document.defaultView` and if I remember correctly, Richard was once
> explaining that this is not really a good idea, as `window` can differ
> from `document.defaultView` in some of the clients like IceBrowser.

That's not a good idea. There's no guarantee that window will
reference the same object as document.defaultView.

>
> Then there are other minor things such as `Array#map` implementation not
> matching JS1.6 one (now codified in ES5 too); color abstraction not
> supporting `rgba`-based values (or `hsl` ones); native objects'
> extensions (e.g. Array#create, String#setProp), so often criticized in
> Prototype.js; array checks done in cross-frame incompatible manner
> (<smth>.constructor == Array); usage of `window` instead of
> `global.window`; and others.

All valid points.

>
> Other than that, it seems like a solid set of helpers that probably
> serves very well to its author.

That's probably what it was meant to be. IMO, helpers like this
shouldn't do anything more than the context (application, deployment,
developer habits, etc.) requires. A general purpose library must do
everything for every context, which is why I don't use them. Best
example of this is quirks mode. If you avoid quirks mode (a no-
brainer of course), you can cut a lot of workarounds out of the
typical GP library.

Garrett Smith

unread,
Aug 16, 2009, 4:47:09 AM8/16/09
to

Come to think of it, it might be a good idea to make sure it's not
matching finishOpacity, too. (\W?).

>> It is not as troubled as what is in YUI, not nearly as bad as what I
>> see in Dojo, and does not make embarrasing mistakes like browser
>> detection or checking for non-standard "filters" before seeing if
>> opacity is present.
>
> I remember looking at vxJS some time ago. IIRC, it wasn't unit tested at
> all (or at least I didn't see any mention of unit and/or functional
> tests). Peter's Fork had same "problem" (contrary to your APE, which is
> how it stood out among others for me).

8-)

So how come you dropped out? There is a ton of work that needs to be
done. Some of it is monkey work, but mostly not. You're welcome back any
time.

(Anyone interested can check out "APE JavaScript Library" on GitHub.)

I added more tests, and some other tests are failing in Safari 2 and 3.

I'm pulling stuff out like mad. The great thing about being AFL 3.0 and
having effectively 0 user base.

I've taken an odd interest in testing some things in IE5.5, Chrome, and
Seamonkey.

A new DOM_CONSTANT that I think you might like for CFT:

var od = "ownerDocument",
doc = document,
docEl = doc.documentElement,
OWNER_DOCUMENT = docEl && od in docEl ? od : "document";

IE 5, Safari 2, and even Mac IE, have a "document" property on elements.
That property is the same thing as ownerDocument.

The problem is where there is a browser that has neither
el.ownerDocument nor el.document. Check your BlackBerry and let us know
(please).

There is a lot more. APE.createFactory is something I quite like.

>
> Looking at the core file right now, I see that it will definitely fail
> in certain versions of Safari 2.x (<2.0.4, to be more precise) due to
> reliance on `hasOwnProperty` and String#replace with replacement as a
> function.
>
> But then vxJS doesn't claim to support Safari 2, so I guess that's an
> expected behavior. On a related note, I'm not sure which versions of
> Opera it has been tested with; The home page has an abstract "Opera +" :)
>

[...]

>
> I see that `addListener` abstraction closes element over an event
> handler in `attachEvent` and should lead to circular references in IE.
> It's also surprising that these leaks are not circumvented by breaking
> up references on page unload (perhaps to take advantage of "fast
> history", so often advocated by D. Mark). Either I'm missing something
> or pages using vxJS will keep eating more and more memory on every refresh.
>

Probably. Refreshing the page is different than navigating away and then
navigating back. You need at least two pages.

Page1 ----> Page2 -----> Page1 (check memory usage).

> It uses boolean type-conversion on host methods, such as - `if
> (e.preventDefault) ...` - something that's often advised against as well
> (although it does use `isHostMethod` in some of the other cases).
>
> It accesses `getComputedStyle` off of a `window`, rather than
> `document.defaultView` and if I remember correctly, Richard was once
> explaining that this is not really a good idea, as `window` can differ
> from `document.defaultView` in some of the clients like IceBrowser.

Yes, Richard mentioned IceBrowser. Safari 2.0.2 and konqueror choke on
that as well. document.defaultView standard and more widely supported
than non-standard window.defaultView.

Safari 2 is kind of, well, it's on its way out.

>
> Then there are other minor things such as `Array#map` implementation not
> matching JS1.6 one (now codified in ES5 too); color abstraction not
> supporting `rgba`-based values (or `hsl` ones); native objects'

I think it depends on the context where that is needed. In a color
transition, rgba is often not needed. For that, it might not be wort it;
maybe easier to just have rgb and opacity separate. Then again, if it is
an easy add, and easy to test, then it might be worth it.

> extensions (e.g. Array#create, String#setProp), so often criticized in
> Prototype.js; array checks done in cross-frame incompatible manner
> (<smth>.constructor == Array); usage of `window` instead of
> `global.window`; and others.
>

I usually don't need to see if something is an array. I would probably
one-off a feature test on-the-spot.

Generally I dislike type-checking. Mootools takes the cake in silliness
on that. YUI has a lot of isFunction, etc, there's the legendary jQuery
"isFunction" and kangax' Miller device 8-D.

Typechecking can tend get overused/misused and add a lot of extra code
and overhead with extra function calls.

> Other than that, it seems like a solid set of helpers that probably
> serves very well to its author.
>

I only looked at it for a minute, but what I saw was very short methods
and it seemed pretty easy to read through.

But yeah, no unit tests.

Gregor Kofler

unread,
Aug 16, 2009, 5:12:30 AM8/16/09
to
kangax meinte:

[issues pointed out]

Thanks for pointing out all those issues. I'll look into them, once I
find time (some are already on the todo list, like a purgeEventListeners()).

Though some points won't see any fixes: hasOwnProperty(), and replace()
with callback functions are extensively used in Crockford's JSON
library, which I use, too. (True, without XHR or JSON functionality
needed, I could get around that.)

> Other than that, it seems like a solid set of helpers that probably
> serves very well to its author.

Indeed. vxJS was never intended to become an "all-purpose" library.
Besides the (mentioned and overlooked) errors and pitfalls - it lacks a
lot, what I deem completely unnecessary, since vxJS is only used with my
own webpages and by one more web author I know of (e.g. no workarounds
for quirksmode, XHR only with POST and JSON, no "general selector"
function, lacking functionality of widgets etc).

I'm currently working on a slightly improved version, with a brief API
documentation, but it's only halfways done. But hey, I haven't had any
issues with IE8 so far... ;-)

Gregor Kofler

unread,
Aug 16, 2009, 5:17:33 AM8/16/09
to
Garrett Smith meinte:

> But yeah, no unit tests.

Yepp. But wouldn't that mean to share the fate of APE? Even more work,
and still zero user base. ;-)

David Mark

unread,
Aug 16, 2009, 5:39:49 AM8/16/09
to
On Aug 16, 5:17 am, Gregor Kofler <use...@gregorkofler.com> wrote:
> Garrett Smith meinte:
>
> > But yeah, no unit tests.
>
> Yepp. But wouldn't that mean to share the fate of APE? Even more work,
> and still zero user base. ;-)

Last time I looked at that thing, the basic demos (two of them anyway)
were throwing exceptions in FF3. So much for the unit tests. ;)

David Mark

unread,
Aug 16, 2009, 6:30:41 AM8/16/09
to
On Aug 16, 5:12 am, Gregor Kofler <use...@gregorkofler.com> wrote:
> kangax meinte:
>
> [issues pointed out]
>
> Thanks for pointing out all those issues. I'll look into them, once I
> find time (some are already on the todo list, like a purgeEventListeners()).

That will compound the existing problem. Fix the problem instead.

>
> Though some points won't see any fixes: hasOwnProperty(), and replace()
> with callback functions are extensively used in Crockford's JSON
> library, which I use, too. (True, without XHR or JSON functionality
> needed, I could get around that.)

So don't use that library.

>
> > Other than that, it seems like a solid set of helpers that probably
> > serves very well to its author.
>
> Indeed. vxJS was never intended to become an "all-purpose" library.
> Besides the (mentioned and overlooked) errors and pitfalls - it lacks a
> lot, what I deem completely unnecessary, since vxJS is only used with my
> own webpages and by one more web author I know of (e.g. no workarounds
> for quirksmode, XHR only with POST and JSON, no "general selector"
> function, lacking functionality of widgets etc).

Why only with POST? IE's broken GET caching is simple to get around.

>
> I'm currently working on a slightly improved version, with a brief API
> documentation, but it's only halfways done. But hey, I haven't had any
> issues with IE8 so far... ;-)

You mean you didn't have to re-plow huge tracts like jQuery's "Script
of the Month" club? They must have freaked the first time they tried
their wonderful "cross-browser" script in IE8. Of course, the script
is still a nightmare in IE (any version.) Seems they talk monthly of
discontinuing their "support" for IE6. (!) I've got "news" for them:
IE7 is almost a carbon copy, so they might as well drop it too. IE8
is often used in "compatibility mode", which is much like IE6/7, so no
hope there either. And since IE poses most of the problems for cross-
browser scripts, it seems they should scrap the entire effort.

kangax

unread,
Aug 16, 2009, 11:06:06 AM8/16/09
to
Garrett Smith wrote:
> kangax wrote:
>> Garrett Smith wrote:
[...]

>>> It is not as troubled as what is in YUI, not nearly as bad as what I
>>> see in Dojo, and does not make embarrasing mistakes like browser
>>> detection or checking for non-standard "filters" before seeing if
>>> opacity is present.
>>
>> I remember looking at vxJS some time ago. IIRC, it wasn't unit tested
>> at all (or at least I didn't see any mention of unit and/or functional
>> tests). Peter's Fork had same "problem" (contrary to your APE, which
>> is how it stood out among others for me).
>
> 8-)
>
> So how come you dropped out? There is a ton of work that needs to be
> done. Some of it is monkey work, but mostly not. You're welcome back any
> time.

Thank you. The only problem is time, which is never enough... as always.

>
> (Anyone interested can check out "APE JavaScript Library" on GitHub.)
>
> I added more tests, and some other tests are failing in Safari 2 and 3.
>
> I'm pulling stuff out like mad. The great thing about being AFL 3.0 and
> having effectively 0 user base.
>
> I've taken an odd interest in testing some things in IE5.5, Chrome, and
> Seamonkey.
>
> A new DOM_CONSTANT that I think you might like for CFT:
>
> var od = "ownerDocument",
> doc = document,
> docEl = doc.documentElement,
> OWNER_DOCUMENT = docEl && od in docEl ? od : "document";

I've been a bit turned off by this string munging lately. I know it
minifies much better (YUI3 seem to be using it a lot) but it makes for a
somewhat less readable code; besides following the logic flow, you now
have to keep in mind what some of these short (and so undescriptive)
variable names translate to.

This seems like a better job for some kind of a pre-processor, where you
specify which strings can be replaced with variables (and so replaced
with shorter names during minification).

>
> IE 5, Safari 2, and even Mac IE, have a "document" property on elements.
> That property is the same thing as ownerDocument.

Ah, but I see that Safari 2 has `ownerDocument` too, so what's the
advantage of `document` over `ownerDocument`? Does IE5 and Mac IE lack it?

>
> The problem is where there is a browser that has neither
> el.ownerDocument nor el.document. Check your BlackBerry and let us know
> (please).

`ownerDocument` exists and references a document on Blackberry 9530

[...]

>> It accesses `getComputedStyle` off of a `window`, rather than
>> `document.defaultView` and if I remember correctly, Richard was once
>> explaining that this is not really a good idea, as `window` can differ
>> from `document.defaultView` in some of the clients like IceBrowser.
>
> Yes, Richard mentioned IceBrowser. Safari 2.0.2 and konqueror choke on
> that as well. document.defaultView standard and more widely supported
> than non-standard window.defaultView.

Ah, yes indeed. Safari 2.0.2 - `typeof window.getComputedStyle ==
"undefined"`

>
> Safari 2 is kind of, well, it's on its way out.

I actually still see few users of Safari 2.0.4 (last in 2.x series) on
my employer website (http://www.artstor.org) which gets ~3K visits a
day. I also see a lot (!) of Safari 1.3 users (even more than 2.x),
apparently all those people stuck with older Mac OS and so can't upgrade
to 2.x+. No wonder why BBC supports Safari 1.3 with their in-house Glow
library <http://www.bbc.co.uk/glow/>

>
>>
>> Then there are other minor things such as `Array#map` implementation
>> not matching JS1.6 one (now codified in ES5 too); color abstraction
>> not supporting `rgba`-based values (or `hsl` ones); native objects'
>
> I think it depends on the context where that is needed. In a color
> transition, rgba is often not needed. For that, it might not be wort it;
> maybe easier to just have rgb and opacity separate. Then again, if it is
> an easy add, and easy to test, then it might be worth it.

Perhaps not. I just notice myself using `rgba` more and more often as it
looks better, falling back on `rgb` in non-supporting clients.

>
>> extensions (e.g. Array#create, String#setProp), so often criticized in
>> Prototype.js; array checks done in cross-frame incompatible manner
>> (<smth>.constructor == Array); usage of `window` instead of
>> `global.window`; and others.
>>
>
> I usually don't need to see if something is an array. I would probably
> one-off a feature test on-the-spot.

What do you mean?

>
> Generally I dislike type-checking. Mootools takes the cake in silliness
> on that. YUI has a lot of isFunction, etc, there's the legendary jQuery
> "isFunction" and kangax' Miller device 8-D.

Well, as we have found out on ES5 mailing list a couple of days ago,
Flanagan actually wrote about [[Class]] checking on 175th page of its
book back in 2006 :) It wasn't really used for type-checking across
frames (which is what I focused on in my post) and would actually fail
due to following `constructor` checks, but still...

<https://mail.mozilla.org/pipermail/es5-discuss/2009-August/003080.html>

>
> Typechecking can tend get overused/misused and add a lot of extra code
> and overhead with extra function calls.
>
>> Other than that, it seems like a solid set of helpers that probably
>> serves very well to its author.
>>
>
> I only looked at it for a minute, but what I saw was very short methods
> and it seemed pretty easy to read through.

Yep, I liked that too. I think APE might benefit from cutting some of
its god-like methods into smaller chunks :)

--
kangax

Gregor Kofler

unread,
Aug 16, 2009, 1:11:05 PM8/16/09
to
David Mark meinte:

> On Aug 16, 5:12 am, Gregor Kofler <use...@gregorkofler.com> wrote:

>> Indeed. vxJS was never intended to become an "all-purpose" library.
>> Besides the (mentioned and overlooked) errors and pitfalls - it lacks a
>> lot, what I deem completely unnecessary, since vxJS is only used with my
>> own webpages and by one more web author I know of (e.g. no workarounds
>> for quirksmode, XHR only with POST and JSON, no "general selector"
>> function, lacking functionality of widgets etc).
>
> Why only with POST? IE's broken GET caching is simple to get around.

The JS library was (and still is) intended to work with my (again
homebrewn) PHP framework, in which I resort to POST (and JSON for that
matter) with XHRs (predefined parameter names also stem from this).
Since POST hasn't let me down so far, I can't see a reason, or at least
no priority, for caring about GET support (apart from going towards a
"please-them-all library").

Garrett Smith

unread,
Aug 16, 2009, 5:12:35 PM8/16/09
to
Gregor Kofler wrote:
> Garrett Smith meinte:
>
>> But yeah, no unit tests.
>
> Yepp. But wouldn't that mean to share the fate of APE? Even more work,
> and still zero user base. ;-)
>

How do you determine when a piece of code can be changed or removed?

How do you verify something that is a intrinsically more complex, like
reading opacity or finding position, in multiple contexts and multiple
browsers and OS'?

Do you ever just find a better way of doing something then want to
change the code? How can you be sure that won't break anything else?

Unit testing is not absolute insurance, but it provides quick
verification of what the effects of a code change.

Unit testing makes me ask: "what is this code for?" and "how can I break
it?", which is good, not only because I like breaking stuff, but because
I get to see where the code will fail and assess that case.

The question "what is this code for?" is really an important one. If the
code can be determined to be unnecessary, then it can be removed. Unit
tests help verify if something can be removed.

The benefit of having 0 user base is that what the "users" might want
(users=clients of the API) isn't really a concern. You don't really need
to worry about an xhtml DOM, quirksmode, appeasing users with a
Selectors API.

I chose to license as "AFL 3.0" because it seems most appropriate for my
goals (no user base, available for studying). Unfortunately, not
everyone will follow license terms. Adsense ads in my gmail recently
revealed someone decided to create another javascript library with the
same name.

> Gregor

kangax

unread,
Aug 16, 2009, 8:41:39 PM8/16/09
to
kangax wrote:
> Garrett Smith wrote:
>> kangax wrote:
[...]
>>> It accesses `getComputedStyle` off of a `window`, rather than
>>> `document.defaultView` and if I remember correctly, Richard was once
>>> explaining that this is not really a good idea, as `window` can
>>> differ from `document.defaultView` in some of the clients like
>>> IceBrowser.
>>
>> Yes, Richard mentioned IceBrowser. Safari 2.0.2 and konqueror choke on
>> that as well. document.defaultView standard and more widely supported
>> than non-standard window.defaultView.
>
> Ah, yes indeed. Safari 2.0.2 - `typeof window.getComputedStyle ==
> "undefined"`

Just noticed that MDC mixes up window/document.defaultView in
`getComputedStyle` docs:

<https://developer.mozilla.org/en/DOM/window.getComputedStyle>

[...]

--
kangax

Garrett Smith

unread,
Aug 17, 2009, 4:03:25 AM8/17/09
to
kangax wrote:
> Garrett Smith wrote:
>> kangax wrote:
>>> Garrett Smith wrote:
> [...]

[about vxJS, comments about browsers, etc]

>>
>> A new DOM_CONSTANT that I think you might like for CFT:
>>
>> var od = "ownerDocument",
>> doc = document,
>> docEl = doc.documentElement,
>> OWNER_DOCUMENT = docEl && od in docEl ? od : "document";
>
> I've been a bit turned off by this string munging lately. I know it
> minifies much better (YUI3 seem to be using it a lot) but it makes for a
> somewhat less readable code; besides following the logic flow, you now
> have to keep in mind what some of these short (and so undescriptive)
> variable names translate to.
>

In the case above, though, I assinged to "dom.OWNER_DOCUMENT". No munging.

el[dom.OWNER_DOCUMENT]

A debugger would have the ability to resolve those identifiers, though,
so one could add a "watch" and type that in.

> This seems like a better job for some kind of a pre-processor, where you
> specify which strings can be replaced with variables (and so replaced
> with shorter names during minification).
>

It is useful for a load time constant. A dynamic property is going to be
faster than a function call that accesses that property.

For example:-
el[dom.OWNER_DOCUMENT]

- will be faster than:-

dom.getOwnerDocument(el)

dom.getOwnerDocument = function(el) {
return el.ownerDocument;
};

- because the former is a property lookup to get dom.OWNER_DOCUMENT, the
latter is a lookup to dom.getOwnerDocument, and the latter is a [[Call]]
expression.

>>
>> IE 5, Safari 2, and even Mac IE, have a "document" property on
>> elements. That property is the same thing as ownerDocument.
>
> Ah, but I see that Safari 2 has `ownerDocument` too, so what's the
> advantage of `document` over `ownerDocument`? Does IE5 and Mac IE lack it?
>

Safari 2 and Mac IE have both. IE 5.5 has node.document, but not
node.ownerDocument. IE 6 up has both.

>>
>> The problem is where there is a browser that has neither
>> el.ownerDocument nor el.document. Check your BlackBerry and let us
>> know (please).
>
> `ownerDocument` exists and references a document on Blackberry 9530
>

Hmm. Should I remove dom[OWNER_DOCUMENT] and let it fail in IE 5.5?

It's not that much extra code to support, but then again, it is only IE
5.5, which is pretty old.

[...]

>>
>> Safari 2 is kind of, well, it's on its way out.
>
> I actually still see few users of Safari 2.0.4 (last in 2.x series) on
> my employer website (http://www.artstor.org) which gets ~3K visits a
> day. I also see a lot (!) of Safari 1.3 users (even more than 2.x),
> apparently all those people stuck with older Mac OS and so can't upgrade
> to 2.x+. No wonder why BBC supports Safari 1.3 with their in-house Glow
> library <http://www.bbc.co.uk/glow/>
>

Yeah. Lets look at getting some more stuff working in older versions of
Safari. hasOwnProperty, e.g.

>>
>>>
>>> Then there are other minor things such as `Array#map` implementation
>>> not matching JS1.6 one (now codified in ES5 too); color abstraction
>>> not supporting `rgba`-based values (or `hsl` ones); native objects'
>>
>> I think it depends on the context where that is needed. In a color
>> transition, rgba is often not needed. For that, it might not be wort
>> it; maybe easier to just have rgb and opacity separate. Then again, if
>> it is an easy add, and easy to test, then it might be worth it.
>
> Perhaps not. I just notice myself using `rgba` more and more often as it
> looks better, falling back on `rgb` in non-supporting clients.

I took "color abstraction" to mean some sort of Color ADT or "class". My
comment was based on that understanding. Now it seems like you are
talking about support of css rgba. There seems to be a misunderstanding.

>
>>
>>> extensions (e.g. Array#create, String#setProp), so often criticized
>>> in Prototype.js; array checks done in cross-frame incompatible manner
>>> (<smth>.constructor == Array); usage of `window` instead of
>>> `global.window`; and others.
>>>
>>
>> I usually don't need to see if something is an array. I would probably
>> one-off a feature test on-the-spot.
>
> What do you mean?
>

Like, if I had a case where - someIdent - could be either, say, and -
arguments - object or an Array, and I wanted to call - concat - if it is
an array, then I could check to see if that has a concat, and, provided
I don't have a formal parameter named - concat -, I'll use:-

if(typeof someIdent.concat == "function") {
// can I have a dollar?
}

[...]

> Well, as we have found out on ES5 mailing list a couple of days ago,
> Flanagan actually wrote about [[Class]] checking on 175th page of its
> book back in 2006 :) It wasn't really used for type-checking across
> frames (which is what I focused on in my post) and would actually fail
> due to following `constructor` checks, but still...
>
> <https://mail.mozilla.org/pipermail/es5-discuss/2009-August/003080.html>
>

Shall we be diplomatic and call it the Flanagan-kangax-miller-device?

:-D

[...]

>
> Yep, I liked that too. I think APE might benefit from cutting some of
> its god-like methods into smaller chunks :)
>

Adding WebkitTopRightBorderRadius didn't help much, did it ;-D

You want the honors? Yank out border radius support. There's one unit
test and one animation demo uses animated border radius. That demo also
uses the deprecated APE.getById, which can be replaced by
APE.createFactory. That'll get style-f.js down closer to 200 LOC.

No rush. There never deadlines with APE :-D. Craftsmanship above all.

In other areas, getOffsetCoords fails a few tests in Safari 2.

More examples (demos) for animation and drag drop would be good.

I am simplifying Draggable. Using "APE.createFactory simplified the
interface and helped get the file size down -- 11k minified and shrinking.

Oh, I also use a MOUSE_MOVE_THRESHOLD to reduce CPU strain in mousemove.

var now = +new Date;
if(now - lastMouseMoveTime < MOUSE_MOVE_THRESHOLD) return;
lastMouseMoveTime = now;

When mousemove is entered, I check the current time and compare that to
the last recorded time (initially -1). If that is less than the
MOUSE_MOVE_THRESHOLD, the function exits. This has the effect of
creating new Date each mousemove, which is significantly less CPU than
dragging an element around.

I removed the "constraint" feature, removed the out-of-place focus
management. Next up for consideration is removing the "animateBack", for
when the user hits Esc (as on Mac) though it might be worth
consideration to do that, but only when Animation is available. I'd like
to find someone local few hours a week, to pair on stuff.

0 new messages