How should we handle new styles

[JamesGeiger]

As the title says, how should we go about handling doing a makeover on the styles (to make them responsive/fluid and avoid the use of @import and perhaps Superfish + the menu scripts altogether in favor of a pure CSS menu system?). One solution would be to add a hidable message for a couple of releases that instructs a user to install a Legacy Thematic plugin that contains the old styles and Superfish + menu scripts. Of course this will break their site but they would just have to change the url of their @imports in their child theme's style.css. We could post a sticky in the forums instructing them on this or something.

Let me know what you think,

James

P.S. On an unrelated matter, does Thematic use the default WP body classes? e.g. http://codex.wordpress.org/Function_Reference/body_class

[middlesister]

I think Gene said something about just creating a new stylesheet altogether for the new styling and leave all the rest where they are for backwards compatibility. That means style.css would no longer be enqueued, but only the new stylesheet.

Regarding superfish, I don't know the best course there. The latest version of superfish contains updates to work on touchscreens, we could simply update it. But there are also other script solutions out there. I don't think css only is an alternative since there is no hover state on touch screens, but the markup can definitely be simplified.

And yes, thematic uses the default body_class() wordpress output.

[JamesGeiger]

@middlesister should we at least put a deprecated message in the old styles? Then we could change the name of the sample child theme folder to legacychildtheme and have a new childtheme folder with new styles inside it. Using @import is a bad idea so we should just bundle the new styles inside the child theme - perhaps without too many options like all the 18px.css stuff - just one clean stylesheet?

[middlesister]

Well yes I think the sample child theme style.css should not use any @import's at all. The sample child theme should show recommended/best practice so I think we can safely remove those references when the new stylesheet is in place.

[middlesister]

I am thinking about enqueueing both a parent stylesheet and the child stylesheet in the future. Then the child stylesheet could hold only customizations while keping the parent styles upgradable. The child stylesheet would list the parent as a dependency to ensure output in the right order.

It would result in two <link>tags and thus two http requests, but browser cache and/or caching plugins would mitigate that. And I think minifying plugins can concatenate enqueued scripts but not @import-ed ones so we would still be better off compared to today.

Child themes that prefer to do all the styles and have all the control can simply dequeue the parent style. @emhr what do you say?

[middlesister]

Regarding the superfish, I think they could only be enqueued when we are in backwards compatibillity mode and not added to the html5 version.

[middlesister]

Revisiting the superfish - I updated it in a pull request because I think it is useful still. Expecially for assistive technologies since it enables tabbing through the links in the navigation. Pure css is still not enough for critical navigation.

I have started pulling all the stylesheets into the main style.css in the develop branch.

[middlesister]

Oh, and it won't break a thing for old child themes since the old stylesheets are still in the same path that the @imports references.

[middlesister]

I have started tinkering with a redesign that might be ready to show soon. My current thoughts around styles goes like this:

function thematic_create_stylesheet() {
    $theme = wp_get_theme();
    $version = $theme->Version;
    $themeslug = get_stylesheet();

    $template = wp_get_theme( 'thematic' );

    wp_register_style( 'genericons', get_template_directory_uri() . '/library/css/genericons.css', array(), '' );
    wp_register_style( 'thematic-style1', get_template_directory_uri() . '/library/css/style1.css', array(), $template->Version );
    wp_register_style( 'thematic-style2', get_template_directory_uri() . '/library/css/style2.css', array( 'genericons' ), $template->Version );

    wp_enqueue_style( "{$themeslug}-style", get_stylesheet_uri(), array( 'thematic-style2' ), $version );
}

add_action( 'wp_enqueue_scripts', 'thematic_create_stylesheet' );

A child theme can then put any overriding style declarations in it's style.css since the parent theme stylesheet is added before the child's. If a child theme want to use another of the stylesheets as base, or not be based on the thematic styles at all, it can re-enqueue the child stylesheet with different parameters. With an empty dependency array no parent stylesheet will be enqueued at all, or if genericons is added as a dependency, only the icon font will be enqueued.

wp_enqueue_style( "{$themeslug}-style", get_stylesheet_uri(), array(), $version );

[JamesGeiger]

It looks great :)

[middlesister]

Committed in develop branch. Legacy mode gets no dependency, only the child style.css is enqueued. The @import's still work for the old themes, nothing breaks for them but also nothing is new. By default, new child themes depends on style1, which includes the responsive styles. A new filter is introduced to change dependency. By switching to style2, the child theme gets both style2 and genericons.

function childtheme_style_dependency( $dependencies ) {
    return array( 'thematic-style2' );
}
add_filter( 'thematic_childtheme_style_dependencies', 'childtheme_style_dependency' );

As of this moment, style1 and style2 is identical, but the stylesheet switching works. I am closing this issue since I think this problem is solved. The actual styling is another thing :)