Pro CSS Techniques- P6

Chia sẻ: Thanh Cong | Ngày: | Loại File: PDF | Số trang:50

lượt xem

Pro CSS Techniques- P6

Mô tả tài liệu
  Download Vui lòng tải xuống để xem tài liệu đầy đủ

Tham khảo tài liệu 'pro css techniques- p6', công nghệ thông tin, kỹ thuật lập trình phục vụ nhu cầu học tập, nghiên cứu và làm việc hiệu quả

Chủ đề:

Nội dung Text: Pro CSS Techniques- P6

  1. 222 CHAPTER 10 ■ STYLING TABLES agent understand which cells are related to one another. Again, this is especially helpful to screen readers and other assistive technology. It helps them read or display tables more logically. Our example table, with the scope attribute added, might look something like this: Name Affiliation Website URL Jeff Croft World Online Ian Lloyd Accessify Dan Rubin Webgraph Note that the element containing the names of individuals is marked up as a td, not a th, but is still assigned the scope attribute. Because our names are data values in this table and not simply generic labels, they should be table data cell elements rather than table header elements. However, they still provide context for the rest of the information in the row, so the addition of the scope attribute is appropriate. Assigning scope in Complex Tables As your tables become more complex, you may find cases where the header information for a particular data cell is not the same row or column as that cell, or where three or more head- ers apply to a single data cell. In these cases, scope breaks down and you’ll need to use the headers attribute on your cells. By assigning a unique id to your headers, you can then refer- ence them as the context for a data cell. Our example is simple enough that scope works fine, but here’s an example of how it looks using headers instead: Name Affiliation Website URL
  2. CHAPTER 10 ■ STYLING TABLES 223 Jeff Croft World Online Ian Lloyd Accessify Dan Rubin Webgraph As this markup is far more complex than using the scope attribute, it’s always best to use scope where possible—and it works great for most cases. Only quite complex tables require the use of the headers attribute. The thead, tfoot, and tbody Elements Rows within a table can be optionally grouped in a table head, table foot, and one or more table body sections, using the thead, tfoot, and tbody elements, respectively. Typically, the thead element is used to contain the header rows of the table, the tbody element is used to hold the main content, and the tfoot element is used to collect any totals and similar “closing” information. By including these divisions in your markup, you provide the “hooks” necessary to create common and often desirable presentational effects, and also allow the user agent to do logical things, such as including the same header and footer on each page of a printed version of your table. It is worth remembering that both the thead and tfoot elements should appear above any tbody elements in your markup. The browser will still display the tfoot ele- ment at the bottom of the table where it belongs. Our example table doesn’t have data appropriate for multiple tbody elements or a tfoot element, but as it gets a bit more complex, it may. Consider the following: Pro CSS Techniques authors and editors Name Affiliation Website URL Role
  3. 224 CHAPTER 10 ■ STYLING TABLES Jeff Croft World Online Author Ian Lloyd Accessify Author Dan Rubin Webgraph Author Chris Mills Apress/friends of ED Editor Wilson Miner Apple Computer Technical Editor Here, we’ve wrapped our first row in the thead element, and also added a second tbody section for the book’s editors. We haven’t used the tfoot element, as this set of data doesn’t have any information appropriate for it. A case where you may use tfoot may be for the totals at the bottom of a spreadsheet or invoice. You’re probably already envisioning ways these markup additions could be exploited with CSS styles—we’ll get to that later in the chapter. Columns Tables have always contained the tr element to designate table rows, but only more recently did columns earn their way into the (X)HTML specifications. However, no current browser supports using CSS to style columns, so their current benefits are purely semantic and “future proofing.” If you define columns now, you won’t have to when browsers begin supporting the styling of them; therefore, we’ve decided to cover them here.
  4. CHAPTER 10 ■ STYLING TABLES 225 The colgroup element provides a way to define a set of columns for your table. Individual columns are then defined using the col element. To define proper columns for our table, we would add the following code: The summary Attribute Data tables can take an optional summary attribute whose purpose is to provide a description of the table’s purpose and structure. The summary attribute, by default, doesn’t display on the page (although by using CSS attribute selectors, you could make it display). The summary attribute is especially helpful to nonvisual viewers of your content. When writing a table sum- mary, consider explaining any nonobvious relationships between rows and columns, as well as defining the relationship between the table and the context of the document that contains it. Although our example table is very simple and may not require a summary, one could be added like so: All Marked Up So, our fully marked-up, semantic table code looks like this: Pro CSS Techniques authors and editors Name Affiliation Website URL Role
  5. 226 CHAPTER 10 ■ STYLING TABLES Jeff Croft World Online Author Ian Lloyd Accessify Author Dan Rubin Webgraph Author Chris Mills Apress/friends of ED Editor Wilson Miner Apple Computer Technical Editor With the addition of a handful of useful elements and attributes, we’ve added a great deal of meaning, usability, and accessibility to even this simple table. But perhaps more importantly (at least in the context of this book), we’ve added a plethora of hooks within the table we can attach CSS styles to.
  6. CHAPTER 10 ■ STYLING TABLES 227 Adding Style Data tables may seem like boring spreadsheets of mind-numbing information—and often they are. But that is, if anything, a really good reason to give them special attention when it comes to visual and information design. With a bit of CSS work, we can take the mundane, ordinary table and transform it into a fascinating resource that is a pleasure to browse. In this section, we’ll cover some of the common styles and features you can add to your table to increase readability, findability, and aesthetic value. First, take a look at Figure 10-2, which shows our finished example table as it appears in a browser with no CSS styling. Figure 10-2. Our sample table, completely unstyled Most folks will agree this isn’t ideal. Let’s add some basic table styles, as well as some type styling (see the previous chapter), to enhance its presentation. We’ll start with this CSS: table { width: 90%; margin: 0 auto; font-family: "Lucida Grande", Verdana, Helvetica, Arial, sans-serif; font-size: .9em; line-height: 1.4em; } By simply making the table 90 percent wide, centering it on the page (by giving it auto left and right margins), and tweaking the type a bit, we get a good start toward a cleaner presenta- tion, as shown in Figure 10-3.
  7. 228 CHAPTER 10 ■ STYLING TABLES Figure 10-3. Some basic tweaks have already improved our table to no end! Now, what about those headers? We’d rather see them left-aligned, and perhaps a border under them would help delineate them from the data cells: th { text-align: left; border-bottom: 1px solid #000; } Let’s also adjust the color of the text in the data cells while we’re at it: td { color: #333; } Our table now looks like Figure 10-4. Figure 10-4. Basic delineation of headers and body using color and a border
  8. CHAPTER 10 ■ STYLING TABLES 229 Getting better already! But nothing we’ve done so far is table specific. We’ve simply styled some type and added some borders, just as we can do on any element with CSS. Table Borders CSS defines two separate models for table borders: collapsed and separate. The default ren- dering mode for most browsers is the separate model, in which borders around cells are kept separate from one another. For example, adding a one-pixel border to our example table in separate mode produces the results shown in Figure 10-5. Figure 10-5. Table borders in the separate model You’ll note there is some space between each cell, and each cell receives its own, noncon- necting border. Let’s change the border model to collapsing before we add our border, like so: table { width: 90%; margin: 0 auto; font-family: Lucida Grande, Verdana, Helvetica, Arial, sans-serif; font-size: .9em; line-height: 1.4em; border-collapse: collapse; } th { text-align: left; border-bottom: 1px solid #000; } td { color: #333; border: 1px solid #ccc; }
  9. 230 CHAPTER 10 ■ STYLING TABLES As you can see in Figure 10-6, the result is quite different. Figure 10-6. Table borders in the collapsed model The borders have “collapsed” into one another and the space between cells has been removed. For most purposes, this collapsed model is more useful than it’s separate counter- part. The rules that control the collapsed model are quite specific: • The table element itself cannot have padding (although it can have margins). This means there is never any space between a table’s border and its outermost cells. • In addition to the table element, cells, rows, columns, row groups, and column groups can all have borders. • There is never any space between cell borders. Borders themselves collapse into one another so that only one is actually drawn. So, if two cells each have a one-pixel-wide border, rather than two adjacent one-pixel-wide borders (for a total width of two pix- els), you will see only one border line with a one-pixel weight. • If two cells collapsing into one another have differing border-style attributes, the style with the greater priority will be displayed. The priority, from most preferred to least pre- ferred, is as follows: hidden, double, solid, dashed, dotted, ridge, outset, groove, inset, none. If the two collapsing cells have the same border-style attribute, that value will be used. • If two cells collapsing into one another have borders of the same style and width but different color, the displayed color is taken from the element with the greater priority. The priority, from most preferred to least preferred, is as follows: cell, row, row group, column, column group, table. If the two elements are of the same type, then no behav- ior is defined, and each user agent or browser is left to its own devices when choosing which color to display. With that in mind, let’s experiment with some different border styles for our example table:
  10. CHAPTER 10 ■ STYLING TABLES 231 table { width: 90%; margin: 0 auto; font-family: Lucida Grande, Verdana, Helvetica, Arial, sans-serif; font-size: .9em; line-height: 1.4em; border-collapse: collapse; } tr { border: 1px solid #666; } th { text-align: left; border-left: 1px solid #333; border-right: 1px solid #333; border-bottom: 3px double #333; padding: 0 .5em; } td { color: #333; border: 1px dotted #666; padding: 0 .5em; } Adding these styles to our CSS gives us the result shown in Figure 10-7. Figure 10-7. Adding some basic border styles to our sample table As you can see, there are countless ways to use borders with tables. Throughout the chap- ter, the examples will use different borders to show more possibilities.
  11. 232 CHAPTER 10 ■ STYLING TABLES Zebra Tables A common interface idiom with any kind of table is to display alternating rows or columns with subtly different background colors. Doing so aids in reading, and it helps keep readers on top of which column or row they are currently reading. Most major browsers do not currently support styling the col element. As such, this approach is only practical for rows. (You could achieve the effect on columns, but it would require adding a class to a lot of cells. This may be OK for very small tables but usually proves to be impracti- cal for tables of any size.) However, future versions of browsers should let you apply the same approach to columns as well. To do this in today’s browser environment, you’ll need to add a class to every other row in your table. A common practice is to add class="odd" to each of the odd numbered-rows. How- ever, this isn’t a practical thing to do manually, especially on large tables. Besides needing to manually put the class on every row, you also have to go back and rework the entire table when you add a single row to the middle of the table somewhere. As such, web developers often use DOM scripting or server-side template languages to add the class automatically. (For an exam- ple of such a DOM scripting trick, check out David F. Miller’s article at articles/zebratables.) No matter how you add the class to your document, it’s simple to style the table accordingly once it’s there: tr.odd { background-color: #dfdfdf; } Check out the result in Figure 10-8. Figure 10-8. Making our table into a zebra!
  12. CHAPTER 10 ■ STYLING TABLES 233 ■Note CSS 3 provides a selector that allows for this sort of thing. However, no major browser currently supports it: tr:nth-child(odd) { background-color: #dfdfdf } Styling the Caption Early in the chapter, we added the caption element to our table. By default, it will appear above your table. However, CSS offers a property, caption-side, which positions the caption on the top, bottom, left, or right of the table. Let’s position our caption at the bottom of the table, and give it some additional style as well: caption { caption-side: bottom; line-height: 4em; font-family: Georgia, "Times New Roman", serif; font-size: .85em; font-style: italic; } This gives us the result shown in Figure 10-9. Figure 10-9. Styling our table caption effectively
  13. 234 CHAPTER 10 ■ STYLING TABLES Ideas for Going Further You can find many examples of deliciously styled tables online. Beyond the basic examples shown here, you can consider using the background-image property on the tables, individual rows, or heads to achieve great effects. Veerle Pieters does this very well in her example at, as well as her CSS-styled calendar at Nathan Smith also uses a calendar as a demonstration of some beautiful table design at http:// Using your creativity and CSS’s power, you should be able to make tables that not only look brilliant but are accessible, readable, and usable to boot. Summary CSS allows you to present data tables in virtually limitless ways. Although the examples here are relatively simple, they illustrate the kind of things you can do—and your creativity can take it from here. A real key to creating tables that are useful, readable, and interesting to look at is the (X)HTML markup you use to provide those additional styling “hooks.” By taking advantage of some of the newer and more semantic elements, you can create tables that both look great and work effectively for users visiting your site with assistive technology and other alternate devices. Now that you’re familiar with styling tabular data, let’s move on to laying out another common web page component: forms.
  14. CHAPTER 11 ■■■ Styling Forms U sing the power of CSS, forms can be styled in many interesting and creative ways to enhance not only their aesthetics, but also their usability. However, forms are also the single area where default styling and differences in CSS support are the most inconsistent across browsers. There are two main components to forms and CSS: laying out entire forms and styling individual form widgets. Let’s start with the latter. Styling Form Widgets The degree to which individual form widgets can be styled varies greatly from browser to browser. For example, Safari does not allow for CSS borders or backgrounds on input elements (although this may be changing in the near future), but Firefox does. Web designers often find this frus- trating. However, there are two schools of thought on whether browsers should let CSS authors modify the appearance of form widgets. Whereas smart designers can use CSS’s widget styling to create usable forms that better integrate with the overall design of a site, less savvy CSS authors may abuse the power to the point where a form is rendered unusable. Also, users come to expect their default form widgets and can be confused by controls that appear unusual to them. Either way, the important thing to understand when styling form elements is that it’s very likely users of some browsers will see the standard, default form widgets supplied by their operating system and/or browser instead of your custom-styled versions. You should ensure that your design works well with or without the custom styles you are applying. It’s also important to understand that the default styles of button, text fields, radio but- tons, check boxes, and other form element vary drastically from one browser and platform to the next. Where a select box may be 16 pixels tall in one browser, it could be 20 pixels tall in another. Again, your design should accommodate these inconsistencies. Web professional Roger Johansson created what may be the world’s most authoritative source on both the default styles of form elements and which CSS properties can and cannot be applied to them in various browsers across multiple platforms. In a blog post titled “Styling even more form controls,” (, Roger provides screen shots and comparisons of tests he ran across the board. It’s an invalu- able resource. 235
  15. 236 CHAPTER 11 ■ STYLING FORMS The conclusion Roger reaches may be disheartening, but it’s accurate: “Very little styling is applied the same way in every browser,” he says, “Trying to style form controls to look the same across platforms is often a waste of time.” In short, the best practice is probably to leave most form controls alone, or to style them only lightly, using basic properties such as those for font color, size, and style, borders, and background colors—and to do so with the expectation that these styles will often go unseen by your visitors. Laying Out Forms As we’ve said, the default styling of form elements is notoriously inconsistent between browsers. Sadly, this applies not only to the individual field widgets, but to the overall style of the whole form. To demonstrate how this affects web designers looking to create usable and attractive forms on the Web, let’s first look at the same basic form in both Safari and Firefox on Mac OS X (see Figures 11-1 and 11-2). Figure 11-1. Basic unstyled form as seen in Safari
  16. CHAPTER 11 ■ STYLING FORMS 237 Figure 11-2. Basic unstyled form as seen in Firefox Although the two may appear similar at first glance, closer inspection shows considerable differences in margins, spacing, and font size—and that’s beyond the obvious differences in widgets for select boxes, radio buttons, and submit buttons. For this reason, it becomes more essential than ever to use some kind of mass reset style sheet (as described in Chapter 5) to start with as level a playing field as possible. Applying the mass reset style sheet provided in the Yahoo! User Interface library to our form results in the comparison shown in Figures 11-3 and 11-4. Figure 11-3. Basic unstyled form in Safari, after applying a mass reset
  17. 238 CHAPTER 11 ■ STYLING FORMS Figure 11-4. Basic unstyled form in Firefox, after applying a mass reset While this is certainly less attractive, it’s at least much closer to being the same across both browsers. It may not be a clean slate, but it’s a lot cleaner than it was before. Now let’s start looking at the (X)HTML behind well-designed forms. Semantic (X)HTML for Forms As has been noted throughout this book, CSS styling works best and most consistently when it is applied to pages that are built with clean, semantic (X)HTML. (X)HTML provides a few helpful yet underused elements for forms that not only add structure and meaning to your document but also provide significant form usability improvements and copious hooks on which to hang CSS styles. The fieldset and legend Elements The fieldset element is used for grouping form elements. In the example screen shots earlier, three fieldset elements are shown. You can detect them in the unstyled version by their default styling, which is typically a thin dark border (note that this border is turned off by our mass reset style sheet, and thus is not visible in those screen shots). Within fieldset elements, the page author can optionally provide a legend element, which serves as a title for the grouping of form elements the fieldset contains. In the screen shots, you’ll find legends containing the fieldset titles “Name,” “Address,” and “Payment option.”
  18. CHAPTER 11 ■ STYLING FORMS 239 The label Element As you may guess from its name, the label element serves to give a label to each widget in your form. More than anything, the label element serves important usability and accessibility functions. In most user agents, clicking on a field’s label will bring the keyboard focus to that field. label elements also help assistive technology like screen readers understand the rela- tionship between a textual label and a form field. The label element can be used one of two ways in (X)HTML. It can be wrapped around the field it is associated with, like so: Street In this method, the relationship is implicit; because the input field with the id attribute value street is nested within the label element, the label is related to that field. The relation- ship can also be defined explicitly: Street Here, the input element is not nested, so the relationship is defined explicitly by using the label element’s for attribute—it is set to the id value of the related form element. When defining relationship explicitly, the label element doesn’t need to be near the form element to which it relates in the (X)HTML source. Once in a while, this proves advantageous, but most of the time, it really doesn’t matter which way you choose to use the label element. Our Example Form For the rest of the examples in this chapter, we’ll be using this example form: Example form Name Title Mr. Mrs. Ms.
  19. 240 CHAPTER 11 ■ STYLING FORMS First name Last name Address Street City State Zip code Country Payment option Credit card Visa Mastercard Discover
  20. CHAPTER 11 ■ STYLING FORMS 241 Card number Expiration date Applying Basic Styling to the Form To start with, let’s apply some basic, simple styles to the form. First, we’ll set the form to be 75 percent wide and to be centered horizontally with a 3em vertical margin: form { margin: 3em auto; width: 75%; } We’ll also shape up our fieldset elements a bit, giving them a background color, a border, and some margin and padding: fieldset { background-color: #dfdfdf; border: 1px solid #ccc; margin: 2em 0; padding: 1em; }
Đồng bộ tài khoản