[daisy] [skin2] Poll for participation and input

Tue Sep 25 09:15:19 CDT 2007

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.

- 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.

- 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.

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

- 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 { .... }
)

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.

- 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.

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

Bye, Helma