Posted by Alexander Ladda |
|
Hey Herbert,
what's the deal with html/css design for SCT? What are your visions? I've only taken a very superficial look at the implementation so far, but it seems as though they'd use some polishing/remodeling - and I'm sure you have your thoughts. Besides some general semantical cleaning up, I'd suggest something like this: [...] <ul> <li> <dl> <dt>Title</dt> <dd>Threads</dd> <dd>Posts</dd> <dd>last post</dd> </dl> </li> <li> <dl> <dt>General Discussion</dt> <dd>35 <dfn>Treads</dfn></dd> <dd>167 <dfn>Posts</dfn></dd> <dd>last post by: ... etc ...</dd> </dl> </li> <li> <dl> <dt>Sandbox</dt> <dd>17 <dfn>Treads</dfn></dd> <dd>45 <dfn>Posts</dfn></dd> <dd>last post by: ... etc ...</dd> </dl> </li> </ul> [...] (no table layout for the forum - although a forum comes pretty close to a table) I know, a lot of people consider that kind of talk nitpicking, but for me personally it is important. I'm far from being html/css wizard, but I think - I'll just have a go and dive into /sitetemplates and let you know about my work. |
|
Posted by Herbert Poul |
|
well.. i'm not really sure..
how would the CSS look like that transforms those li/dds into a "table" similar to the current look ? i'm not really a design guru as you can tell from this site ;) .. so .. i had no plans on remodelling the html layout of the category list .. i guess it boils down to what is less hackish :) .. if i'm conviced that simply ul/li/dd tags can be transformed easily using CSS into more or less the look of the current table (doesn't have to be 1:1 of course).. i would probably go for it .. but .. if it requires hundreds of dirty CSS tricks.. i would probably stay with the current HTML - because the only advantage of non-table HTML is that it is easier to customize without editing the actual code.. but if the CSS is too complicated.. it's probably easier extending the current template and overloading a few {% block %}'s to customize the look .. Hey, we have Signatures !!! Great, isn't it ? ;) |
|
Posted by Alexander Ladda |
|
I posted a little proof of concept:
http://paste.css-standards.org/35094 you can have a look at that as a webpage: http://paste.css-standards.org/35094/view I deliberately only entered the css necessary for the layout and didn't bother about spacing and stuff. |
|
Posted by Alexander Ladda |
|
I fear designing complex web applications includes a fair amount of very dirty CSS tricks... not so much concerning the table vs. list issue, but in general. I believe one could say:
CSS requires dirty tricks ;) |
|
Posted by Herbert Poul |
|
hmm.. this looks nice.. but.. it has one flaw .. it doesn't scale ..
with the current table text wouldn't need to wrap for people with higher resolutions .. and on lower resolutions the text would simply start to wrap .. i'm not really a fan of fixed-width layouts .. i can't force users with 1024x768 to scroll, and i don't want to force myself (or anyone else using >=1600x..) to live with a screen that is 50% empty :) considering how hard it is to create a simple variable-width layout with css.. i guess it is next to impossible to create a variable-width table like view with just css ? --- Last Edited by Herbert Poul at 2008-03-15 10:54:21 --- Hey, we have Signatures !!! Great, isn't it ? ;) |
|
Posted by Alexander Ladda |
|
Actually, it wouldn't be too hard to make a flexible layout, I believe. I myself, i hate fixed layouts.
But while doing some research I found this article. unfortunately kind of incomplete, but still very insightful: http://theartisticoutlaw.com/?s=Anatomy+of+a+Forum he goes way further ... a little too far as far as I'm concerned on some points, but one never knows. Since django fails silently, when variables are not fetched by the template (is that right) this could be a chance to have two branches of design templates... one, that is very much complying with the habits, culture and visual/functional idioms we all know and love in forums. and well one, that's just way out there, trying to reinvent the whole world. And maybe a third one in pink with pretty horses etc. I personally believe, that the separation from functionality and layout is only helpful, when coding and organization of files for distribution and maintenance. There definitely needs to be some unifying design level to the whole thing. But that's crossing bridges, that are not even built :) --- Last Edited by Alexander Ladda at 2008-03-15 12:20:15 --- |
|
Posted by Herbert Poul |
|
the post is very interesting .. although .. i don't think it is really accurate..
because to me the list of categories contains tabular content.. but that's probably because i think too much in SQL terms and i see everything as a table anyway :) but i think .. you are right in your last comment.. the best way would be to simply provide more than one layout from which to choose .. no single design can make everyone happy :) - take for example http://www.epostasia.com/forum/listgroups/ .. it really love this design .. but this only works for a very specific category-configuration structure .. so .. i think will take another look at the _displayCategories.html template.. to see how i can make it simpler .. and easier to extend... i imagine .. that you could extend the original template and simply override those blocks that you need.. for example for a hierarchical list: {% extends "sphene/sphboard/_display_categories_base.html" %} {% block category_list %} <ul> <li> <!-- the header --> </li> <ul> {{ block.super }} {% endblock %} {% block category_item %} <li> <dl> <dt>{{ category_name }}</dt> <dd>{{ category_posts }}</dd> </dl> </li> {% if category.children %} <ul> {% sphboard_listCategories category.children %} </ul> {% endif %} {% endblock %} the important thing here is, that you only define your HTML structure, and don't have to figure out where to link to, which folder icon to display, etc. i'm not sure how much of this is actually possible because the _displayCategories.html is already quite simplistic .. Hey, we have Signatures !!! Great, isn't it ? ;) |
|
Posted by Alexander Ladda |
|
I read the chapter in the djangobook about templates and that seems to be pretty straight-forward stuff.
The only thing, I don't quite get is the big picture with the whole organisation of the project yet- that is, ... :) it's a little obscure how the html-sniplets excactly find each other through the whole folder structures :D but I see enough to get started... --- Last Edited by Alexander Ladda at 2008-03-15 19:03:49 --- |
|
Posted by Herbert Poul |
|
i'm not sure what you mean ?
SCT has 3 main django applications, community, sphwiki and sphboard.. these are all under sphenecoll/sphene/ .. and it makes use of the "app directories template loader" .. which means, every application has in it's base directory a 'template' directory .. under which all templates for it are stored.. (to not get naming conflicts in the template directory i again have sphene/<application name>/) and all include and extends statements use absolute paths (starting from the template directories) as for the {% blocks xxx %} statement.. django simply takes the root template (the one without any {% extends .. %} and parses it from start to end.. for every defined {% block ... %} it looks if it is overloaded in the current hierarchy .. Hey, we have Signatures !!! Great, isn't it ? ;) |
|
Posted by Alexander Ladda |
|
that is ROOT_PATH/communitytools/sphenecoll/sphene/<application>/templates/<path-provided-by-extend> ?
|