Add "first" and "last" CSS-class-names to each Widget in sidebars (Frontend)

[hakre]

It would be nice if the first widget and the last widget in each sidebar would have a css-class that would make them identifyable as the first and the last widget.

Maybe something that is nice to have for 2010 as well. So I leave this open for others to decide on which version to put it.

[nacin]

This would mean filtering or adding to the classes that are sprintf'd into before_widget.

[hakre]

Add "first" and "last" css-class in frontend use. Backend works as expected.

[hakre]

It would be nice for any theme if the tag-cloud styles aren't hardcoded any longer as well: #5031

[hakre]

Related: #14250

[hakre]

Related: #12615

[nacin]

Thinking wontfix. We're not doing this in menus either.

[garyc40]

Replying to nacin:

Thinking wontfix. We're not doing this in menus either.

That makes sense.

[hakre]

Replying to nacin:

Thinking wontfix. We're not doing this in menus either.

Please reference the ticket.

[garyc40]

try to do less than hackre's patch, just in case

[garyc40]

I'm attaching a patch anyways. Hackre's patch tries to do too much.

[hakre]

Replying to garyc40:

I'm attaching a patch anyways. Hackre's patch tries to do too much.

Don't forget to test the widget screen in the backend.

And try to exploit the last one, imagine the last widget is not registered.

I didn't wrote that I implemented the best strategy to find it, but from what I remember writing the patch months ago, it was not that trivial to solve.

[hakre]

Replying to garyc40:

Replying to nacin:

Thinking wontfix. We're not doing this in menus either.

That makes sense.

Highly subjective such a comment. Anyway, other CMSes have this since ages for everything added dynamically and from the standpoint of a CSS author sticking to stable (HTML 4.1 CSS 2.1 as safe base) this is just helpful, be it Menu, Content, Widgets, Gallery Images or just the tagcloud. CSS is cool. Well chosen class names help.

So I would have loved to see that in core. But I can understand as it was too complicated to do so for menus (wasn't it?) to not do it where it is actually possible.

[nacin]

Replying to hakre:

Highly subjective such a comment.

Of course it's subjective. It's my opinion.

Anyway, other CMSes have this since ages for everything

Yes. And they no longer need to, so why should we add it?

Please reference the ticket.

#15529

[garyc40]

Replying to hakre:

Don't forget to test the widget screen in the backend.

Tested my patch, switching stuff in and out, re-ordering items etc. It works.

And try to exploit the last one, imagine the last widget is not registered.

Hmm, not sure what you meant by that. All the items that are iterated in that function are registered to the dynamic sidebar being output, correct?

Anyways, this is what I thought when I wrote "That makes sense". I haven't heard anyone saying that they need to use these "first" and "last" classes. I myself couldn't think of a specific scenario when we need this. We're moving away from supporting IE6, and :first-child works just fine in IE7, 8 and 9.

Perhaps a filter? In #15529, there's already a filter for menu items' classes.

[hakre]

​A plugable workaround is available in the forums.

[obenland]

Support for :first-of-type/:first-child and :last-of-type/:last-child selectors ​is pretty solid across browsers nowadays.