User Tools

Site Tools


mantisbt:style_guide

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
mantisbt:style_guide [2010/10/14 21:57]
daryn
mantisbt:style_guide [2013/04/30 05:54] (current)
dregad
Line 1: Line 1:
-====== HTML ====== +====== Style Guide (DRAFT) ======
-  * NO Inline Javascript. None. At all. Ever. In any HTML body output.   +
-    * NO onclick/onmouseover/etc attributes +
-    * NO inline <script..>something();</script> blocks  +
-    * NO use of javascript:something() in hyperlink hrefs. +
-  * No Inline CSS styling should appear in any HTML output. +
-    * No style attributes +
-    * No inline <style>..</style> blocks +
-  * I strongly suggest looking at PHPTAL over any other templating engine I've come across. This will assist us with security (automatically escaping strings to prevent XSS attacks), internationalisation and ease of template maintenance. The templates are valid XML documents and can be rendered directly in a web browser without needing to be parsed through the templating engine. +
-  * Any statement about use of tables vs. CSS for layout?  I assume we want to limit/ban the use of the first.+
  
-====== CSS ====== +===== HTML ===== 
-  * The only method allowed for including CSS styling is via including an external CSS stylesheetin the <head> of the document. +  * Do use HTML5 
-  * Use multiple stylesheets for different screen resolutions so that the page will appear differently on smartphone (small horizontal width) and widescreen monitor (large horizontal width). +  * Do not use tables for layout.  Tables may only be used when the content is actually table data. 
-  * Support for a print stylesheet which emphasizes legibility, clarity and efficient printing. +  * Do not put business logic in the templates - //Using PHPTAL templating engine will assist with security (automatically escaping strings to prevent XSS attacks), internationalisation and ease of template maintenance. The templates are valid XML documents and can be rendered directly in a web browser without needing to be parsed through the templating engine.// 
-  * Support for mobile devices screen sizes (iPhone/Android/Windows Phone 7).+ 
 +===== CSS ===== 
 +  * The only method allowed for including CSS styling is via including an external CSS stylesheet in the <head> of the document. 
 +  * Do use fluid layout 
 +  * Do use css styles to make adjustments for browser widths 
 +    * Investigate media queries for determining width 
 +  * Do support a print stylesheet which emphasizes legibility, clarity and efficient printing 
 +  * Do support mobile devices screen sizes (iPhone/Android/Windows Phone 7)
     * Must be optional     * Must be optional
     * Must support screen rotation     * Must support screen rotation
     * Must not require a separate url     * Must not require a separate url
-  * Split layout and colour/text into different stylesheets. The layout stylesheet would control the layout of components on the screen (positions, widths, heights, etc) whereas the colour/text stylesheet would control the branding of MantisBT. This could make it easier for people to rebrand MantisBT as they won't need to worry about breaking layout CSS to change colours and text effects on their MantisBT install+  * Do design stylesheets with rebranding in mind so that users may change colours and text effects without breaking the layouts 
-    Investigate media queries to determine width +  * Do not use inline CSS styling in any HTML output
-  * Use a fluid layout+  Do not use html style attributes 
 +  * Do not use inline <style>..</style> blocks in the body
  
-====== Javascript ====== +===== Javascript ===== 
-  * The only method allowed for including Javascript is via including an external script file in the <head> of the document. +  * The only method allowed for including Javascript is via including an external script file in the <head> of the document //(or by placing all script tags just before the body closing tag as this seems to be the standard now)// 
-  * The pages should be able to function without Javascript enabled. If Javascript is available then it can be used to replace parts of the DOM with more advanced functionality (in the same way jQuery UI operates). +  * The pages must be able to fully function without Javascript enabled. If Javascript is available then it can be used to replace parts of the DOM with more advanced functionality (in the same way jQuery UI operates) 
-  * jQuery should be used exclusively for any Javascript-based features so that we don't have a huge mismatch of various frameworks and libraries to maintain in the future. jQuery plugins are OK to use (there are plenty of them) but we should at least try to opt for plugins that have high rates of usage and are under active and healthy development.+  * Use jQuery exclusively for any javascript based features 
 +  * Use only jQuery plugins with high rates of usage and activehealthy development 
 +  * Do not use inline Javascript in any HTML output 
 +    * No onclick, onmouseover, etc. attributes 
 +    * No inline <script..>something();</script> blocks 
 +    * Do not use javascript:something() in hyperlink hrefs.
  
-====== Accessibility ====== +===== Accessibility and Localization ===== 
-  * Look at supporting right-to-left (RLT) in the redesign for languages that require this functionality.+  * Maintain support for right-to-left (RLT) languages in the redesign (related to CSS)
   * Investigate accessibility concerns in depth to determine how the pages will work in screen readers, on browsers with extra large font sizes, for colour blind users, etc.   * Investigate accessibility concerns in depth to determine how the pages will work in screen readers, on browsers with extra large font sizes, for colour blind users, etc.
  
-====== User Interface ====== +===== User Interface ===== 
-  * Avoid dumbing down the interface to cater for computer illiterate users (and making the interface look pretty) at the expense of making life hard for "power users"Power users are those who are attached to MantisBT for many hours of the day triaging issues, scheduling work, creating reports, etc and they desire the most efficient workflow possible. Having to find functionality that has been hidden away behind multiple mouse clicks is going to frustrate them. +  * Don't make life hard for power users.  Clean up the interface but keep the functionality readily accessible 
 +  * Workflow must be as efficient as possible
  
-====== Questions for discussion ======+ 
 +===== Questions for discussion =====
   - App Mode -- several browsers are now supporting App Mode, do we have any requirements for that?  Are there standards around this?   - App Mode -- several browsers are now supporting App Mode, do we have any requirements for that?  Are there standards around this?
   - Any requirements to have MantisBT grease monkey friendly to allow users to easily customize the page?  Not sure what that means, does it mean naming fields? divs, etc?   - Any requirements to have MantisBT grease monkey friendly to allow users to easily customize the page?  Not sure what that means, does it mean naming fields? divs, etc?
   - Supported browsers / versions?  What is the cut off?   - Supported browsers / versions?  What is the cut off?
 +    - Firefox 3.0+
 +    - Recent versions of Opera, Chromium, Konqueror, Safari (should almost come for free from I)
 +    - IE7+
 +    - IE6 support, if needed, can come through community contributions
   - Come to some sort of arrangement on how plugins will manipulate the HTML to insert their own buttons, widgets, etc as required.   - Come to some sort of arrangement on how plugins will manipulate the HTML to insert their own buttons, widgets, etc as required.
- + 
mantisbt/style_guide.1287107848.txt.gz · Last modified: 2010/10/14 22:02 (external edit)