forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shaun Evans <sh...@shaunevans.fsnet.co.uk>
Subject Status on visual aspects of skins
Date Wed, 13 Apr 2005 21:03:56 GMT
Hi all,
I haven't been a very good dev and haven't posted since last November, 
but I have monitored the progress of leather-dev and it's implementation 
of the scale-dev css.
Having tried to get the leather-dev skin looking good (I am a picky web 
designer ;) ), I have hit the point of giving up - I feel that I cannot 
get the css working well both in standards-compliant browsers, such as 
Firefox and Konqueror, and other ones like IE.

I think that the visual results are just as important as the quality 
code produced by Forrest - and the lack of aesthetically pleasing 
designs available as part of the default packages is potentially 
damaging to the project, IMO. For example, I am involved in an open 
source software project which requires a piece of software to generate 
its documentation from XML, to make PDF and XHTML. Obviously, Forrest 
was what I recommended, but the person who maintains the documentation 
refused to use it because he hated all of the included skins. While I 
don't mean to bash the existing skins, pelt is buggy (particularly in 
IE), tigris is not visually desirable, plain is... well, plain, and 
leather(-dev) is quite frankly unsuitable for release at this time. I 
attempted to rectify the problem with scale-dev, but the skin itself 
caused a huge number of problems, particularly the lack of compatibility 
with leather. I therefore propose a change in the way in which skins are 
produced.

Obviously, pelt and tigris will not have a future once leather-dev works 
well, as the contracts will be able to emulate those of said skins, and 
the css will be recycled, for those still needing to use pelt and 
tigris. The plain skin, I suppose, will remain, so that a clear division 
is provided between the 'full' skin, leather, and the html-only skin, 
plain. Leather should be able to take the name of a css file as a 
variable, and use just this css file as the presentation layer. One of 
the main points of Forrest is to separate content from presentation, and 
I hope we can further this by separating content from page structure, 
and then from the specific presentation layer provided by css. The main 
hurdle in moving to this method of presentation is the fact that Leather 
is very dynamic, and can use a different DOM tree, with contracts that 
can be placed elsewhere.
I don't know who else on this list is a web designer, but I am, and my 
main headache is css-controlled positioning of objects. For example, I 
think that the search box should be within the header of the page, or 
close to it such that it is prominent. With scale-dev, I semantically 
put it inside the header, so that I would not have to cause lack of 
compatibility across browsers deliberately. Using css position:absolute 
or position:relative would cause nothing but problems, with the myriad 
of browsers, in focus those not using standards as they should be 
(*cough* IE). For that reason, it is best that the capability *is 
provided* for the search box to exist within the header, and not be 
picky about where it is, but this, in the eyes of a web developer, is a 
world nowhere near perfect, and this simply will not work.
To produce a skin, and make it visually appealing, would take little 
effort. To compare to the example of an OSS project I gave above: no 
basic users would need any of the advanced capabilities of leather-dev. 
What they do need is a visual style that works, "out of the box".

Producing such a skin would be easy by itself (see my work with 
scale-dev, for example), but to use leather or a similar skinning 
'engine', one would have to make a freeze on a semantic structure that 
works, and could be transferred into css easily. With scale-dev, this was:

> container
>    +-branding
>      +-search
>      +-tabs
>    +-nav
>    +-content
>    +-siteinfo 

By freezing the tree like this, it would be easy to move on and produce 
the skin, while the leather compatibility is retained. This would be 
simple enough, but there are further complications.
Leather, and other skins, are seemingly using a strange and 
unnecessarily long and complicated navigation structure. For example, I 
snip the forrest.apache.org homepage:

><!--+
>    |start Tabs
>    +-->
><ul id="tabs">
><li class="current">
><a class="base-selected" href="index.html">Welcome</a>
></li>
><li>
><a class="base-not-selected" href="contrib.html">Project</a>
></li>
><li>
><a class="base-not-selected" href="docs/index.html">Documentation</a>
></li>
><li>
><a class="base-not-selected" href="howto/index.html">How-To</a>
>  
>
></li>
></ul>
><!--+
>    |end Tabs
>    +-->
>
><!--+
>    |start Menu
>    +-->
><div id="menu">
><div onclick="SwitchMenu('menu_selected_1.1', 'skin/')" id="menu_selected_1.1Title"
class="menutitle" style="background-image: url('skin/images/chapter_open.gif');">About</div>
><div id="menu_selected_1.1" class="selectedmenuitemgroup" style="display: block;">
><div class="menupage">
><div class="menupagetitle">Index</div>
></div>
><div class="menuitem">
><a title="" href="license.html">License</a>
></div>
><div class="menuitem">
>  
>
><a title="" href="http://forrest.apache.org/mirrors.cgi">Download</a>
></div>
><div class="menuitem">
><a title="" href="who.html">Who we are</a>
></div>
><div class="menuitem">
><a title="" href="flyer.html">Flyer</a>
></div>
><div class="menuitem">
><a title="" href="live-sites.html">Example sites</a>
></div>
></div>
><div onclick="SwitchMenu('menu_1.2', 'skin/')" id="menu_1.2Title" class="menutitle">Documentation</div>
>  
>
><div id="menu_1.2" class="menuitemgroup">
><div class="menuitem">
><a title="" href="docs/">0.6 (current)</a>
></div>
><div class="menuitem">
><a title="" href="docs/dev/">0.7-dev (unstable)</a>
></div>
></div>
><div onclick="SwitchMenu('menu_1.3', 'skin/')" id="menu_1.3Title" class="menutitle">Related
projects</div>
><div id="menu_1.3" class="menuitemgroup">
><div class="menuitem">
><a title="" href="http://gump.apache.org/">Apache Gump</a>
></div>
>  
>
><div class="menuitem">
><a title="" href="http://cocoon.apache.org/">Apache Cocoon</a>
></div>
><div class="menuitem">
><a title="" href="http://lenya.apache.org/">Apache Lenya</a>
></div>
><div class="menuitem">
><a title="" href="http://xml.apache.org/">Apache XML</a>
></div>
><div class="menuitem">
><a title="" href="http://www.apache.org/~vgritsenko/stats/">Statistics</a>
></div>
></div>... (I know there are more divs to close ;) )
>  
>
Most of this code is redundantly redundant in a redundant way :P. 
Mozilla.org (if you haven't noticed, the inspiration for scale-dev, see 
screenshot scale-dev-s1.png) uses a very sensible system whereby the 
entire navigation is controlled by <ul>, <li> and <a>, reducing the 
amount of code significantly, and making the css much easier to work 
with, and compatible with other ways in which the page could be 
displayed (e.g. by moving the navigation to a vertical or horizontal 
system, or moving it to another part of the page). Referring to second 
snip: what does the title="" in each link do? Why does each and every 
div need a class="menuitem", considering they are *all* menu items?  Why 
is a <div> soup used to make this navigation structure look exactly how 
an unordered list looks with an image as the bullet?
Unfortunately, leather recycles this system from pelt, and the 
navigation really does not need to be like this.

(Oops, I seem to have deviated from my original points, but these are 
all relevant problems in full standards compliance)

To Thorsten in particular: why do you say that leather-dev is dead? I 
see great potential in it, with a more refined output system, and it is 
certainly the way forward for the even-more-dynamic skins expected 
before a 1.0 release (it should be an experimental inclusion in the 
post-0.7 releases, IMO).

So, that is a selection of some of the thoughts of an admittedly picky 
web designer. I am particularly interested to know the opinions of 
Thorsten and Diwaker Gupta, after your significant contributions of 
discussion with scale-dev, but obviously, all comments are welcome...

Thanks in advance,
#shaun


Mime
View raw message