Make WordPress Core

Opened 15 years ago

Closed 11 years ago

#12615 closed defect (bug) (wontfix)

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

Reported by: hakre's profile hakre Owned by:
Milestone: Priority: normal
Severity: normal Version:
Component: Themes Keywords:
Focuses: Cc:

Description

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.

Attachments (2)

12615.patch (3.1 KB) - added by hakre 15 years ago.
Add "first" and "last" css-class in frontend use. Backend works as expected.
garyc40.12615.diff (1.1 KB) - added by garyc40 14 years ago.
try to do less than hackre's patch, just in case

Download all attachments as: .zip

Change History (21)

#1 @nacin
15 years ago

  • Keywords needs-patch added; dev-feedback removed
  • Milestone changed from Unassigned to Future Release

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

@hakre
15 years ago

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

#2 @hakre
15 years ago

  • Keywords has-patch tested added; needs-patch removed

#3 @hakre
15 years ago

  • Summary changed from Widget CSS class enhancement to Add "first" and "last" CSS-class-names to each Widgets in sidebars (Frontend)

#4 @hakre
15 years ago

  • Summary changed from Add "first" and "last" CSS-class-names to each Widgets in sidebars (Frontend) to Add "first" and "last" CSS-class-names to each Widget in sidebars (Frontend)

#5 @hakre
15 years ago

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

#6 @hakre
14 years ago

Related: #14250

#7 @hakre
14 years ago

Related: #12615

#8 @garyc40
14 years ago

  • Owner set to garyc40
  • Status changed from new to assigned

#9 follow-ups: @nacin
14 years ago

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

#10 in reply to: ↑ 9 @garyc40
14 years ago

  • Owner garyc40 deleted

Replying to nacin:

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

That makes sense.

#11 in reply to: ↑ 9 @hakre
14 years ago

Replying to nacin:

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

Please reference the ticket.

@garyc40
14 years ago

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

#12 follow-up: @garyc40
14 years ago

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

#13 in reply to: ↑ 12 ; follow-up: @hakre
14 years ago

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.

#14 follow-up: @hakre
14 years ago

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.

#15 in reply to: ↑ 14 @nacin
14 years ago

  • Keywords close added; tested removed

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

#16 in reply to: ↑ 13 @garyc40
14 years ago

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.

#17 @mikeschinkel
14 years ago

  • Cc mikeschinkel@… added

#19 @obenland
11 years ago

  • Keywords has-patch close removed
  • Milestone Future Release deleted
  • Resolution set to wontfix
  • Status changed from assigned to closed

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

Note: See TracTickets for help on using tickets.