WordPress.org

Make WordPress Core

Opened 4 years ago

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

Download all attachments as: .zip

Change History (21)

comment:1 nacin4 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.

hakre4 years ago

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

comment:2 hakre4 years ago

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

comment:3 hakre4 years ago

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

comment:4 hakre4 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)

comment:5 hakre4 years ago

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

comment:6 hakre4 years ago

Related: #14250

comment:7 hakre4 years ago

Related: #12615

comment:8 garyc403 years ago

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

comment:9 follow-ups: nacin3 years ago

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

comment:10 in reply to: ↑ 9 garyc403 years ago

  • Owner garyc40 deleted

Replying to nacin:

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

That makes sense.

comment:11 in reply to: ↑ 9 hakre3 years ago

Replying to nacin:

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

Please reference the ticket.

garyc403 years ago

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

comment:12 follow-up: garyc403 years ago

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

comment:13 in reply to: ↑ 12 ; follow-up: hakre3 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.

comment:14 follow-up: hakre3 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.

comment:15 in reply to: ↑ 14 nacin3 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

comment:16 in reply to: ↑ 13 garyc403 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.

comment:17 mikeschinkel3 years ago

  • Cc mikeschinkel@… added

comment:19 obenland9 months 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.