Closed Bug 778732 Opened 7 years ago Closed 7 years ago

Change JSTerm's $ helper function from getElementById to querySelector


(DevTools :: Console, defect)

Not set


(Not tracked)

Firefox 17


(Reporter: rcampbell, Assigned: rcampbell)


(Whiteboard: [fixed-in-fx-team])


(1 file)

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.
cc'ing some people...
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.
(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.
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 $$()?
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).
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.
(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.
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.
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.
Attached patch querySelectaSplinter Review
Assignee: nobody → rcampbell
Attachment #648449 - Flags: review?(mihai.sucan)
Comment on attachment 648449 [details] [diff] [review]

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

r+ if all tests pass, no doubt. Thank you!
Attachment #648449 - Flags: review?(mihai.sucan) → review+
Whiteboard: [land-in-fx-team]
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.

Closed: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 17
Product: Firefox → DevTools
You need to log in before you can comment on or make changes to this bug.