[daisy] [skin2] Poll for participation and input

Tue Sep 25 11:27:01 CDT 2007

2007/9/25, hepabolu <hepabolu at gmail.com>:
> 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.

The same happened to me.

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

I found it also useful to have the document id visible in the page
title of the browse (for non guest users), so I altered my daisy
instances accordingly.

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

There's a way to avoid restarting the wiki every time, this is also
mentioned in the documentation:
http://cocoondev.org/daisydocs-2_1/374-cd/54-cd.html:

<snip>
Usually when an XSLT or one of the XSLTs included/imported by it
changes, Cocoon should reload it. However, it seems this only works
for the first level of includes, if included files themselve again
include other XSLTs, it seems to stop working. Therefore changes to
the file query-styling-html.xsl are not immediately reflected in the
wiki. There is an easy work-around to avoid having to restart the wiki
In order to let the changes take effect: simply touch an XSLT which
Cocoon will check for changes, in this case the searchresult.xsl
(which is a first-level include in document-to-html.xsl). In case you
applied document type specific styling, you have to touch the
stylesheet you created for that purpose (e.g. <wikidata
directory>/resources/skins/default/document-styling/html/mydoctype.xsl).
('Touching' means updating the last modification time of the file,
e.g. by saving it in an editor, or on unix using the touch command).
</snip>

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

Regards
Andreas