This project is read-only.

Ideas to cleaner theming

Topics: Writing themes
Oct 16, 2011 at 12:51 AM

Hi all!

Some thoughts about what I think could be better in terms of theming:

  1. It would be beneficial to give theme authors a tool to "decouple" stylesheets from their theme. This would aid theme inheritance: because if a stylesheet is included (or required) in a shape template, this means these inclusions can't be deleted without overriding the template (in addition to that inclusion of remote resources can't easily be overridden AFAIK). The problem could be solved by for example by using a resource manifest file to tie stylesheets (and script) to shape templates. This isn't always needed, but would be a nice feature for theme-wide styling.
  2. I have the feeling that if you want to add a favicon from a theme, you have to do it from the Document shape template (Layout doesn't work). This ain't good.
  3. Favicon support really should be something out of the box. Like if there's a favicon.ico in the root of the theme's Images folder, add the link entry it automatically.
  4. CSS resets could be organized in a central css, so themes could include it, without providing it on their own.
  5. I don't want to advertise here my less-than-half complete product (Piedone.Combinator), but if the combination of css files is possible, than there is no reason to not separate parts of a css file into separate files. This would make overriding of specific styling much easier, again helping theme inheritance (and speeding up rendering of pages: if the stylesheet was overridden, than there is no need to override styling).
  6. Maybe somehow (like with server-side processing) it could be done that resources (like images) referenced in a stylesheet could be overridden too? For example now images in css files are referenced with relative paths what makes it impossible to simply override them. Maybe this would be just an overkill since this is already possible with overriding styles.
Oct 16, 2011 at 3:05 AM

Thanks for the suggestions. A few remarks and questions...

  1. I'm a little confused about this one. When you do a Style.Include, it should resolve to the parent theme if necessary. Can you give more details about what exactly the problem is and what scenario is not handled?
  2. mmh, no, look at the favicon feature in Vandelay industries. No need to touch document.
  3. I disagree. Plus, Vandelay handles this just fine.
  4. And have one more download? Maybe when we have a way to aggregate resources into one download (yours for example). Even so, it would best be done through a module.
  5. Sure, but we'd need that to be a core feature then I think. This is something we want to have but currently we don't (except through a module such as yours).
  6. There is no reason why a stylesheet would need to be a static file. You can do this today if you want to. It hasn't seemed to be a huge problem that image overrides necessitate a css override, as 100% of the themes I've seen so far override the stylesheet anyways. The return on investment on this seems exceedingly small, for a performance cost that is substantial as those files are currently very fast to handle as they go through the static file handler.
Oct 19, 2011 at 2:19 PM
Edited Oct 19, 2011 at 2:20 PM
  1. Resolving is great, the problem arises if we don't want to inherit a stylesheet inclusion from the parent theme. Real-life scenario: The Theme Machine has a font css included from Google. Now if we don't want to use this css in the derived theme, there is no possiblity to delete the inclusion (other than programatically) without overriding the shape template that contains the inclusion. Similarly, if we don't want to inherit some of the local inclusions (like the base theme includes three stylesheets, but we don't need one completely), we have to override the included stylesheets with blank ones (or also override the template).
  2. You are right, but if one is a theme developer, the most straightforward way would be to add a favicon in the theme and don't give the end-user options to alter it (not that they wanted to...). Of course if one is not a developer but wants her/his site to have a favicon without diving into the source, your module is the right choice.
  3. Please take a look at PGBT linked from below for an example.
  4. Maybe resets should indeed be in a module (I have taken the way to add it to a theme, PGBT), but since Orchard has a javascript framework of choice, why not have a css framework too?
  5. I have provided an example of this in PGBT, so again, please take a look at it.
  6. You are fully right, I learned too that there is really no need for this.

Today I released Pretty Good Base Theme, which addresses some of these issues and demonstrates possible solutions. The big point is, there is no need to add anything to the core, a simple theme as a base is enough too.

Oct 20, 2011 at 12:43 AM
  1. It seems to me like overriding the shape that does the inclusion is a simple way to implement that, and that anything more automatic would introduce some new conventions that may be hard to discover and reconcile with existing code.
  2. Should be easy enough to implement in a theme, but that is also a feature I could add to my module. Please feel free to file a bug in
  3. What should I be looking for?
  4. Mmmh. Well, no module to date as far as I know introduces its own css reset, so I think it's fine to keep in the theme. The overhead of putting it into its own module seems way overkill for what looks to be a non problem.
  5. I'll look when I get the chance. Are you planning on writing a blog post on this?
Oct 20, 2011 at 7:44 AM
Edited Oct 20, 2011 at 8:32 AM
  1. Yeah, this is what I've actually done in my theme. But it has shape templates just for resource inclusion that can be overridden, so not the whole Document.cshtml or Layout.cshtml has to be overridden. So this is perfectly doable with present techniques, just the theme author has to be aware of how theme inheritance can be helped.
  2. Actually I have indeed implemented drop-in change of favicon in my theme, so it is indeed simple. But this could be also a nice feature of your module, I've filed an issue here.
  3. This is the drop-in favion change I've mentioned in the previous point. Nothing special, but I think it does help to avoid unnecessary work.
  4. Yeah, this is really better in a theme.
  5. Believe it or not, I don't have a blog for such topics, but I'm considering to start on now. Please let me know if I can help you to navigate in the project quicker.

So all in all I've learned that there is no need to add to the Orchard functionality, but there are some simple techniques that can very well aid theme inheritance and therefore cleaner theming. The task here is rather to include these in the common knowledge. Would this be appropriate in the wiki? Should I write an article?

Oct 20, 2011 at 9:16 PM

Sure, if you want to write a wiki article, that would be great. I'll take a look at the theme.