Total Pageviews

Wednesday, May 25, 2011

Rounded Corner Boxes the CSS3 Way

If you’ve been doing CSS for a while you’ll know that there are approximately 3,762 ways to create a rounded corner box. The simplest techniques rely on the addition of extra mark-up directly to your page, while the more complicated ones add the mark-up though DOM manipulation. While these techniques are all very interesting, they do seem somewhat of a kludge. The goal of CSS is to separate structure from presentation, yet here we are adding superfluous mark-up to our code in order to create a visual effect. The reason we are doing this is simple. CSS2.1 only allows a single background image per element.
Thankfully this looks set to change with the addition of multiple background images into the CSS3 specification. With CSS3 you’ll be able to add not one, not four, but eight background images to a single element. This means you’ll be able to create all kinds of interesting effects without the need of those additional elements.
While the CSS working group still seem to be arguing over the exact syntax, Dave Hyatt went ahead and implemented the currently suggested mechanism into Safari. The technique is fiendishly simple, and I think we’ll all be a lot better off once the W3C stop arguing over the details and allow browser vendors to get on and provide the tools we need to build better websites.
To create a CSS3 rounded corner box, simply start with your box element and apply your 4 corner images, separated by commas.

.box {
background-image: url(top-left.gif), url(top-right.gif), url(bottom-left.gif), url(bottom-right.gif);
}


We don’t want these background images to repeat, which is the normal behaviour, so lets set all their background-repeat properties to no-repeat.

.box {
background-image: url(top-left.gif), url(top-right.gif), url(bottom-left.gif), url(bottom-right.gif);
background-repeat: no-repeat, no-repeat, no-repeat, no-repeat;
}


Lastly, we need to define the positioning of each corner image.

.box {
background-image: url(top-left.gif), url(top-right.gif), url(bottom-left.gif), url(bottom-right.gif);
background-repeat: no-repeat, no-repeat, no-repeat, no-repeat;
background-position: top left, top right, bottom left, bottom right;
}


And there we have it, a simple rounded corner box with no additional mark-up.
As well as using multiple background images, CSS3 also has the ability to create rounded corners without the need of any images at all. You can do this by setting the border-radius property to your desired value as seen in the next example.

.box {
border-radius: 1.6em;
}


This technique currently works in Firefox/Camino and creates a nice, if somewhat jagged rounded corner. If you want to create a box that works in both Mozilla and WebKit based browsers, why not combine both techniques and see what happens.

Monday, May 2, 2011

Really a basic question but people don't know the reasoning?

What Is CSS?


Have you ever thought about what a web page is? I mean, what it really is? Some people think of a web page as a visual medium—an aesthetically pleasing experience which may or may not contain information that’s of interest to the viewer. Other people think of a web page as a document that may be presented to readers in an aesthetically pleasing way. From a technical point of view, the document interpretation is more appropriate.

When we examine the elements of its construction, a web document can consist of up to three layers—content, presentation, and behavior—as illustrated in Figure 1.

The content layer is always present. It comprises the information the author wishes to convey to his or her audience, and is embedded within HTML or XHTML markup that defines its structure and semantics. Most of the content on the Web today is text, but content can also be provided through images, animations, sound, video, and whatever else an author wants to publish.

The presentation layer defines how the content will appear to a human being who accesses the document in one way or another. The conventional way to view a web page is with a regular web browser, of course, but that’s only one of many possible access methods. For example, content can also be converted to synthetic speech for users who have impaired vision or reading difficulties.

Figure 1. The three layers of a web document A representation of the three layers of a web document. The first         layer is HTML or content, the second is CSS or presentation and the         third is JavaScript or behaviour.

The behavior layer involves real-time user interaction with the document. This task is normally handled by JavaScript. The interaction can be anything from a trivial validation that ensures a required field is filled in before an order form can be submitted, to sophisticated web applications that work much like ordinary desktop programs.

It’s possible to embed all three layers within the same document, but keeping them separate gives us one valuable advantage: we can modify or replace any of the layers without having to change the others.

Certain versions of HTML and XHTML also contain presentational element types—that is, elements that specify the appearance of the content, rather than structure or semantics. For example, and can be used to control the presentation of text, and


will insert a visible rule element. However, as these types of elements embed presentation-layer information within the content layer, they negate any advantage we may have gained by keeping the layers separate.

Cascading Style Sheets, or CSS, is the recommended way to control the presentation layer in a web document. The main advantage of CSS over presentational HTML markup is that the styling can be kept entirely separate from the content. For example, it’s possible to store all the presentational styles for a 10,000-page web site in a single CSS file. CSS also provides far better control over presentation than do presentational element types in HTML.

By externalizing the presentation layer, CSS offers a number of significant benefits:

  • All styling is kept in a limited number of style sheets. The positive impact this has on site maintenance can’t be overestimated—editing one style sheet is obviously more efficient than editing 10,000 HTML files!
  • The overall saving in bandwidth is measurable. Since the style sheet is cached after the first request and can be reused for every page on the site, it doesn’t have to be downloaded with each web page. Removing all presentational markup from your web pages in favor of using CSS also reduces their size and bandwidth usage—by more than 50% in many documented cases. This benefits the site owner, through lower bandwidth and storage costs, as well as the site’s visitors, for whom the web pages load faster.
  • The separation of content from presentation makes it easier for site owners to reuse the content for other purposes, such as RSS feeds or text-to-speech conversion.
  • Separate styling rules can be used for different output media. We no longer need to create a special version of each page for printing—we can simply create a single style sheet that controls how every page on the site will be printed.

Although CSS is designed to be independent of the markup language of the documents to which it is applied, in reality, it’s used mainly with HTML and XML (including XHTML).


via--

http://reference.sitepoint.com/css/css.....


Sunday, March 20, 2011

Transitional vs. Strict Markup

When promoting web standards, standardistas often talk about XHTML as being more strict than HTML. In a sense it is, since it requires that all elements are properly closed and that attribute values are quoted. But there are two flavours of XHTML 1.0 (three if you count the Frameset DOCTYPE, which is outside the scope of this article), defined by the Transitional and Strict DOCTYPEs. And HTML 4.01 also comes in those flavours.

The names reveal what they are about: Transitional DOCTYPEs are meant for those making the transition from older markup to modern ways. Strict DOCTYPEs are actually the default – the way HTML 4.01 and XHTML 1.0 were constructed to be used.

A Transitional DOCTYPE may be used when you have a lot of legacy markup that cannot easily be converted to comply with a Strict DOCTYPE. But Strict is what you should be aiming for. It encourages, and in some cases enforces, the separation of structure and presentation, moving the presentational aspects from markup to CSS. From the HTML 4 Document Type Definition:This is HTML 4.01 Strict DTD, which excludes the presentation attributes and elements that W3C expects to phase out as support for style sheets matures. Authors should use the Strict DTD when possible, but may use the Transitional DTD when support for presentation attribute and elements is required.

An additional benefit of using a Strict DOCTYPE is that doing so will ensure that browsers use their strictest, most standards compliant rendering modes.

Tommy Olsson provides a good summary of the benefits of using Strict over Transitional in Ten questions for Tommy Olsson at Web Standards Group:In my opinion, using a Strict DTD, either HTML 4.01 Strict or XHTML 1.0 Strict, is far more important for the quality of the future web than whether or not there is an X in front of the name. The Strict DTD promotes a separation of structure and presentation, which makes a site so much easier to maintain.

For those looking to start using web standards and valid, semantic markup, it is important to understand the difference between Transitional and Strict DOCTYPEs. For complete listings of the differences between Transitional and Strict DOCTYPEs, see XHTML: Differences between Strict & Transitional, Comparison of Strict and Transitional XHTML, and XHTML1.0 Element Attributes by DTD.

Some of the differences are more likely than others to cause problems for developers moving from a Transitional DOCTYPE to a Strict one, and I’d like to mention a few of those.

Elements that are not allowed in Strict DOCTYPEs

  • center
  • font
  • iframe
  • strike
  • u

Attributes not allowed in Strict DOCTYPEs

  • align (allowed on elements related to tables: col, colgroup, tbody, td, tfoot, th, thead, and tr)
  • language
  • background
  • bgcolor
  • border (allowed on table)
  • height (allowed on img and object)
  • hspace
  • name (allowed in HTML 4.01 Strict, not allowed on form and img in XHTML 1.0 Strict)
  • noshade
  • nowrap
  • target
  • text, link, vlink, and alink
  • vspace
  • width (allowed on img, object, table, col, and colgroup)

HTML5 is a language for structuring and presenting content for the World Wide Web, a core technology of the Internet. It is the latest revision of the HTML standard (originally created in 1990) and currently remains under development. Its core aims have been to improve the language with support for the latest multimedia while keeping it easily readable by humans and consistently understood by computers and devices (web browsers, parsers etc.).

Following its immediate predecessors HTML 4.01 and XHTML 1.1, HTML5 is a response to the observation that the HTML and XHTML in common use on the World Wide Web is a mixture of features introduced by various specifications, along with those introduced by software products such as web browsers, those established by common practice, and the many syntax errors in existing web documents. It is also an attempt to define a single markup language that can be written in either HTML or XHTML syntax. It includes detailed processing models to encourage more interoperable implementations; it extends, improves and rationalises the markup available for documents, and introduces markup and APIs for complex web applications. In particular, HTML5 adds many new syntactical features. These include the and elements, as well as the integration of SVG content. These features are designed to make it easy to include and handle multimedia and graphical content on the web without having to resort to proprietary plugins and APIs. Other new elements, such as are designed to enrich the semantic content of documents. New attributes have been introduced for the same purpose, while some elements and attributes have been removed. Some elements, such as , and have been changed, redefined or standardised. The APIs and DOM are no longer afterthoughts, but are fundamental parts of the HTML5 specification. HTML5 also defines in some detail the required processing for invalid documents, so that syntax errors will be treated uniformly by all conforming browsers and other user agents