Bikesheds Re: [selectors-api] Consider backporting find() behavior to querySelector()
On Wed, 20 Jun 2012 16:26:14 +0200, Lachlan Hunt lachlan.h...@lachy.id.au wrote: On 2012-06-20 10:42, Charles McCathieNevile wrote: In other words we have the same arguments that we had five years ago, when we settled on querySelector as the one that provoked least objection. ... But spending another few months arguing about it hasn't proven that we are any wiser, nor (importantly) any closer to agreement. This is why it should be an editorial decision, not a group vote. The least-objectionable alternative is rarely the best alternative, and trying to please everyone is a fool's errand. Hopefully, this time, the group will let me, as editor, evaluate the options and supporting rationale and make a decision based on that. Yeah, if that works, it's fine. Back then we were in a position where people cared enough to object, so we chose a different way of making most of the people unhappy that drew less objection... cheers Chaals (You think this is bad, people bikeshed how I should write *my*name* ...) -- Charles 'chaals' McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg kan noen norsk http://my.opera.com/chaals Try Opera: http://www.opera.com
Re: [selectors-api] Consider backporting find() behavior to querySelector()
On 2012-06-20 17:46, Marat Tanalin | tanalin.com wrote:
20.06.2012, 18:14, Lachlan Hunt lachlan.h...@lachy.id.au:
4. Support for returning elements that are not descendants of the
context object.
This feature allows a selector to be constructed such that it matches an
element anywhere in the tree relative to the context element. This
feature is not relevant to document.find(), since it can already return
anything from the whole tree.
elm.find(+span)// span is a sibling
elm.find(/for/ input) // input could be anywhere
elm.find(:not(:scope)) // Everything except the context object
This feature cannot be supported on Element.qSA, even when using eplicit
:scope, because matching elements need to be descendants of the context
object.
It's unclear why an _updated_ qSA version should have same limitation
that matching elements need to be descendants of the context
object. There is nothing obvious that makes h1.querySelector('+ H2')
impossible to work in newer implementations (in older ones it would
not work anyway -- to the same extent as `elm.querySelector(span)`
that you've declared as could work).
Supporting this without the risk of breaking compatibility would require
switching selection behaviour based on the presence of the :scope pseudo
class (either explicit or implied), for each individual selector in the
group. When :scope is present, then matching could be applied to the
entire tree, just like it is in element.find().
That is, given the group of selectors:
elm.querySelectorAll(:scope+p, div p)
(Note: After pre-processing, there is no difference between explicit
:scope and implied :scope in +p)
Only :scope+p would be permitted to match non-descendant elements and
the other div p would have to retain the backwards compatible
selection behaviour where the subject of the selector must be a
descendant of the context object.
That means, the implementation would need to split the group of
selectors such that :scope+p (or any other selector with explicit or
implied :scope) is potentially compared with all elements in the tree.
Then the other selector div p should only be compared with descendants
of the context object.
It will also not work for the reference combinator in some cases. If
switching selection behaviour depends on the presence of :scope, then
the reference combinator will not always work effectively.
elm.querySelectorAll(label /for/ input)
In this case with no :scope, the matching input must be a descendant of
the context object, but the label may or may not be. Compare that with
this:
elm.findAll(label /for/ input)
In this case, :scope is implied at the beginning, so the label must be a
descendant of the context object, but the matching input elements may
appear anywhere in the tree.
Overall, this adds significant complexity to the implementations, so
while it may actually be technically possible in some cases, it's far
from ideal and doesn't address all problems.
--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/
Re: Bikesheds Re: [selectors-api] Consider backporting find() behavior to querySelector()
(12/06/20 22:26), Lachlan Hunt wrote: On 2012-06-20 10:42, Charles McCathieNevile wrote: In other words we have the same arguments that we had five years ago, when we settled on querySelector as the one that provoked least objection. ... But spending another few months arguing about it hasn't proven that we are any wiser, nor (importantly) any closer to agreement. This is why it should be an editorial decision, not a group vote. While I don't think a WG vote is the right way to do, I strongly disagree that naming of a function belongs to an editorial decision. Changing the name of a function requires all the tests be rewritten, and therefore it is by definition not editorial. The least-objectionable alternative is rarely the best alternative, and trying to please everyone is a fool's errand. While I agree that trying to please everyone is foolish, I am curious about data that can be used to prove the the least-objectionable alternative is rarely the best alternative statement. Hopefully, this time, the group will let me, as editor, evaluate the options and supporting rationale and make a decision based on that. I don't know what happened when the WG decided on the poor name querySeletor, but from a outsider's point of view, along with the final decision, I also care about a detailed description about why a function name is chosen. For example, attributing the poor querySelector decision to an abstract concept of design by committee doesn't seem to be reasonable and genuine. I'd rather want to see a long explanation like: Despite the fact the editor thinks function name X is better than 'querySelector', there were a few people (name goes here) who were strongly opposed to X and a group vote happened and a decision was made by (name goes here). Nobody ran a compatibility research. And this time, I would like to ask whoever is going to make the decision to take the opinion of the *public* into account. I am not saying it should be the sole factor, but what I am looking for is an explanation like Compatibility research shows that both name X and Y are fine. 70% of the Web developers are in favor of name X and therefore X is chosen. or Despite 70% of the Web developers are in favor of name X, compatibility research shows that or even Despite 70% of the Web developers are in favor of name X, 100% of browser developers are not and therefore ... or even Nobody ran either a public vote and compatibility research and the editor made the decision on X because he likes it. (Seriously, I don't see why a rationale like this is better than the one for querySelector as this is pretty much just s/WG/editor/ of that since the WG vote didn't represent the public, but at least this is easier to understand than design by committee or design by editor, which is just well, difficult to understand to a causal person who cares about the standard but doesn't have the bandwidth to go in.) In other words, while I can agree that a single +1/-1 statement isn't strong as a rationale (or even not a rationale) I beg you to take the sum as a valid and strong rationale, at least in this case where X and Y don't have much difference. And I am still interested in what really happened last time. (will try to bring real feedback next time.) Cheers, Kenny
Re: Bikesheds Re: [selectors-api] Consider backporting find() behavior to querySelector()
On 2012-06-21 15:56, Kang-Hao (Kenny) Lu wrote: (12/06/20 22:26), Lachlan Hunt wrote: On 2012-06-20 10:42, Charles McCathieNevile wrote: In other words we have the same arguments that we had five years ago, when we settled on querySelector as the one that provoked least objection. ... But spending another few months arguing about it hasn't proven that we are any wiser, nor (importantly) any closer to agreement. This is why it should be an editorial decision, not a group vote. While I don't think a WG vote is the right way to do, I strongly disagree that naming of a function belongs to an editorial decision. Changing the name of a function requires all the tests be rewritten, and therefore it is by definition not editorial. By editorial decision, I meant that the decision of what to name it should be up to the editor, not that it is a minor editorial issue. Sorry for the confusion. Fixing tests is trivial, but the name should be decided before implementation begins and a testsuite is written anyway. At this stage, I haven't seen any overly strong objections to the names find/findAll anyway, so hopefully this is a non-issue. Hopefully, this time, the group will let me, as editor, evaluate the options and supporting rationale and make a decision based on that. I don't know what happened when the WG decided on the poor name querySeletor, but from a outsider's point of view, along with the final decision, I also care about a detailed description about why a function name is chosen. For example, attributing the poor querySelector decision to an abstract concept of design by committee doesn't seem to be reasonable and genuine. I'd rather want to see a long explanation like: What happened last time was that I carefully reviewed the entire debate, taking into account all arguments for and against every suggested alternative I found at the time and posted a thorough review and rationale for the decision I made at the end. http://lists.w3.org/Archives/Public/public-webapi/2007Jun/0077.html This then resulted in some people in the group complaining loudly enough because they weren't happy, mostly because it's impossible to please everyone, leading to a vote between 6 choices, ultimately overruling me. Anecdotally, I heard from a few web developers at the time saying they even liked the names I'd chosen, despite them being a little long, but were later disappointed with the result of the vote. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: Bikesheds Re: [selectors-api] Consider backporting find() behavior to querySelector()
On Thu, 21 Jun 2012 15:56:45 +0200, Kang-Hao (Kenny) Lu kennyl...@csail.mit.edu wrote: (12/06/20 22:26), Lachlan Hunt wrote: On 2012-06-20 10:42, Charles McCathieNevile wrote: In other words we have the same arguments that we had five years ago, when we settled on querySelector as the one that provoked least objection. ... The least-objectionable alternative is rarely the best alternative, and trying to please everyone is a fool's errand. While I agree that trying to please everyone is foolish, I am curious about data that can be used to prove the the least-objectionable alternative is rarely the best alternative statement. I don't think there is any readily available. There are no clear criteria for judging best, although there are some clear criteria for judging bad - for example things that often get confused are definitely bad. Hopefully, this time, the group will let me, as editor, evaluate the options and supporting rationale and make a decision based on that. I don't know what happened when the WG decided on the poor name querySeletor Pretty much what Lachy said. As chair, I was the one who decided there ws too much objection and called for some other process. I don't claim it was especially good or came up with a great name, but I don't think it was awful and I don't see a better alternative if the situation arises again. Despite the fact the editor thinks function name X is better than 'querySelector', there were a few people (name goes here) who were strongly opposed to X and a group vote happened and a decision was made by (name goes here). Nobody ran a compatibility research. And this time, I would like to ask whoever is going to make the decision to take the opinion of the *public* into account. I am not saying it should be the sole factor, but what I am looking for is an explanation like Compatibility research shows that both name X and Y are fine. 70% of the Web developers are in favor of name X and therefore X is chosen. We don't have that data. We don't agree which web developers are the ones whose opinions matter - those who type a name once a month and want something self-explanatory, or those who type it once every 3 minutes, or those who write tools to avoid typing it at all, or ... And then we don't have representative samples. We know, for example, that focus/blur made sense to english-speaking developers but confused millions of developers whose first language was something else. So claiming we are basing a decision on the data will probably give results as arbitrary as the process we used, but with a veneer of intellectual dishonesty. Seriously, I don't see why a rationale like this is better than the one for querySelector as this is pretty much just s/WG/editor/ of that since the WG vote didn't represent the public Sure. In other words, while I can agree that a single +1/-1 statement isn't strong as a rationale (or even not a rationale) I beg you to take the sum as a valid and strong rationale, at least in this case where X and Y don't have much difference. And I am still interested in what really happened last time. (It is instructive to think for five minutes about the things that can go wrong, and how much effort we should spend on trying to get it right) Essentially, a bunch of people tossed up all the reasons to object to a name that they could think of based on their experience of things that go wrong. Based on that, some proposals were rapidly rejected, and then we looked at the rest, kicking the tyres of each in turn until we figured out which one the most people didn't think was truly problematic. It can be dismissed as design by committee, but it can also be characterised as applying the wisdom of several smart people to avoid as many pitfalls as possible. Frankly I think that suggesting one is smarter than any committee of smart people could be is a bold claim - if nobody is especially happy with the outcome, it can often be said that a number of very clever hardworking people recognise that it doesn't have any of several obvious problems they can name, and they think it is an acceptable outcome. cheers Chaals -- Charles 'chaals' McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg kan noen norsk http://my.opera.com/chaals Try Opera: http://www.opera.com
Re: Bikesheds Re: [selectors-api] Consider backporting find() behavior to querySelector()
(12/06/21 23:28), Charles McCathieNevile wrote: On Thu, 21 Jun 2012 15:56:45 +0200, Kang-Hao (Kenny) Lu kennyl...@csail.mit.edu wrote: (12/06/20 22:26), Lachlan Hunt wrote: The least-objectionable alternative is rarely the best alternative, and trying to please everyone is a fool's errand. While I agree that trying to please everyone is foolish, I am curious about data that can be used to prove the the least-objectionable alternative is rarely the best alternative statement. I don't think there is any readily available. There are no clear criteria for judging best, although there are some clear criteria for judging bad - for example things that often get confused are definitely bad. Well, yes, though I wonder why we can't define best to be what gets the most public votes (just in this case, please don't generalize this to cases when X and Y are having different implementation difficulty). Hopefully, this time, the group will let me, as editor, evaluate the options and supporting rationale and make a decision based on that. I don't know what happened when the WG decided on the poor name querySeletor Pretty much what Lachy said. As chair, I was the one who decided there ws too much objection and called for some other process. I don't claim it was especially good or came up with a great name, but I don't think it was awful and I don't see a better alternative if the situation arises again. Thanks for the information (and to Lachy too). I also found the vote[1] itself quite interesting. [1] http://www.w3.org/2002/09/wbs/38482/selectorsNames/results Despite the fact the editor thinks function name X is better than 'querySelector', there were a few people (name goes here) who were strongly opposed to X and a group vote happened and a decision was made by (name goes here). Nobody ran a compatibility research. And this time, I would like to ask whoever is going to make the decision to take the opinion of the *public* into account. I am not saying it should be the sole factor, but what I am looking for is an explanation like Compatibility research shows that both name X and Y are fine. 70% of the Web developers are in favor of name X and therefore X is chosen. We don't have that data. We don't agree which web developers are the ones whose opinions matter - those who type a name once a month and want something self-explanatory, or those who type it once every 3 minutes, or those who write tools to avoid typing it at all, or ... And then we don't have representative samples. We know, for example, that focus/blur made sense to english-speaking developers but confused millions of developers whose first language was something else. So claiming we are basing a decision on the data will probably give results as arbitrary as the process we used, but with a veneer of intellectual dishonesty. I claim that numeric data is as honest as we ever can be. Taking a look at Lachy's summary, I have to say while I appreciate the effort spent on this, there are really just contradictory sentences that made me frown, and Lachy later admitted[2]: [[ In hindsight, looking at the arguments above, I probably did let my own personal dislike of the name get in the way of my objectivity in this case, as much as I tried to avoid doing so. As such, I am now willing to consider these alternatives. ]] . Debating these rationale seems to be a waste of time too. I don't see why doing a public poll can be considered dishonest. The honest description would just be We ran a public poll on (pointer goes here) with X people, Y % of them are Web developers (pointer to the statistics goes here). The result ... [2] http://lists.w3.org/Archives/Public/public-webapi/2007Jun/0120 (It is instructive to think for five minutes about the things that can go wrong, and how much effort we should spend on trying to get it right) Essentially, a bunch of people tossed up all the reasons to object to a name that they could think of based on their experience of things that go wrong. Based on that, some proposals were rapidly rejected, and then we looked at the rest, kicking the tyres of each in turn until we figured out which one the most people didn't think was truly problematic. It can be dismissed as design by committee, but it can also be characterised as applying the wisdom of several smart people to avoid as many pitfalls as possible. Frankly I think that suggesting one is smarter than any committee of smart people could be is a bold claim - if nobody is especially happy with the outcome, it can often be said that a number of very clever hardworking people recognise that it doesn't have any of several obvious problems they can name, and they think it is an acceptable outcome. I never like the design by committee term because it seems to suggest a solution (the benevolent dictator) without explaining what's going on. In the querySelector case, although I admit that I think what
Re: [selectors-api] Consider backporting find() behavior to querySelector()
On Wed, 20 Jun 2012 06:19:22 +0200, Elliott Sprehn espr...@gmail.com wrote: On Tue, Jun 19, 2012 at 1:38 PM, Tab Atkins Jr. jackalm...@gmail.comwrote: ... This is not a good argument. qSA is used often enough, and has a long enough name, that the name is actually a pretty significant misfeature. This is a pretty core API, and both it and its precursors (getElementByID, etc.) are very commonly renamed by libraries precisely because you need a very short name for such a commonly used function. Why does it need a short name? If the name is too long to type then that's an argument for better IDEs. Otherwise you end up with stuff like strncpy to save typing. gzip eliminates the file size issue. I'm in agreement with Marat that find() is not as clear as most DOM APIs usually are. findBySelector() makes much more sense. In other words we have the same arguments that we had five years ago, when we settled on querySelector as the one that provoked least objection. getElementsB(y)Selector is consistent with the platform, subject to getting the s wrong, awfully long. find is too short for a general platform that has lots of ways of finding things and things you might be finding. querySelector is just sucky. But spending another few months arguing about it hasn't proven that we are any wiser, nor (importantly) any closer to agreement. If you want quick typing, alias it. If you want to know what it does because you only use it once a month (or in my case about once every six months), the name is barely clear enough. There are no good answers here, since there are significant and competing needs. cheers Chaals -- Charles 'chaals' McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg kan noen norsk http://my.opera.com/chaals Try Opera: http://www.opera.com
Re: [selectors-api] Consider backporting find() behavior to querySelector()
On 2012-06-20 10:42, Charles McCathieNevile wrote: In other words we have the same arguments that we had five years ago, when we settled on querySelector as the one that provoked least objection. ... But spending another few months arguing about it hasn't proven that we are any wiser, nor (importantly) any closer to agreement. This is why it should be an editorial decision, not a group vote. The least-objectionable alternative is rarely the best alternative, and trying to please everyone is a fool's errand. Hopefully, this time, the group will let me, as editor, evaluate the options and supporting rationale and make a decision based on that. Right now, that draft uses find/findAll() simply because they're the names that were used throughout the discussion that led to them being added. There are still issues to resolve, however, which I would like feedback on. In particular, is there really value in adding two distinct methods that differ only by whether they return 1 element or a collection? Resolving this issue first would help with resolving the naming issue. It should be noted that JQuery/sizzle does not use querySelector() at all, AFAICS. It only uses querySelectorAll() and sometimes switches to .getElementById() or document.body. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: [selectors-api] Consider backporting find() behavior to querySelector()
20.06.2012, 18:26, Lachlan Hunt lachlan.h...@lachy.id.au:
In particular, is there really value in adding two distinct methods that
differ only by whether they return 1 element or a collection? Resolving
this issue first would help with resolving the naming issue.
It should be noted that JQuery/sizzle does not use querySelector() at
all, AFAICS. It only uses querySelectorAll() and sometimes switches to
.getElementById() or document.body.
The whole jQuery's paragigm of always searching all matching elements is a
potentially big shortcoming of jQuery as for (at least) performance. It's
natural to suppose that searching for just _first_ matching element and
returning immediately once it's found should be much _faster_ than searching
for _all_ matching elements (be it 100 or 1000 elements) even if we need just
first one.
So yes, we need two separate methods: one to select first matching element and
another one to select all matching elements. They could be united into one
single method with an optional argument, but I doubt it would be quite handy
and nonconfusing for using. Also, a method generally should return consistent
result as for type of returning value, so if we had one method that always
returns collection of elements, that would force us to often use the method
with item accessor (like find('A')[0]) that would be redundant, unusable and
less readable.
For example, I very like `querySelector()` and use it at least as much as (and
maybe even more often than) `querySelectorAll()`.
Re: [selectors-api] Consider backporting find() behavior to querySelector()
It should be noted that JQuery/sizzle does not use querySelector() at all, AFAICS. It only uses querySelectorAll() and sometimes switches to .getElementById() or document.body. I took a look at using querySelector as an optimization a while back but it did not seem to make a significant difference in speed, at least once the library overheads were included. This test html is based on the msn.comhome page to be representative of a big real-life document. http://jsperf.com/findone-vs-findall The reason we switch to getElementById is because querySelectorAll is much slower for that case. qSA can retrieve multiple elements in invalid documents with duplicate IDs, but that's not a case we are worried about.
Re: [selectors-api] Consider backporting find() behavior to querySelector()
20.06.2012, 18:14, Lachlan Hunt lachlan.h...@lachy.id.au:
4. Support for returning elements that are not descendants of the
context object.
This feature allows a selector to be constructed such that it matches an
element anywhere in the tree relative to the context element. This
feature is not relevant to document.find(), since it can already return
anything from the whole tree.
elm.find(+span) // span is a sibling
elm.find(/for/ input) // input could be anywhere
elm.find(:not(:scope)) // Everything except the context object
This feature cannot be supported on Element.qSA, even when using eplicit
:scope, because matching elements need to be descendants of the context
object.
It's unclear why an _updated_ qSA version should have same limitation that
matching elements need to be descendants of the context object. There is
nothing obvious that makes h1.querySelector('+ H2') impossible to work in newer
implementations (in older ones it would not work anyway -- to the same extent
as `elm.querySelector(span)` that you've declared as could work).
Re: [selectors-api] Consider backporting find() behavior to querySelector()
On 6/20/12 10:52 AM, Dave Methvin wrote: This test html is based on the msn.com http://msn.com home page to be representative of a big real-life document. For what it's worth, that document has about 2200 DOM nodes. That's two orders of magnitude smaller than big real-life documents. This is a medium-small real-life document. Just for scale, the google.com homepage has about 500 DOM nodes. The W3C homepage has about 1400 DOM nodes. A Zimbra UI with about 200 messages in the inbox is about 5000 nodes. Anything that does dynamic UI stuff will tend to be in the 5k-50k node range. Of course the library overhead might still kill you enough that it doesn't matter... -Boris
Re: [selectors-api] Consider backporting find() behavior to querySelector()
On 6/20/12 11:34 AM, Marat Tanalin | tanalin.com wrote: It's natural to suppose that searching for just _first_ matching element and returning immediately once it's found should be much _faster_ than searching for _all_ matching elements (be it 100 or 1000 elements) even if we need just first one. It's natural to suppose that, but it would be wrong if the majority of the time is spent setting up the search (e.g. preprocessing the selector, which jQuery does), not actually searching For example, I very like `querySelector()` and use it at least as much as (and maybe even more often than) `querySelectorAll()`. If you're calling these directly, there's a lot less preprocessing going on. -Boris
Re: [selectors-api] Consider backporting find() behavior to querySelector()
On Mon, 18 Jun 2012 16:57:17 +0200, Kang-Hao (Kenny) Lu kennyl...@csail.mit.edu wrote: (12/06/18 22:45), Simon Pieters wrote: I think we should instead either fix the old API (if it turns out to not Break the Web) or live with past mistake (if it turns out it does). To find out whether it Breaks the Web (and the breakage can't be evanged), I suggest we ship the backwards-incompatible change to querySelector() in nightly/aurora (or equivalent) in one or more browsers for some time. I didn't read through all the QSA threads, but isn't the function name itself a mistake that many people don't want to live with? We have lots of shipped APIs with worse names. I think we should live with past mistakes, try not to make them again, and move on. -- Simon Pieters Opera Software
Re: [selectors-api] Consider backporting find() behavior to querySelector()
I am very opposed to this, they do different things. Having abilities isn't a bad thing and numerous Web sites and libraries make use of qsa, not just because find was not available but because different APIs shapes interesting new possibilities, different ways of looking at problems, etc... We solve problems with the tools at hand, so given that it has been widely implemented a long time, you can safely assume we have found good uses for it. There are a vast number of libraries and websites that have use cases for find, this is especially true because selector engines that solved those cases evolved in the wild a long time ago it probably would have been nice to have had that native first, as it would have been a more immediate help for the vast number of users, but qsa is definitely useful. On Jun 18, 2012 10:45 AM, Simon Pieters sim...@opera.com wrote: So http://dev.w3.org/2006/webapi/**selectors-api2/http://dev.w3.org/2006/webapi/selectors-api2/introduces the methods find() and findAll() in addition to querySelector() and querySelectorAll() and changes the scoping behavior for the former methods to match what people expect them to do. I'm not convinced that doubling the API surface is a good idea. If we were to do that every time we find that a shipped API has suboptimal behavior, the API surface on the Web would grow exponentially and we wouldn't make the overall situation any better. What if we find a new problem with find() after it has shipped? Do we introduce yet another method? I think we should instead either fix the old API (if it turns out to not Break the Web) or live with past mistake (if it turns out it does). To find out whether it Breaks the Web (and the breakage can't be evanged), I suggest we ship the backwards-incompatible change to querySelector() in nightly/aurora (or equivalent) in one or more browsers for some time. -- Simon Pieters Opera Software
Re: [selectors-api] Consider backporting find() behavior to querySelector()
On Mon, Jun 18, 2012 at 10:59 PM, Simon Pieters sim...@opera.com wrote: On Mon, 18 Jun 2012 16:57:17 +0200, Kang-Hao (Kenny) Lu kennyl...@csail.mit.edu wrote: (12/06/18 22:45), Simon Pieters wrote: I think we should instead either fix the old API (if it turns out to not Break the Web) or live with past mistake (if it turns out it does). To find out whether it Breaks the Web (and the breakage can't be evanged), I suggest we ship the backwards-incompatible change to querySelector() in nightly/aurora (or equivalent) in one or more browsers for some time. I didn't read through all the QSA threads, but isn't the function name itself a mistake that many people don't want to live with? We have lots of shipped APIs with worse names. I think we should live with past mistakes, try not to make them again, and move on. This is not a good argument. qSA is used often enough, and has a long enough name, that the name is actually a pretty significant misfeature. This is a pretty core API, and both it and its precursors (getElementByID, etc.) are very commonly renamed by libraries precisely because you need a very short name for such a commonly used function. ~TJ
Re: [selectors-api] Consider backporting find() behavior to querySelector()
20.06.2012, 00:38, Tab Atkins Jr. jackalm...@gmail.com: On Mon, Jun 18, 2012 at 10:59 PM, Simon Pieters sim...@opera.com wrote: On Mon, 18 Jun 2012 16:57:17 +0200, Kang-Hao (Kenny) Lu kennyl...@csail.mit.edu wrote: We have lots of shipped APIs with worse names. I think we should live with past mistakes, try not to make them again, and move on. This is not a good argument. qSA is used often enough, and has a long enough name, that the name is actually a pretty significant misfeature. This is a pretty core API, and both it and its precursors (getElementByID, etc.) are very commonly renamed by libraries precisely because you need a very short name for such a commonly used function. There is a key difference between native functionality and one implemented as a library -- they quite differently relate to backward compatibility. A library can be rewritten partially or even entirely if needed (older applications can just continue using older versions of the library), while native functionality, once widely implemented, have to be supported forever and in fact cannot (and should never) be dropped. As for `querySelector()` in particular, its name is indeed not the best, but _not_ because it's too long, but because it's not quite _clear_ / _self-documenting_. `querySelector()` and `querySelectorAll()` should have been named `getElementBySelector()` and `getElementsBySelector()` instead. In this regard, `find()` is far less clear (and even confusing) as for what it does.
Re: [selectors-api] Consider backporting find() behavior to querySelector()
On Tue, Jun 19, 2012 at 1:38 PM, Tab Atkins Jr. jackalm...@gmail.comwrote: ... This is not a good argument. qSA is used often enough, and has a long enough name, that the name is actually a pretty significant misfeature. This is a pretty core API, and both it and its precursors (getElementByID, etc.) are very commonly renamed by libraries precisely because you need a very short name for such a commonly used function. Why does it need a short name? If the name is too long to type then that's an argument for better IDEs. Otherwise you end up with stuff like strncpy to save typing. gzip eliminates the file size issue. I'm in agreement with Marat that find() is not as clear as most DOM APIs usually are. findBySelector() makes much more sense. - Elliott - E
Re: [selectors-api] Consider backporting find() behavior to querySelector()
(12/06/18 22:45), Simon Pieters wrote: I think we should instead either fix the old API (if it turns out to not Break the Web) or live with past mistake (if it turns out it does). To find out whether it Breaks the Web (and the breakage can't be evanged), I suggest we ship the backwards-incompatible change to querySelector() in nightly/aurora (or equivalent) in one or more browsers for some time. I didn't read through all the QSA threads, but isn't the function name itself a mistake that many people don't want to live with? I'd rather like to see querySelector() marked as deprecated so it doesn't appear in tutorials in the future. Cheers, Kenny
RE: [selectors-api] Consider backporting find() behavior to querySelector()
-Original Message- From: Kang-Hao (Kenny) Lu [mailto:kennyl...@csail.mit.edu] (12/06/18 22:45), Simon Pieters wrote: I think we should instead either fix the old API (if it turns out to not Break the Web) or live with past mistake (if it turns out it does). To find out whether it Breaks the Web (and the breakage can't be evanged), I suggest we ship the backwards-incompatible change to querySelector() in nightly/aurora (or equivalent) in one or more browsers for some time. I didn't read through all the QSA threads, but isn't the function name itself a mistake that many people don't want to live with? I'd rather like to see querySelector() marked as deprecated so it doesn't appear in tutorials in the future. Despite being non-optimal according to a vocal sub-set of people, querySelector[All] has been deployed in browsers for around 3-4 years. I strongly oppose any notion of altering its behavior now. As to find/findAll, let's just make sure we get the behavior right the second time so we don't go through this again.
