Ideas for a new skin

Some grab of first ideas on what a new Daisy skin should provide:
(This list started off as a resume of email discussions, feel free to add more stuff here)

Organization/principles

Very rough idea: separate display organisation from content organisation.

The text below should be verified against the current works of the styling. There is probably some overlap and there might be some problems implementing this.

Currently all documents follow the same styling/layout. Great for consistency. Documenttypes differentiate between various types of content. However, if you want to change the layout you need to create a new documenttype, if necessary with different parts. You then create a different documentstyle for that type of document.

If you need a different documenttype for a different type of content that basically has the same layout, you would need to recreate the documentstyle.

If you look from the GUI perspective, the screen is divided into parts, let's call them modules, to avoid confusion with document parts. Each module has an ID.

Each module is connected to the content source.

Example:

Assume a typical layout:

header with logo
subheader with 'toolbar' (loging, actions etc.)
left side navigation
main content
footer

On the home page, the main content contains a right hand side sidebar with news. On the Events page, there is also a sidebar which contains a calendar of the current and the upcoming month. All other pages don't have a sidebar.

You could now create a template/skin that defines the layout marking the location of the various modules. In a separate file each module is connected to the content/documents/parts.

Below are explanations of how it could work, this need not be the final format!

template:

<html>
  <head>
    <module id='metatags'/>
    <title><module id='doctitle'/></title>
    ....
  </head>
  <body>
    <div id='header'><module id='header'/></div>
      <div id='content'>
      <div id='navigation'><module id='navtree'/></div>
      <div id='main'><module id='maincontent'/></div>
      <div id='sidebar'><module id='sidebar'/></div>
    </div>
    <div id='footer'>Footer info</div>
  </body>
</html>

Config file:

metatags=/doc/tags/metatags
doctitle=/doc/tags/title
header=/doc/header
navtree=/menu[@name='main'], /menu[@name='context']
maincontent=/doc/parts[@tag='main']
sidebar=/doc/parts[@name='sidebar']

metatags: the document can have a field 'metatags', that contains the relevant metatag information to be put in the HTML document header.

doctitle: the default document name can be adjusted for the HTML 'title' tag. This allows full HTML/Unicode characters in the visible document, while the title tag is set to the allowed set. You can also make a different title/document name set.

header: the information of the document that should be put in the header/masthead section of the page. This could also be a site-wide variable, e.g. the company's address.

navtree: this holds the navigation tree. If the site has multiple navtrees, they can be identified. Multiple menus can be put in sequence.

maincontent: the actual content. Document parts can be identified by a name (or parttype) or by a tag, such as 'main' or 'default'. The latter allows for documenttypes with different parttypes to be mapped to a single template.

sidebar: in the home page the 'sidebar' part is configured to show news, while in the events page, the 'sidebar' part is configured to show calendars.
In all other parts, the 'sidebar' module is empty. Using some testing, the layout of the maincontent can be adjusted to grow/shrink to take the available space.

Pros

Such a template makes it easier for web designers to get starting.
You can have a single template for multiple documenttypes without copy/paste of XSL code.

Cons

You still need to code XSL to style the content of various document(s) (parts) and queries.
An extra layer is added, how about performance and complexity?

xslt

more designed for reuse and extend (as mentioned in DSY-542)
more chunksize ready templates for various things, like

insertion of named fields/parts
navigation flavours

start at this node, so much levels deep
breadcrumb
show first two levels regardless @selectedPath (for top menu)
show a sliding window of currentlevel -1 and +1
show only the options below the current selected node
...

link flavours
menu insertion
header insertion and customization there-of

like allowing to include ie6 specific css <!-- [if ie6] through constructs

html

provide a well-documented set of id's and classes that will be used by default

these should map/extend those of whatever chosen css framework (see below)
as well as for daisy stuff

mark body with #dsy-id-{$docid}
mark container with .dsy-mode-display versus .dsy-mode-edit
mark DaisyHTML content with .daisyHTML
...

produce valid XHTML Transitional

although trying to avoid the slip through of phantom xmlns:p=url declarations might involve more (runtime) effort than gain here?

css

consider a css framework like YAML or YUI

extras

provide reusable templates for integration with 'stuff out there'

microformats
google integrations (maps, calendar, analytics)

provide more 'configurable' things in the skin-conf

documentation

better documentation of the xslt variables

IDEA: maybe helps if we even split off the variables in a separate xslt?

provides samples of different layouts

Comments (0)