Viewing 8 replies - 1 through 8 (of 8 total)
  • Looks like a moderator removed the code, so I don’t exactly know what this is referring to. Can you re-post? We don’t like causing backwards compatibility issues, even for CSS classes.

    Thread Starter John Turner

    (@johnnytee)

    Sure

    Here’s the two column post layout in version 3.3. This shows as 1 col in 3.4

    https://gist.github.com/2889074

    Thanks, I’ve asked some people to take a look at this.

    Thread Starter John Turner

    (@johnnytee)

    Ok , thank you

    The problem is that some css classes that are part of the metabox API were used directly, instead of using the API. If “Metabox 1” and “Metabox 2” were created by API calls, they would use the proper HTML and CSS.

    This also brings the question of what part of the core CSS could be used directly by plugins and what is “private”. That’s a big gray area for now as the process of updating, cleaning and standardizing the admin CSS continues.

    Generally if WP provides an API, it should always be used. A lot of efforts go into keeping the core APIs backwards compatible, not only for the back-end (PHP) but for the front-end too (HTML/CSS/JS).

    Thread Starter John Turner

    (@johnnytee)

    It would be nice to have a dedicated Developers UI classes that could be used for plugin development that keeps inline with the core WordPress styles and not tied to a specific WordPress php api.

    Yes, that’s the plan. Things like table.widefat, div.wrap, even div.postbox, etc. should form a list of core UI elements that are reusable by plugins (some sort of CSS API?). We are getting closer to this with each release, the problem is cleaning and updating the admin CSS is a huge (and slow) process.

    Thread Starter John Turner

    (@johnnytee)

    Completely Understood

Viewing 8 replies - 1 through 8 (of 8 total)
  • The topic ‘Backwards Two-Column Layout Support in 3.4’ is closed to new replies.