New default templates for WebGUI!

Welcome to the WebGUI templates working group forum! And let's start our first discussion right away: what are our goals, requirements, wishes, demands for the new default templates.

I have made a list of requirements to get us started. Please let me know what you think.

This is the list of requirements as it is now:

• Clean up templates:

  • remove all inline css from templates, necessary css goes into head section or separate file

  • remove all head tag css from templates (except for css for page layouts and positioning of complex assets)

  • remove all table layout that is used for positioning

  • replace / fix template vars that are incorrect or not working

  • use standard tags whenever possible

• Redesign and add classes and IDs:

  • identify reoccurring template constructions and come up with standard classes and IDs, which are used consistently in every template (like the "pagination" class, as it is used now)

  • come up with a set of rules for templates of new contributions (wiki)

  • compliant with XHTML 1.0 strict, WCAG Priority 1, Section 508 (US) =~ Webrichtlijnen (NL) - come up with tests for compliance to aformentioned standards

• Reduce number of templates

  • ideally from approx. 375 to approx. 200

Steps for redesigning a template:

1. Decide on the features and template variables to include. The criteria are: 1. only include the features that are used the most, 2. templates should be versatile but understandable

2. Replace template vars that are incorrect or not working. Post RFE's. Include “new default templates” in RFE title.

3. Use standard html tags as often as possible. Use them consistently (asset title is always h3 etc.)

4. Make the templates in a way that they look decent without any css. The document flow should be logical.

5. Add standard classes and Ids. Document these and reuse them where appropriate.

6. Test for standards compliance and “designability” (i.e. Is it easy to implement a design, is it possible to implement a design).

Rogier | United Knowledge
www.unitedknowledge.nl · www.webgui-help.nl

Another requirement: use the International macro for labels instead of template vars.

Rogier | United Knowledge
www.unitedknowledge.nl · www.webgui-help.nl

Just curious, what is the advantage of keeping css for layouts and positioning of complex assets in head tags?

JT made that request but, as I recall, he also contemplated if these styles could possibly be moved to a global webgui.css file. The issue I see, and I believe he was eluding to in our conversation, with the layouts for complex assets and page layouts is that the styles are not always needed so it could bloat a stylesheet.

Our options appear to be:

1. Leave the styles where they are and ensure that they can be easily overridden.
2. Move the styles a separate stylesheet and import as needed, probably using the extra head tags.
3. Include them in the webgui.css file.
   

• #1 is where we currently stand.
• #2 would increase the number of http requests.
• #3 sounds like a really unwise course of action unless compression would offset the bloat. Still...it sounds questionable.
  

Diona

----
Knowmad Technologies
http://www.knowmad.com

Yeah this is a tough one, let's take a look at the pros and cons:

#1 - pros:

• easy editing
• clear which styles go with which template
  

#1 - cons:

• when viewing multiple pages on a site this is slower
• no separation of style and content
• duplicate styles if there's two of the same asset on one page

#2 - pros:

• clear which styles go with which template
• only http req when needed
• separation of style and content

#2 - cons:

• more http reqs
  
• lots of files

#3 - pros:

• one http req
• separation of style and content

#3 - cons:

• webgui.css will be huge
• not clear which styles go with which template

I think the idea of webgui.css was mainly to have a place for the removed inline styles and for styles that can be found in more than one template. These are styles you want to have, even if you are editing the templates.

#1 is just bad practice and slowest in the end.

So I would go with #2 as the best solution. Yes there will be more http requests, but there are almost never more than 2 or 3 complex assets on 1 page. And on a second page visit it will perform better than #1 anyway.

Agreed, or no? Maybe something missing in these list?

Rogier | United Knowledge
www.unitedknowledge.nl · www.webgui-help.nl

I really prefer #2.  Styles in head sections of templates frustrate me as a designer, as I have trouble tracking them down.  I really prefer the external style sheet method, and I think this is a good solution.