Agregator RSS - Darmowe tutoriale i porady CSS - Strona 1 z 2

Tim Berners-Lee created the Web at CERN, and the initial standards for HTML 1.0 and HTML 2.0 were governed by them. But CERN's main focus is particle physics research, not the Web, and so in 1994 CERN abdicated its role as the standards-setting body for HTML. It passed the torch to a newly created body called the World Wide Web Consortium, better known simply as "W3C." The W3C has convinced major software companies, including Netscape Communications, Microsoft, IBM, Novell, Sun Microsystems and many more, to become members of this standards body. This arrangement provides the software firms with lines of communication to other member firms and to a body recognized as authoritative in the devising and setting of a workable standard for HTML.

The W3C is designed to be a neutral meeting ground, where competing companies can come together to contribute to and comply with future Web standards. The W3C recognized the need to bring some stability to HTML, as the multiple tags introduced during the "browser wars" threatened to introduce widespread incompatibilities into working HTML. The W3C tried to consolidate existing HTML standards, first with the official HTML 3.2 specification, later with the HTML 4.0, and most recently the XHTML 1.0 specification and the XHTML 1.1 recommendation. These specifications adopted many of the HTML tags made popular in both Internet Explorer and Netscape Navigator, even though these tags often failed to conform to one of HTML's main guiding principles: that markup should reflect the structure of a document rather than its physical layout.

HTML was originally designed with the intention of displaying the logical structure of a document, as opposed to dealing with the finer issues of formatting text and image layout. This was done because there are many different varieties of computers out there, and they could not be expected to display content in exactly the same way. By defining logical constants as the basis for Web documents, it was left up to the Web browser programmer to create software that could adequately represent these structures in a way that would look best under a particular computer or a specific operating system. In this way, HTML was designed to be as widely compatible with as many computer platforms as possible.

But much of the drive by the browser manufacturers to provide Webmasters with proprietary tags was spurred by Webmasters' demand for better control over the layout of elements on a Web page, similar to what already exists in desktop publishing programs. Over time, however, these extra tags have increased the overall complexity of Web pages, in addition to producing many Web sites along the way that could not be viewed properly when viewed under the "wrong" browser. The HTML 4.0 specification in particular tried to consolidate the existing state of HTML at that point in time, but it was felt that action had to be taken in order to curb the development of further HTML tags by the browser manufacturers.

Thus the idea of Cascading Style Sheets (CSS) was born.

CSS is an effort by the W3C to minimize the need for the introduction of new physical formatting tags (such as the font or table tags) by browser manufacturers �?? chiefly Microsoft and Netscape �?? by making such tags unnecessary. CSS is a compromise, providing the page layout features that Webmasters want by adding CSS formatting elements to existing HTML tags.

CSS retains much of the logical structure of a Web page while delivering many of the page layout features in a way that is easy to understand and powerful in the effects it produces. Under currently implemented CSS, it is possible to do the following on a Web page:

• specify the exact point size of text

• add indentations to text

• set margins within a Web page

• add new formatting elements to a Web page, such as borders around text

• use such measurement units as inches and centimeters to set precise sizes for text or images displayed on a Web page

• create a distinctive style for individual Web pages or sets of Web pages

• change the fundamental way a tag is supposed to be displayed onscreen

• precisely lay out text, images and other objects using absolute screen references

• set precisely where a background image is displayed, and whether it should be repeated across or down a Web page

• alter the spacing between letters, between words or lines of text, and much more

CSS's long list of features provides many of the page layout and typographical functions Webmasters have been looking for, although it still provides less layout or typographic control than desktop publishing programs. CSS is really a mechanism for modifying how content is displayed on a Web page, and is not designed as a comprehensive layout tool. Despite this, CSS provides Webmasters much finer control over where and how things appear on a Web page than can be achieved using regular HTML.

One can justifiably ask about the relevancy of a "browser war" now that the major battles seem to have been handily won by Internet Explorer, which currently commands somewhere in the region of 90% of all browsers used. For many Web authors, it's no longer a matter of ensuring a Web site is compatible with all of the major browsers, but instead making sure that it is workable when used by the most recent versions of Internet Explorer. Knowing how to tailor pages to work best with this browser is knowledge most Web authors want to know.

Despite Internet Explorer's preponderance on the browser scene, it would be foolish to dismiss the existence of other browsers out there. In fact, it may be fair to say that the browser wars have simply entered a new phase, and CSS has become one of the battlegrounds as browser manufacturers add their own extensions to it. On the good side, it seems as though browser manufacturers have been converted to the potential of implementing as many of the officially sanctioned CSS properties as possible in order to win mind share amongst Web authors.

Starting with Internet Explorer 4.0 Microsoft has been adding their own extensions to CSS. Some of these CSS properties have later become recommendations under developing CSS specifications �?? such as Ruby �?? while others are wholly new properties that as yet have no parallel under the official W3C specifications, like the scrollbar formatting properties and transition filters. In all, over 40 cumulative CSS properties have been added to various versions of Internet Explorer, and these are all covered in detail in this book.

While the user base for such browsers as Netscape Navigator has been greatly diminished since the start of the browser wars, it is far from dead. In fact, with the deep pockets of AOL behind it as well as the collected efforts of the open source development community behind the Mozilla browser (whose code base has been going into versions of Netscape Navigator since version 6.0) it certainly should not be written off. It is interesting to note that Mozilla/Netscape have been adding their own CSS extensions within the releases of these twinned browsers �?? in fact a staggering 160+ CSS extensions have been added to various versions of these browsers. But for the most part these extensions are anticipations of developments of the CSS specification by the W3C, and they are also "unofficial" extensions, none of them officially documented (the extensions to Internet Explorer are well covered by Microsoft for aspiring developers). These extensions are not included in this book due to their ever-changing nature, and because for the most part they parallel developments in upcoming CSS specifications.

While its command of the browser market is relatively small, Opera is another browser that should not be ignored. While it has long been at the forefront of CSS compatibility, it has also introduced its own small subset of CSS extensions �?? so far, three in total (again, they are covered in this book). Though Opera has a small user base when compared to Internet Explorer, the company that produces it has been aggressively pushing it for use in forthcoming portable hardware browsers, and it is also available under a wide variety of operating systems.

Though versions of Internet Explorer are available for various releases of Microsoft Windows as well as the Macintosh OS, there is no version of it available for the increasingly popular Linux operating system �?? nor is there likely to be in the foreseeable future. There are a number of different browsers available for this operating system, including Opera and Netscape Navigator, as well as Linux-only browsers such as Galleon, Emacspeak and Konqueror. Many of these browsers have good-to-excellent support for CSS, though thankfully none of them seem to have added their own CSS extensions. Taken together, they may represent a small portion of the browsers used to visit your Web site, but they too are worth noting, if only for the ways they implement CSS �?? sometimes, like Emacspeak, they are well in advance of other leading browsers.

It is probably too early to say whether or not the browser wars are over, since it seems likely that they are entering a new phase �?? one in which the operating system or hardware platform is likely to prove as important for Web authors to consider as browser-specific extensions belonging to any one browser. No matter how you look at it, CSS compatibility has become a real factor in garnering mind share amongst the user base and with Web authors. Greater adoption of CSS properties within the major browsers means that today's Webmasters can no longer afford to overlook using CSS as an integral part of their Web site designs.

One thing is clear: CSS is here to stay. The more you know about how to use it effectively, the more professional you and your Web site designs will be.

The <style> element is always contained within the header of a Web page, and unless overridden elsewhere in the Web page, its effects are applied globally to the selected HTML elements contained within it.

The <style> element has several attributes: accesskey, dir, disabled, lang, language, media, tabindex, title, and type, all of which are optional �?? and frankly, only a few of which are used routinely in practice. It is important to know the values of the attributes in those cases where it may be useful, however.

The accesskey attribute enables Web authors to assign a keyboard key to the <style> element. This keyboard "shortcut" enables the user to hit ALT plus the designated key which then selects the element.

The dir attribute is a standard HTML attribute that sets the text direction, and can take the values ltr and rtl (for "left-to-right" and "right-to-left," respectively). This does not necessarily switch the direction for displayed text, but instead is there to tell the browser which way it is meant to be read.

The disabled attribute �?? which is an unofficial attribute for <style> and is only supported within Internet Explorer version 4.0 and higher �?? indicates that the particular CSS function should not be "enabled" (in other words, that its effects should not be displayed). This is for use in circumstances where you may wish to disable the CSS formatting display in a particular place on the Web page. If you use this particular attribute, the content associated with the selected element is still displayed, but is not formatted in the CSS style indicated.

lang is another standard HTML attribute, and is used to set the language code (i.e., "english" or "french"). Internet Explorer 4.0 and up add an additional language attribute, which associates the element with a scripting language (like JavaScript or VBScript).

The media attribute is used to specify the type of medium for which the CSS formatting is to be used. There are nine distinct values: all, aural, braille, handheld, print, projection, screen, tv and tty, each reflecting the different types of media the Web page can be "viewed" in. The default value is screen (i.e., a computer screen). If a device exists to translate the Web page into a different medium (such as a digital video projector for the projection value, or a Palm device for the handheld value), the device will use the CSS elements associated with the particular style used for it. Actual support for most of these attributes has always been spotty, and on the whole you are probably better off trying to tailor your code for specific devices if you expect heavy use in these other media displays. (Also, as we will see, there are a number of media types called by the @media "at-rule" which accomplishes much the same thing, and is much more flexible.

tabindex is another accessibility attribute (like accesskey), and in this case it sets the tab order for the element. This relates to the order in which selectable elements on a page can be accessed when you hit the tab key repeatedly. Normally, when you do this, elements are selected in order from the top of the page to the bottom. But when you set an integer value to tabindex, you can interrupt this flow and make the element it is associated with either a priority tab-able item or not.

The type attribute simply specifies the MIME type contained by the <style> element. There are two possible values for this at the moment: "text/css", which applies to CSS, and "text/javascript", which applies to JavaScript code. For the most part, the text/css value is simply assumed, and the two major browsers do not have any problems interpreting CSS code when this value is not present. This attribute is widely recognized in all major browsers.

There used to be a common recommendation to surround the style element with comment elements (i.e., "<!--" and "-->") in case older browsers which do not recognize the element display the content contained within them. This concern is pretty much a thing of the past these days, and if you are truly concerned about your CSS code being displayed in an older browser, it's old enough so that you wouldn't seriously be coding CSS for it anyway.

<style> and CSS3

The CSS3 specification has introduced some interesting variations for the <style> element. These variations greatly extend the uses to which this element can be used for adding CSS code to a page. When adopted by browser manufacturers, they will enable Web authors to add code directly to the style attribute that otherwise would have had to have been added to the header of a Web page �?? greatly increasing coding flexibility. Say, for example, you are working with a standard template file for a Web site that contains the HTML header, and you either don't have ready access to changing it, or don't want to add code to the header of a page when you only intend to implement a single formatting instance limited to a single page. This would be a situation where the CSS3 extensions to the <style> element would help you out of a potential jam.

The first variant allows Web authors to add pseudo-elements to a particular Web element. Curly braces are wrapped around the "standard" CSS properties for a given element, and then the pseudo-element code is added, and the CSS properties associated with the pseudo-element are similarly wrapped in curly braces. The following code snippet makes this clear:

<p>Some sample text</p>

(Note that in CSS3 double colons are recommended over single colons for pseudo-elements, hence "::first-letter" instead of ":first-letter"). Pseudo-elements are covered in detail in Chapter 7, "Pseudo-Elements, Pseudo-Classes and Selectors."

The second variation allows you to set the display properties on a link �?? something that hitherto would have had to have been set either in the header of a page or in an external style sheet. Like the first variant, the CSS properties are wrapped in curly braces, as the following line of code shows:

Visit <a href="http://www.captmondo.com" 

style={color: navy}

:link {background: aqua}

:visited {background: red}

:hover {background: yellow}

:active {background: green}">captmondo.com</a>.

The third variation allows you to reference an external style sheet directly within an element. Again, this allows you to easily supercede any CSS code that may already be contained in the document, providing the flexibility of creating style sheets on an element-by-element basis if need be. The following line of code shows how this could be done:

<span"@import url(funky.css)">

Funky-looking text</span> set 

against decidedly un-funky text.

Internet Explorer 3.x was the first major browser to implement CSS, although only in a rudimentary fashion. It did not implement many CSS properties, and those that were implemented were rarely implemented fully. Very few people use Internet Explorer 3.x today, so it is probably not worthwhile to try and design pages that would look good in it. This is just as well, since designing Web pages that use the few CSS properties implemented in Internet Explorer 3.x is pretty much an exercise in frustration, anyway. In short, don't plan on designing a CSS-oriented Web site that has to be "safe" for whatever Internet Explorer 3.x users are still out there.

For this reason, in the summary listing of "safe" and "unsafe" elements provided at the end of this book, Internet Explorer 3.x is not included, as it would render too many CSS elements as "unsafe."

Microsoft greatly extended CSS compatibility within the initial 4.x version of Internet Explorer. This version of Internet Explorer was the first to show that a major browser vendor was serious about implementing CSS.

This version of Internet Explorer was not without its drawbacks, however. While it supported much of the background, border, font, margin, list and padding CSS element families at least partially, it could not support a number of other elements, such as display or clear/float in the Macintosh version at all. There were also some minor variances worth noting in the ways the browser implemented the same CSS elements across different operating systems. Problems implementing the text-align property have been noted, as have more general problems when implementing some basic CSS functions, such as containment, inheritance and dealing with certain length units.

This version of Internet Explorer has subsequently been superceded by versions 5.x and 6.x, and the vast majority of Internet Explorer users now use one of these later releases. However, it is worthwhile keeping its limitations in mind for those few users who may still be using it.

Microsoft's tendency to start adding their own browser-specific CSS properties began with this release of Internet Explorer. The filter property was added to this version, enabling Web authors to add a number of transitioning effects . Compared to later versions of the browser, this was a relatively minor addition, but arguably started a trend towards adding fresh browser-specific properties in future versions of Internet Explorer.

Another interesting development with this version of the browser was that it implemented �?? at least partially �?? some positioning properties (like top, left and vertical-align) which were being considered at the time for inclusion for the CSS2 specification, which was in a draft status at the time. Microsoft was truly looking forward with this development, though it would take version 5.5 before CSS2 properties were substantially supported.

Beginning with Internet Explorer 4, Microsoft began adding a number of programmable visual filter and transition effects to their browser. In fact these new extensions were to be the first CSS-based extension that Microsoft added to their browser. Depending on the filter, their effects can either be modified programmatically via JavaScript, or can be added using CSS elements on a given Web object.

In practice, filters and transitions have seen relatively little use on the Web, as their display properties are exclusive to Internet Explorer, and their effects can be dramatic enough that a page must be viewed using Internet Explorer in order for its content to be readable �?? in other words, they don't make for browser-compatible code. Having said that, if you are confident that your audience is composed largely of Internet Explorer users �?? say, on a corporate intranet �?? or are willing to customize your code on a browser-by-browser basis, you can use these filters and transitions to good effect.

Visual filters and transitions differ from regular CSS properties in that they require the full program code prior to the name of the filter, so the code specified for the Alpha filter actually looks something like this code snippet:

filter: progid:DXImageTransform.Microsoft.Alpha

A given filter's values are further modified by enclosing its values in parentheses, separated by commas, as you can see from the following code snippet:

(Opacity=100,FinishOpacity=0,
StartY=0, FinishY=100)

At this point you may well be thinking that this is really beginning to stretch the boundaries of CSS, and frankly, you'd be right. In some cases the properties rely upon JavaScript to make them work, so they don't fit the mold of your typical static CSS property used to make some text look nice on a Web page.

Internet Explorer 4.x introduced over a dozen visual filters. All of these original filters were superceded or expanded upon by the release of Internet Explorer 5.5, when Microsoft took the opportunity to rationalize and greatly expand the filtering and transition capabilities within the browser, deprecating several of these earlier filter types in the process.

There are two classes of filters: static filters and transitional filters. The static filters are not always so static, as you will see from some of the examples in this chapter, but their often dynamic effects are rendered on a single selected object. The transition filters are all designed to produce interesting "wipes," slowly revealing new content over the old. This chapter provides an overview of what's available.

Beginning with Internet Explorer 4, Microsoft began adding a number of programmable visual filter and transition effects to their browser. In fact these new extensions were to be the first CSS-based extension that Microsoft added to their browser. Depending on the filter, their effects can either be modified programmatically via JavaScript, or can be added using CSS elements on a given Web object.

In practice, filters and transitions have seen relatively little use on the Web, as their display properties are exclusive to Internet Explorer, and their effects can be dramatic enough that a page must be viewed using Internet Explorer in order for its content to be readable �?? in other words, they don't make for browser-compatible code. Having said that, if you are confident that your audience is composed largely of Internet Explorer users �?? say, on a corporate intranet �?? or are willing to customize your code on a browser-by-browser basis, you can use these filters and transitions to good effect.

Visual filters and transitions differ from regular CSS properties in that they require the full program code prior to the name of the filter, so the code specified for the Alpha filter actually looks something like this code snippet:

filter: progid:DXImageTransform.Microsoft.Alpha

A given filter's values are further modified by enclosing its values in parentheses, separated by commas, as you can see from the following code snippet:

(Opacity=100,FinishOpacity=0,
StartY=0, FinishY=100)

At this point you may well be thinking that this is really beginning to stretch the boundaries of CSS, and frankly, you'd be right. In some cases the properties rely upon JavaScript to make them work, so they don't fit the mold of your typical static CSS property used to make some text look nice on a Web page.

Internet Explorer 4.x introduced over a dozen visual filters. All of these original filters were superceded or expanded upon by the release of Internet Explorer 5.5, when Microsoft took the opportunity to rationalize and greatly expand the filtering and transition capabilities within the browser, deprecating several of these earlier filter types in the process.

There are two classes of filters: static filters and transitional filters. The static filters are not always so static, as you will see from some of the examples in this chapter, but their often dynamic effects are rendered on a single selected object. The transition filters are all designed to produce interesting "wipes," slowly revealing new content over the old. This chapter provides an overview of what's available.

The first thing you have to do to be able to arrange a column layout is to set the number of columns to display. This is handled using the column-count property. This property takes one of three values: a numeric value, auto and inherit. The numeric value allows you to set a specific number of columns to be displayed. The auto value leaves the browser to determine how many columns are to be displayed, and is used in conjunction with the values present for the column-width and column-gap properties. The inherit value takes on whatever parent value for column-count may already be present. Not surprisingly, the default value for column-count is 1, which equates the width of the browser window to a column.

The following code fragment shows how you could set three columns to a div element:

This property allows you to set a specific width for the columns that are displayed. It can take a standard length value, a percentage value, auto and inherit. The default behavior for this property is that if a single value is supplied, it is applied equally across all displayed columns. So if you set a specific length or percentage value, it is applied equally across all of the displayed columns. The auto value apportions the same amount of available space to the number of columns that have been set by the column-count property. If you want to set a width value for successive columns, you can also do that by setting successive values to this property in order. The following code snippet shows how you could use this property to set three columns, the first of which is set to 150 pixels in width, the second being 35% of the browser window, and third filling the rest of the available space.

div.columns {column-count: 3; column-width: 150px 35% auto}

It is easy to go wrong with this sort of property by setting larger widths than are possible to be displayed �?? like setting more than two 50% width values. In cases like these it is possible that content could be "lost" in the process. In these cases it is recommended that overflow: visible be used in order to ensure that any content that might overflow the columnar layout might be displayed by default.

In order to set some spacing between columns, use the column-gap property. This takes the same values as column-width (i.e., a standard length value, a percentage value, auto and inherit) as well as one more: normal. This last property is the default, and the specification recommends that it be set to a value of 1 em in width, though individual browsers may differ in how they render this. When the auto value is used, it tells the browser to make the gaps between the columns equal to each other.

If column rules are used, they are placed in the middle of the column gaps. It is worth noting that the width value set to any column rules does not affect the width of any column gaps that are set. The following code snippet adds a 15-pixel-wide column gap to a div element:

div.columns {column-count: 3; column-width: 150px 35% auto;
column-gap: 15px}

The only other thing worth noting is that column-gap values are not allowed to be negative, as this would allow for a situation where the content from one column could overlap that of an adjacent column.