Embedded styles still have you working exclusively within the (X)HTML template, but this time
all styles are grouped together in the head of the document, as part of one element.
1. Open embedded.html in your text editor.
2. Within the <head> section of the template, just after the <title> element, paste the
following: <style type="text/css">p {color: #F00;}</style>. Again, you are using
a simple CSS declaration to render the text red.
3. Save the template, and open it in the web browser.
Notice now that the text contained within both paragraphs is red. This time around, all
paragraphs in the document are affected by the declaration, as the style is applied without
exception to all <p> tags within the page.
Pros of Embedded Styles
There are times when this method is useful, but again they are rare. Admittedly, this approach
is much better than inline CSS, as it allows you to make blanket changes to all instances of an
element rather than using duplicated inline styles. The idea of grouping all styles in one place
is much more sensible too, although as before, the actual (X)HTML document isn’t the best
place for this. Many seasoned developers will tell you that this method can be ideal during
initial testing.
Cons of Embedded Styles
Embedded styles are again loading presentational bloat into the document. Also, the styles
need to be downloaded again and again with every page load. Every page of your web site will
need its own embedded styles, and making sitewide style changes is going to be very labor
intensive (unless perhaps you pull the styles in as an include). Hey, that’s a good idea actually.
Let’s move on.
Showing posts with label styles. Show all posts
Showing posts with label styles. Show all posts
Monday, October 4, 2010
Inline Styles in Css
Inline styles make use of the style attribute applied to specific tags within the document,
where the actual style value is declared using the form name:value, or property:value, if you
want to use the correct terminology. There is a more detailed explanation of correct CSS syntax
later in the “Effective CSS Syntax” section.
1. Open inline.html in your text editor.
2. Find the first opening paragraph tag <p>.
3. Replace the <p> with <p style="color: #F00"> and save the template. This very simple
declaration will ensure that the paragraph text will be red.
Notice now that the text contained within that paragraph will be red. Only that paragraph
is affected, and the second paragraph defaults to black. This method can be applied to any
(X)HTML element within the <body> of the page.
Pros of Inline Styles
There are times when this method is useful, but these times are few and far between. You’ve
just learned how to make a paragraph red using CSS—that was useful, right? This method
might also be useful for testing out simple CSS examples within this book. However, I think it
best to skip to the “Cons of Inline Styles” paragraph rather than seek poor justification for
inline CSS—as you’ll soon find out when you have a bit more experience, it’s not a good idea
generally.
Cons of Inline Styles
Your (X)HTML should always be as presentation-free as possible. Peppering your code with
inline styles is going to weigh the page down significantly. As if that were not reason enough,
imagine having to declare the styles for every paragraph, every link, every header, and so on. To
further scare you off, consider redesigning a site containing hundreds of pages where inline styles
litter the markup. You’d have to go into every page and change each CSS property individually—
not good.
where the actual style value is declared using the form name:value, or property:value, if you
want to use the correct terminology. There is a more detailed explanation of correct CSS syntax
later in the “Effective CSS Syntax” section.
1. Open inline.html in your text editor.
2. Find the first opening paragraph tag <p>.
3. Replace the <p> with <p style="color: #F00"> and save the template. This very simple
declaration will ensure that the paragraph text will be red.
Notice now that the text contained within that paragraph will be red. Only that paragraph
is affected, and the second paragraph defaults to black. This method can be applied to any
(X)HTML element within the <body> of the page.
Pros of Inline Styles
There are times when this method is useful, but these times are few and far between. You’ve
just learned how to make a paragraph red using CSS—that was useful, right? This method
might also be useful for testing out simple CSS examples within this book. However, I think it
best to skip to the “Cons of Inline Styles” paragraph rather than seek poor justification for
inline CSS—as you’ll soon find out when you have a bit more experience, it’s not a good idea
generally.
Cons of Inline Styles
Your (X)HTML should always be as presentation-free as possible. Peppering your code with
inline styles is going to weigh the page down significantly. As if that were not reason enough,
imagine having to declare the styles for every paragraph, every link, every header, and so on. To
further scare you off, consider redesigning a site containing hundreds of pages where inline styles
litter the markup. You’d have to go into every page and change each CSS property individually—
not good.
Wednesday, September 29, 2010
Adding styles to forms
Form fields can be styled, enabling you to get away from the rather clunky default look
offered by most browsers. Although the default appearance isn’t very attractive, it does
make obvious which elements are fields and which are buttons. Therefore, if you choose
to style forms in CSS, ensure that the elements are still easy to make out.
A simple, elegant style to apply to text input fields and text areas is as follows:
.formField {
border: 1px solid #333333;
background-color: #dddddd;
padding: 2px;
}
In HTML, you need to add the usual class attribute to apply this rule to the relevant element(
s):
<input class="formField" tabindex="11" type="text" id="realname"
å name="realname" size="30" />
This replaces the default 3D border with a solid, dark gray border, and it also sets the
background color as a light gray, thereby drawing attention to the form input fields. Note
that browsers that support :hover and :focus on more than just anchors can have these
states styled with different backgrounds, thereby providing further prompts. For example,
upon focusing a form field, you might change its background color, making it more obvious
that it’s the field in focus.
Because the border in the previous code is defined using a class, it can be applied to multiple
elements. The reason we don’t use a tag selector and apply this style to all input fields
is that radio buttons and check boxes look terrible with rectangular borders around them.
However, applying this style to the select element can work well.
Note that the background color in this example is designed to contrast slightly with the
page’s background color, but still provide plenty of contrast with any text typed into the
form fields; as always, pick your colors carefully when working with form styles.
The default Submit button style can be amended in a similar fashion, and padding can also
be applied to it. This is usually a good idea because it enables the button to stand out and
draws attention to the text within. Should you desire a more styled Submit button, you can instead use an image:
<input type ="image" src="submit.gif" height="20" width="100"
å alt="Submit form" />
Along with the fields and controls, it’s also possible to style the elements added in the previous
section “The label, fieldset, and legend elements.” The fieldset rule applies a
1-pixel dashed line around the elements grouped by the fieldset element, along with
adding some padding and a bottom margin. The legend rule amends the legend element’s
font and the padding around it, and sets the text to uppercase; it also adds a background
color so that the dotted line of the fieldset won’t be shown behind the legend text in
Internet Explorer. Note that not all browsers treat margins on legend elements in the same
way, so if you add a margin value, be sure to thoroughly test your page. The screenshot
that follows also includes the styles included in the default CSS document from the
basic-boilerplates folder.
fieldset {
border: 1px dashed #555555;
padding: 10px;
margin-bottom: 10px;
}
legend {
padding: 0 10px;
font-family: Arial, Helvetica, sans-serif;
color: #000000;
background: #ffffff;
text-transform: uppercase;
}
A final style point worth bearing in mind is that you can define styles for the form itself.
This can be useful for positioning purposes (e.g., controlling the form’s width and its bottom
margin); the width setting can prove handy, since the fieldset border stretches to
the entire window width, which looks very odd if the form labels and controls take up only
a small area of the browser window. Reducing the form’s width to specifically defined
dimensions enables you to get around this. Alternatively, you can set a fixed width on the
fieldset itself (or float it, enabling you to display fieldsets side by side.
You can also color the form’s (or fieldset’s) background in addition to or instead of the
input fields, thereby making the entire form prominent. This is a device I’ve used on various
versions of the Snub Communications website’s contacts page, as shown in the following
screenshot.
Regardless of the form styles you end up using, be sure to rigorously test across browsers,
because the display of form elements is not consistent. Some variations are relatively
minor—you’ll find that defining values for font sizes, padding, and borders for input fields
doesn’t always result in fields of the same height, and that text fields and Submit buttons
don’t always align. A more dramatic difference is seen in versions of Safari prior to 3.0,
which ignore many CSS properties for forms, instead using the Mac OS X “Aqua” look and
feel—see the following screenshot for how the Snub Communications form looks in that
browser. Form functionality is not affected by this, but layouts can be.
offered by most browsers. Although the default appearance isn’t very attractive, it does
make obvious which elements are fields and which are buttons. Therefore, if you choose
to style forms in CSS, ensure that the elements are still easy to make out.
A simple, elegant style to apply to text input fields and text areas is as follows:
.formField {
border: 1px solid #333333;
background-color: #dddddd;
padding: 2px;
}
In HTML, you need to add the usual class attribute to apply this rule to the relevant element(
s):
<input class="formField" tabindex="11" type="text" id="realname"
å name="realname" size="30" />
This replaces the default 3D border with a solid, dark gray border, and it also sets the
background color as a light gray, thereby drawing attention to the form input fields. Note
that browsers that support :hover and :focus on more than just anchors can have these
states styled with different backgrounds, thereby providing further prompts. For example,
upon focusing a form field, you might change its background color, making it more obvious
that it’s the field in focus.
Because the border in the previous code is defined using a class, it can be applied to multiple
elements. The reason we don’t use a tag selector and apply this style to all input fields
is that radio buttons and check boxes look terrible with rectangular borders around them.
However, applying this style to the select element can work well.
Note that the background color in this example is designed to contrast slightly with the
page’s background color, but still provide plenty of contrast with any text typed into the
form fields; as always, pick your colors carefully when working with form styles.
The default Submit button style can be amended in a similar fashion, and padding can also
be applied to it. This is usually a good idea because it enables the button to stand out and
draws attention to the text within. Should you desire a more styled Submit button, you can instead use an image:
<input type ="image" src="submit.gif" height="20" width="100"
å alt="Submit form" />
Along with the fields and controls, it’s also possible to style the elements added in the previous
section “The label, fieldset, and legend elements.” The fieldset rule applies a
1-pixel dashed line around the elements grouped by the fieldset element, along with
adding some padding and a bottom margin. The legend rule amends the legend element’s
font and the padding around it, and sets the text to uppercase; it also adds a background
color so that the dotted line of the fieldset won’t be shown behind the legend text in
Internet Explorer. Note that not all browsers treat margins on legend elements in the same
way, so if you add a margin value, be sure to thoroughly test your page. The screenshot
that follows also includes the styles included in the default CSS document from the
basic-boilerplates folder.
fieldset {
border: 1px dashed #555555;
padding: 10px;
margin-bottom: 10px;
}
legend {
padding: 0 10px;
font-family: Arial, Helvetica, sans-serif;
color: #000000;
background: #ffffff;
text-transform: uppercase;
}
A final style point worth bearing in mind is that you can define styles for the form itself.
This can be useful for positioning purposes (e.g., controlling the form’s width and its bottom
margin); the width setting can prove handy, since the fieldset border stretches to
the entire window width, which looks very odd if the form labels and controls take up only
a small area of the browser window. Reducing the form’s width to specifically defined
dimensions enables you to get around this. Alternatively, you can set a fixed width on the
fieldset itself (or float it, enabling you to display fieldsets side by side.
You can also color the form’s (or fieldset’s) background in addition to or instead of the
input fields, thereby making the entire form prominent. This is a device I’ve used on various
versions of the Snub Communications website’s contacts page, as shown in the following
screenshot.
Regardless of the form styles you end up using, be sure to rigorously test across browsers,
because the display of form elements is not consistent. Some variations are relatively
minor—you’ll find that defining values for font sizes, padding, and borders for input fields
doesn’t always result in fields of the same height, and that text fields and Submit buttons
don’t always align. A more dramatic difference is seen in versions of Safari prior to 3.0,
which ignore many CSS properties for forms, instead using the Mac OS X “Aqua” look and
feel—see the following screenshot for how the Snub Communications form looks in that
browser. Form functionality is not affected by this, but layouts can be.
Sunday, September 26, 2010
Editing link styles using CSS
Along with changing link colors, CSS enables you to style links just like any other piece of
text. You can define specific fonts; edit padding, margins, and borders; change the fontweight and style; and also amend the standard link underline, removing it entirely if you
wish (by setting the text-decoration property to none).
a:link {
color: #3366cc;
font-weight: bold;
text-decoration: none;
}
Removing the standard underline is somewhat controversial, even in these enlightened
times, and causes endless (and rather tedious) arguments among web designers. My view
is that it can be OK to do so, but with some caveats.
If you remove the standard underline, ensure your links stand out from the surrounding
copy in some other way. Having your links in the same style and color as other words and
not underlined is a very bad idea. The only exception is if you don’t want users to easily
find the links and click them (perhaps for a children’s game or educational site).
A common device used by web designers is to recolor links, in order to distinguish them
from body copy. However, this may not be enough (depending on the chosen colors),
because a significant proportion of the population has some form of color blindness. A
commonly quoted figure for color blindness in Western countries is 8%, with the largest
affected group being white males (the worldwide figure is lower, at approximately 4%).
Therefore, a change of color (to something fairly obvious) and a change of font weight to
bold often does the trick.
Whatever your choice, be consistent—don’t have links change style on different pages of
the site. Also, it’s useful to reinforce the fact that links are links by bringing back the
underline on the hover state. An example of this is shown to the right (see editing-linkstyles-
using-css.html and editing-link-styles-using-css.html in the chapter 5
folder of the completed files).
text. You can define specific fonts; edit padding, margins, and borders; change the fontweight and style; and also amend the standard link underline, removing it entirely if you
wish (by setting the text-decoration property to none).
a:link {
color: #3366cc;
font-weight: bold;
text-decoration: none;
}
Removing the standard underline is somewhat controversial, even in these enlightened
times, and causes endless (and rather tedious) arguments among web designers. My view
is that it can be OK to do so, but with some caveats.
If you remove the standard underline, ensure your links stand out from the surrounding
copy in some other way. Having your links in the same style and color as other words and
not underlined is a very bad idea. The only exception is if you don’t want users to easily
find the links and click them (perhaps for a children’s game or educational site).
A common device used by web designers is to recolor links, in order to distinguish them
from body copy. However, this may not be enough (depending on the chosen colors),
because a significant proportion of the population has some form of color blindness. A
commonly quoted figure for color blindness in Western countries is 8%, with the largest
affected group being white males (the worldwide figure is lower, at approximately 4%).
Therefore, a change of color (to something fairly obvious) and a change of font weight to
bold often does the trick.
Whatever your choice, be consistent—don’t have links change style on different pages of
the site. Also, it’s useful to reinforce the fact that links are links by bringing back the
underline on the hover state. An example of this is shown to the right (see editing-linkstyles-
using-css.html and editing-link-styles-using-css.html in the chapter 5
folder of the completed files).
Links are bold and orange, making them stand out from surrounding text. On the hover
state, the link darkens to red and the standard underline returns. The second of those
things is achieved by setting text-decoration to underline in the a:hover declaration.
Note that even when presented in grayscale, such as in this book, these two states can be
distinguished from surrounding text.
state, the link darkens to red and the standard underline returns. The second of those
things is achieved by setting text-decoration to underline in the a:hover declaration.
Note that even when presented in grayscale, such as in this book, these two states can be
distinguished from surrounding text.
You can also combine pseudo-classes. For example, if you add the rules shown following
to a style sheet (these are from the editing-link-styles-using-css documents), you’d
have links going gray when visited, but turning red on the hover state (along with showing
the underline). Note that because the link and visited states are exclusive, the bold
value for font-weight is assigned using the grouped selector. It could also be applied to
individual rules, but this is neater.
a:link, a:visited {
font-weight: bold;
}
a:link {
color: #f26522;
text-decoration: none;
}
a:visited {
color: #8a8a8a;
}
a:hover {
color: #f22222;
text-decoration: underline;
}
a:active {
color: #000000;
text-decoration: underline;
}
If you decided that you wanted visited links to retain their visited color on the hover
state, you could add the following rule:
a:visited:hover {
color: #8a8a8a;
}
to a style sheet (these are from the editing-link-styles-using-css documents), you’d
have links going gray when visited, but turning red on the hover state (along with showing
the underline). Note that because the link and visited states are exclusive, the bold
value for font-weight is assigned using the grouped selector. It could also be applied to
individual rules, but this is neater.
a:link, a:visited {
font-weight: bold;
}
a:link {
color: #f26522;
text-decoration: none;
}
a:visited {
color: #8a8a8a;
}
a:hover {
color: #f22222;
text-decoration: underline;
}
a:active {
color: #000000;
text-decoration: underline;
}
If you decided that you wanted visited links to retain their visited color on the hover
state, you could add the following rule:
a:visited:hover {
color: #8a8a8a;
}
Subscribe to:
Posts (Atom)