WordPress.org

Make WordPress Core

Opened 3 years ago

Closed 3 years ago

Last modified 3 years ago

#15426 closed defect (bug) (fixed)

invalid markup in comments table

Reported by: macbrink Owned by: scribu
Milestone: 3.1 Priority: normal
Severity: minor Version: 3.0.1
Component: Administration Keywords:
Focuses: Cc:

Description

ID "submitted-on" is used in all comment rows

Change History (16)

comment:1 scribu3 years ago

  • Owner set to scribu
  • Status changed from new to accepted

comment:2 scribu3 years ago

  • Milestone changed from Awaiting Review to 3.1

comment:3 scribu3 years ago

  • Resolution set to fixed
  • Status changed from accepted to closed

(In [16375]) Make submitted-on a class instead of an id. Fixes #15426

comment:4 JohnONolan3 years ago

  • Resolution fixed deleted
  • Status changed from closed to reopened

This fix has no consideration for backwards compatibility and will break any themes and plugins using that ID.

comment:5 scribu3 years ago

I think you're exagerating.

What do themes have to do with the comment id in the admin comments screen?

Also, can you point to a plugin specifically depending on 'submitted_on' being an id?

comment:6 scribu3 years ago

s/comment id/submitted-on

s/submitted_on/submitted-on

comment:7 JohnONolan3 years ago

I think you're missing the point.

I'm not going to to trawl through every plugin in the world looking for an instance of the ID, but if you feel the need to do that then go right ahead. If any theme or plugin has ever wanted to match the style of the comments ui then this is an issue.

We either support backwards compatibility or we don't - I've just spent two months refactoring CSS files and going to painstaking lengths not to delete or rename a single class or ID for backwards compatibility, even when some classes and ID's aren't even used in core any more!

comment:8 scribu3 years ago

Ah, so the problem is that this bug fix messes your CSS refactoring.

It's frustrating when patches get stale; I know.

comment:9 macbrink3 years ago

Having multiple elements with the same ID is just wrong. What if a plugin developer wants to use submited-on in javascript. Selecting these elements will fail because of invalid xhtml.
imo, fixing defects overrules backwards compatibility.

comment:10 scribu3 years ago

  • Resolution set to fixed
  • Status changed from reopened to closed

Indeed, bug fixes trump backwards compatibility.

See http://wpdevel.wordpress.com/2010/10/27/plugin-activation-hooks-no-longer-fire-for-updates/ for a recent example where we break back-compat to fix inconsistencies.

comment:11 JohnONolan3 years ago

@scribu - Nope it doesn't go anywhere near my work. I was just making the point that we should all be working to the same standards.

@macbrink - No one is arguing the fact that a class is better than an ID, the point of debate is over how the transition is made. Backwards compatibility needs to be considered.

Will raise this issue at this week's dev meeting as "lol my bug fix trumps your backwards compatibility" doesn't seem like a particularly considered approach to me.

comment:12 filosofo3 years ago

Unlike the templates and query APIs and such, historically there has been practically no attempt to maintain backwards-compatibility with the WP admin. Most significant changes to the admin have resulted in breaking markup with abandon.

In fact, there seems to be active resistance to the idea of being concerned about backwards-compatibility in the admin; when I proposed #11517 over a year ago, one of the objections from the core devs was that it would create more work because we would have to start being concerned about backwards-compatibility.

comment:13 follow-up: scribu3 years ago

Unlike the templates and query APIs and such, historically there has been practically no attempt to maintain backwards-compatibility with the WP admin.

Even if you were referring strictly to CSS back-compat, this would still not be true, at least not recently. I have tried to keep all the ids and all the classes while working on #14579

comment:14 in reply to: ↑ 13 filosofo3 years ago

Replying to scribu:

Even if you were referring strictly to CSS back-compat, this would still not be true, at least not recently. I have tried to keep all the ids and all the classes while working on #14579

When I say "historically," I'm referring to changes across released versions. Maybe the attempt will start with 3.1, but it will be a change to how things have usually been done.

comment:15 nacin3 years ago

(In [16386]) Restore rule for #submitted-on. props JohnONolan, see #15426.

comment:16 scribu3 years ago

So that's what CSS back-compat looks like.

Note: See TracTickets for help on using tickets.