forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thorsten Scherler <thors...@apache.org>
Subject Re: Forrest skins (leather-dev screenshot)
Date Sun, 31 Oct 2004 02:33:44 GMT
Shaun Evans escribió:
> I've almost finished 'scale-dev' which is a CSS enhancement for
> leather-dev. Please have a look at the attached screenshot
> (scale-dev-s1.png) and tell me if there are any things that you don't
> like or things that could be improved.
> 

:)

Very nice.

It looks really promising.

Can you please attach the patch to 
http://issues.cocoondev.org/browse/FOR-342

I am keen to see the code. ;-)

> I also have to look at
> bringing in most of the features of pelt.

See my RT. IMO we have to find a way to capsulate the feature into 
sub-plugins first and then implement them to leather. It is no fun to 
repeat a work over and over again. ;-)

> 
> A question: as it's a hot topic at the moment, should the final skin be
> in XHTML 1 or 2?
> 

Input XHTML2
Output XHTML1 (maybe optional XHTML2)

> I have a suggestion about skins in general: from 0.7 upwards, there are
> 4 or 5 'channels' of skins:
> 	pelt: CSS and DIV-based, relies on skinconf.xml for
> customisation

IMO this skin should be only in 0.6. It can be used to extract 
functionality and see how the skinconf.xml work now. I wrote it to bring 
a css-only skin.

> 	tigris: Table-based, relies on CSS files for customisation

IMO we should not support it anymore

> 	leather/scale: generic DIV-based structure (leather), controlled
> by CSS (scale)
plugable functionality (pelt++)

This skin is the consequence of the lesson I learned from pelt. I had to 
break the layout because I restructed the skellton. We decide not to do 
that before the release so we created leather as pelt++.

The idea in leather is to have naming convention for css-elements. This 
are contracts between the designer and the programmer.

e.g. I as programmer will dump all the stuff related to brand a site 
into the semantic container "branding". If the element is new to the 
container the programmer has to send the new contract to the designer. 
This designer implements then the design template. Both are happy 
because they can concentrate what they are good on.

The thread with David I posted earlier as link opened my eyes that we 
have to import again all the functionality from one skin to another. 
Dude, this time we have to develope a mechanism frist that we can reuse. 
;-) Lets first find a way how we can capsulate the functionality into 
contracts. If we finsh all this we have a first skin provider.

A skin provider is somebody who offers different skins. A corium 
provider needs at least the information about:
a) skelleton (+ functionality)
b) css


> 	plain: plain HTML, no CSS, not customisable
> 	corium: next-generation, dynamic CSS, controlled in skinconf.xml
> and DIV (could supersede leather/scale?)
> 

Corium is the result from leather and pelt.
The idea behind corium is to support not only leather-skin-provider, but 
also other e.g. zencssgarden, OSWD, et. al..

> 
> Just a little about the skin: there are about 150 lines of CSS and I've
> tried to achieve Thorsten's original target of making a totally generic
> skin that is controlled entirely by the CSS. The entire skinned page
> weighs in at about 12kb, of which 5kb is CSS. (Thus the average page
> loads in about 3 seconds over 56k).
> 

Good on ya, mate!


> #shaun
> 
> 
> ------------------------------------------------------------------------
> 


Mime
View raw message