[jQuery] Re: SlickSpeed CSS Selector TestSuite

2007-06-29 Thread jsrobinson


I agree with all the points about jQuery's greatness thus far, but...

I have noticed that jQuery's animation can sap an older CPU, even in simpler
examples. I understand that the SlickSpeed test is not about animation, but
given my anecdotal observations, the user experience on older PCs leaves
something to be desired. 

I am in no way singling out jQuery for this problem, but I am pointing it
out here so that maybe, if there is any chance that an speed-optimized
version could become available, it would really seal the deal for me and
jQuery (and all of my clients as well). 

This used to be a question of demographics as much as anything else (am I
developing sites for grandmas or affluent corporate types), but with the
iPhone (which doesn't have a dual-core 2GHz CPU) and other web-enabled
devices, the game changes.

What are the chances of seeing a speed-optimized library?
-- 
View this message in context: 
http://www.nabble.com/SlickSpeed-CSS-Selector-TestSuite-tf3907626s15494.html#a11355849
Sent from the JQuery mailing list archive at Nabble.com.



[jQuery] Re: SlickSpeed CSS Selector TestSuite

2007-06-29 Thread Rey Bango


v1.1.3 will have enhanced performance in many areas including selectors, 
effects, and animations. It should be out very, very soon.


jsrobinson wrote:


I agree with all the points about jQuery's greatness thus far, but...

I have noticed that jQuery's animation can sap an older CPU, even in simpler
examples. I understand that the SlickSpeed test is not about animation, but
given my anecdotal observations, the user experience on older PCs leaves
something to be desired. 


I am in no way singling out jQuery for this problem, but I am pointing it
out here so that maybe, if there is any chance that an speed-optimized
version could become available, it would really seal the deal for me and
jQuery (and all of my clients as well). 


This used to be a question of demographics as much as anything else (am I
developing sites for grandmas or affluent corporate types), but with the
iPhone (which doesn't have a dual-core 2GHz CPU) and other web-enabled
devices, the game changes.

What are the chances of seeing a speed-optimized library?


--
BrightLight Development, LLC.
954-775- (o)
954-600-2726 (c)
[EMAIL PROTECTED]
http://www.iambright.com


[jQuery] Re: SlickSpeed CSS Selector TestSuite

2007-06-18 Thread Jean


Well, for my intranet projects will better if the selectors are faster
even with 100k
but have to exists 2 versions, the fasterfat and the slowerthin

It´s funny how mootols get an error with div[class|=dialog] and 0ms
but jQuery have problems with div:nth-child(2n),
div:nth-child(2n+1),div:nth-child(n) and returns 0 elements too, but
dont get an error so the time was 543 ms | zero results each


On 6/15/07, Toby [EMAIL PROTECTED] wrote:





You gotta admit, 1.2mb for that page is explosively large ;¬]



 


From: jquery-en@googlegroups.com [mailto:[EMAIL PROTECTED] On
Behalf Of Glen Lipka
 Sent: 13 June 2007 17:47
 To: jquery-en@googlegroups.com
 Subject: [jQuery] Re: SlickSpeed CSS Selector TestSuite



http://www.apple.com/safari/
 File size 1.2 megs.

 If Toby worked on this website, I think he would spontaneously combust.

 Glen

 PS.  Every page I visit on Apple seems to get bigger and bigger.







--

[]´s Jean
www.suissa.info

  Ethereal Agency
www.etherealagency.com


[jQuery] Re: SlickSpeed CSS Selector TestSuite

2007-06-15 Thread Toby
You gotta admit, 1.2mb for that page is explosively large ;¬]

 

  _  

From: jquery-en@googlegroups.com [mailto:[EMAIL PROTECTED] On
Behalf Of Glen Lipka
Sent: 13 June 2007 17:47
To: jquery-en@googlegroups.com
Subject: [jQuery] Re: SlickSpeed CSS Selector TestSuite

 

http://www.apple.com/safari/
File size 1.2 megs.

If Toby worked on this website, I think he would spontaneously combust.

Glen

PS.  Every page I visit on Apple seems to get bigger and bigger. 



 



[jQuery] Re: SlickSpeed CSS Selector TestSuite

2007-06-13 Thread Gilles (Webunity)

I agree with Glenn on this one. I vote for more speed, we need to
fight back. Another 5k doesn't matter that much to me or my clients
since all of them have caching on. Maybe an extra plugin?



[jQuery] Re: SlickSpeed CSS Selector TestSuite

2007-06-13 Thread Gordon

In IE6 that seems to be the case, but I discovered that by accident
with a buggy script.  Haven't deliberately tested what happens in
other browsers, I would think that they probably all just return the
first element they find with the correct ID but as the behaviour is
describes as undefined I wouldn't write any scripts that depend on
that.

On Jun 13, 1:31 am, Aaron Heimlich [EMAIL PROTECTED] wrote:
 On 6/12/07, Dan G. Switzer, II [EMAIL PROTECTED] wrote:



  Plus, what happens if you have:

  div id=bam /

  span id=bam /

  What if you need to retrieve the span tag? If it's checking #bam first,
  won't it only find the div / element?

 The DOM2 has this to say:

 getElementById introduced in DOM Level 2

  Returns the Element whose ID is given by elementId. If no such element
  exists, returns null. Behavior is not defined if more than one element has
  this ID.

 Source:http://www.w3.org/TR/DOM-Level-2-Core/core.html#ID-getElBId

 I would think that the first one the browser finds is selected, but I can't
 be certain of that as I've never actually tried to do this.

 --
 Aaron Heimlich
 Web Developer
 [EMAIL PROTECTED]://aheimlich.freepgs.com



[jQuery] Re: SlickSpeed CSS Selector TestSuite

2007-06-13 Thread Benjamin Sterling

I hear what everyone is saying about IDs, but lets flip the switch here and
what if we have:

div class=bam
span class=bam

This situation is a valid situation, one I normally am in (actually in a
link situation).  So, what is the fastest selector to retrieve on or
another.



--
Benjamin Sterling
http://www.KenzoMedia.com
http://www.KenzoHosting.com


[jQuery] Re: SlickSpeed CSS Selector TestSuite

2007-06-13 Thread Andy Matthews
That's not a good example anyway. It's invalid because there can only be ONE
unique ID per page.

  _  

From: jquery-en@googlegroups.com [mailto:[EMAIL PROTECTED] On
Behalf Of Aaron Heimlich
Sent: Tuesday, June 12, 2007 7:32 PM
To: jquery-en@googlegroups.com
Subject: [jQuery] Re: SlickSpeed CSS Selector TestSuite


On 6/12/07, Dan G. Switzer, II [EMAIL PROTECTED] wrote: 

Plus, what happens if you have:

div id=bam /

span id=bam /

What if you need to retrieve the span tag? If it's checking #bam first,
won't it only find the div / element? 



The DOM2 has this to say:



getElementById introduced in DOM Level 2 
Returns the Element whose ID is given by elementId. If no such element
exists, returns null. Behavior is not defined if more than one element has
this ID.   



Source: http://www.w3.org/TR/DOM-Level-2-Core/core.html#ID-getElBId

I would think that the first one the browser finds is selected, but I can't
be certain of that as I've never actually tried to do this. 

-- 
Aaron Heimlich
Web Developer
[EMAIL PROTECTED]
http://aheimlich.freepgs.com 


[jQuery] Re: SlickSpeed CSS Selector TestSuite

2007-06-13 Thread Rey Bango


I've tested it with v1.1.3 and the improvements are enough to make a 
substantial difference.


Rey

David Duymelinck wrote:


Gilles (Webunity) schreef:

I agree with Glenn on this one. I vote for more speed, we need to
fight back. Another 5k doesn't matter that much to me or my clients
since all of them have caching on. Maybe an extra plugin?
  
I thought John announced speed enchantments in 1.1.3. Is there someone 
who benchmarked the test release already?


I would like to work with a speedy library too but i stay for the syntax 
and plugins :) I agree with the fact that 20 shouldn't be an absolute 
figure.




--
BrightLight Development, LLC.
954-775- (o)
954-600-2726 (c)
[EMAIL PROTECTED]
http://www.iambright.com


[jQuery] Re: SlickSpeed CSS Selector TestSuite

2007-06-13 Thread Karl Swedberg

Hi Benjamin,

In this case, these are faster ...
$('div.bam')
$('span.bam')

than this ...
$('.bam')

What I don't know is whether $('div.bam, span.bam') is faster than $ 
('.bam'). I suspect that it might depend on the what the DOM looks  
like on a given page.



--Karl
_
Karl Swedberg
www.englishrules.com
www.learningjquery.com



On Jun 13, 2007, at 8:15 AM, Benjamin Sterling wrote:

I hear what everyone is saying about IDs, but lets flip the switch  
here and what if we have:


div class=bam
span class=bam

This situation is a valid situation, one I normally am in (actually  
in a link situation).  So, what is the fastest selector to retrieve  
on or another.




--
Benjamin Sterling
http://www.KenzoMedia.com
http://www.KenzoHosting.com




[jQuery] Re: SlickSpeed CSS Selector TestSuite

2007-06-13 Thread Benjamin Sterling

Karl,
Thanks, I am going to try to put together a real life example and test out
what is faster.  I will try to have something by end of week.

Thanks again.

On 6/13/07, Karl Swedberg [EMAIL PROTECTED] wrote:


Hi Benjamin,
In this case, these are faster ...
$('div.bam')
$('span.bam')

than this ...
$('.bam')

What I don't know is whether $('div.bam, span.bam') is faster than
$('.bam'). I suspect that it might depend on the what the DOM looks like on
a given page.


--Karl
_
Karl Swedberg
www.englishrules.com
www.learningjquery.com



On Jun 13, 2007, at 8:15 AM, Benjamin Sterling wrote:

I hear what everyone is saying about IDs, but lets flip the switch here
and what if we have:

div class=bam
span class=bam

This situation is a valid situation, one I normally am in (actually in a
link situation).  So, what is the fastest selector to retrieve on or
another.



--
Benjamin Sterling
http://www.KenzoMedia.com
http://www.KenzoHosting.com






--
Benjamin Sterling
http://www.KenzoMedia.com
http://www.KenzoHosting.com


[jQuery] Re: SlickSpeed CSS Selector TestSuite

2007-06-13 Thread Andy Matthews
We'll expect something by the end of the day today.
 
Get on that okay?
 
;)

  _  

From: jquery-en@googlegroups.com [mailto:[EMAIL PROTECTED] On
Behalf Of Benjamin Sterling
Sent: Wednesday, June 13, 2007 8:27 AM
To: jquery-en@googlegroups.com
Subject: [jQuery] Re: SlickSpeed CSS Selector TestSuite


Karl,
Thanks, I am going to try to put together a real life example and test out
what is faster.  I will try to have something by end of week.

Thanks again.


On 6/13/07, Karl Swedberg [EMAIL PROTECTED] wrote: 

Hi Benjamin, 

In this case, these are faster ...
$('div.bam')
$('span.bam') 

than this ...
$('.bam')

What I don't know is whether $('div.bam, span.bam') is faster than
$('.bam'). I suspect that it might depend on the what the DOM looks like on
a given page. 




--Karl
_
Karl Swedberg
www.englishrules.com 
www.learningjquery.com




On Jun 13, 2007, at 8:15 AM, Benjamin Sterling wrote:


I hear what everyone is saying about IDs, but lets flip the switch here and
what if we have:

div class=bam 
span class=bam

This situation is a valid situation, one I normally am in (actually in a
link situation).  So, what is the fastest selector to retrieve on or
another. 



-- 
Benjamin Sterling
http://www.KenzoMedia.com
http://www.KenzoHosting.com





-- 
Benjamin Sterling
http://www.KenzoMedia.com
http://www.KenzoHosting.com 


[jQuery] Re: SlickSpeed CSS Selector TestSuite

2007-06-13 Thread Benjamin Sterling

Too much pressure, I crack easily. :)

On 6/13/07, Andy Matthews [EMAIL PROTECTED] wrote:


 We'll expect something by the end of the day today.

Get on that okay?

;)

 --
*From:* jquery-en@googlegroups.com [mailto:[EMAIL PROTECTED] *On
Behalf Of *Benjamin Sterling
*Sent:* Wednesday, June 13, 2007 8:27 AM
*To:* jquery-en@googlegroups.com
*Subject:* [jQuery] Re: SlickSpeed CSS Selector TestSuite

Karl,
Thanks, I am going to try to put together a real life example and test out
what is faster.  I will try to have something by end of week.

Thanks again.

On 6/13/07, Karl Swedberg [EMAIL PROTECTED] wrote:

 Hi Benjamin,
 In this case, these are faster ...
 $('div.bam')
 $('span.bam')

 than this ...
 $('.bam')

 What I don't know is whether $('div.bam, span.bam') is faster than
 $('.bam'). I suspect that it might depend on the what the DOM looks like on
 a given page.


 --Karl
 _
 Karl Swedberg
 www.englishrules.com
 www.learningjquery.com



  On Jun 13, 2007, at 8:15 AM, Benjamin Sterling wrote:

 I hear what everyone is saying about IDs, but lets flip the switch here
 and what if we have:

 div class=bam
 span class=bam

 This situation is a valid situation, one I normally am in (actually in a
 link situation).  So, what is the fastest selector to retrieve on or
 another.



 --
 Benjamin Sterling
 http://www.KenzoMedia.com
 http://www.KenzoHosting.com





--
Benjamin Sterling
http://www.KenzoMedia.com
http://www.KenzoHosting.com





--
Benjamin Sterling
http://www.KenzoMedia.com
http://www.KenzoHosting.com


[jQuery] Re: SlickSpeed CSS Selector TestSuite

2007-06-13 Thread Christopher Jordan

Benjamin,

I have a scheduling program with three months worth of calendars on 
screen. I build the calendars empty on the server side, and then 
populate them with javascript. Each calendar was a table and I was 
storing information on each td like, what date was represented, 
whether the cell was selected, and a couple of other things.


Now, I still just quite a bit of jQuery on the page, but I'm not always 
searching the DOM for information, I've got a couple of structures 
(objects), that I search through now for certain information and it sped 
up a fair amount. However, I really should take a close look at this 
app, and maybe rewrite it from scratch, because it still doesn't pop the 
way it should. In fact, it's quite slow. I'm sure there's plenty that 
I'm doing wrong with it.


Chris

Benjamin Sterling wrote:

I switched to a different methodology and it sped up

Can you explain what you did?  I try to give a full path to an item, ie:

div id=car
div class=part/div
/div

$('div#car div.part')

This may be off topic a bit, but I do believe we should educate people 
on the fastest way to select an object.


--
Benjamin Sterling
http://www.KenzoMedia.com
http://www.KenzoHosting.com 


--
http://www.cjordan.us



[jQuery] Re: SlickSpeed CSS Selector TestSuite

2007-06-13 Thread Toby

I vote for smaller footprint... I also think its quite harsh people making
their own settled opinions on what the file size should be... I believe it
should be as small as possible, not 'sub 100k', or sub '50k' - I heard
comments from JS developers already saying 23k is a lot... as a front end
developer I see it as a reasonable cost as long as the improvements are seen
and or used. In my humble opinion if it was 50k, twice its current size, to
settle some speed reports I would stick to using the old version - even
upping it to 30k would seem rash in my humble opinion - I believe most speed
issues could be addressed by better pathing or syntax considerations.

Don’t forget http://www.dallaway.com/sloppy/ if you have forgotten what 56k
or even ISDN is like... if you want integrity you want gracefulness however
your site is accessed. Saying all this, for sites that do require speed as
priority and can suffer downloading an additional file maybe a plugin would
settle the issue?

I love jQuery :¬)


-Original Message-
From: jquery-en@googlegroups.com [mailto:[EMAIL PROTECTED] On
Behalf Of Gilles (Webunity)
Sent: 13 June 2007 10:01
To: jQuery (English)
Subject: [jQuery] Re: SlickSpeed CSS Selector TestSuite


I agree with Glenn on this one. I vote for more speed, we need to
fight back. Another 5k doesn't matter that much to me or my clients
since all of them have caching on. Maybe an extra plugin?




[jQuery] Re: SlickSpeed CSS Selector TestSuite

2007-06-13 Thread Benjamin Sterling

Toby, that is a great link, thanks for sharing.



Don't forget http://www.dallaway.com/sloppy/ if you have forgotten what
56k
or even ISDN is like... if you want integrity you want gracefulness
however
your site is accessed. Saying all this, for sites that do require speed as
priority and can suffer downloading an additional file maybe a plugin
would
settle the issue?




--
Benjamin Sterling
http://www.KenzoMedia.com
http://www.KenzoHosting.com


[jQuery] Re: SlickSpeed CSS Selector TestSuite

2007-06-13 Thread Glen Lipka

http://www.apple.com/safari/
File size 1.2 megs.

If Toby worked on this website, I think he would spontaneously combust.

Glen

PS.  Every page I visit on Apple seems to get bigger and bigger.



On 6/13/07, Benjamin Sterling [EMAIL PROTECTED] wrote:


Toby, that is a great link, thanks for sharing.


 Don't forget http://www.dallaway.com/sloppy/ if you have forgotten what
 56k
 or even ISDN is like... if you want integrity you want gracefulness
 however
 your site is accessed. Saying all this, for sites that do require speed
 as
 priority and can suffer downloading an additional file maybe a plugin
 would
 settle the issue?



--
Benjamin Sterling
http://www.KenzoMedia.com
http://www.KenzoHosting.com



[jQuery] Re: SlickSpeed CSS Selector TestSuite

2007-06-13 Thread Benjamin Sterling



PS.  Every page I visit on Apple seems to get bigger and bigger.




They must be compensating for a lack of something.

--
Benjamin Sterling
http://www.KenzoMedia.com
http://www.KenzoHosting.com


[jQuery] Re: SlickSpeed CSS Selector TestSuite

2007-06-12 Thread Andy Matthews

It's by the people who won the testing, so that makes it just a little
suspect. This is probably just like the testing from about 6 months back in
which the jQuery library was several versions older than the most recent.
That said, here's what I got:

IE 7.0.57/PC
-
prototype 1.5.1 - 1879
jQuery 1.1.2dev - 3409
MooTools 1.2dev - 1623
ext 1.1b1 - 1206
cssQuery 2.02 - 8057


FF 2.0.0.4/PC
-
prototype 1.5.1 - 267 
jQuery 1.1.2dev - 6940 
MooTools 1.2dev - 278 
ext 1.1b1 - 1725 
cssQuery 2.02 - 9514 

Regardless, it appears to be a nice test suite. 

-Original Message-
From: jquery-en@googlegroups.com [mailto:[EMAIL PROTECTED] On
Behalf Of Bil Corry
Sent: Tuesday, June 12, 2007 8:49 AM
To: jquery-en@googlegroups.com
Subject: [jQuery] Re: SlickSpeed CSS Selector TestSuite


Bil Corry wrote on 6/12/2007 6:43 AM: 
 -
 SlickSpeed is a CSS selector test suite provided by the MooTools folk.
 
 This tool comes at the same time as they release CSS3 support in 
 Mootools, and it compares Prototype, jQuery, MooTools, Ext, and CSS Query.
 
 http://ajaxian.com/archives/slickspeed-css-selector-testsuite
 -

Opps, meant to post the results I got:

  MooTools 1.2dev:   208 ms
  prototype 1.5.1:   231 ms
  ext 1.1b1:1385 ms
  jQuery 1.1.2dev:  5678 ms  -- jQuery!
  cssQuery 2.02:6995 ms


- Bil





[jQuery] Re: SlickSpeed CSS Selector TestSuite

2007-06-12 Thread Michael Stuhr


Andy Matthews schrieb:

It's by the people who won the testing, so that makes it just a little
suspect. This is probably just like the testing from about 6 months back in
which the jQuery library was several versions older than the most recent.
That said, here's what I got:

IE 7.0.57/PC
-
prototype 1.5.1 - 1879
jQuery 1.1.2dev - 3409
MooTools 1.2dev - 1623
ext 1.1b1 - 1206
cssQuery 2.02 - 8057


FF 2.0.0.4/PC
-
prototype 1.5.1 - 267 
jQuery 1.1.2dev - 6940 
MooTools 1.2dev - 278 
ext 1.1b1 - 1725 
cssQuery 2.02 - 9514 




my results:
FF 2.0.0.4 WinXP-SP2
http://onenterframe.de/temp/

micha


[jQuery] Re: SlickSpeed CSS Selector TestSuite

2007-06-12 Thread Andy Matthews

It's crazy how much faster Prototype, MooTools and ext are. 

-Original Message-
From: jquery-en@googlegroups.com [mailto:[EMAIL PROTECTED] On
Behalf Of Michael Stuhr
Sent: Tuesday, June 12, 2007 9:14 AM
To: jquery-en@googlegroups.com
Subject: [jQuery] Re: SlickSpeed CSS Selector TestSuite


Andy Matthews schrieb:
 It's by the people who won the testing, so that makes it just a 
 little suspect. This is probably just like the testing from about 6 
 months back in which the jQuery library was several versions older than
the most recent.
 That said, here's what I got:
 
 IE 7.0.57/PC
 -
 prototype 1.5.1 - 1879
 jQuery 1.1.2dev - 3409
 MooTools 1.2dev - 1623
 ext 1.1b1 - 1206
 cssQuery 2.02 - 8057
 
 
 FF 2.0.0.4/PC
 -
 prototype 1.5.1 - 267
 jQuery 1.1.2dev - 6940
 MooTools 1.2dev - 278
 ext 1.1b1 - 1725
 cssQuery 2.02 - 9514
 


my results:
FF 2.0.0.4 WinXP-SP2
http://onenterframe.de/temp/

micha




[jQuery] Re: SlickSpeed CSS Selector TestSuite

2007-06-12 Thread Rey Bango


One of the reasons that these libraries have made substantial 
improvements has been that jQuery has lead the pack in terms of 
innovation and our efforts have motivated them to finally improve their 
frameworks. Prototype is probably the best example of this, having been 
forced to finally formalize the project after sitting in limbo for 
almost a year, add chaining and even improve its DOM querying.


With that said, its definitely our turn to get things ramped up but 
we're kind of in a quandary. See, one of the benefits of jQuery is its 
very small file size. We're still the smallest library out there and our 
overall functionality is on par with any of the ones listed. In terms of 
overall ease of use, I still think we're the leader. But in keeping a 
small size we're limited in how much tweaking can be done. Neither PT, 
Ext or Moo have limitations on file size so they have the flexibility 
to add much more code to enhance their speed than we do. Our core team 
certainly has the talent to greatly enhance the selector speeds but we 
want to continue to provide a nice, small package.


So at the end of the day, it comes down to this:

- We can increase selector speeds at the expense of file size

or

- We can continue to focus on providing tight code in a small package 
and take what is arguably a small hit in speed


The reason I say arguably is because unless you're manipulating a HUGE 
amount of selectors, I'm not sure how much of a visual difference you 
would see. I know this has been discussed before and that was pretty 
much the consensus (ie: small # of selectors, no big deal. Large # of 
selectors, possible concern).


Considering that we are, IMO, the project thats most in tune with its 
community, your feedback is definitely most welcome.


Rey...


Bil Corry wrote:


Bil Corry wrote on 6/12/2007 6:43 AM:

-
SlickSpeed is a CSS selector test suite provided by the MooTools folk.

This tool comes at the same time as they release CSS3 support in 
Mootools, and it compares Prototype, jQuery, MooTools, Ext, and CSS 
Query.


http://ajaxian.com/archives/slickspeed-css-selector-testsuite
-


Opps, meant to post the results I got:

 MooTools 1.2dev:   208 ms
 prototype 1.5.1:   231 ms
 ext 1.1b1:1385 ms
 jQuery 1.1.2dev:  5678 ms  -- jQuery!
 cssQuery 2.02:6995 ms


- Bil





--
BrightLight Development, LLC.
954-775- (o)
954-600-2726 (c)
[EMAIL PROTECTED]
http://www.iambright.com


[jQuery] Re: SlickSpeed CSS Selector TestSuite

2007-06-12 Thread Robert O'Rourke


Michael Stuhr wrote:


my results:
FF 2.0.0.4 WinXP-SP2
http://onenterframe.de/temp/

micha




Is Jquery slower because it's more compact then? ie. better for light usage?
I much prefer the syntax and the community around jquery. I never got 
any helpful responses from anyone on the mootools forum when I was using 
that library.


Rob



[jQuery] Re: SlickSpeed CSS Selector TestSuite

2007-06-12 Thread Andy Matthews

Don't we have a plugin which might allay some of the speed concerns?

I'm LOVING the fact that jQuery is 19k, BUT even if it were to bump up to
25k or 30k, it would STILL be the smallest overall library. And honestly,
these days, people spend 100k just on one IMAGE, which doesn't even provide
any functionality.

I'd say that increasing the library size up to 10k would be an acceptable
compromise to get increased speed and flexibility.

Thoughts?

-Original Message-
From: jquery-en@googlegroups.com [mailto:[EMAIL PROTECTED] On
Behalf Of Rey Bango
Sent: Tuesday, June 12, 2007 9:25 AM
To: jquery-en@googlegroups.com
Subject: [jQuery] Re: SlickSpeed CSS Selector TestSuite


One of the reasons that these libraries have made substantial improvements
has been that jQuery has lead the pack in terms of innovation and our
efforts have motivated them to finally improve their frameworks. Prototype
is probably the best example of this, having been forced to finally
formalize the project after sitting in limbo for almost a year, add chaining
and even improve its DOM querying.

With that said, its definitely our turn to get things ramped up but we're
kind of in a quandary. See, one of the benefits of jQuery is its very small
file size. We're still the smallest library out there and our overall
functionality is on par with any of the ones listed. In terms of overall
ease of use, I still think we're the leader. But in keeping a small size
we're limited in how much tweaking can be done. Neither PT, Ext or Moo have
limitations on file size so they have the flexibility to add much more code
to enhance their speed than we do. Our core team certainly has the talent to
greatly enhance the selector speeds but we want to continue to provide a
nice, small package.

So at the end of the day, it comes down to this:

- We can increase selector speeds at the expense of file size

or

- We can continue to focus on providing tight code in a small package and
take what is arguably a small hit in speed

The reason I say arguably is because unless you're manipulating a HUGE
amount of selectors, I'm not sure how much of a visual difference you would
see. I know this has been discussed before and that was pretty much the
consensus (ie: small # of selectors, no big deal. Large # of selectors,
possible concern).

Considering that we are, IMO, the project thats most in tune with its
community, your feedback is definitely most welcome.

Rey...


Bil Corry wrote:
 
 Bil Corry wrote on 6/12/2007 6:43 AM:
 -
 SlickSpeed is a CSS selector test suite provided by the MooTools folk.

 This tool comes at the same time as they release CSS3 support in 
 Mootools, and it compares Prototype, jQuery, MooTools, Ext, and CSS 
 Query.

 http://ajaxian.com/archives/slickspeed-css-selector-testsuite
 -
 
 Opps, meant to post the results I got:
 
  MooTools 1.2dev:   208 ms
  prototype 1.5.1:   231 ms
  ext 1.1b1:1385 ms
  jQuery 1.1.2dev:  5678 ms  -- jQuery!
  cssQuery 2.02:6995 ms
 
 
 - Bil
 
 
 

--
BrightLight Development, LLC.
954-775- (o)
954-600-2726 (c)
[EMAIL PROTECTED]
http://www.iambright.com




[jQuery] Re: SlickSpeed CSS Selector TestSuite

2007-06-12 Thread Felix Geisendörfer

Well here is my personal (and widely uneducated) opinion on this speed test.

First what I think is good about it:

   * each framework get's it's own iframe - avoid conflicts between them
   * the test itself is written without using a framework

What I think is bad about it:

   * There are 3 nth-child(x*n)-style tests that jQuery seems to choke
 on as those selectors are not implemented in 1.1.2 (correct me if
 I'm wrong). On my machine this equates in 617ms (20 %) of jQuery's
 total test time (2857ms)
   * The div ~ div selector seems to take jQuery really long to
 perform, 1125ms (43%) go into it
   * The div:only-child + div:contains selector seem to be slow in
 jQuery and 203ms total (12%) go into them

What does this mean? It means that jQuery is nowhere as slow as the 
final test results make it appear (26x slower then mootools). It means 
that mootools got the performance lead in some specific selector (and 
does good in general) which is given way too much weight by the test 
itself.


I'm also questioning how far one can even go in terms of benchmarking 
selector engines. I mean everybody has different needs. Most of the time 
I use very simple selectors which jQuery does very fast according to the 
test. So I'd actually be willing to loose performance on the more 
complicated selectors if that allows the more common ones to run faster. 
What's missing in my eyes is a survey or analysis of common selector 
usage that could be used to weigh in the different selector results.


That being said I'm not trying to say jQuery is actually the fastest 
library and the evil test just made it look bad. I'm sure there is room 
for improvements and who knows what 1.1.3 will bring. But what I'm 
trying to communicate is that it's not an easy job to actually interpret 
the results coming from those speed tests and hence one should be very 
careful when using them to make a point for one lib being faster then 
another.


-- Felix Geisendörfer aka the_undefined
--
http://www.thinkingphp.org
http://www.fg-webdesign.de


Robert O'Rourke wrote:


Michael Stuhr wrote:


my results:
FF 2.0.0.4 WinXP-SP2
http://onenterframe.de/temp/

micha




Is Jquery slower because it's more compact then? ie. better for light 
usage?
I much prefer the syntax and the community around jquery. I never got 
any helpful responses from anyone on the mootools forum when I was 
using that library.


Rob




[jQuery] Re: SlickSpeed CSS Selector TestSuite

2007-06-12 Thread Mike Alsup


Great post, Felix!  Very well said.



What does this mean? It means that jQuery is
nowhere as slow as the final test results make it appear (26x slower then
mootools). It means that mootools got the performance lead in some specific
selector (and does good in general) which is given way too much weight by
the test itself.

 I'm also questioning how far one can even go in terms of benchmarking
selector engines. I mean everybody has different needs. Most of the time I
use very simple selectors which jQuery does very fast according to the test.
So I'd actually be willing to loose performance on the more complicated
selectors if that allows the more common ones to run faster. What's missing
in my eyes is a survey or analysis of common selector usage that could be
used to weigh in the different selector results.


[jQuery] Re: SlickSpeed CSS Selector TestSuite

2007-06-12 Thread Tane Piper


I agree.  I don't want to see jQuery get bloated, but if it was
between the two options of Keep it  20kb but slower or Go to
25-30kb and get major improvements I'd vote for number two.  I'd only
go for number one if there was really going to be little improvement
to any of the changes.

One of the great things for me about jQuery is the shear number of
plugins that add functionality, rather than putting them in the core.
I think more needs to be made of that fact, rather than Prototype's
Lets put everything in one file philosophy.

And the jQuery MVC - Jamal - interests me too.  I'm a CakePHP
developer, and I'd love to start applying the same principles that I
use in that to my jQuery code.  But I don't want the bloat of say Dojo
or Freja.



On 6/12/07, Su [EMAIL PROTECTED] wrote:

On 6/12/07, Rey Bango [EMAIL PROTECTED] wrote:
- We can increase selector speeds at the expense of file size

How about looking at this specifically a little closer? It's already been
pointed out that jQuery could get a lot bigger and /still/ remain the
smallest library. So, the question is why 20k?

I'm not saying damn the filesize, but let's just say that some test comes
out which does illustrated a /significant/ deficiency which is being brought
about by the filesize restriction. What would the argument then be for
staying at 20k?

Is the goal keep the library small or keep the library at 20k? And if
the latter, what is the basis for that number?




--
Tane Piper
http://webrocket.wordpress.com

This email is: [ ] blogable [ x ] ask first [ ] private


[jQuery] Re: SlickSpeed CSS Selector TestSuite

2007-06-12 Thread Robert O'Rourke


Rey Bango wrote:


Hi Robert,

Thats precisely the reason that its slower. We continue to work on 
providing the most comprehensive functionality in the smallest 
package. This is one of the drawbacks of that approach.


Rey...

Robert O'Rourke wrote:
  Is Jquery slower because it's more compact then? ie. better for light

usage?
I much prefer the syntax and the community around jquery. I never got 
any helpful responses from anyone on the mootools forum when I was 
using that library.





Righto, cheers Rey.
I'm definitely sticking with jquery as a tool of choice but I wonder, 
seeing as how mootools is modular couldn't someone just take that 
selector code snippet and write a plugin to make it spit out the jquery 
object?



Rob


[jQuery] Re: SlickSpeed CSS Selector TestSuite

2007-06-12 Thread Glen Lipka

This topic comes up every time a speed test emerges.  To me, speed is
totally irrelevant in most circumstances that I use jQuery.
Speed of Development is most important. if I can finish my job faster then
the user will be happier.  If they have to wait 1/10 of a second longer,
they will not be heart broken.  These tests are geeky comparisons of
technical detail that is irrelevant to human beings.  It's like video card
comparisons that talk about speed of polygonal shading textures per
billionth of a second.

Apple just redesigned their site.  On the inside they use
Scriptaculous/Prorotype.  Check http://www.apple.com/mac.  Notice the file
size, 772k!  That is humongous.  Does it matter what the script is at that
point?

So with that said, although I do like jQuery small, I don't think it makes a
difference whether its 20k or 50k.  In the tradeoff's, I think you need to
find out how much major improvements in speed will really cost?  Is it
really 10k more? Can it be a plugin?  I have no idea.  I am just saying, I
am not concerned with file size up to 50k.

My only concern is about ease of use and maintainability.  As long as jQuery
has that, then all these tests miss the point.

Glen


On 6/12/07, Robert O'Rourke [EMAIL PROTECTED] wrote:



Rey Bango wrote:

 Hi Robert,

 Thats precisely the reason that its slower. We continue to work on
 providing the most comprehensive functionality in the smallest
 package. This is one of the drawbacks of that approach.

 Rey...

 Robert O'Rourke wrote:
   Is Jquery slower because it's more compact then? ie. better for light
 usage?
 I much prefer the syntax and the community around jquery. I never got
 any helpful responses from anyone on the mootools forum when I was
 using that library.



Righto, cheers Rey.
I'm definitely sticking with jquery as a tool of choice but I wonder,
seeing as how mootools is modular couldn't someone just take that
selector code snippet and write a plugin to make it spit out the jquery
object?


Rob



[jQuery] Re: SlickSpeed CSS Selector TestSuite

2007-06-12 Thread Andy Matthews
Well said. That about sums it up for me.

  _  

From: jquery-en@googlegroups.com [mailto:[EMAIL PROTECTED] On
Behalf Of Glen Lipka
Sent: Tuesday, June 12, 2007 11:08 AM
To: jquery-en@googlegroups.com
Subject: [jQuery] Re: SlickSpeed CSS Selector TestSuite


This topic comes up every time a speed test emerges.  To me, speed is
totally irrelevant in most circumstances that I use jQuery.
Speed of Development is most important. if I can finish my job faster then
the user will be happier.  If they have to wait 1/10 of a second longer,
they will not be heart broken.  These tests are geeky comparisons of
technical detail that is irrelevant to human beings.  It's like video card
comparisons that talk about speed of polygonal shading textures per
billionth of a second. 

Apple just redesigned their site.  On the inside they use
Scriptaculous/Prorotype.  Check http://www.apple.com/mac.  Notice the file
size, 772k!  That is humongous.  Does it matter what the script is at that
point? 

So with that said, although I do like jQuery small, I don't think it makes a
difference whether its 20k or 50k.  In the tradeoff's, I think you need to
find out how much major improvements in speed will really cost?  Is it
really 10k more? Can it be a plugin?  I have no idea.  I am just saying, I
am not concerned with file size up to 50k.  

My only concern is about ease of use and maintainability.  As long as jQuery
has that, then all these tests miss the point.

Glen



On 6/12/07, Robert O'Rourke [EMAIL PROTECTED] wrote: 


Rey Bango wrote:

 Hi Robert,

 Thats precisely the reason that its slower. We continue to work on
 providing the most comprehensive functionality in the smallest
 package. This is one of the drawbacks of that approach. 

 Rey...

 Robert O'Rourke wrote:
   Is Jquery slower because it's more compact then? ie. better for light
 usage?
 I much prefer the syntax and the community around jquery. I never got 
 any helpful responses from anyone on the mootools forum when I was
 using that library.



Righto, cheers Rey.
I'm definitely sticking with jquery as a tool of choice but I wonder, 
seeing as how mootools is modular couldn't someone just take that
selector code snippet and write a plugin to make it spit out the jquery
object?


Rob





[jQuery] Re: SlickSpeed CSS Selector TestSuite

2007-06-12 Thread Marshall Salinger





Well said Glen. I would have to agree that these tests are for the most
part totally irrelevant with regards to most usage. Anyways, I would
still use jQuery even if it was 30k. That is still
very small compared to a the image file sizes that are used in highly
designed/styled web sites.

I noticed the Apple site yesterday when downloading Safari for Windows.
They finally dropped the tab navigation! It's about time. I was a
little sad to see that they were using prototype when I looked under
the hood.

-Marshall


Glen Lipka wrote:
This topic comes up every time a speed test emerges. To
me, speed is totally irrelevant in most circumstances that I use jQuery.
  Speed of Development is most
important. if I can finish my job faster then the user will be
happier. If they have to wait 1/10 of a second longer, they will not
be heart broken. These tests are geeky comparisons of technical detail
that is irrelevant to human beings. It's like video card comparisons
that talk about speed of polygonal shading textures per billionth of a
second.
  
  
Apple just redesigned their site. On the inside they use
Scriptaculous/Prorotype. Check http://www.apple.com/mac.
Notice the file size, 772k! That is humongous. Does it matter what
the script is at that point?
  
  
So with that said, although I do like jQuery small, I don't think it
makes a difference whether its 20k or 50k. In the tradeoff's, I think
you need to find out how much "major improvements in speed" will really
cost? Is it really 10k more? Can it be a plugin? I have no idea. I
am just saying, I am not concerned with file size up to 50k. 
  
My only concern is about ease of use and maintainability. As long as
jQuery has that, then all these tests miss the point.
  
Glen
  
  
  On 6/12/07, 
Robert O'Rourke [EMAIL PROTECTED]
wrote:
  
Rey Bango wrote:

 Hi Robert,

 Thats precisely the reason that its slower. We continue to work on
 providing the most comprehensive functionality in the smallest
 package. This is one of the drawbacks of that approach.


 Rey...

 Robert O'Rourke wrote:
 Is Jquery slower because it's more compact then? ie. better
for light
 usage?
 I much prefer the syntax and the community around jquery. I
never got

 any helpful responses from anyone on the mootools forum when I
was
 using that library.



Righto, cheers Rey.
I'm definitely sticking with jquery as a tool of choice but I wonder,

seeing as how mootools is modular couldn't someone just take that
selector code snippet and write a plugin to make it spit out the jquery
object?


Rob
  
  
  






[jQuery] Re: SlickSpeed CSS Selector TestSuite

2007-06-12 Thread Robert O'Rourke


Glen Lipka wrote:
This topic comes up every time a speed test emerges.  To me, speed is 
totally irrelevant in most circumstances that I use jQuery.
Speed of Development is most important. if I can finish my job faster 
then the user will be happier.  If they have to wait 1/10 of a second 
longer, they will not be heart broken.  These tests are geeky 
comparisons of technical detail that is irrelevant to human beings.  
It's like video card comparisons that talk about speed of polygonal 
shading textures per billionth of a second.


Apple just redesigned their site.  On the inside they use 
Scriptaculous/Prorotype.  Check http://www.apple.com/mac.  Notice the 
file size, 772k!  That is humongous.  Does it matter what the script 
is at that point?


So with that said, although I do like jQuery small, I don't think it 
makes a difference whether its 20k or 50k.  In the tradeoff's, I think 
you need to find out how much major improvements in speed will 
really cost?  Is it really 10k more? Can it be a plugin?  I have no 
idea.  I am just saying, I am not concerned with file size up to 50k. 

My only concern is about ease of use and maintainability.  As long as 
jQuery has that, then all these tests miss the point.


Glen




Agreed, I'm not that fussed because it's still plenty nippy and so much 
simpler for a newbite such as myself.
Thats an obscene filesize for apples site! What percentage of people are 
actually on broadband these days? Or do they just not care anymore...


[jQuery] Re: SlickSpeed CSS Selector TestSuite

2007-06-12 Thread Klaus Hartl


Andy Matthews wrote:

Well said. That about sums it up for me.


Yes, I agree as well. The problem is that probably still people will 
draw the wrong conclusions from such tests. I have the feeling that 
library makers just use these tests to get draw attention. Thus its even 
more important to stress the philosophy behind jQuery.


I'd really like to see a real life speed test... Certain selectors I 
have never ever used.



-- Klaus


[jQuery] Re: SlickSpeed CSS Selector TestSuite

2007-06-12 Thread Andy Matthews

I would guess that most (at least a large percentage) of their target
audience has broadband. 

-Original Message-
From: jquery-en@googlegroups.com [mailto:[EMAIL PROTECTED] On
Behalf Of Robert O'Rourke
Sent: Tuesday, June 12, 2007 11:56 AM
To: jquery-en@googlegroups.com
Subject: [jQuery] Re: SlickSpeed CSS Selector TestSuite


Glen Lipka wrote:
 This topic comes up every time a speed test emerges.  To me, speed is 
 totally irrelevant in most circumstances that I use jQuery.
 Speed of Development is most important. if I can finish my job faster 
 then the user will be happier.  If they have to wait 1/10 of a second 
 longer, they will not be heart broken.  These tests are geeky 
 comparisons of technical detail that is irrelevant to human beings.
 It's like video card comparisons that talk about speed of polygonal 
 shading textures per billionth of a second.

 Apple just redesigned their site.  On the inside they use 
 Scriptaculous/Prorotype.  Check http://www.apple.com/mac.  Notice the 
 file size, 772k!  That is humongous.  Does it matter what the script 
 is at that point?

 So with that said, although I do like jQuery small, I don't think it 
 makes a difference whether its 20k or 50k.  In the tradeoff's, I think 
 you need to find out how much major improvements in speed will 
 really cost?  Is it really 10k more? Can it be a plugin?  I have no 
 idea.  I am just saying, I am not concerned with file size up to 50k.

 My only concern is about ease of use and maintainability.  As long as 
 jQuery has that, then all these tests miss the point.

 Glen



Agreed, I'm not that fussed because it's still plenty nippy and so much
simpler for a newbite such as myself.
Thats an obscene filesize for apples site! What percentage of people are
actually on broadband these days? Or do they just not care anymore...




[jQuery] Re: SlickSpeed CSS Selector TestSuite

2007-06-12 Thread DaveG


A lot is being made of how small jQ is. From the quick check I did, jQ 
compressed is 5k smaller than Prototype, and MooTools with a quick selection of 
the functions that seem to be in jQ was 27k, only 10k more than jQ. Considering 
the library is typically downloaded once and then cached, 5-10k is negligible. 

File size is important, but not when we're already down in the single digits 
for differences. Even low double digit difference aren't that significant. At 
this range of difference the only reason file size makes a difference is 
perhaps in understanding/reading the library code -- I suspect that's not 
something that many people do anyway.

What is important is the perception of things like speed tests. People will 
make a library decision by eliminating the slower running, larger sized, 
libraries, and will deifniately steer clear of libraries that seem to fail 
tests. If correcting and improving those things adds a few bytes, then jQ is 
foimproved.

As others have said, 'soft-factors' like ease of use, maintainability, 
documentation (and ability to find and access the documentation), and community 
are the keys. However, being at the bottom of the pile in speed, file size, 
etc, will form a barrier of entry that may override the 'soft-factors'.

 ~ ~ Dave


On Tue, 12 Jun 2007 09:08:25 -0700, Glen Lipka [EMAIL PROTECTED] wrote:
 This topic comes up every time a speed test emerges.  To me, speed is
 totally irrelevant in most circumstances that I use jQuery.
 Speed of Development is most important. if I can finish my job faster then
 the user will be happier.  If they have to wait 1/10 of a second longer,
 they will not be heart broken.  These tests are geeky comparisons of
 technical detail that is irrelevant to human beings.  It's like video card
 comparisons that talk about speed of polygonal shading textures per
 billionth of a second.
 
 Apple just redesigned their site.  On the inside they use
 Scriptaculous/Prorotype.  Check http://www.apple.com/mac.  Notice the file
 size, 772k!  That is humongous.  Does it matter what the script is at that
 point?
 
 So with that said, although I do like jQuery small, I don't think it makes
 a
 difference whether its 20k or 50k.  In the tradeoff's, I think you need to
 find out how much major improvements in speed will really cost?  Is it
 really 10k more? Can it be a plugin?  I have no idea.  I am just saying, I
 am not concerned with file size up to 50k.
 
 My only concern is about ease of use and maintainability.  As long as
 jQuery
 has that, then all these tests miss the point.
 
 Glen
 
 
 On 6/12/07, Robert O'Rourke [EMAIL PROTECTED] wrote:


 Rey Bango wrote:
 
  Hi Robert,
 
  Thats precisely the reason that its slower. We continue to work on
  providing the most comprehensive functionality in the smallest
  package. This is one of the drawbacks of that approach.
 
  Rey...
 
  Robert O'Rourke wrote:
Is Jquery slower because it's more compact then? ie. better for
 light
  usage?
  I much prefer the syntax and the community around jquery. I never got
  any helpful responses from anyone on the mootools forum when I was
  using that library.
 
 
 
 Righto, cheers Rey.
 I'm definitely sticking with jquery as a tool of choice but I wonder,
 seeing as how mootools is modular couldn't someone just take that
 selector code snippet and write a plugin to make it spit out the jquery
 object?


 Rob

 
 



[jQuery] Re: SlickSpeed CSS Selector TestSuite

2007-06-12 Thread Bil Corry


Rey Bango wrote on 6/12/2007 7:25 AM: 

So at the end of the day, it comes down to this:

- We can increase selector speeds at the expense of file size

or

- We can continue to focus on providing tight code in a small package 
and take what is arguably a small hit in speed


Since most browsers cache the .js file on the first hit, wouldn't a small size 
only be most valuable on the first page?  I'm wondering how much benefit is 
derived from a small file size beyond the first page hit.

As for speed improvements, they provide value on every page, not just the first 
hit.  So my vote would be for improving the speed at the expense of file size.


- Bil




[jQuery] Re: SlickSpeed CSS Selector TestSuite

2007-06-12 Thread Su

On 6/12/07, Glen Lipka [EMAIL PROTECTED] wrote:


This topic comes up every time a speed test emerges.  To me, speed is
totally irrelevant in most circumstances that I use jQuery.



It does, and it is. That was why I tried to open the consideration out a bit
further to the eventuality of something more substantial running into the
filesize cap.

I'm of the opinion that the true goal is keeping the library (as) small (as
possible), except that small isn't a number, so an essentially arbitrary
one was chosen. And that's fine, otherwise small would continually be open
to interpretation. Some people say they'd allow up to 25 or 30k, you say up
to 50, etc.

But I'm also curious to know that the limit isn't also arbitrarily absolute.
I'm interested what sort of thing it would take to bring about a serious
reconsideration of that limit, without even getting into discussion of the
numbers that would be involved. The differences shown in this test, for
example, don't seem likely to do it.


[jQuery] Re: SlickSpeed CSS Selector TestSuite

2007-06-12 Thread Priest, James (NIH/NIEHS) [C]

 -Original Message-
 From: Andy Matthews [mailto:[EMAIL PROTECTED] 

 I would guess that most (at least a large percentage) of their target
 audience has broadband. 

Last weekend I was over a friends house with dial-up and I was amazed at
how completely unusable the web was for me...

Gmail, my local weather site, news - all took forever to load up... I no
longer develop public facing sites - but if it's been awhile since
you've tried surfing with a modem - I'd give it a try now and then just
to remember what a majority of people are experiencing on the web...

Sept 2006:
http://www.consumeraffairs.com/news04/2006/09/jd_power_high_speed.html
The study finds that 56 percent of residential ISP customers subscribe
to high-speed Internet service -- an increase of 11 percentage points
from 2005.

So I'm guessing in 07 you are still looking at 40%+ using dialup.  That
said - I'd vote for smaller file sizes...

Jim

There is more to life than simply increasing its speed. ~Gandhi
 


[jQuery] Re: SlickSpeed CSS Selector TestSuite

2007-06-12 Thread Glen Lipka

Things I would vote to increase the base size with:

  1. Dimensions http://jquery.com/plugins/project/dimensions (13k
  uncompressed / 3 packed)
  2. More selectors:
  http://www.softwareunity.com/sandbox/JQueryMoreSelectors/ (12k
  uncompressed / ? packed)
  3. Speed Improvements (Up to 10k additional?)


However, there is a name missing from this thread.  John Resig Esq.
It's his vision, and I think he will get the final say.  He has to answer
what it would take to reconsider the 20k ceiling.

For me, I think the base should be focused on enabling the end-developer AND
the plugin developer.  I think dimensions, and selectors are the meat and
potatoes of the base and should come with that out of the box.  Speed is
less critical for me, but I agree with the perception issue brought up
earlier.  It should be in the ballpark.

Who is good with surverymonkey.com or equivalent?  We need some data.

Glen


On 6/12/07, Su [EMAIL PROTECTED] wrote:


On 6/12/07, Glen Lipka [EMAIL PROTECTED] wrote:

 This topic comes up every time a speed test emerges.  To me, speed is
 totally irrelevant in most circumstances that I use jQuery.


It does, and it is. That was why I tried to open the consideration out a
bit further to the eventuality of something more substantial running into
the filesize cap.

I'm of the opinion that the true goal is keeping the library (as) small
(as possible), except that small isn't a number, so an essentially
arbitrary one was chosen. And that's fine, otherwise small would
continually be open to interpretation. Some people say they'd allow up to 25
or 30k, you say up to 50, etc.

But I'm also curious to know that the limit isn't also arbitrarily
absolute. I'm interested what sort of thing it would take to bring about a
serious reconsideration of that limit, without even getting into discussion
of the numbers that would be involved. The differences shown in this test,
for example, don't seem likely to do it.



[jQuery] Re: SlickSpeed CSS Selector TestSuite

2007-06-12 Thread Tane Piper


Someone once said to me this will be a moot point by 2008 - but I
totally disagreed with them.  Yes countries like the UK, USA, Canada
and Japan may have  80% coverage and  50% subscription rates, but in
these countries as you say there are still a large proportion of users
on dialup.

Many people here in UK cannot get speeds of  2Mbps (now considered
the minimum broadband level) - I'm lucky if I hit 4Mbps on my line,
and my work is still on a 1Mbps ADSL line shared between the whole
office of 15 people.

And don't even get me started on the emerging markets in Africa and
South America..

I've was taught that a start page should be no larger than 500kb in
size, and for Apple to have 700k in just JS, that's just silly.

And to top it off...Apple have released Safari on Windows - yet
another browser to saturate an already crowded market where no one
browser is standards complant and it just makes more work for us
developers.

Anyway, my point I'm making is that jQuery is almost perfect as it is,
and I wouldn't want it to be bloated, but there is leaway to increase
its size a little and still be able to provide highly optimised sites.
If jQuery is one of the slowest libraries out there, then it SHOULD be
optimised - newcomers are going to look at there figures and make a
decision on it - good or bad.  But by providing the middle ground of
maybe being one of the faster ones but still being smaller than
fastest lib, then maybe more people will consider using it.

My 2p



On 6/12/07, Priest, James (NIH/NIEHS) [C] [EMAIL PROTECTED] wrote:


 -Original Message-
 From: Andy Matthews [mailto:[EMAIL PROTECTED]

 I would guess that most (at least a large percentage) of their target
 audience has broadband.

Last weekend I was over a friends house with dial-up and I was amazed at
how completely unusable the web was for me...

Gmail, my local weather site, news - all took forever to load up... I no
longer develop public facing sites - but if it's been awhile since
you've tried surfing with a modem - I'd give it a try now and then just
to remember what a majority of people are experiencing on the web...

Sept 2006:
http://www.consumeraffairs.com/news04/2006/09/jd_power_high_speed.html
The study finds that 56 percent of residential ISP customers subscribe
to high-speed Internet service -- an increase of 11 percentage points
from 2005.

So I'm guessing in 07 you are still looking at 40%+ using dialup.  That
said - I'd vote for smaller file sizes...

Jim

There is more to life than simply increasing its speed. ~Gandhi





--
Tane Piper
http://webrocket.wordpress.com

This email is: [ ] blogable [ x ] ask first [ ] private


[jQuery] Re: SlickSpeed CSS Selector TestSuite

2007-06-12 Thread Sean Catchpole


I hear a lot of discussion about how jQuery isn't that slow, the test
wasn't perfectly fair (what test is?), that keeping code small is
important, and that development time is the most important thing.

1) Lots of people take speed tests seriously, even if they're not a
good way to judge a libraries use.

2) Making jQuery faster doesn't mean it has to be bigger in size, only
more clever.

3) Development time is important, but so are viewer's patience. Slow
code is never good.

4) People's perception of a jQuery is what will ultimately decide it's fame.

I've seen jQuery on the slow end of lots of speed tests. Even if there
are good reasons for it being slow, we should strive to make it
faster.

~Sean


[jQuery] Re: SlickSpeed CSS Selector TestSuite

2007-06-12 Thread Klaus Hartl


Sean Catchpole wrote:

2) Making jQuery faster doesn't mean it has to be bigger in size, only
more clever.


Well, at some point there are boundaries and it has to become bigger. 
For example if using native XPath support in certain browsers is the 
only way to speed it up.



--Klaus


[jQuery] Re: SlickSpeed CSS Selector TestSuite

2007-06-12 Thread Rick

it totaly agree. And about the Dimensions plugin: a lot of other
plugins use their own (not so good) implementation of the
functionality the Dimensions plugin provide.

On 12 jun, 20:22, Glen Lipka [EMAIL PROTECTED] wrote:
 Things I would vote to increase the base size with:

1. Dimensions http://jquery.com/plugins/project/dimensions(13k
uncompressed / 3 packed)
2. More selectors:
http://www.softwareunity.com/sandbox/JQueryMoreSelectors/(12k
uncompressed / ? packed)
3. Speed Improvements (Up to 10k additional?)




[jQuery] Re: SlickSpeed CSS Selector TestSuite

2007-06-12 Thread Christopher Jordan




Sean Catchpole wrote:


I hear a lot of discussion about how jQuery isn't that slow, the test
wasn't perfectly fair (what test is?), that keeping code small is
important, and that development time is the most important thing.

1) Lots of people take speed tests seriously, even if they're not a
good way to judge a libraries use.


I agree 100%

2) Making jQuery faster doesn't mean it has to be bigger in size, only
more clever.


I can't really speak to this one.

3) Development time is important, but so are viewer's patience. Slow
code is never good.

*Absolutely!* I could not agree more. I had a page where I was using a 
bunch of selectors, and it was just plain slow. I switched to a 
different methodology and it sped up (some... I think there are still 
problems with my code on that page... but that's another topic :o)


I would like to see jQuery's speed improve. I don't want a bloated core, 
but if the library stays relatively small (I know very subjective) say, 
under 100K that wouldn't be too bad. Would it?


Chris




--
http://www.cjordan.us



[jQuery] Re: SlickSpeed CSS Selector TestSuite

2007-06-12 Thread Glen Lipka

Ok, Apple engineers are seriously a few kilobytes short of meg.

Check out the file size of http://www.apple.com/itunes/
Compressed its 878k.  But look why. They are using the uncompressed,
unminified, totally commented versions of prototype and scriptaculous.
Nothing is minified, much less packed.  AND, they are not using GZIP on the
scripts either.

Now, most users never know this sort of thing.  But, come on, is a little
craftsmanship that difficult?
One bad Apple spoils the bunch.

Glen



On 6/12/07, Christopher Jordan [EMAIL PROTECTED] wrote:





Sean Catchpole wrote:

 I hear a lot of discussion about how jQuery isn't that slow, the test
 wasn't perfectly fair (what test is?), that keeping code small is
 important, and that development time is the most important thing.

 1) Lots of people take speed tests seriously, even if they're not a
 good way to judge a libraries use.

I agree 100%
 2) Making jQuery faster doesn't mean it has to be bigger in size, only
 more clever.

I can't really speak to this one.
 3) Development time is important, but so are viewer's patience. Slow
 code is never good.

*Absolutely!* I could not agree more. I had a page where I was using a
bunch of selectors, and it was just plain slow. I switched to a
different methodology and it sped up (some... I think there are still
problems with my code on that page... but that's another topic :o)

I would like to see jQuery's speed improve. I don't want a bloated core,
but if the library stays relatively small (I know very subjective) say,
under 100K that wouldn't be too bad. Would it?

Chris


--
http://www.cjordan.us




[jQuery] Re: SlickSpeed CSS Selector TestSuite

2007-06-12 Thread Andy Matthews
Someone should let them know...that's just assinine.

  _  

From: jquery-en@googlegroups.com [mailto:[EMAIL PROTECTED] On
Behalf Of Glen Lipka
Sent: Tuesday, June 12, 2007 4:26 PM
To: jquery-en@googlegroups.com
Subject: [jQuery] Re: SlickSpeed CSS Selector TestSuite


Ok, Apple engineers are seriously a few kilobytes short of meg.  

Check out the file size of http://www.apple.com/itunes/
Compressed its 878k.  But look why. They are using the uncompressed,
unminified, totally commented versions of prototype and scriptaculous. 
Nothing is minified, much less packed.  AND, they are not using GZIP on the
scripts either.

Now, most users never know this sort of thing.  But, come on, is a little
craftsmanship that difficult?
One bad Apple spoils the bunch. 

Glen




On 6/12/07, Christopher Jordan [EMAIL PROTECTED] wrote: 




Sean Catchpole wrote:

 I hear a lot of discussion about how jQuery isn't that slow, the test
 wasn't perfectly fair (what test is?), that keeping code small is
 important, and that development time is the most important thing. 

 1) Lots of people take speed tests seriously, even if they're not a
 good way to judge a libraries use.

I agree 100%
 2) Making jQuery faster doesn't mean it has to be bigger in size, only 
 more clever.

I can't really speak to this one.
 3) Development time is important, but so are viewer's patience. Slow
 code is never good.

*Absolutely!* I could not agree more. I had a page where I was using a 
bunch of selectors, and it was just plain slow. I switched to a
different methodology and it sped up (some... I think there are still
problems with my code on that page... but that's another topic :o)

I would like to see jQuery's speed improve. I don't want a bloated core,
but if the library stays relatively small (I know very subjective) say,
under 100K that wouldn't be too bad. Would it?

Chris 


--
http://www.cjordan.us






[jQuery] Re: SlickSpeed CSS Selector TestSuite

2007-06-12 Thread Benjamin Sterling

I switched to a different methodology and it sped up


Can you explain what you did?  I try to give a full path to an item, ie:

div id=car
   div class=part/div
/div

$('div#car div.part')

This may be off topic a bit, but I do believe we should educate people on
the fastest way to select an object.

--
Benjamin Sterling
http://www.KenzoMedia.com
http://www.KenzoHosting.com


[jQuery] Re: SlickSpeed CSS Selector TestSuite

2007-06-12 Thread Dan G. Switzer, II

One bad Apple spoils the bunch.

I think there's a Donnie Osmond joke in there somewhere... 



[jQuery] Re: SlickSpeed CSS Selector TestSuite

2007-06-12 Thread Dan G. Switzer, II

Benjamin,

I switched to a different methodology and it sped up

Can you explain what you did?  I try to give a full path to an item, ie:

div id=car
div class=part/div
/div

$('div#car div.part')

This may be off topic a bit, but I do believe we should educate people on
the fastest way to select an object.

More information isn't always better. I'm just going to break down the first
part.

Saying div#car is literally saying find me all div tags, where the id
is car. To do that, we have to first get find all DIV tags and then figure
out which one has an id of car.

A much more efficient method is just using #car--which says go get me the
element who's ID is car. The browser has a native method for getting this
and this is very fast an efficient.

-Dan



[jQuery] Re: SlickSpeed CSS Selector TestSuite

2007-06-12 Thread Benjamin Sterling

Really?  hmmm...  guess there a some code a need to change.

A much more efficient method is just using #car--which says go get me the

element who's ID is car. The browser has a native method for getting
this
and this is very fast an efficient.





--
Benjamin Sterling
http://www.KenzoMedia.com
http://www.KenzoHosting.com


[jQuery] Re: SlickSpeed CSS Selector TestSuite

2007-06-12 Thread Rey Bango


Hi Sean,


1) Lots of people take speed tests seriously, even if they're not a
good way to judge a libraries use.


Absolutely true Sean.


2) Making jQuery faster doesn't mean it has to be bigger in size, only
more clever.


Actually that's not 100% true. As Klaus mentioned, there are boundaries 
that you will hit where maintaining a small file size needs to be 
sacrificed in order to achieve greater performance. The core team has 
looked seriously into this, especially in light of all of the speed 
tests. For example, you take DomQuery from the Ext project, which at one 
point was the fastest selector engine out, and its 9K minimized by 
itself. Thats 9k without all of the extra EXT functionality.



3) Development time is important, but so are viewer's patience. Slow
code is never good.


The thing is that in reality, jQuery isn't slow. Unfortunately, these 
tests paint a picture that really doesn't match reality. I have yet to 
see anyone provide a real-world example where jQuery is so slow at DOM 
manipulation that the user experience is unbearable (or anywhere near 
that).


4) People's perception of a jQuery is what will ultimately decide it's 
fame.


This describes the results better than point #3. The perception, based 
on these tests, could certainly sway someone from using jQuery even when 
there's not necessarily a problem.


Rey...


[jQuery] Re: SlickSpeed CSS Selector TestSuite

2007-06-12 Thread Benjamin Sterling

That is what I thought, especially after reading (I thought it was on
learningjquery.com, but could not find it) an article a couple months back.
Maybe someone can put together a Best Practices article.



That's the way it worked pre 1.1. Now, it's get #car and check if it's a
div.



--
Benjamin Sterling
http://www.KenzoMedia.com
http://www.KenzoHosting.com


[jQuery] Re: SlickSpeed CSS Selector TestSuite

2007-06-12 Thread Aaron Heimlich

On 6/12/07, Benjamin Sterling [EMAIL PROTECTED] wrote:


(I thought it was on learningjquery.com, but could not find it) an article
a couple months back.



Could you be thinking of
http://aheimlich.freepgs.com/javascript/jquery-11-selector-speeds (server
seems to be a bit funky today, so watch out).

--
Aaron Heimlich
Web Developer
[EMAIL PROTECTED]
http://aheimlich.freepgs.com


[jQuery] Re: SlickSpeed CSS Selector TestSuite

2007-06-12 Thread Karl Swedberg

I think maybe he was referring to this one:
http://www.learningjquery.com/2006/12/quick-tip-optimizing-dom-traversal

As someone else already mentioned, the part about how it finds  
something like $('div#foo') is no longer true (as of 1.1), but the  
general principles are still relevant, I think.


It has a link to a speed test I threw together, and also to Aaron's  
enhancement. There was a further enhancement somewhere -- I think a  
subdomain of jquery.com -- at some point, but don't know if it's  
still there, especially after the ddos attack.


I've enjoyed reading the discussion about selector speeds and file size.

--Karl
_
Karl Swedberg
www.englishrules.com
www.learningjquery.com



On Jun 12, 2007, at 6:40 PM, Aaron Heimlich wrote:

On 6/12/07, Benjamin Sterling [EMAIL PROTECTED]  
wrote:
(I thought it was on learningjquery.com, but could not find it) an  
article a couple months back.


Could you be thinking of http://aheimlich.freepgs.com/javascript/ 
jquery-11-selector-speeds (server seems to be a bit funky today, so  
watch out).


--
Aaron Heimlich
Web Developer
[EMAIL PROTECTED]
http://aheimlich.freepgs.com




[jQuery] Re: SlickSpeed CSS Selector TestSuite

2007-06-12 Thread Aaron Heimlich

On 6/12/07, Karl Swedberg [EMAIL PROTECTED] wrote:


It has a link to a speed test I threw together, and also to Aaron's
enhancement.



Just so nobody's confused, Karl's link[1] and my Firebug-enhanced speed
test[2] both deal with jQuery 1.0, not 1.1. I have yet to upgrade my
Firebug-enhanced test to jQuery 1.1.

[1] http://www.learningjquery.com/2006/12/quick-tip-optimizing-dom-traversal
[2] http://aheimlich.freepgs.com/tests/jquery/speed-test-firebug/

--
Aaron Heimlich
Web Developer
[EMAIL PROTECTED]
http://aheimlich.freepgs.com


[jQuery] Re: SlickSpeed CSS Selector TestSuite

2007-06-12 Thread Karl Swedberg

Oh yeah. thanks a lot for pointing that out, Aaron.

By the way, does anyone know which page the slickspeed test is run on  
(http://mootools.net/slickspeed/) ?  I can't find any of the actual  
elements on the page itself.


It's funny, though, that from the looks of the window.selectors array 
[1], they're using the same page I threw together back in December,  
which in retrospect was probably a dumb choice on my part, because it  
doesn't exactly represent a typical page on a corporate site or  
blog or anything else really. I just grabbed a portion of  
Shakespeare's As You Like It (an excerpt of Act I, Scene III, in case  
anyone else out there is a literature buff. :) ) and marked it up  
with HTML. Oh well, chalk it up to the folly of youth. I do think,  
however, that someone should come up with a better test page for  
these speed tests, especially if people are going to use them to  
compare the various libraries and take the results so seriously.


[1]
window.selectors = ['*','div:only-child','div:contains 
(CELIA)','div:nth-child(even)','div:nth-child(2n)','div:nth-child 
(odd)','div:nth-child(2n+1)','div:nth-child(n)','div:last- 
child','div:first-child','div  div','div + div','div ~  
div','body','body div','div','div div','div div div','div, div,  
div','div, a,  
span','.dialog','div.dialog','div .dialog','div.character,  
div.dialog','#speech5','div#speech5','div #speech5','div.scene  
div.dialog','div#scene1 div.dialog div','#scene1 #speech1','div[% 
class]','div[%class=dialog]','div[%class^=dia]','div[%class 
$=log]','div[%class*=sce]','div[%class|=dialog]','div[%class! 
=madeup]','div[%class~=dialog]']




--Karl
_
Karl Swedberg
www.englishrules.com
www.learningjquery.com



On Jun 12, 2007, at 7:09 PM, Aaron Heimlich wrote:


On 6/12/07, Karl Swedberg [EMAIL PROTECTED] wrote:
It has a link to a speed test I threw together, and also to Aaron's  
enhancement.


Just so nobody's confused, Karl's link[1] and my Firebug-enhanced  
speed test[2] both deal with jQuery 1.0, not 1.1. I have yet to  
upgrade my Firebug-enhanced test to jQuery 1.1.


[1] http://www.learningjquery.com/2006/12/quick-tip-optimizing-dom- 
traversal

[2] http://aheimlich.freepgs.com/tests/jquery/speed-test-firebug/

--
Aaron Heimlich
Web Developer
[EMAIL PROTECTED]
http://aheimlich.freepgs.com




[jQuery] Re: SlickSpeed CSS Selector TestSuite

2007-06-12 Thread Benjamin Sterling

Karl,

By the way, does anyone know which page the slickspeed test is run on (

http://mootools.net/slickspeed/) ?  I can't find any of the actual
elements on the page itself.



Not sure if I understand your question correctly, but they are using iframes
for each framework.

... I do think, however, that someone should come up with a better test page

for these speed tests, especially if people are going to use them to compare
the various libraries and take the results so seriously.



I totally agree, I would suggest taking a top ranked site, maybe
microsoft.com, and setting up a test geared for that site.


--
Benjamin Sterling
http://www.KenzoMedia.com
http://www.KenzoHosting.com


[jQuery] Re: SlickSpeed CSS Selector TestSuite

2007-06-12 Thread Dan G. Switzer, II

   Saying div#car is literally saying find me all div tags, where
the id
   is car. To do that, we have to first get find all DIV tags and
then
figure
   out which one has an id of car.


That's the way it worked pre 1.1. Now, it's get #car and check if it's a
div.

I actually thought that was the case now, but it's still faster not to
perform additional checks if not needed.

Plus, what happens if you have:

div id=bam /

span id=bam /

What if you need to retrieve the span tag? If it's checking #bam first,
won't it only find the div / element?

(And yes, I know the HTML spec says that IDs should be unique, but
occasionally you're dealing w/dynamically generated server content that's
out of your control.)

-Dan



[jQuery] Re: SlickSpeed CSS Selector TestSuite

2007-06-12 Thread Benjamin Sterling

div id=bam /

span id=bam /

What if you need to retrieve the span tag? If it's checking #bam first,
won't it only find the div / element?



But that is my thinking of why $('span#bam') would be faster then just
$('bam').


(And yes, I know the HTML spec says that IDs should be unique, but

occasionally you're dealing w/dynamically generated server content that's
out of your control.)



In that case,  when I generate dynamically I append the id with the unique
id of the record.



--
Benjamin Sterling
http://www.KenzoMedia.com
http://www.KenzoHosting.com


[jQuery] Re: SlickSpeed CSS Selector TestSuite

2007-06-12 Thread Aaron Heimlich

On 6/12/07, Dan G. Switzer, II [EMAIL PROTECTED] wrote:


Plus, what happens if you have:

div id=bam /

span id=bam /

What if you need to retrieve the span tag? If it's checking #bam first,
won't it only find the div / element?



The DOM2 has this to say:

getElementById introduced in DOM Level 2

Returns the Element whose ID is given by elementId. If no such element
exists, returns null. Behavior is not defined if more than one element has
this ID.



Source: http://www.w3.org/TR/DOM-Level-2-Core/core.html#ID-getElBId

I would think that the first one the browser finds is selected, but I can't
be certain of that as I've never actually tried to do this.

--
Aaron Heimlich
Web Developer
[EMAIL PROTECTED]
http://aheimlich.freepgs.com


[jQuery] Re: SlickSpeed CSS Selector TestSuite

2007-06-12 Thread Matt Stith

Yes, getElementById returns the first one found, i.e. the first one in the
dom, if there are multiple nodes with the same id.

On 6/12/07, Aaron Heimlich [EMAIL PROTECTED] wrote:


On 6/12/07, Dan G. Switzer, II [EMAIL PROTECTED] wrote:

 Plus, what happens if you have:

 div id=bam /

 span id=bam /

 What if you need to retrieve the span tag? If it's checking #bam first,
 won't it only find the div / element?


The DOM2 has this to say:

getElementById introduced in DOM Level 2
 Returns the Element whose ID is given by elementId. If no such
 element exists, returns null. Behavior is not defined if more than one
 element has this ID.


Source: http://www.w3.org/TR/DOM-Level-2-Core/core.html#ID-getElBId

I would think that the first one the browser finds is selected, but I
can't be certain of that as I've never actually tried to do this.

--
Aaron Heimlich
Web Developer
[EMAIL PROTECTED]
http://aheimlich.freepgs.com


[jQuery] Re: SlickSpeed CSS Selector TestSuite

2007-06-12 Thread Dan G. Switzer, II

But that is my thinking of why $('span#bam') would be faster then just
$('bam').

But getting an element by ID is much faster--because there's a native method
of retrieval. 

You're either selecting all span / tags and then looking to see which has
an ID of bam, or your finding the first instance of bam and then
checking to see if it's a span / tag.

If you use #bam it uses document.getElementById(bam)--which is native to
the browser and uses a predefined map to the objects and returns the object
with little processing expense.

The other two methods require additional processing on the behalf of jQuery.

That's when my ID is unique, I use the simplest selector: #bam.

-Dan 



[jQuery] Re: SlickSpeed CSS Selector TestSuite

2007-06-12 Thread Dan G. Switzer, II

Yes, getElementById returns the first one found, i.e. the first one in the
dom, if there are multiple nodes with the same id.

The fact that jQuery looks for the id first, then the tag definitely
improves performance, but causes the following example to fail:

script type=text/javascript
$(document).ready(
function (){
$(div#bam).append( -- yellow);
$(p#bam).append( -- pink);
}
);
/script

style type=text/css
div#bam {
background-color: yellow;
}

p#bam {
background-color: pink;
}
/style

div

div id=bamI'm div#bam!/div

p id=bamI'm p#bam!/p

/div

If you run this example, the div / has a yellow background and the p /
has a pink background. 

However, only the div / get it's text appended to it. You can work around
it by doing:

$([EMAIL PROTECTED]'bam']).append( -- pink);

This just isn't exactly intuitive and can be confusing to people who'd
expect a valid CSS selector rule to work in jQuery.

-Dan



[jQuery] Re: SlickSpeed CSS Selector TestSuite

2007-06-12 Thread Aaron Heimlich

On 6/12/07, Dan G. Switzer, II [EMAIL PROTECTED] wrote:


This just isn't exactly intuitive and can be confusing to people who'd
expect a valid CSS selector rule to work in jQuery.



Except that, while the selectors are syntactically valid, you can't have
duplicate IDs on the same page, so you're basically at the mercy of how the
browser decides to handle this situation. As has been said before, scripting
on top of an invalid DOM is asking for trouble. If you cannot avoid doing
this (i.e. the HTML is generated by a CMS that you have no control over),
then

$([EMAIL PROTECTED]'bam']).append( -- pink);

is probably the best workaround.

--
Aaron Heimlich
Web Developer
[EMAIL PROTECTED]
http://aheimlich.freepgs.com


[jQuery] Re: SlickSpeed CSS Selector TestSuite

2007-06-12 Thread Karl Swedberg



On Jun 12, 2007, at 8:14 PM, Benjamin Sterling wrote:



By the way, does anyone know which page the slickspeed test is run  
on ( http://mootools.net/slickspeed/) ?  I can't find any of the  
actual elements on the page itself.


Not sure if I understand your question correctly, but they are  
using iframes for each framework.


Yeah, you were understanding me correctly. I was being thick. Didn't  
see the iframes in the source first time around. And, regrettably,  
they are using the As You Like It page.


--Karl
_
Karl Swedberg
www.englishrules.com
www.learningjquery.com




[jQuery] Re: SlickSpeed CSS Selector TestSuite

2007-06-12 Thread Karl Swedberg



On Jun 12, 2007, at 9:57 PM, Dan G. Switzer, II wrote:



If you run this example, the div / has a yellow background and  
the p /

has a pink background.

However, only the div / get it's text appended to it. You can  
work around

it by doing:

$([EMAIL PROTECTED]'bam']).append( -- pink);


yep. that's the workaround.


This just isn't exactly intuitive and can be confusing to people who'd
expect a valid CSS selector rule to work in jQuery.


True, it can be confusing. But a lot of things are potentially  
confusing to people who are writing HTML that isn't valid. A few  
months ago I hung out on the CSS IRC channel, but I had to stop after  
a few days because it was too excruciating to hear person after  
person complaining about how CSS wasn't working right, only to  
discover that they're HTML wasn't valid.


Others have said it here on the list before, and I agree, that it's a  
fool's errand to try to make jQuery anticipate the ways in which  
people are going to write bad markup.




--Karl
_
Karl Swedberg
www.englishrules.com
www.learningjquery.com