(Add utility classes) |
|||
(3 intermediate revisions by the same user not shown) | |||
Line 122: | Line 122: | ||
------------------------- | ------------------------- | ||
| | | | | | | | ||
|intnav | |intnav content | | ||
| | | | | | | | ||
------------------------- | ------------------------- | ||
Line 129: | Line 129: | ||
| | | | | | ||
</pre> | </pre> | ||
{{admon/note|intnav part of content|intnav is normally placed inside of content. This is due to intnav being closely associated with the application itself. It may change as the user visits new pages and otherwise is closely tied to the working of the application. Remember, though to use the classes, ids, and html tags mentioned here so that the intnav menu can be properly styled.}} | |||
== Utility classes == | == Utility classes == | ||
Line 138: | Line 140: | ||
Sometimes a page author wants to dynamically display and hide an element. Adding the class invisible to an element will set the element to <code>display: none</code> which will hide it and remove it from the page flow for rendering. | Sometimes a page author wants to dynamically display and hide an element. Adding the class invisible to an element will set the element to <code>display: none</code> which will hide it and remove it from the page flow for rendering. | ||
== Application implementation == | |||
Applications following this need to implement the classes and ids described above. They also need to place the elements onto the page in the proper places (ie: prefbar on top, followed by header, then extnav. intnav to the left side of the content area. footer below everything). To make theming work, applications should also include the ability for local sites to override the stylesheet. This means importing their stylesheets in a certain order. Do it like this: | |||
<pre> | |||
<!-- First, theme stylesheet --> | |||
<link rel="stylesheet" type="text/css" media="screen" href="${tg.url(tg.config('stylesheet.theme', '/css/theme.css'))}" /> | |||
<!-- Then, overrides specific to this app --> | |||
<link rel="stylesheet" type="text/css" media="screen" href="${tg.url('/css/raffle.css')}" /> | |||
<!-- Finally, and optionally, give sites the ability to customize even further. --> | |||
<link rel="stylesheet" type="text/css" media="screen" href="{tg.url(tg.config('stylesheet.site', '/css/site.css'))}" /> | |||
</pre> | |||
The theme css url and the site stylesheet overrides are pulled from the config file for the application which allows individual sites to customize the style as they like. For Fedora, the theme stylesheet would be set to the location of fedora-infra.css. | |||
== Things specifically removed == | == Things specifically removed == | ||
;id: wrapper This used to wrap around all of the body. Why not just use <body> instead? | ;id: wrapper | ||
This used to wrap around all of the body. Why not just use <body> instead? Possibly wrapper was used in order to have a background that boxed in the left and right sides of the screen. With current browsers that implement CSS3 we can do this with a single background tag on the body element: | |||
<pre> | |||
body { | |||
background-color: #FFFFFF, #FFFFFF; | |||
background: url("../images/border-left.png") 0 0 repeat-y scroll, url("../images/border-left.png") 100% 0 repeat-y scroll; | |||
} | |||
</pre> |
Latest revision as of 00:26, 19 August 2011
Design Guide for Fedora Infrastructure Web Applications
All Fedora Infrastructure Applications should be designed with a few common elements. These elements should share common css classes and ids to allow a common look and feel.
Menus and toolbars
Menus are represented as unordered lists. Each element in the menu is a <li>. It is recommended that the standard menus presented here stay at one or at most two levels. Menu items that are simply textual links do not need any special classes. Menuitems that are more dynamic (for instance, searchboxes, login buttons, and loginboxes) should have the class "toolitem". The <li> contains additional classes based on what they do:
- search-toolitem
- use this if they contain a widget to enter search terms.
- lang-toolitem
- Use this for a language selector box.
- login-toolitem
- Use this for something that allows a user to login.
For instance, for a button that takes the user to a login form, use:
<li class="toolitem login-toolitem">You are not logged in <form action="/accounts/login" method="POST"> <input type="submit" value="Login" class="button" /> </form> </li>
Preferences
- id
- prefbar
- id
- infobar(obsolete)
This menu is for user preferences and user-oriented information. It should include the entries for the user to login and logout of the application, information on the logged in state, language selection (if applicable), perhaps other simple preferences, and a link if needed for more complex preferences.
In the fedora stylesheet this is rendered as a single bar across the top of the page. It is best kept to a flat hierarchy (no nesting of lists).
- id
- extnav
- id
- topnav(obsolete)
The External Navigation is for items that are external to the application. For instance, links to the fedoraproject home page, documentation, instructions for joining fedora, the Fedora Account System, etc.
In the fedora stylesheet this is rendered as a single bar below the header. It is best kept to a flat hierarchy (no nesting of lists).
- id
- intnav
- id
- sidebar(obsolete)
This menu is for links internal to the application. In the fedora stylesheet, it is rendered as a menu along the side of the application. It can handle one nested level of hierarchy and still look okay:
<ul> <li>User view <ul> <li>User packages</li> <li>User friends</li> </ul> </li> <li>Package Information <ul> <li>Builds</li> <li>Updates</li> </ul> </li> </ul>
Search boxes should appear as a <li> in this menu with the class "toolitem toolitem-searchbox"
Header
- id
- header
- id
- head(obsolete):
The header area is a banner across the top of a page. It contains information to visually identify the page as being part of Fedora and/or part of a specific web application. The header is the most specified area of this design document. It may contain the following classes:
- fedora_title
- This is logo and/or text pointing for Fedora. It will normally be rendered on the left side of the header area. It should be placed on an <h1> that contains a link to a main part of the fedoraproject.org website like this:
<h1 class="fedora_logo"><a href="http://fedoraproject.org/">Fedora</a></h1>
- The fedora stylesheet will place the Fedora Logo in place of the words inside of the <a> link. The link should point to something very highlevel like fedoraproject.org, fedoraproject.org/wiki/ or another major portal page. It should not point to a portal page relevant to the app itself. For that, use the app_title class
- app_title
- This is text and logos that reference the app itself. If this contains a link, it should reference the top level of the application (not a fedorahosted page for the app, etc). Use it like this:
<h1 class="app_title"><a href="https://admin.fedoraproject.org/community/">Fedora Community</a></h1>
- Apps which don't use this should contain a link to the application's top page in their Internal Navigation Bar (for instance, "Home"). The fedora stylesheet contains a simple rendering of this that sizes the text, removes the obvious link decorations and places it so that it will render alongside a fedora_title element if present. The application is free to override this in its own stylesheet to display a logo in its place. Applications which do the latter may want to forgo using fedora_title to avoid having two competing logos in the header.
Content
- id
- content
The content area should be the central and largest area of the app. It is where the application does most of its app-specific drawing. Nothing within the content area is specified here; the content area is entirely up to the application to use.
- id
- footer
The footer is the place for links that people don't normally need but may want to access if they have a special interest in meta-information about the project or software. This includes things like copyright and license information, the software's bug tracker and source code, and links to the same.
The following classes are recognized:
- copyright
- The software copyright holders and years
- (obsolete)copy
- same as above
- license
- The license information for the software (optional)
- version
- Version information for the software (optional)
- content_copyright
- Separate copyright information for the content (optional)
- content_license
- Separate license information for the content (optional)
- content_version
- Separate version information for the content (optional)
- disclaimer
- Any boilerplate legal disclaimers
- lhost
- Host that the app is running on (optional)
- powered_by
- Powered by logos (optional)
- sponsor
- Links and logos for sponsors (optional)
- footlinks
- An
- of links. If this is used, it should be a simple list of items. It might be rendered like this::
<center>About | Fedora Project | Contact Us | Legal</center>
Layout
In the Fedora stylesheet, these elements are laid out like this:
[ <======prefsbar|] ------------------------- | | | Header|===> | | | ------------------------- [ <===|extnav|===> ] ------------------------- | | | |intnav content | | | | ------------------------- | | | <===|footer|===> | | |
Utility classes
In addition to the style elements that define how the page is put together, there are certain things that a stylesheet can define that allow web pages to create certain effects. These utilities create a presentation at a low level instead of the high level talked about above. However, they're common enough needs that adding them to a site-wide stylesheet makes sense.
Invisible elements
- class
- invisible
Sometimes a page author wants to dynamically display and hide an element. Adding the class invisible to an element will set the element to display: none
which will hide it and remove it from the page flow for rendering.
Application implementation
Applications following this need to implement the classes and ids described above. They also need to place the elements onto the page in the proper places (ie: prefbar on top, followed by header, then extnav. intnav to the left side of the content area. footer below everything). To make theming work, applications should also include the ability for local sites to override the stylesheet. This means importing their stylesheets in a certain order. Do it like this:
<!-- First, theme stylesheet --> <link rel="stylesheet" type="text/css" media="screen" href="${tg.url(tg.config('stylesheet.theme', '/css/theme.css'))}" /> <!-- Then, overrides specific to this app --> <link rel="stylesheet" type="text/css" media="screen" href="${tg.url('/css/raffle.css')}" /> <!-- Finally, and optionally, give sites the ability to customize even further. --> <link rel="stylesheet" type="text/css" media="screen" href="{tg.url(tg.config('stylesheet.site', '/css/site.css'))}" />
The theme css url and the site stylesheet overrides are pulled from the config file for the application which allows individual sites to customize the style as they like. For Fedora, the theme stylesheet would be set to the location of fedora-infra.css.
Things specifically removed
- id
- wrapper
This used to wrap around all of the body. Why not just use <body> instead? Possibly wrapper was used in order to have a background that boxed in the left and right sides of the screen. With current browsers that implement CSS3 we can do this with a single background tag on the body element:
body { background-color: #FFFFFF, #FFFFFF; background: url("../images/border-left.png") 0 0 repeat-y scroll, url("../images/border-left.png") 100% 0 repeat-y scroll; }