I use :last-child
selector plenty of times, mostly when using border-bottom
in a list where I use border: none;
for the last child, or whe
I believe it's still the simplest, low-performance way to get your last child. by that I mean, all others way to get the last child will be worse for performance, because it won't have any work done by the W3C community before.
If it was deferred from CSS2 for performance concerns, but reintroduced in Selectors 3, I suspect that it's because performance is no longer an issue as it previously was.
Remember that :last-child
is the definitive and only way to select the last child of a parent (besides :nth-last-child(1)
, obviously). If browser implementers no longer have performance concerns, neither should we as authors.
The only compelling reason I can think of for overriding a border style with :first-child
as opposed to :last-child
is to allow compatibility with IE7 and IE8. If that boosts performance, let that be a side effect. If you don't need IE7 and IE8 support, then you shouldn't feel compelled to use :first-child
over :last-child
. Even if browser performance is absolutely critical, you should be addressing it the proper way by testing and benchmarking, not by premature optimization.
In general, the core CSS selectors perform well enough that most of us should not be worried about using them. Yes, some of them do perform worse than others, but even the worst performing ones are unlikely to be the main bottleneck in your site.
Unless you've already optimised everything else to perfection, I would advise not worrying about this. Use a profiling tool like YSlow to find the real performance issues on your site and fix those.
In any case, even if there is a noticable performance implication for a given CSS selector (or any other browser feature), I would say that it's the browser makers' responsibility to fix it, not yours to work around it.