WordPress.org

Make WordPress Core

Opened 6 years ago

Closed 3 years ago

#12615 closed defect (bug) (wontfix)

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

Reported by: 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 6 years ago.
Add "first" and "last" css-class in frontend use. Backend works as expected.
garyc40.12615.diff (1.1 KB) - added by garyc40 6 years ago.
try to do less than hackre's patch, just in case

Download all attachments as: .zip

Change History (21)

#1 @nacin
6 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
6 years ago

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

#2 @hakre
6 years ago

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

#3 @hakre
6 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
6 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
6 years ago

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

#6 @hakre
6 years ago

Related: #14250

#7 @hakre
6 years ago

Related: #12615

#8 @garyc40
6 years ago

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

#9 follow-ups: @nacin
6 years ago

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

#10 in reply to: ↑ 9 @garyc40
6 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
6 years ago

Replying to nacin:

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

Please reference the ticket.

@garyc40
6 years ago

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

#12 follow-up: @garyc40
6 years ago

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

#13 in reply to: ↑ 12 ; follow-up: @hakre
6 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
6 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
6 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
6 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
6 years ago

  • Cc mikeschinkel@… added

#19 @obenland
3 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.