forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thorsten Scherler <>
Subject [RT] Forrest templates for second generation skining - towards Corium
Date Thu, 04 Nov 2004 17:53:56 GMT
Hello devs, again, ;-)

the following mail is an aggregation and consolidation of different 
mails I wrote in this ml. I added some new concepts to the topic.

The recent discussion about the problems with semantic container for 
css-elements and the positioning showed me that we may have to see 
leather-dev more like a plain-dev approach. I reckon leather should 
produce xhtml as output which then can be used in other transformations.

Leather-dev is an implementation of a not yet established standard 
regarding naming conventions about css-elements. It is about keeping 
elements of the site in semantic container rather then in visual container.

That makes it possible for developers to create new functions for the 
(x)html outcome without knowing the actual visual outcome (positioning 
etc.) and drop them into leather [1].

To drop a function in the responding semantic container (sc) will it 
make it possible that a designer afterwards can take care about the 
display. Having everything in sc will make it as well easy to find an 
element and alter the functionality.

Here is an example of what I mean by "dropping in".

<div id="content-main">
<div title="Portable Document Format" id="content-pdf">
<a class="dida" href="index.pdf"><img alt="PDF - icon"
src="skin/images/pdfdoc.gif" class="skin"><br>

"Dropping in" means to just add the matches within the container where 
the content semanticly belongs to. e.g.
<div title="XML" id="content-xml">
<a class="dida" href="index.xml"><img alt="xml - icon"
src="skin/images/xml.gif" class="skin"><br>

Would be "dropped in" like:
<div id="content-main">
<div title="Portable Document Format" id="content-pdf">
<a class="dida" href="index.pdf"><img alt="PDF - icon"
src="skin/images/pdfdoc.gif" class="skin"><br>
<div title="XML" id="content-xml">
<a class="dida" href="index.xml"><img alt="xml - icon"
src="skin/images/xml.gif" class="skin"><br>

The problem for a designer with the semantic-container approach is that 
he has to place all elements with absolute position in the page what is 
quite ugly. Designer should have the freedom to use graphical hooks for 
reasons of design [2].

The problem is that if we allow graphical hooks in leather we cannot use 
it anymore as internal format for our future skin becaused we mix up 
concerns again. The consequence will be that if we implemend a new 
function we have to implemend it not only in 1 skin but in x and we have 
to know where we have to place it in each skin. That means editing the 
xsl of several different skins.

The solution could be to use the contracts we have and introduce a 
templating file that designer can use to place the elements whithin 
graphical container. This would make it easy to create new styles 
without programming xsl and still keeping the concept of "dropping in" 
new functions.

The following template shows the pelt skin using leather naming 
conventions and graphical hooks. I will refer to this template as 
forrest-template (ft).

   <contract name="branding-trail-path"/>
   <hook name="intro">
     <contract name="grouplogo"/>
     <contract name="projectlogo"/>
     <contract name="search-input"/>
     <contract name="nav-main"/>
     <contract name="nav-main-sub"/>
   <hook name="main">
     <contract name="published-a1"/>
     <contract name="branding-trail-path-a1"/>
     <contract name="nav-section">
       <contract name="nav-section-current"/>
     <contract name="content">
       <contract name="content-pdf"/>
       <contract name="content-xml"/>
       <contract name="content-txt"/>
       <contract name="font-size"/>
       <contract name="minitoc"/>
   <hook name="clear"/>
   <hook name="outro">
     <contract name="siteinfo-legal"/>
     <contract name="published"/>
     <hook name="outro-feedback">
       <contract name="feedback"/>

This template file contains all the information of how the new skin can 
look like. Now let us see the big picture.

1) pipeline A - use the values of the skinconf to determine which 
elements and functions are used and where.
****************   ***********   *********************************
* skinconf.xml * + * leather * = * customized set of elements CE *
****************   ***********   *********************************

2) pipeline B - transform the customized elements with the 
forrest-template to create the final page.
******   ******
* CE * + * FT * = final skin output
******   ******

What happen in pipeline A and B is that first we will use the 
information of the skinconf to customize the elements we need to put in 
the skin. e.g. <disable-xml>true</disable-xml> would mean that we do not 
going to include the xml to our actual output CE.

The pipeline B will now use the forrest-template informations and the CE 
elements to produce the final output.

- Having this concept in the back in my head I will now implemend all 
functions that are missing in leather now and drop them into their 
semantic containers.
- I will then write down all contracts that we have in a xml-file. This 
file will contain the name of the contract and a description of it. This 
way it will be easy to know which element designers can implement in 
skins and what the outcome of the elements are.
- In the meantime we can implement a basic css-style for leather to 
finish the skin. BTW this maybe will not be necessary if we use it as 
internal only format but I would love to see a style. ;-)

This work let us then enter the road of Corium. The forrest-template can 
be used to imitate e.g. zen-css-garden. I would like to use this concept 
to create Corium, our skin bot.

- We will have pure semantic container (SOC).
- One big advantage is that all new functions would be introduced to 
only leather.
- All skins using leather as internal format can use new features by 
adding only on line of code to their forrest-template.
- We can imitate more all less all known html-skelletons that are out there.
- We have a document where all contracts are declared.
- We can use the concept of ft as well for pdf et. al. I am thinking to 
implement Adobe Indesign (*.inx) support with this concept.

- We have to keep the contract document *always* up to date (one more 
document to take care of)

*Open Questions*
I have some issues that are not 100% clear to me right now:
- Some element like the published note can be used in different 
locations. Right now there are be copied and placed with into the 
alternativ location via ~-a1. That is not really efficent. Can we thing 
about a method that is better (more copyless)?
- The common skin and leather are having then more or less the same 
function. Should they be consolidated?
- Should leather have css-stylesheets at all?
- I used now some naming conventions for graphical hooks. Should we as 
well try to introduce this conventions?

*Recent scale-dev*
I can imagine that we can have the scale-dev as first second generation 
skin and as example for the new skin concept.



"Together we stand, divided we fall"
Hey you (Pink Floyd)

View raw message