Create new stylesheet for the new markup

[middlesister]

Depends on #50

I like the strucure and TOC of twentythirteen

/**
 * Table of Contents:
 *
 * 1.0 - Reset
 * 2.0 - Repeatable Patterns
 * 3.0 - Basic Structure
 * 4.0 - Header
 *   4.1 - Site Header
 *   4.2 - Navigation
 * 5.0 - Content
 *   5.1 - Entry Header
 *   5.2 - Entry Meta
 *   5.3 - Entry Content
 *   5.4 - Galleries
 *   5.5 - Post Formats
 *   5.6 - Attachments
 *   5.7 - Post/Paging Navigation
 *   5.8 - Author Bio
 *   5.9 - Archives
 *   5.10 - Search Results/No posts
 *   5.11 - 404
 *   5.12 - Comments
 *   5.13 - Multisite
 * 6.0 - Sidebar
 *   6.1 - Widgets
 * 7.0 - Footer
 * 8.0 - Media Queries
 * 9.0 - Print
 */

I'd like to add a plugin-integration section for plugin styles like wp-pagenavi etc as well

[scottnix]

This structure looks totally fine.

The only beefs I would have with it are totally my coding/workflow preferences.

There are quite a few things that would be nice to see, it would nice to use Sass. Anyone who doesn't just goes about using the CSS as normal, the only issue with that is file clutter (for people who don't use it) and those few edge cases where someone edits the CSS, then way later on decides to use Sass and compiles the default Sass file over their CSS changes which would be a major bummer.

As far as the reset goes, personally I use normalize.css... but recently I have seen posts/comments mentioning how people don't use it correctly, it really isn't intended to be a separate chunk of CSS and is instead suppose to be worked into the 2.0 Repeatable Patterns, I just recently stopped doing this, but it is tougher because it bloats the code (you don't really have to pay attention to the reset if it is separate) and you have to know/pay attention to the bits you need and don't need if you work it in.

For layouts, I now prefer grid systems, but everyone has their own (or nothing at all), so that won't be an issue as long as the layout is kept in the 3.0 basic structure section, so that can just be tossed out easily.

Also the 8.0 media query section, I no longer like chunks of media queries in the bottom. With Sass I started inserting the media queries with the classes they pertain to http://scottnix.com/placement-of-media-queries/ This is something I totally at first thought was dumb, I couldn't see how it was better but after switching, it massively increased my workflow and the organization is better.

TL;DR The structure looks totally fine as long as the layout is in the basic structure, and no matter how the CSS turns out, I would just churn out my own version to the workflow I currently use. :)

[middlesister]

Haha I am totally with you there. I am using sass and susy grids myself and it feels like going back in time to do 'ordinary' css.

I was thinking of introducing sass here too, the partials feature alone is such a great help in organizing the code. But in the end I think people who are technichally savvy do what you do and roll their own, and for beginners plain 'normal' css is easier to understand. Or maybe it can be something for a future version.

The media queries can definitely be part of the layout section instead of a section of their own. I find I have trouble envisioning what to do here because I think responsiveness should be custom to the design and it's hard to do something generic. I am also not a fan of using only apple hardware breakpoints ('iphone', and 'ipad'), but they are the easy ones and I feel like picking the low hanging fruit in order to get this thing going.

Would you be interested in helping out with the css?

[middlesister]

New stylesheet is here, all in one long file. :) I am unsure about how much re-styling to do, this is basically a port of all the old styles into one place. I have created a feature branch locally where I test some styling ideas. But I want to keep it as clean and nondescript as possible, rather encouraging people to do their own. But sensible defaults are a good thing.

[middlesister]

I'll leave this open until the styles are finshed

[JamesGeiger]

@middlesister I am looking at the new stylesheet now

[middlesister]

Great. My idea with style1 is to mimic the old styles in appearance but update the css code to be more efficient. And any bigger redesign would go into style2, including using the genericons icon font. At the moment style1 needs to be finished before getting to style2.

At the moment I am really itching to introduce sass for css partials so as to avoid having to maintain duplicate styles for common thing between the stylesheets. Layout and resets for example. Sass would be compiled using grunt, which also can concatenate and minify scripts and styles. But that would mean a learning curve for everyone involved and maybe raise the barrier for contributions. But it sure would simplify development...

[JamesGeiger]

Using SASS and Grunt would be a bad idea. I use SASS almost every day, but for the average user it would be a nightmare. Thematic is supposed to make lives easier and I don't think using SASS or grunt would help the average user. I'm not even sure most of them know about best practices for responsive design, so it would be a good idea to just have basic css that is well done. People like us will just roll out our own styles anyway, so I think we should stick to the basics.

As for the two stylesheets, maybe it would be better for now if we just had one really good stylesheet that was up to date standards wise, but retained the old styles. I think we should save a redesign for later. I love including genericons out of the box though. That was a good move :)

[JamesGeiger]

Also, @middlesister, can I go ahead and alter style1? I will do that tonight after I am done working.

[middlesister]

Sure, just make a pull request with your changes. Only make sure to do your changes in a separate branch, it will be easier to keep the develop branch in sync then.

9 jan 2014 kl. 16:49 skrev James notifications@github.com:

Also, @middlesister, can I go ahead and alter style1? I will do that tonight after I am done working.

— Reply to this email directly or view it on GitHub.

[middlesister]

Some notes from @scottnix :

• [ ] 1 Create placeholder screenshot image in the child theme folder
• [x] 2 Remove display:inline-block from .menu-toggle
• [x] 3 Set they menu list item links to display:block
• [x] 4 consider moving padding for sub-items from the ul to the li
• [ ] 5 remove italics from h3 and uppercase from h4 Keeping them for clearer type herarchy
• [x] 6 add cursor:help to abbr[title]
• [x] 7 q element is missing style
• [x] 8 align content and sidebar on small screen

[scottnix]

I am just going to throw this out there. Icon fonts are awesome and super useful, but including a file like genericons probably will do more harm than good.

Ideally everyone should be using an icon building system like http://icomoon.io/ where you select the specific icon fonts you want and load only those. Using their build system, you can save out a file that maps the icons so you can easily add and remove icons and regenerate the 7 icons you want to use instead of loading all 100+.

It may just be adding bloat for people who don't use it much, or at all. It is probably a better idea to just make a tutorial on how to easily add icon fonts to Thematic.

[middlesister]

Yes you have a point there. I used fontello on a recent client project to custom pick what I needed from font awesome. I had no need for 100+ icons.

I'm also rethinking the enqueueing thing. Perhaps it would just be easier to instruct people to enqueue the parent stylesheet in their child theme. It's slightly less plug-n-play but becomes a more concious choice from the user.

While waiting for Gene to catch up, I am itching to begin working on a sass version. The project I worked on provided sass files in the original theme and to make customizations was so easy. Just copy over the sass folder to my child theme, change a few variables, run compass watch and boom - there was my new stylesheet. To really make Thematic useful in a framework sense, I think having sass files helps a lot.

[scottnix]

What is the correct way to drop all default styling and just use the child themes CSS?

I ask because if you wp_deregister_style('thematic-style1'); it also kills the link to the stylesheet for the child theme since it is listed as a dependency. So you need to requeue a new stylesheet for the child theme.

But if I don't use the wp_deregister and just use

function childtheme_script_manager() {
    $themeslug = get_stylesheet();

    wp_enqueue_style("{$themeslug}", get_stylesheet_uri());
}
add_action('wp_enqueue_scripts', 'childtheme_script_manager');

This also works, but I am not 100% sure why ;x

[middlesister]

The reason that re-enqueuing works is that it replaces the other call and therefore overrides the dependency array.

The easiest way to remove the parent style as it currently stands is to use the child dependency filter and simply return an empty array.

function remove_parent_styling( $dependencies ) {
    return array();
}
add_filter( 'thematic_childtheme_style_dependencies', 'remove_parent_styling' );

This is what I am thinking of doing. Let the dependency array be empty by default and keep the parent style registered. Then child theme's that want to use the default styling would simply add the parent as a dependency using that filter. A normal wp_enqueue_style() will also work of course.

[scottnix]

Thanks, it wasn't immediately evident (to me) to just drop the dependency through a filter and it would just work. Have gotten too use to the standard unregister/dequeue and went down that thought process instead. Now it makes sense. :)

[middlesister]

So that is now changed. No parent stylesheet will be enqueued by default. Part of the transition for child themes will be to add (enqueue) the parent stylesheet if desired, either by the dependency filter or by normal wp_enqueue_style()

That essentially means no change from 1.0.4. The child stylesheet is enqueued by Thematic like before. And instead of using the ugly @imports to add the parent styles, the child themes need to enqueue the stylesheet.

Also, I renamed the stylesheet to main.css as James suggested in #52

[middlesister]

We have the stylesheet. Any outstanding issues gets their own ticket.