[daisy] [skin2] Poll for participation and input

Fri Sep 28 10:05:59 CDT 2007

hepabolu wrote:
> Hi,
> 
> here are some random thoughts based on things I've seen in other 
> websites and/or my experiences with skinning Daisy sites.
> 
> Thoughts/suggestions/observations are in random order.
> 
> - first of all, make the standard Daisy skin valid XHTML Transitional. 
> Coming from valid XML this should not be too hard; my HTML Tidy Firefox 
> plugin only reports warnings. The advantage is that debugging the new 
> skin is easier, since you know that all errors and warnings are 
> introduced by the modifier.
> 

I'm not entirely sure where the daisy html might be not valid

there is however one clear issue that we're rather reluctant to solve: 
we feel that listing phantom xmlns attributes on elements as 'invalid' 
is quite over the top (and a consequence of the DTD heritage of HTML)

anyway, filtering out those might turn out a lot bigger (runtime) effort 
then gain...

> - split XSL and CSS for the editing and for the 'display' environment. 
> After extensive changes in the various XSL files I found myself with a 
> non-functional editing environment. Also, when you want to style the 
> editing environment different from the 'display' environment, it's very 
> hard to figure out what should go where when you still want the editor 
> to closely match the final display.
> 

not entirely sure:
I find it often a plus that the editing environment looks similar to the 
display.  So I see it as a plus that I don't need to do the skinning 
work twice.

However I do think we need clearer class/id markings so css files would 
know as well in which mode pages currently are...

> - add the document id to the final HTML output, e.g. <body 
> id='dsy-123-ns'>. This allows page specific CSS styling. I know this 
> should not be promoted, since it connects CSS and HTML through the 
> document ID, but sometimes you just want to style one page a bit 
> different without creating a special documentType for it.
> Note that this id should not start with a number, since that is not 
> valid in XHTML.
> 

maybe we should even prefix with dsy-id- (as other dsy- prefixes might 
be useful)

> - something that still eludes me: what is the purpose of specific 
> documentTypes? To me they hold a specific type of content, e.g. news 

each of them typically has a different set of fields/parts

> items, a FAQ, whatever. While skinning, I found myself creating a new 
> documentType just to be able to introduce a sidebar on certain pages, 
> i.e. no special information, just special layout.
> 

xslt can react on other properties of the document as well if you'ld 
prefer that

> - I agree that a new version of the skin system should result in 
> something that's easier to modify, thus allowing for various users to 
> provide their own skin to the community.
> 
> - standardized naming in CSS classes are also welcome. Preferably no 
> markup for HTML tags directly, but through classes (i.e. not
> 
> table { .... }
> 
> but
> 
> table.tableMarkup { .... }
> )
> 

or .daisyHtml table {....}

> This makes it easier for designers to change the look and feel without 
> touching the XSL, but it also helps in differentiating between the 
> editing and the 'display' environment.
> 
> - start off with a CSS framework. This is more or less also described at 
> the Yahoo site, mentioned in this thread. Proposal:
> 
> reset.css - contains tags that reset all margins, padding, font size 
> etc. to give you a browser independent starting point
> 
> layout.css - contains only layout related attributes (margins, padding 
> etc.)
> 
> typography.css - contains only font related attributes (font, size, text 
> alignment etc.)
> 
> graphics.css - contains only colors and graphics (background, borders, 
> colors etc.)
> 
> doctypespecific.css - contains specific styling for one or more 
> documentTypes.
> 
> style.css is basicall the file that call it all:
> 
> @import reset.css
> @import layout.css
> @import typography.css
> @import graphics.css
> 
> maybe even divide into 'display' and 'edit' files (i.e. 
> layout-display.css and layout-edit.css etc.)
> 
> This way part of the CSS markup can be changed without touching the 
> rest, i.e. reusability as much as possible.
> 
> - The Daisy wiki needs to be restarted to pick up a modified query 
> styling. This is quite annoying when you want to debug your styling.
> 

as andreas mentioned 'touching' the parent-xslt for all query styling 
should suffice (otherwise cocoon doesn't notice that he should recompile 
the xsl)

> - To allow for more flexible styling (i.e. web designers fiddling with 
> CSS rather than XSL), the default (X)HTML output should have a default 
> layout that allows for skinning, like the page used for the CSS 
> Zengarden. This would look something like this (elaborating on Marc's 
> example):
> 
> <html>
>   <xsl:call-template name="insert-daisy-header"    />
>   <xsl:call-template name="insert-my-extra-header" />
> 
>   <body id="dsy-{$docid}>
>     <div id="wrapper">
>       <div id="header">
>         <!-- masthead/banner etc. -->
>       <xsl:call-template name="insert-daisy-navigation" />
>       <xsl:call-template name="insert-daisy-breadcrumb" />
>       </div>
>       <div id="contentwrapper">
>         <div id="menu-navigation">
>            <xsl:call-template name="insert-menu-navigation"/>
>         </div>
>         <div id="content>
>          <xsl:call-template name="insert-daisy-part" >
>           <xsl:with-param name="partName" select="'SimpleContentPart'" />
>          </xsl:call-template>
>         </div>
>         <div id="sidebar">
>           <xsl:call-template name="partName" select="'SidebarPart'"/>
>         </div>
>       </div> <!-- end contentwrapper -->
>       <div id="footer">
>       <!-- footer info -->
>       </div>
>    </div> <!-- end wrapper -->
> </body>
> </html>
> 
> Maybe some extra divs are added to provide web designers with some hooks 
> for extra images (ala CSS Zengarden). Although Webstandards purists 
> would shiver at the thought of inserting non-content related markup.
> 
> This template should be compiled in one XSL file, as near to the end of 
> the pipeline as possible. I remember that I needed to change 2 or three 
> XSL files to come up with something resembling this.
> 
> Again, the separation between the 'display' and the editing environment 
> should be more distinct than it is now.
> 
> 
> - we need a simple fall back mechanism. The current 'add the name of the 
> default skin to file XYZ' is much better than before, but not very 
> intuitive.
> 

I think it's quite ok, and only needs clear documentation of the 
baseskin.txt file

but I might be missing something and would surely like to learn any 
suggestions...

> 
> As said before, these are just thoughts, observations and ideas and are 
> only meant as input to a brainstorm.
> 

cool, thx, that is what I was hoping for at this stage...
hope we can continue some more...

have started listing ideas in some organized way at 
http://cocoondev.org/wiki/521-cd/522-cd.html

please add if I missed something

regards
-marc=