Friday 15th of December 2017 08:49:39 PM

CSS Style Guide

XHTML and CSS Validation

Before publishing any XHTML page on the library’s server, you must be certain that it contains only W3C-approved tags and properly authored Style Sheets. The process of Kosherizing your XHTML and CSS is known as validation.

Free online tools

Free online tools make validation easy. Just follow these steps:

  1. Upload your page to the library’s server but do not yet link to it externally.
  2. Visit the W3C Validator (or the HTML Help Validator maintained by the Web Design Group).
  3. Type the URL of the web page you just uploaded into the forms at either of these services.
  4. Wait a few seconds while the validator examines your page.
  5. Fix any errors offline, upload the corrected page, and try again.
  6. Be sure to validate your CSS as well and correct errors (if any).
  7. When all documents validate, you may link to your page from the library’s site. (If you are unable to understand or correct your errors, see the Web Coordinator.)

Validation takes getting used to, but soon the process will become second nature. Essentially it is like receiving the consulting services of a world-class HTML and CSS expert for free.

Understanding Validator Error Messages

Note that the Validators’ error-reporting can be confusing. Sometimes an error in one part of the markup gets reported as an error further down.

For instance, if the validator is coughing on a paragraph tag, and the tag appears to be written correctly, check the markup preceding the paragraph tag. Higher up on the page, you may have forgotten to include a closing quotation mark at the end of a link, or you may have neglected to end an IMAGE tag with a a closing forward slash (/). For some reason, the Validator catches these errors, but reports them incorrectly.

One-click validation

If you tire of typing the validation service URLs, you can install free validation "bookmarklets" in your browser’s Favorites bar courtesy of David Lindquist, an independent web developer.

« XHTML Section Index | Cascading Style Sheets »

Only three of these seven properties can be set to auto: the width of the element's content, and the left and right margins. The left and right padding and borders must be set to specific values, or else they default to a width of zero (again, assuming no border-style is declared; if one has been set, then the width of the borders is set to be the vaguely defined value medium ). Figure 8-10 provides a handy illustration for remembering which parts of the box can take a value of auto, and which cannot.

want the floated elements from one section hanging down into the next. In that case, you'd want to set the first element of each section to prohibit floating elements from appearing next to it. If it might otherwise be placed next to a floated element, it will be pushed down until it appears below the floated image, and all subsequent content will appear after that, as shown in Figure 7-73.

Figure 7-73

Figure 7-73. Displaying an element in the clear

This is done with clear.



When it comes right down to it, the extension isn't actuallythe important part. What matters is the MIME type the server useswhen sending a file. However, since the vast majority of web serversuse a file's extension to decide which MIME type to use whensending the file, it obviously becomes important to have a friendlyserver configuration.

within, not of the visual effect you're trying to achieve at the moment. For example, let's say that we want the dark blue color to be applied to all H2 elements that are subsection headings. It would be much better to pick a class name like subsec or even sub-section. Both of these names have the advantage of actually meaning something -- and, furthermore, of being independent of any presentational concepts. After all, you might decide later to make all subsection titles dark red instead of dark blue, and the statement H2.dkblue {color:the course of wrapping text so that it fits inside the browser's window, for example, or inside a parent element. The only effect margins have on line-breaking is that, by causing extra space to appear within the line, they can move content over. This may cause a line to break at a different spot than it ordinarily would have.

Turn to Figure 7-25 to see what happens when an inline element with a margin is displayed across multiple lines: