-
Notifications
You must be signed in to change notification settings - Fork 41
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Create new stylesheet for the new markup #61
Comments
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. :) |
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? |
New stylesheet is here, all in one long file. :) |
I'll leave this open until the styles are finshed |
@middlesister I am looking at the new stylesheet now |
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... |
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 :) |
Also, @middlesister, can I go ahead and alter style1? I will do that tonight after I am done working. |
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:
|
Some notes from @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. |
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 |
What is the correct way to drop all default styling and just use the child themes CSS? I ask because if you But if I don't use the wp_deregister and just use
This also works, but I am not 100% sure why ;x |
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.
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 |
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. :) |
Let child themes enqueue the stylesheet themselves if desired. This will also avoid a potential removal of styles if the legacy mode checkbox is checked by accident see #61
…dependencies This will ensure any child theme that is using the filter will have it's function execute after and override the parent see #61
So that is now changed. No parent stylesheet will be enqueued by default. That essentially means no change from 1.0.4. The child stylesheet is enqueued by Thematic like before. And instead of using the ugly Also, I renamed the stylesheet to main.css as James suggested in #52 |
We have the stylesheet. Any outstanding issues gets their own ticket. |
Depends on #50
I like the strucure and TOC of twentythirteen
I'd like to add a plugin-integration section for plugin styles like wp-pagenavi etc as well
The text was updated successfully, but these errors were encountered: