HTML structure

So, I’ve been looking at Scribbish[1] and the CSS Zen Garden[2] and I
like what I see. In particular, I like the idea of the hAtom
microformat for our articles, and I really like the idea of making
sure we have a robust semantic structure for our core HTML. Every time
someone has to write rhtml in their themes I cringe slightly.

So, I’m thinking that the whole Theming thing needs looking at. Here’s
a few ideas:

  • No more overriding layouts/default.rhtml just to add a couple of
    theme specific css files. We’ve already moved to having most of
    the layout’s header generated by a helper method, it should not be
    beyond our wit to have it do something like:

    <%= render :partial => ‘common/stylesheets.rhtml’ %>

    as part of its strategy.

  • Nail down the basic semantic structure of our layout and have more
    of the
    individual divs rendered as partials (and hence more finely
    overrideable by a theme). Also, the ‘partial’ boundary might well
    be a good place to insert more granular fragment caching for
    better performance.

  • Make use of the hAtom microformat (and possibly other microformats
    for other bits and pieces, is there one for tag clouds yet?)

  • Get some feedback from (or become) CSS experts with an eye to
    designing a basic page structure that’s flexible enough that most
    themes can simply provide a css file and a bunch of images. Check
    out the CSS Zen Garden for the sort of thing that has been
    achieved with ‘pure’ CSS.

  • As we’re breaking themes already, let’s break 'em good and proper
    so we can rebuild them stronger, better, faster…

Thoughts?

  1. http://quotedprintable.com/pages/scribbish
  2. http://csszengarden.com/

I’m a happy user of Scribbish. It’s a great foundation, simply and
easy to mod. I think it’s great to use it as inspiration for an
upgrade of the typo theme system.

If you want to get CSS happy, I’ll suggest generating CSS from ERb
templates. I put together a simple solution for that in Rails -
check out this article on my blog:
http://blog.hasmanythrough.com/articles/2006/03/23/dirt-simple-rcss-
templates
The cool thing about using RCSS is you can parameterize style
settings in the database and generate the CSS based on those values.

The one thing I didn’t like about how Scribbish does CSS is that it
has so many files. Each reader hits my server six times just to get
the CSS for one page! I ended up merging all the modular files into
one, and even if it’s not a big deal for my server my log files are
smaller and easier for me to look at if I need to. But going with an
RCSS based system you could generate one file easily. I haven’t
tried it, but I think my RCSS trick should support partials, which
would allow for modular construction of the CSS with little effort.


Josh S.
http://blog.hasmanythrough.com

On 14 Apr 2006, at 07:05, Piers C. wrote:

individual divs rendered as partials (and hence more finely
out the CSS Zen Garden for the sort of thing that has been
achieved with 'pure' CSS.
  • As we’re breaking themes already, let’s break 'em good and proper
    so we can rebuild them stronger, better, faster…

Thoughts?

I don’t understand what you’re getting at here … at all. And I’ve
tried.

Breaking themes has nothing to do with CSS. Rendering a sidebar has
nothing to do with CSS, rendering the content has nothing to do with
CSS. I could put my CSS on a wordpress install and it would look the
same (after renaming my divs). That’s the whole point of CSS - it’s
just the styling.

My theme was broken because I had to change

<%= render_component(:controller => ?sidebars/sidebar?,
:action => ?display_plugins? %>

to

<%= render_sidebars %>

in default.rhtml and that has nothing to do with how pretty my site
looks (CSS) but how the sidebar is rendered (Typo code).

Separate CSS and HTML in your mind.

Why would you want to stop a themes overriding default.rhtml (if
that’s what you mean)? As that’s a nice feature.

Why are you talking about nailing down a basic structure of the
layout? That’s for a theme designer to do surely?

I’m lost.

Is it just me? Could be :wink:

I readily agree that something needs to be firmed out though because
I’d put money on the fact that nearly every theme in the contest
would be broken in trunk now.

Gary

Hi,

On 4/14/06, Piers C. [email protected] wrote:

So, I’ve been looking at Scribbish[1] and the CSS Zen Garden[2] and I
like what I see. In particular, I like the idea of the hAtom
microformat for our articles, and I really like the idea of making
sure we have a robust semantic structure for our core HTML. Every time
someone has to write rhtml in their themes I cringe slightly.

That sounds like a great idea. However as part of this move it may be
a good idea to pull in some of themes that have been created for typo
into a subversion repo somewhere. That way they can be adapted for the
new system as it progresses and we wouldn’t be in situation now where
the theme contest consists of themes that are now no longer compatible
with trunk. I would be happy to help maintain the three themes that I
use and I am sure other people would be willing to put work into
maintaining themes if there was some central location to do it in.


Cheers,

Peter D.

Gary S. [email protected] writes:

  • Nail down the basic semantic structure of our layout and have
    designing a basic page structure that’s flexible enough that most
    tried.
    Bah! You obviously haven’t tried hard enough!

to

<%= render_sidebars %>

in default.rhtml and that has nothing to do with how pretty my site
looks (CSS) but how the sidebar is rendered (Typo code).

Separate CSS and HTML in your mind.

Pointy end grandma.

Why would you want to stop a themes overriding default.rhtml (if
that’s what you mean)? As that’s a nice feature.

I want to stop every theme and its brother having to override
default.rhtml. It’s a ‘nice’ feature, but we’re definitely cracking
nuts with sledgehammers if we end up overriding default.rhtml just
because we want to change a stylesheet.

If we have a default (rails) layout that goes something like:

<%= render :partial => 'common/html_head' %>
<%= render :partial => 'common/header' %>
<%= yield %>
<%= render :partial => 'common/sidebar' %>

<%= render :partial => 'common/footer' %>

And make the various ‘common/*’ partials overrideable by the theme,
then we’re already in the position that a theme designer can alter the
structure of the various divs without having to repeat a bunch of
boilerplate.

Why are you talking about nailing down a basic structure of the
layout? That’s for a theme designer to do surely?

No, I’m talking about nailing down the basic structure of the HTML we
generate. Layout is done with CSS. The problem here is that the Rails
concept of a layout clashes with the CSS concept of a layout. It’s
awfully easy to get the two confused (and my original post wasn’t a
model of clarity in this respect, for which I apologise).

Take a look at the sort of thing that’s achievable using nothing but
CSS styling over at the CSS Zen Garden. My goal here is to have our
default theme consist of nothing more than a couple or three
stylesheets and have our basic, unthemed output be structurally sound
enough that the majority of themes can do the same. At the very least
we need to make sure that our unthemed output (including the core
sidebars, which means I need to take a look at the Amazon contoller)
is fully compliant with XHTML Strict.

I’m lost.

Is it just me? Could be :wink:

I readily agree that something needs to be firmed out though because
I’d put money on the fact that nearly every theme in the contest
would be broken in trunk now.

Well, if it uses sidebars, it’s broken. And if it wants to use at
least one of the plugins (can’t remember which one) that needs a
particular javascript included in the header, it’s doubly broken.


Piers C. [email protected]

On 14 Apr 2006, at 15:59, Piers C. wrote:

I don’t understand what you’re getting at here … at all. And I’ve
tried.

Bah! You obviously haven’t tried hard enough!

True

  <%= render :partial => 'common/html_head' %>
      <%= render :partial => 'common/sidebar' %>

then we’re already in the position that a theme designer can alter the
structure of the various divs without having to repeat a bunch of
boilerplate.

The dawn of a new day brings clarity :slight_smile:

I can see the benefit of that, definitely. But is it not almost
like doing the same thing as overriding default.rhtml … 'cept in
separate files? For instance, let’s say I need to place my own meta
tags, a custom div and a custom footer. At the moment that all goes
in the themes default.rhtml. So in the future I’d have to put the
meta tags in ‘common/header’, and I want the custom div before the
content so I’d normally place that just before the content is called
in default.rhtml … would I place that at the top of ‘content’?
(There would be a ‘common/content’?) The custom work for the footer
would then go into ‘common/footer’ - obviously :slight_smile: Now that’s not
about CSS. I haven’t even styled any changes yet. But is that right?

particular javascript included in the header, it’s doubly broken.

So yeah … pretty much every one. I smell a new contest after the
release of 4.0

Gary

Hi,

On 4/15/06, Gary S. [email protected] wrote:

On 15 Apr 2006, at 07:50, Peter D. wrote:

I am sure other people would be willing to put work into
maintaining themes if there was some central location to do it in.

I think that’s called typogarden.com :wink:

As far as I can tell that is just an unordered list of pointers to
themes that no longer work. I guess I was talking about a subversion
repo that contained a set of themes that are maintained in concert
with typo development. Each theme would list which version(s) of typo
it is compatible with and that way when you wanted a theme that worked
you could look at this repo. Something like typogarden may work when
the theme API is stable but until now it is just going to frustrate
people when they try and use it IMHO.


Cheers,

Peter D.

On 15 Apr 2006, at 07:50, Peter D. wrote:

I am sure other people would be willing to put work into
maintaining themes if there was some central location to do it in.

I think that’s called typogarden.com :wink:

Gary

On 15 Apr 2006, at 12:18, Peter D. wrote:

As far as I can tell that is just an unordered list of pointers to
themes that no longer work. I guess I was talking about a subversion
repo that contained a set of themes that are maintained in concert
with typo development. Each theme would list which version(s) of typo
it is compatible with and that way when you wanted a theme that worked
you could look at this repo. Something like typogarden may work when
the theme API is stable but until now it is just going to frustrate
people when they try and use it IMHO.

I think there’s going to be/is work going on to sort out those
themes. It’s very much needed as all those themes will be broken
with Typo 4.0. But it might be a suggestion you could put to those
behind Typogarden. It’s a good point about a svn repository, but I
can just imagine the ‘discussion’ over which themes would be
included :slight_smile: Especially as there were a few noses out of joint after
the competition result.

In an ideal world designers would be altering their themes to keep
pace, but to be honest Typo can change so rapidly that it would be a
bit of a chore. Azure keeps stable so I just watch for changes in that.

Gary

Gary S. [email protected] writes:

nuts with sledgehammers if we end up overriding default.rhtml just
because we want to change a stylesheet.

[…]

The dawn of a new day brings clarity :slight_smile:

Mmm… clarity… I like clarity.

about CSS. I haven’t even styled any changes yet. But is that
right?

Well, yes, and no. The benefit of overriding your footer in
common/_footer.rhtml[1] and your header stuff in common/_sidebar.rhtml
etc is that you don’t have to copy quite so much crap (that might
change, but we hope not) just to make your changes. And we’ll probably
arrange things so that the default versions will default to include
theme/_extra_headers.html and so, assuming you’re not making a major
structural change, you get to write a partial which only has stuff
specific to your theme with, with no boiler plate. The aim of the game
is to apply the Hollywood Principle[2] to themes. It works well for
the rest of Rails, so we should be able to make it work for themes as
well.

particular javascript included in the header, it’s doubly broken.

So yeah … pretty much every one. I smell a new contest after the
release of 4.0

Speaking as someone with the graphic design sense of a teeny tiny
kitten, I’d quite like the chance to win a Macbook too. And if there
is another competition, can we please try and avoid bitterness this
time?

  1. Partials have a leading _, it’s a Rails thing, I’m not entirely
    sure I understand why.

  2. Don’t call us, we’ll call you