Roots Discourse

Development Questions/Suggestions

One of the other things I noticed about Roots is that the HTML uses a lot of Bootstrap-specific markup in the classes. What I’ve tried to do in my personal fork of Roots is edit that markup for semantics, rather than Bootstrap specific code:

(I also edited it for using Codekit and keeping the framework outside of the theme, but that’s another issue.)

The other thing I wanted to ask was about this issue/confusion that I came across while working on another site:

If the developers are interested, I think the framework would improve by:

  1. Replacing the Bootstrap-specific markup with semantic markup on the front-end and using bootstrap mixins on the back-end.

  2. Replacing the loop on the single.php with a get_template_part calling content-(post-format).php instead, and fixing the content.php to be “universal” i.e. using is_single, etc. to make it look right.

I would be happy to do it if you guys are interested. I just ask before I go ahead and do it because I’d have to unwind my Codekit-related commits before submitting the pull request.

Thanks for a great framework guys!

I’m not exactly sure how you could turn col-sm-4 more semantic. Is it semantic? Not exactly, but the idea of having everything 100% semantic just isn’t possible in my opinion, and really comes down to semantics, in this way meaning not necessary.

The issue you run into with turning things 100% semantic is you can set up .main and .sidebar with the Bootstrap CSS, and then possibly other areas with semantic CSS classes, but then you get into having a bunch of CSS classes set to very specific widths and other CSS.

It comes down to personal preference oftentimes, and yes, many others won’t agree with choices made. But hey, in the end, the website displays correctly, loads quickly, and makes sense to more than 1 developer, you’re not doing too bad.

Well, no - col-sm-4 (for example) isn’t ‘semantic.’ Making it a semantic class would include just classing it as ‘sidebar,’ and then using the .make-sm-column(4) Bootstrap mixin in Less. There wouldn’t be any need for specific widths or even much extra CSS, because it’s done with Less.

The idea is basically the HTML classes should describe what something is while the CSS rules tell you how to display it. Naming something col-sm-4 doesn’t tell you what it is and could make it harder to work with in the future. Also, given Bootstrap changed all its classes in BS3, making the front-end semantic would make future upgrades easier.

Yes, I understand and agree to a large degree with making things semantic. What I meant though, was you would have to add mixins to every “semantic” column you wanted to make in your website. IMO, this would cause a lot of CSS bloat, since every place you mixin col-sm-4 will have the same widths and duplicate CSS.

Really, it’s not a big deal though, as I believe it’s only the class being added on to col-sm-4 in CSS. I can see doing that for the main sections I suppose.

This would create unnecessary/duplicate CSS, so I can’t see it being incorporated into Roots. If you want to create only the columns you need, I would suggest removing the others from grid.less.

1 Like

Fair enough, I’ll keep that for my personal use.

What about my second suggestion RE: de-duping the loop with content.php?

Personally, I don’t like the idea of adding more logic to templates/content.php. There are a lot of things that change when you have multiple posts per page (headings need to be changed for SEO, comments don’t need to be displayed, thumbnails will change size etc) and it will just get cluttered if all of those are contained within conditionals.

What I do instead is change single.php to this:

<?php get_template_part('templates/content-single', get_post_format()); ?>

Yeah, that’s what I do as well - I’m actually going to switch that over to my default with conditionals rather than the way it’s set up currently.

Ok, I’ll keep both ideas for personal use. Thanks again!

Actually, I was just thinking - in the starter theme, you wouldn’t necessarily require a lot of conditionals, and it would actually declutter duplicate code in the other template files. Thoughts?

I’d need an example to try to envision what you’re suggesting.