Last Comment Bug 778732 - Change JSTerm's $ helper function from getElementById to querySelector
: Change JSTerm's $ helper function from getElementById to querySelector
Status: RESOLVED FIXED
[fixed-in-fx-team]
:
Product: Firefox
Classification: Client Software
Component: Developer Tools: Console (show other bugs)
: unspecified
: All All
: -- normal (vote)
: Firefox 17
Assigned To: Rob Campbell [:rc] (:robcee)
: developer.tools
Mentors:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-07-30 07:53 PDT by Rob Campbell [:rc] (:robcee)
Modified: 2012-08-03 14:26 PDT (History)
8 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
querySelecta (1.48 KB, patch)
2012-08-02 12:53 PDT, Rob Campbell [:rc] (:robcee)
mihai.sucan: review+
Details | Diff | Review

Description Rob Campbell [:rc] (:robcee) 2012-07-30 07:53:56 PDT
getElementById is not that useful in most pages. In most cases, it would be useful to be able to run querySelector and get back the first matching element. This is also more consistent with $$ mapping to querySelectorAll.

Suggested by Paul Irish and addyosmani in #firebug.
Comment 1 Rob Campbell [:rc] (:robcee) 2012-07-30 07:56:04 PDT
cc'ing some people...
Comment 2 Jan Honza Odvarko [:Honza] 2012-07-30 07:57:14 PDT
Bug report cloned in Firebug issue list
http://code.google.com/p/fbug/issues/detail?id=5764

Honza
Comment 3 Rob Campbell [:rc] (:robcee) 2012-07-30 08:20:31 PDT
https://bugs.webkit.org/show_bug.cgi?id=92648
Comment 4 Steve Roussey (:sroussey) 2012-07-31 23:10:27 PDT
What is the point of this? Other than to make the PrototypeJS based design more like a jQuery one? I'm not necessarily opposed per se, but changing this underneath a global set of developers could be a... uh... bad experience.
Comment 5 Panos Astithas [:past] 2012-08-01 03:44:26 PDT
(In reply to Steve Roussey (:sroussey) from comment #4)
> What is the point of this? Other than to make the PrototypeJS based design
> more like a jQuery one? I'm not necessarily opposed per se, but changing
> this underneath a global set of developers could be a... uh... bad
> experience.

Change is always hard, but Paul Irish posted some survey results in IRC a few days ago that suggested developers would welcome this change. Unfortunately, I don't have the links or the numbers available.
Comment 6 Jan Honza Odvarko [:Honza] 2012-08-01 04:05:44 PDT
Here is the survey page:
https://docs.google.com/spreadsheet/viewform?formkey=dHA5RjFzbF9tcElCa3VXYm13ZTctdkE6MQ

Honza
Comment 7 Steve Roussey (:sroussey) 2012-08-01 12:00:32 PDT
From a Firebug developer point of view, I think it is ok. But as a Firebug user I don't like it (a view not strongly held, at least while I think about it). 

But I'm sure a PrototypeJS core dev would promote a survey saying the opposite of what a jQuery core dev would. I'm not surprised that the jQuery team promotes changes to make things more like jQuery, surveys jQuery people and gets jQuery results.

Then again, maybe Query is the way to go, and should be part of the DOM. And I'm not at all being sarcastic.

Anyhow, what is so bad about typing an extra character and using $$()?
Comment 8 Mihai Sucan [:msucan] 2012-08-01 12:05:11 PDT
As a user I no longer find $() useful as implemented (getElementById). I rarely need it.

If $() uses querySelector() << I'd like it more.

Wrt. $ versus $$: I expect $ returns a node (or null), while $$ returns a nodelist (an array, or something like that).
Comment 9 Steve Roussey (:sroussey) 2012-08-01 12:13:29 PDT
I should have re-read my comment before hitting save. I didn't mean to imply that the jQuery team (or Paul, whom I met once, and is great) might in any way mis-represent some survey findings.
Comment 10 Paul Irish 2012-08-01 16:47:37 PDT
(In reply to Steve Roussey (:sroussey) from comment #9)

To be honest I dont think I reach a biased set of developers and I'd consider them representative of the whole population (though probably more participatory). Anybody could distribute such questions and get similar figures, I'll wager. 
Prototype just doesn't set the conventions for javascript developers anymore. So this ticket is about adapting to the norm. Paving the cowpaths.
Comment 11 Rob Campbell [:rc] (:robcee) 2012-08-02 11:27:53 PDT
From my own very informal survey of the web, I don't see many pages that use ids on DOM nodes. $() as it is currently implemented is not very useful, ime. I would accept a patch to swap the behavior from getElementById to querySelector.
Comment 12 Steve Roussey (:sroussey) 2012-08-02 11:42:12 PDT
Paul, I think you sell yourself short as far as being a spokesperson for jQuery, and thus having a biased following. If not you, then who is?

At any rate, real data would be interesting. I can instrument the use of $() in the console, which will be interesting to look at. Perhaps, since there are so many jQuery devs out there, everyone is using $("#someid") right now and it is failing for them.

I don't really see the reason to have $=function(s){return $$(s)[0];}. I really dislike that it is returning a single node when many match. So it is more than convention change, it about not being quite truthful. Before $ always returned one item, because there could be only one id on the page. Now the meaning is changing, not just the selector. Do we issue warnings to the console that we selected the first item, but others matched and you could use $$ to get them all?

I'd rather just force more of jQuery into the page and return a jQuery object. And I'm guessing that this is the end goal anyhow. Though FireQuery can do this already.

What do we do when people continue to do $(id)? Do we see that nothing is returned, and then try $("#"+id) and return that? If so, do we also issue a warning to the console? Or maybe the warning only and return null? How do we transition such that we don't get lots of bug reports? Firebug has the issue tracker right in the product. Firefox dev tools and Chrome dev tools do not. Firebug will get the brunt of support requests, error reports, etc.
Comment 13 Steve Roussey (:sroussey) 2012-08-02 11:45:49 PDT
Paul's results are here:

https://docs.google.com/spreadsheet/viewanalytics?formkey=dHA5RjFzbF9tcElCa3VXYm13ZTctdkE6MQ
Comment 14 Rob Campbell [:rc] (:robcee) 2012-08-02 12:53:45 PDT
Created attachment 648449 [details] [diff] [review]
querySelecta
Comment 15 Mihai Sucan [:msucan] 2012-08-02 13:14:32 PDT
Comment on attachment 648449 [details] [diff] [review]
querySelecta

Review of attachment 648449 [details] [diff] [review]:
-----------------------------------------------------------------

r+ if all tests pass, no doubt. Thank you!
Comment 16 Panos Astithas [:past] 2012-08-03 01:54:43 PDT
https://hg.mozilla.org/integration/fx-team/rev/6ad33e8a2fb8
Comment 17 Sebastian Zartner [:sebo] 2012-08-03 02:17:55 PDT
Actually I don't understand the reasons not to change the behavior.
$() is just valid inside the command line, which means it doesn't break any page's codes.

Instead of writing $("bla") people will now have to write $("#bla"). One character more for the original functionality but therefore way enhanced possibilities in regard of selecting elements.

Of course there will be complaints about the change. But in this case it should be pretty easy to convince the people that the new behavior is better than the current one.

Sebastian
Comment 18 Rob Campbell [:rc] (:robcee) 2012-08-03 14:26:19 PDT
https://hg.mozilla.org/mozilla-central/rev/6ad33e8a2fb8

Note You need to log in before you can comment on or make changes to this bug.