Admin CSS back-compat possibilities

I continue to think about CSS back-compat, especially as we dive deep into the land of MP6. Given that we are talking about build processes as well, I had an idea. There are two steps to this idea: a section (or separate file, if/when we get into building concatenated/compressed CSS for core) for CSS that is being kept for backwards compatibility. Things would generally stay for a cycle or so, but subject to evaluation in some cases for history and wide usage, such as settings tables. After that cycle, rules would move to a deprecated.css that is registered but not enqueued – if a theme or plugin needs it, they should enqueue it on applicable screens.

This is all just an idea – I don’t know if there would be hard lines about how long CSS stays in back-compat or deprecated areas, or if this would even work at all. I have no idea if we could or should throw notices somewhere (console?) like PHP can, and now jQuery with jQuery Migrate. Thoughts?

Admin CSS back-compat possibilities

2 thoughts on “Admin CSS back-compat possibilities

  1. The problem with the current styles is: the selectors are overly specific. I haven’t looked into MP6 yet.

    If we had less specific selectors, there wouldn’t be much to deprecate, because everything could be reused. I think it would be better to clean up the selectors first, add more classes to the markup, and then count what is really not needed anymore.

    Like

    1. I think that’s sort of a faulty relation, for two reasons.

      One, I don’t think we should wait for one thing to be perfect before starting on another, because we’ll get stuck forever. And even if we make the new CSS less specific, people might be relying on the old (that is, current) specific selectors. I agree that our CSS is a mess, which is no secret, but it’s not an inherent barrier to introducing the concept of deprecated CSS.

      Two, being less specific doesn’t change the fact that the settings stuff currently uses tables for layout. That’s what I was looking into this week that got me thinking about how we can handle HTML refactoring while recognizing that people are using what currently exists because, well, it exists. See: http://core.trac.wordpress.org/ticket/16413#comment:45

      Like

Leave a comment