Re: [Openinteract-dev] OI2 + CSS + XHTML thoughts

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

Salve,

excellent post and thanks for looking at this. It's an important issue.
Current plain HTML interface is so 98'ish.

>   - We drop the base_theme package entirely, and implement themes _only_
> using CSS. The goal should be that _no_ presentation details are
> retrieved from a database (sorry, Teemu ;) ), and that there's only one
> authoritative source for information on look and/or theme - namely the
> CSS files. All that's necessary to understand the CSS layout must be
> made available in an obvious, consistent and easy manner. Doing this
> will reduce database/filesystem access, give us a cleaner separation
> between data and presentation and improve debugging, system
> comprehension, CSS data accessibility, performance and cacheability. We
> should try to reduce complexity where we can - keep it simple; Separate
> concerns cleanly.

Absolutely. This is the path I wanted to go for. The theme provider might
want to create its own theme and if there are images and some templates
then distributes that as a separate package. But obviously, base_theme is
not required.

>   - We create a single set of CSS files that describe the look of all
> standard page components and widgets, using CSS classes, ID's and
> cascading/inheritance as appropriate. The goal is to have a sensibly-
> looking and workable site out-of-the-box, with all style information
> easily accessible and/or overrideable.

Modified themes (different color schemes etc) could be implemented with
inherited CSS files. That way I could create user specific themes, so the
user could select the colors etc. she/he wants and the code generates
an inherited CSS file, with only the color definitions in it.

>   - We only allow different "themes" by adding alternative CSS files,
> and referring to them in the usual manner from the XHTML documents.

Exactly, my previous point. I guess we need a table:

theme_id = ?
base_theme_css = ?
theme_css = ?
media = ?
title = ?
description = ?

Based on that, appropriate links to CSS files coul be generated to <head>.

We also might need a mechanism to introduce CSS files for different media
types (for example, hiding certain navigational goodies from small screen
terminals) and browser types. Our experience is that it's possible to write a single
CSS file that is cross-browser compliant from NS4 to latest opera/safari/ie/mozilla, but
requires enormous amount of work (several months) to get right if the page is even
a little bit more complicated.

>   - In the beginning we concentrate on W3C standards compliance. We worry
> about browser-compliance issues later.

w3c compliance with mozilla ;)

>   - There should only be _one_ place for references to style information
> in each XHTML page, namely in the <HEAD> section. We allow NO use of
> local style attributes in the default templates - we want style
> consistency throughout the entire site, and sub-document style
> modifications should therefore be avoided.

Most tags generated should include class information for easy styling.

>   - Likewise, there should be _no_ ECMAScript/JavaScript inline in the
> templates. We'll only allow references to separate .js files so the
> browser can load them. If we need to use JavaScipt triggers of some
> sort (onmouseover, etc.), we add these from the JavaScript files by
> manipulating the DOM tree.

A reason to include meaningful id properties to most central tags.

>   - We should also make sure all XHTML documents are using UTF-8 as
> charset. This may be our first step in making all of OI2 use UTF-8 :).
> In order to ease transition to UTF-8, we _may_ want to try to use HTML
> entities whenever common eight-bit characters are used (e.g. in I18N msg
> files, templates and error messages.)

I've got four thumbs up here. Gettext in the I18N side ;)

>   - Keep the templates as simple as possible, trying to reduce the
> "depth" of INCLUDE and PROCESS calls. A maximum depth of two or three
> levels should be strived for.

Oh yeah.. Template Toolkit isn't very good at executing multiple levels of
INCLUDE/PROCESS. With Dicole we implemented a fairly nice widget framework
out of TT templates, resulting in quite a lot of depth. In theory it was great
but in practice too slow. We have had to optimize certain parts by adding a
partly compiled template for certain heavily used applications which have
complex views.

>   - If we can avoid breaking the widget API, fine. But when we have good
> reasons to break it (e.g. removing the old base_theme-specific stuff),
> then we go ahead and break stuff.

Break, smash and kill it. Basic header, body and footer templates are enough,
maybe some other commonly used sections in body can be separated for easier
modification/maintenance.. but don't do what I did (widgeting everything) =)

>    <!-- Main menu. See /main.css for style information -->
>    <ul class="oi2_menu" id="oi2_global_menu">
>        <li><a href="/user">Users</a></li>
>        <li><a href="/group">Groups</a></li>
>    </ul>
>    <!-- End of main menu -->
>
> This will make it easier to usefult things by manipulating the DOM tree
> with JavaScript.

Yep. For a menu, use an unordered list. With some included javascript and
voodoo CSS you can work out.

>   - Some way of cleanly managing breadcrumbs, clickpaths and other types
> of link-stacks and -queues.

Now that we have REST, why not include a breadcrumbs title for each part..

>   - Likewise standardized a way of telling about program state. (e.g. a
> place on the webpage where one always can expect to see "where" in an
> application one currently "is", at any given time.)

Sitemap? Easy to generate out of registered applications if they include
REST parameters and titles for each..

-- 

Teemu Arina, CTO

Ionstream Oy / Dicole
Komeetankuja 4 A
02210 Espoo
FINLAND
Tel: +358-(0)50 - 555 7636
skype: infe00
Corporate website: http://www.dicole.com
FLOSS in education: http://flosse.dicole.org
Personal weblog: http://infedelic.blogspot.com

"Discover, collaborate, learn."