From Fedora Project Wiki
(Draft of stylesheet for Fedora Infra Apps)
 
(Undo revision 249872 by Toshio (talk))
 
(4 intermediate revisions by the same user not shown)
Line 122: Line 122:
-------------------------
-------------------------
|      |                |
|      |                |
|intnavcontent       |
|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 ==
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 <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 &lt;body&gt; instead?
;id: wrapper
 
This used to wrap around all of the body.  Why not just use &lt;body&gt; 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

This page is a draft only
It is still under construction and content may change. Do not rely on the information on this page.

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

External Navigation

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


Internal Navigation

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.

Footer

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

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;
}