Bug Tracker

Opened 9 years ago

Closed 9 years ago

Last modified 9 years ago

#7570 closed bug (invalid)

nth-last-child not working in IE6,7

Reported by: anonymous Owned by:
Priority: undecided Milestone:
Component: selector Version: 1.4.4
Keywords: Cc:
Blocked by: Blocking:

Description

get: unrecognized expression:nth-last-child

Change History (7)

comment:1 Changed 9 years ago by anonymous

oh its a plugin... a bit confusing though that what you write in ff/safari/chrome return a result but not when you switch to ie... so it means that i need to use "jquery" only selectors?

comment:2 Changed 9 years ago by jitter

Resolution: invalid
Status: newclosed

Thanks for taking the time to contribute to the jQuery project by writing a bug ticket

:nth-last-child(...) isn't supported by jQuery.

As you experienced yourself it may work in those browsers that support querySelectorAll - as jQuery uses that native function when possible - and where the function also understands this CSS3 pseudo-class selector. For the browsers not natively supporting this you of course get no results.

so it means that i need to use "jquery" only selectors?

Yes. jQuery can only provide reliable cross-browser support for the selectors specified in the jQuery selectors API.

comment:3 Changed 9 years ago by anonymous

I still think this is a bug.

The library used to bring support for css selectors that at the time did not exist and therefore offered a cross-browser meaning of querying the DOM. Obviously it would work everywhere as it was no a native system.

now that recent browsers implement querySelectorAll and that jquery uses it under the hood, all selectors available in the native browsers should be de facto available in browsers that do not have querySelectorAll support for css3. Otherwise, it means that jquery offers LESS than the browsers which seems rather counter intuitive to say the least. On top of that it means that now I have to be aware of what selectors I can use when using jquery in order to create cross-browser scripts. Isn't it going against one of the aim of the library?

comment:4 Changed 9 years ago by dmethvin

Component: unfiledselector
Milestone: 1.5

jQuery doesn't document it supports nth-last-child so it's not a bug. You are free to use querySelectorAll, feed that to $(), and drop IE6/7 support in your pages if you'd like. Be sure to avoid any jQuery extensions in your qSA selectors.

comment:5 in reply to:  4 Changed 9 years ago by anonymous

It's not a programming bug per say. a design flow perhaps when you come to think of modern browser capacities. I don't really see the benefit of using jquery only for modern browsers if it does not bring me the advantage of cross browser support for older browser (ie6,7 and 8). i know that jquery uses document.querySelectorAll when it does offer support for css3. so doing $(document.querySelectorAll('...')) does not make much sense in such browsers. i think that if $('tr:nth-last-child(-n+2)') work in every modern browser: chrome/safari/firefox and ie9, it should also work for ie6,7 and 8. this is the entire point of a library like this. when no browsers were offering querySelectorAll having only a subset of the css selectors handled made sense. after all, the library was the only way to get access to such syntax. now it is not true anymore and the library should take this into account instead of forcing users to drop a subset of what they can do. they should offer a way to give a cross browser support to modern functionality don't you think?

Be sure to avoid any jQuery extensions in your qSA selectors.

This is exactly what I do not want to have to think.

drop IE6/7 support in your pages if you'd like

you forget ie8. I am really disappointed to get such an advice.

Thank you for your time though even if such decision (not offering full support to css3 selectors) seems silly nowadays.

Replying to dmethvin:

jQuery doesn't document it supports nth-last-child so it's not a bug. You are free to use querySelectorAll, feed that to $(), and drop IE6/7 support in your pages if you'd like. Be sure to avoid any jQuery extensions in your qSA selectors.

comment:6 Changed 9 years ago by snover

Trying to support 100% of the CSS3 selectors spec will turn jQuery from a 30kB library into a 50kB library while adding no real value to the majority of developers. We have always only supported a subset of the official CSS3 spec, and that subset is documented.

Last edited 9 years ago by snover (previous) (diff)

comment:7 in reply to:  6 Changed 9 years ago by anonymous

Trying to support 100% of the CSS3 selectors spec will turn jQuery from a 30kB library into a 50kB library

the library started at 15kb gzip, now, it's 30kb,certainly as heavy as Prototype now. 20kb less or more is not that much if it allows real cross-browser selectors,especially when you could get rid of the entire javascript selector engine in a near future(well, I hope browsers we'll add some of your custom selectors though!)

while adding no real value to the majority of developers.

This is where I think you're wrong to decide for developers what they should be able to choose or not. I know that jQuery is used mostly by designers but I don't know why you say that it will not add any real value. So you're ahead of the w3 consortium and set up yourself as a mandatory of what can and can not be? This remembers me some old days of the browser war...

We have always only supported a subset of the official CSS3 spec, and >that subset is documented.

Sure. At that time it was absolutely logical! Again see my above comment regarding this point.

Anyhow, I got your vision! Thank your for your time!

Note: See TracTickets for help on using tickets.