How to use CSS in a HTML document

We are much aware what is CSS, and it’s uses in previous blogs, Now Let’s try to understand How to use CSS or Style sheet in a HTML document. CSS present the good presentation in a document and Web page or App.
We can use Style sheet using three methods:
·        We can use an external style sheet, either by importing it or by linking to it.(External Style Sheet)
·        Directly embed a document-wide style in the head element of the document. (Document – Wide Style)
·        Set an inline style rule using the style attribute directly on an element. (Inline Style)
Each of these style sheet approaches has its own pros and cons, as listed below:

   Now let’s some work using all three method

1.       External Style Sheet: An external style sheet is simply a plain text file containing CSS style   
Rules. The common file extension .css indicates that the document provides style sheet information. As an example, the following CSS rules can be found in a file called sitestyle.css, which defines a style sheet used site-wide:
After above sheet we will work with HTML doc…
So now we are done with both files Let’s see the Output:
CSS is, at least theoretically, not the only style technology we could use, though as it stands, by default, most browsers assume that CSS is being used. We set type to be specific but that may get a bit redundant. The HTML specification suggests you can set a default style sheet language in the head element of the document by using the <meta> tag, as
shown here,
<meta http-equiv=”Content-Style-Type” content=”text/css”>
by outputting this value in the HTTP headers delivered to a site. Interestingly, many sites
set the <meta> tag and use the type attribute, which is particularly appropriate as of this
edition’s publication as the specification dictates that the type attribute must be set and
thus the W3C validator will complain if the attribute is not set regardless of the appearance
of the <meta> tag.
2.      Embedding Style Sheets: The second way to include a style sheet is to embed it. When you embed a style sheet, you generally write the style rules directly within the document with a <style> tag found within the <head> </head> of the document.
The basic syntax of the <style> tag is as follows:
<style type=”text/css” media=”all | print | screen” >
* Style Rules….*
</style>
Now let’s do an Example:



You can have multiple occurrences of the style element within the head of the document, and you can even import some styles with these elements.
OutPut for the above code:

While this technique is common practice and used for script masking as well, there are some subtle issues, particularly when including non-comment-friendly content like multiple dashes or trying to address XML strictness. (McGraw-Hill CSS)
3.      Inline Styles:  Instead of using a style sheet for a whole page, you can add style information directly within a single element. Suppose you want to set one particular <h1> tag to render in extra-large, green, Arial font. You could quickly apply the style to only the tag in question using its style attribute, which is a core attribute common to nearly any HTML element.
As an example, the following markup shows an inline style applied to a heading:
<h1 style=”font-size: xx-large; font-family: Arial; color: green;”>
This sort of style information doesn’t need to be hidden from a browser that isn’t style sheet-aware, because browsers ignore any attributes that they don’t understand.
Although using inline styles seems to be an easy route to using CSS, it does have a number of drawbacks. The largest problem is that inline rules are bound very closely to a tag. If you want to affect more than one <h1> tag, you have to copy and paste the style attribute into every other heading of interest. The separation of markup from CSS presentation is not optimal with an inline style. However, for quick and dirty application of CSS rules, this might be appropriate, particularly for testing things out.
The second and lesser-known concern with inline CSS rules is that you simply cannot perform every task with them. For example, if you want to change the look of various link states, this is easily accomplished in a document-wide or linked style sheet with pseudo-class rules like
a:link {color: blue; text-decoration: none;}
a:visited {color: red; text-decoration: none;}
a:hover {color: red; text-decoration: underline;}
a:active {color: red; text-decoration: none;}
However, if you attempt to put such rules in an <a> tag, how are other states indicated? The simple example here would appear to set the color to blue for any state:
<a href=”http://www.w3.org” style=”color: blue;”>Inline Link Styles?</a>
Similarly, in order to change the first letter of a paragraph to large, red text, you might use a pseudo-element rule like
 p:first-letter {color: red; font-size: xx-large;}
However, when you attempt to do this inline, you are forced to introduce an element to hold the first letter:
<p><span style=”color: red; font-size: xx-large;”>T</span>his is a test.</p>
While these examples indicate why these selectors were given the names pseudo-class and pseudo-element, they don’t really show us how to use such inline styles.
<a href=”http://www.w3.org/”
style=”{text-decoration: none;}
:link {color: blue;}
:visited {color: red;}
:hover {color: red; text-decoration: underline;}
:active {color: red;}”>Inline Link Styles?</a>
To set the first letter on paragraphs, we would use:
<p style=”{text-indent: 1em;
text-align: justify;
line-height: 150%;}
:first-letter {color: red; font-size: xx-large;}”>
This is the set of <p></p>
The emerging specification even suggested the importation of style sheets directly inline:
<div id=”navbar” style=”@import url(navigationstyles.css);”>just an example</div>
While all these ideas are quite interesting, more than seven years after the working draft was authored, not a single browser supports this syntax at the time this edition is being completed. So, besides being too closely bound to tags, understand that unless this situation has changed by the time you read this edition, only using inline styles is going to limit your application of some of the more useful CSS selectors. (Reference McGrill CSS)
These were some methods for using CSS, there are many other methods for using CSS but includes above three parent methods.  So for more Stay tune for next blogs mean while keep doing your coding work with different examples.
Do more exercises and ping back your problems.

Let’s know about CSS Error Handling

Sorry writing this blog after very long time, Yet this is not my original I was reading about Error handling in google and find some important points, which are presented here, We know the use of syntactically correct markup is certainly not encouraged by permissive browser parsers that correct mistakes or guess intent when faced with malformed markup. The situation for CSS is a bit better, and the CSS 2.1 specification does describe what browsers should do in the case of various errors, but then again, making the assumption that browsers are not permissive and correctly implement all aspects of Web specifications is dangerous.
Unknown Properties
If an unknown property is encountered, a CSS-conforming user agent should ignore the declaration. Given
h1 {color: red; trouble: right-here;}
the property trouble would simply be ignored and the rule would simply set the color. It does not matter what the position of the bogus property declaration is, the result should be the same as long as the declaration is otherwise well formed.
h1 {trouble: right-here; color: red;}
The case is obviously different if the various separators are missing.
Malformed Rules
In the case where semicolons (;), colons (:), quotes (‘or”), or curly braces ( { } ) are misused, a browser should try to handle any unexpected characters and read the properties until a matching value can be found. As an example, consider the simple case of forgetting a semicolon:
h1 {color: red text-decoration: underline; font-style: italic;}
In this case, we should see the browser continue to parse the value of color as “red text decoration: underline” before it sees a closing semicolon. The font-style property that follows would then be used. Because the color property has an illegal value, it should be ignored.
Other cases are a bit more obvious. For example, here we see the colon missing in a style rule declaration:
h1 {color red; text-decoration: underline; font-style: italic;}
In this case, the color property is simply ignored and the text is underlined and italic.
The situation for quotes and braces is the same, with compliant browsers working to find a matching closing character for any open construct, potentially destroying anything in between. Consider this set of rules, where quite a large amount of style may be lost:
h1 {color: green; font-family: “Super Font;}
h2 {color: orange;}
h3 {color: blue; font-family: “Duper Font”;}
Be careful, though, because in this case you might assume that the rule closes off with a quote, but that may introduce more open construct errors later on in the style sheet.
Unclosed Structures and End of File :
A CSS browser should close all braces and quotes when it reaches the end of a style sheet. While quite permissive, this would suggest that
<style type=”text/css”>
h1 {color: green
</style>
should render properly, as the open rule would be closed automatically by the end of the style sheet. Open quotes would also be closed in a similar manner when the end of the style sheet is reached. Testing reveals this action is actually the case in browsers, but creating a syntactically correct style sheet is obviously far superior than understanding the expected failures of a conformant browser.
Illegal or Unknown Property Values
CSS-conforming browsers must ignore a declaration with an illegal value. For example,
h1 {font-size: microscopic; color: red;}
would simply not set the font-size value but h1 elements would be red. Usage of illegal characters can turn what would appear to be a correct value into an incorrect one. For example,
h1 {color: green;}
is incorrect not because green is an illegal color, but because it is not the same as the keyword green when it is quoted.
Do not assume that a CSS-compliant browser will fix such small oversights. For example, a browser given
h1 {color: green forest;}
should not use green but instead ignore the whole rule. Of course, what browser vendors actually do in the face of malformed Web documents varies.
Incorrect @ Keywords and Media Values:
When an @ media value or media type for a <style> tag is used, incorrect values should be ignored. For example, if you specify <style type=”text/css” media=”tri-corder”>, the browser is supposed to ignore the entire <style> block unless it understands such an odd type. Media types will be discussed in depth later, but for now understand that when faced with syntax problems, a CSS-compliant browser should simply ignore anything related to misunderstood values.
Ignoring Network Failures
When style sheets are linked rather than placed within the page, the browser must apply all
types it is able to fetch and simply ignore those it can’t. So if you had
<link rel=”stylesheet” href=”global.css” type=”text/css”>
<link rel=”stylesheet” href=”pagelevel.css” type=”text/css”>

and the first was fetched by the browser, but the second failed, it would simply apply the rules it had. Obviously, such transitory errors are hard to account for, but other considerations presented in this section should have been caught in the validation of markup and style, discussed next.