Showing posts with label css. Show all posts
Showing posts with label css. Show all posts

Monday, April 27, 2009

divitus classitus

In the book of CSS Mastery: Advanced Web Standards Solutions, there is a section about divitus and classitus.

Using too many divs is often described as divitus and is usually a sign that your code is poorly structured and overly complicated. Some people new to CSS will try to replicate their old table structure using divs. But this is just swapping one set of extraneous tags for another. Instead, divs should be used to group related items based on their meaning or function rather than their presentation or layout.

The root reason of this phenomenon is that designer tend to rush to see the result first, and forget the semantic of the content(the markup) express. My experience is that the a clean markup with strong semantic is a good document. A good document is starting point of good design. A good design is easy to be restyled and extended. Most of visual style can be implemented by CSS of current version. If it can not satisfying your requirements, we can wait for next generation (CSS 3 or CSS 4?). But before they are available, we can use javascript implement your advanced design needs. But the bottom line is to forget about style, when you authorize your markup, and always remember make your markup semantic, which means your document is still understandable even it is opened in notepad or lynx.

Semantic and style , they are different concern. While some developers and visual designer understand the rule of separation of concern, but web technology (like asp.net server controls, Web form) tend to make people deviate from it. Although it is not the fault of these technology, in fact, you can use these technology to achieve very semantic markup, but they tend to lure people to mix them together. ASP.NET MVC is trying to fix this.

Below is example of divitus classitus.

<div class="login_page"> <div class="login_header"> Registration</div> <div class="clear"> &nbsp;</div> <div class="clear"> &nbsp;</div> <!--FORM FIELD--> <div class="reg_form"> <div class="reg_title"> <div class="reg_txt"> First name:</div> </div> <div class="reg_box"> <input type="text" size="50" /> </div> </div> <!--FORM FIELD--> <div class="reg_form"> <div class="reg_title"> <div class="reg_txt"> Last name:</div> </div> <div class="reg_box"> <input type="text" size="50" /> </div> </div> <!--FORM FIELD--> <div class="reg_form"> <div class="reg_title"> <div class="reg_txt"> Email address:</div> </div> <div class="reg_box"> <input type="text" size="50" /> </div> </div> <!--FORM FIELD--> <div class="reg_form"> <div class="reg_title"> <div class="reg_txt"> Password:</div> </div> <div class="reg_box"> <input type="text" size="50" /> </div> </div> <!--FORM FIELD--> <div class="reg_form"> <div class="reg_title"> <div class="reg_txt"> Password Confirmation:</div> </div> <div class="reg_box"> <input type="text" size="50" /> </div> </div> <!--FORM FIELD--> <div class="reg_form"> <div class="reg_title"> <div class="reg_txt"> Company / Access code:</div> </div> <div class="reg_box"> <input type="text" size="50" /> </div> </div> <!--FORM FIELD--> <div class="reg_form"> <div class="reg_title"> <div class="reg_txt"> &nbsp;</div> </div> <div class="reg_box"> <a href="#"> <img src="images/btn_submit.jpg" border="0" /></a> </div> </div> </div>

Here is restructure markup

<div id="membership"> <fieldset> <legend>Login</legend> <p> <label for="txtUserName"> Email Address </label> <input type="text" id="txtUserName" name="txtUserName" /> </p> <p> <label for=""> Password</label> <input type="password" id="txtPassword" name="txtPassword" /> </p> <p> <label for=""> Remember me</label> <input type="checkbox" id="chkRememberMe" name="chkRememberMe" /></p> <p> <input type="submit" id="btnSubmit" name="btnSubmit" /> <a href="registration.aspx">First time here?</a> <a href="ForgetPassword.aspx">Forgot your password?</a> </p> </fieldset> </div>

Saturday, April 4, 2009

Overflow

This property is used to control the behavior of container in which its content expend over its content area. It is not used to control the behavior of container of the container of the content. Normally overflow will not happen because the container of content can expend vertically or horizontally. For text content is non-replaced elements, overflow horizontally will not happen because it can be wrapped into next line. But overflow overcritical y is possible. But for Replaced Elements it can overflow horizontally.

Horizontal Formating of block element

The "seven properties" of horizontal formatting are: margin-left, border-left, padding-left, width, padding-right, border-right, and margin-right. Padding and margin is set to 0 by default. Width is set to auto. This means the block element will try expend as much as possible into its containing content space. /p>

If width is auto, whether margin-left and margin-right is set to auto or just 0 has not effect. Because either way, their computed value will be the same 0. But if width is has a value, and margine-left and margin-right is set to auto, then that margin will expand or contracted automatically. If both margin is set to auto, and the width has a value, the the content of the block will be set to horizonal center.

The Containing Block

Every element is laid out with respect to its containing block; in a very real way, the containing block is the "layout context" for an element.For an element in the normal, Western-style flow of text, the containing block is formed by the content edge of the nearest block-level, table cell, or inline-block ancestor box. You don't need to worry about inline elements since the way they are laid out doesn't depend directly on containing blocks.

vertical-align

In CSS, the vertical-align property applies only to inline elements and replaced elements such as images and form inputs. vertical-align is not an inherited property. It can be one of baseline | sub | super | top | text-top | middle | bottom | text-bottom | | | inherit. The initial value is baseline.

line-height

The line-height property refers to the distance between the baselines of lines of text rather than the size of the font, and it determines the amount by which the height of each element's box is increased or decreased. In the most basic cases, specifying line-height is a way to increase (or decrease) the vertical space between lines of text, but this is a misleadingly simple way of looking at how line-height works. line-height controls the leading, which is the extra space between lines of text above and beyond the font's size. In other words, the difference between the value of line-height and the size of the font is the leading.

When applied to a block-level element, line-height defines the minimum distance between text baselines within that element. Note that it defines a minimum, not an absolute value, and baselines of text can wind up being pushed further apart than the value of line-height

Every element in a line of text generates a content area, which is determined by the size of the font. This content area in turn generates an inline box that is, in the absence of any other factors, exactly equal to the content area. The leading generated by line-height is one of the factors that increases or decreases the height of each inline box.

To determine the leading for a given element, simply subtract the computed value of font-size from the computed value of line-height. That value is the total amount of leading. And remember, it can be a negative number. The leading is then divided in half, and each half-leading is applied to the top and bottom of the content area. The result is the inline box for that element.

As an example, let's say the font-size (and therefore the content area) is 14 pixels tall, and the line-height is computed to 18 pixels. The difference (four pixels) is divided in half, and each half is applied to the top and bottom of the content area. This creates an inline box that is 18 pixels tall, with 2 extra pixels above and below the content area. This sounds like a roundabout way to describe how line-height works, but there are excellent reasons for the description.

When the line-height is inherited by one block-level element from another, things get a bit trickier. line-height values inherit from the parent element as computed from the parent, not the child. It probably wasn't what the author had in mind:

body {font-size: 10px;} div {line-height: 1em;} /* computes to '10px' */ p {font-size: 18px;} <div> <p>This paragraph's 'font-size' is 18px, but the inherited 'line-height' value is only 10px. This may cause the lines of text to overlap each other by a small amount.</p> </div>

A solution is, instead using em, or percentage (%), simply use a number with out any unit symbol

div {line-height: 1.5;} p {font-size: 18px;} <div> <p>This paragraph's 'font-size' is 18px, and since the 'line-height' set for the parent div is 1.5, the 'line-height' for this paragraph is 27px (18 * 1.5).</p> </div>

inherit

There is one keyword that is shared by all properties in CSS2.1: inherit. inherit makes the value of a property the same as the value of its parent element. In most cases, you don't need to specify inheritance, since most properties inherit naturally; however, inherit can still be very useful.

For example, consider the following styles and markup:

#toolbar {background: blue; color: white;} <div id="toolbar"> <a href="one.html">One</a> | <a href="two.html">Two</a> | <a href="three.html">Three</a> </div> </code>

The div itself will have a blue background and a white foreground, but the links will be styled according to the browser's preference settings. They'll most likely end up as blue text on a blue background, with white vertical bars between them.

You could write a rule that explicitly sets the links in the "toolbar" to be white, but you can make things a little more robust by using inherit. You simply add the following rule to the style sheet:

#toolbar a {color: inherit;}

This will cause the links to use the inherited value of color in place of the user agent's default styles. Ordinarily, directly assigned styles override inherited styles, but inherit can reverse that behavior.

Pixel in CSS

CSS2 recommended 90ppi as the reference pixel, but CSS2.1 recommends 96ppia measurement common to Windows machines and adopted by modern Macintosh browsers such as Safari. This means when I display 96 pixel in my screen, it should be 1 inch length in physics. But if my screen is about 110ppi, so 1 inch in css is going to less than 1 inch in my scree. But how about printer, it normally print 600ppi. It actually first convert pixel in screen to inch in scree, then print the length in inch in printer, and print the pixel by timing 600ppi to length in inch.

Unit in css

All length units can be expressed as either positive or negative numbers followed by a label (although some properties will accept only positive numbers). You can also use real numbersthat is, numbers with decimal fractions, such as 10.5 or 4.561. All length units are followed by a two-letter abbreviation that represents the actual unit of length being specified, such as in (inches) or pt (points). The only exception to this rule is a length of 0 (zero), which need not be followed by a unit.

Make IE more css2.1 compliant

Check here

Wednesday, March 18, 2009

Using user style sheet to modify the style of a web site

I tried to modify the style by using user style sheet. But some of style just could not take effect. I seemingly forget the basic rule of css cascade. The cascade works in the following order of importance:

  1. User styles flagged as !important
  2. Author styles flagged as !important
  3. Author styles
  4. User styles
  5. Styles applied by the browser/user agent