invalid markup in comments table

[macbrink]

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

[scribu]

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

[JohnONolan]

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

[scribu]

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?

[scribu]

s/comment id/submitted-on

s/submitted_on/submitted-on

[JohnONolan]

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!

[scribu]

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

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

[macbrink]

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.

[scribu]

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.

[JohnONolan]

@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.

[filosofo]

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.

[scribu]

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

[filosofo]

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.

[nacin]

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

[scribu]

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