[Sputnik-list] Re: Blueprint

Fri Feb 8 03:08:44 GMT+2 2008

> I like the current layout for Sputnik----but maybe that's because I
>  haven't had as much time as I'd like to work with it :)

I wasn't talking about a major change to the layout, more of a minor
visual facelift by switching to a different framework.  Also, I am not
itching to change just for the sake of changing, I just thought this
was an opportunity to ask what you guys thought.

As I can see it, using blueprint would mean:

Pro: Simpler CSS, since it seems that Blueprint produces a decent look
out of the box.
Pro: Simpler templates for controlling layout (fewer levels)
Con: Non-semantic class names.

For instance, here is the markup that Nanoki uses (with closing tags
removed to make it easier to read.):

     <body>
        <div class='container'>
            <div class='column span-24'> &nbsp;
            <div class='column span-18 prepend-1 label'> &nbsp;
            <div class='column span-4 append-1 last label'>  -- Index,
Date, Recent links
            <div class='column span-18 prepend-1'> &nbsp;
            <form>
                <div class='column span-4 append-1 last'>  -- search text box
            <div class='column span-24'> &nbsp;
            <div class='column span-22 prepend-1 append-1 last'> the -- body
            <div class='column span-24'>  &nbsp;

In Sputnik (with YUI) we have:

<body>
  <div id='doc2' class='yui-t4'>
   <div id="login">
   <div id="logo">
   <div id='hd'>
       <ul class='submenu' id='submenu'>
   <div id='bd'>
    <div id="yui-main" >
     <div class="yui-b" id='page'>
      <span class="toolbar">
      <h1>
      <div class='content'>
   <div id="sidebar">

Things like class='column span-22 prepend-1 append-1 last' make me
uneasy about Blueprint.  This is the reason I decided to not use
BluePrint back in Summer, but maybe the benefits are worth it.  After
all, I could just put comments int the templates.

Do other people have their favorite CSS frameworks?

>  As for searching, I like the approach many wikis take of allowing both
>  page-title and full-body search, usually with separate UIs.  One way
>  that you could offer both but only use a single UI would be to recognize
>  a key word in the search spec that chose one vs the other.

Wouldn't that be a bit too complicated?

Anyway, in the long term I want to just add my own full-text search,
then use the same box for both and display the title matches first.
But local full-text is not there.

>  As for the nav bar, I like the two-layered approach.  What I miss (and
>  maybe it's just that I haven't figure it out) is an easy way to have new
>  pages added to a (sub)section.

What would be an "easy" way?  I assume you mean something easier than
editing _navigation? :)

I've been divided between two methods of adding a node to a menu:  (1)
have a page that lists nodes or (2) specifying in the node what page
it belongs to.  Right now I use  (1) for the first two levels and (2)
for the third.  The under-documented "category" field selects which
menu item would be selected when this node is display.  E.g.,
http://sputnik.freewisdom.org/en/Bug_Reports shows with "Problems"
menu item selected.  The problem with this second approach is that it
doesn't allow you to specify the order of the items.  It's not a
problem right now since I only use it for the third-level items which
don't actually show up in the menu, but attaching second-level items
to the menu this way would create a problem with deciding in what
order they should go.

- yuri

-- 
http://sputnik.freewisdom.org/