Adding separator stripes with PHP
If you’re creating a table from data stored in a database, automating separator stripes is a
relatively simple process. After the PHP for retrieving data and the opening table markup
(including headers), you add the following:
$alternate = TRUE;
while ($row = mysql_fetch_object($sqlresult)) :
if($alternate) :
$class = ' class="alt"';
$alternate = FALSE;
else :
$class = "";
$alternate = TRUE;
endif;
echo '<tr'.$class.'>';
echo '<td>' . $row->field1 . '</td>';
echo '<td>' . $row->field2 . '</td>';
echo '</tr>';
endwhile;
This is then followed by the markup to close the table. Note that in this example, the alt
class value is applied to alternate table rows, so the CSS from the previous exercise should
still work fine
Css Source Codes, Css Practical examples ,Css tutorial ,Your best resource for Learning Css
Showing posts with label table. Show all posts
Showing posts with label table. Show all posts
Wednesday, September 29, 2010
Styling a table by Css : Adding borders to tables
As mentioned earlier, it’s a good policy to avoid using the default HTML table border. It
looks ugly and old-fashioned, and it’s a far cry from a clean, flat, 1-pixel border. You might
think it’s a straightforward process to add CSS borders to a table—logically, it makes sense
to simply add a border property/value pair to a grouped selector that takes care of both
the table headers and table data cells.
th, td {
border: 1px solid #c9c9c9;
}
But this doesn’t work. As the screenshot to the right shows, this method
results in the correct single-pixel border around the edge of the table,
but creates double-thick borders everywhere else. This is because the
borders don’t collapse by default, meaning that the right-hand border of
one cell sits next to the left-hand border of an adjacent cell, and so on.
Designers have historically gotten around this by using a rule to define a style for the top
and left borders of the table, and another to define a style for the right and bottom
borders of table cells. However, there’s a perfectly good property that
deals with the double-border syndrome: border-collapse. When this
property, with a value of collapse, is applied to the table element via an
element selector, borders collapse to a single border wherever possible.
The other available border-collapse property value, which reverts
borders back to their “standard” state, is separate.
table {
border-collapse: collapse;
}
With this brief explanation of table borders completed, we’ll now move into exercise
mode and style the table.
looks ugly and old-fashioned, and it’s a far cry from a clean, flat, 1-pixel border. You might
think it’s a straightforward process to add CSS borders to a table—logically, it makes sense
to simply add a border property/value pair to a grouped selector that takes care of both
the table headers and table data cells.
th, td {
border: 1px solid #c9c9c9;
}
But this doesn’t work. As the screenshot to the right shows, this method
results in the correct single-pixel border around the edge of the table,
but creates double-thick borders everywhere else. This is because the
borders don’t collapse by default, meaning that the right-hand border of
one cell sits next to the left-hand border of an adjacent cell, and so on.
Designers have historically gotten around this by using a rule to define a style for the top
and left borders of the table, and another to define a style for the right and bottom
borders of table cells. However, there’s a perfectly good property that
deals with the double-border syndrome: border-collapse. When this
property, with a value of collapse, is applied to the table element via an
element selector, borders collapse to a single border wherever possible.
The other available border-collapse property value, which reverts
borders back to their “standard” state, is separate.
table {
border-collapse: collapse;
}
With this brief explanation of table borders completed, we’ll now move into exercise
mode and style the table.
How to create a table: CssTutorial
1. Structure the table element. In order to emulate the structure of the iTunes
playlist, set the table’s width to a percentage value. This means the table will
stretch with the browser window. As explained earlier, you should also use the
summary attribute to succinctly detail what the table’s all about.
<table width="90%" border="1" cellspacing="0"
å summary="Music selected by Craig Grannell, with details of song,
å playing time, artist, album and play count.">
</table>
playlist, set the table’s width to a percentage value. This means the table will
stretch with the browser window. As explained earlier, you should also use the
summary attribute to succinctly detail what the table’s all about.
<table width="90%" border="1" cellspacing="0"
å summary="Music selected by Craig Grannell, with details of song,
å playing time, artist, album and play count.">
</table>
2. Add a caption. Immediately after the table start tag, add a caption element to provide
the table with a title.
the table with a title.
<caption>A playlist of great music</caption>
3. Add the basic table structure. Use row groups to provide the table with its basic
structure.
<thead>
</thead>
<tfoot>
</tfoot>
<tbody>
</tbody>
4. Using table header cell elements, add the content for the table head (the column
headers) as in the following code block, remembering to include relevant scope
attribute/value pairs:
<thead>
<tr>
<th scope="col">Song Name</th>
<th scope="col">Time</th>
<th scope="col">Artist</th>
<th scope="col">Album</th>
<th scope="col">Play Count</th>
</tr>
</thead>
There’s no need to add any styling—not even strong tags. By default, most
browsers display table header cell content in bold (and centered) to differentiate it
from table data; also, in the following section, you’ll be using CSS to style everything,
anyway.
5. Add table foot content. As mentioned, the footer for this table is to essentially be
a signature, stating who’s at fault for this selection of music. Because this is a single
line of text that could potentially span the entire table width, simply include a
single table cell, set to span five rows (using the colspan attribute).
<tfoot>
<tr><td colspan="5">Music selection by:
å www.snubcommunications.com</td></tr>
</tfoot>
a signature, stating who’s at fault for this selection of music. Because this is a single
line of text that could potentially span the entire table width, simply include a
single table cell, set to span five rows (using the colspan attribute).
<tfoot>
<tr><td colspan="5">Music selection by:
å www.snubcommunications.com</td></tr>
</tfoot>
6. Add table body content. Finally, add the table’s body content via the usual method,
using table row and table cell elements. This table will have nearly 20 rows, so to
save on trees, only the first two rows are detailed in the following printed code
block—you can add all the others in the same way, or just copy across the content
of building-the-table-body.txt from the download files, to save inputting the
data yourself.
<tbody>
<tr>
<td>In The Art Of Stopping</td>
<td>3:34</td>
<td>Wire</td>
<td>Send</td>
<td>3</td>
</tr>
<tr>
<td>Electron John</td>
<td>3:18</td>
<td>Worm Is Green</td>
<td>Push Play</td>
<td>42</td>
</tr>
</tbody>
Using table headers
Only a fraction of data tables on the Web make use of table headers, even though the
majority of tables include cell data that would be better placed within headers. The table
header cell element (<th></th>) performs a similar function to the standard table cell, but
is useful with regard to accessibility. Imagine a long data table comprised solely of standard
cells. The first row likely contains the headers, but because they’re not differentiated,
a screen reader might treat them as normal cells, read them once, and then continue reading
the remainder of the data. (If it doesn’t do this, it still has to assume which cells are
headers, and it might guess wrong.) When using table headers, the data is usually read in
context (header/data, header/data, and so on), enabling the user to make sense of everything.
Things can be sped up slightly by using the abbr attribute—long table headers can
be cut down, reducing what needs to be repeated when a table’s data is being read out.
An example of table header cells and a row of data cells follows:
<th>Country</th><th abbr="Capital">Capital city</th>
<td>France</td><td>Paris</td>
In this case, a screen reader should read the headers and then provide them with the data
of each cell (Country: France, Capital: Paris, etc.). But even with screen-based browsers, the
inclusion of headers proves beneficial for users, because table header cell content by
default is styled differently from data cell content, meaning the two cell types can be
easily differentiated.
Although headers are often at the top of a table, they may also be aligned down the lefthand
side. Therefore, you also need to specify whether the header provides header information
for the remainder of the row, column, row group, or column group that contains
it. This can be done with the scope attribute, which is added to the table header start tag
and given the relevant value (row, col, rowgroup, or colgroup). It’s also possible to use the
headers attribute in conjunction with id values. See the following “Scope and headers”
section for more information.
majority of tables include cell data that would be better placed within headers. The table
header cell element (<th></th>) performs a similar function to the standard table cell, but
is useful with regard to accessibility. Imagine a long data table comprised solely of standard
cells. The first row likely contains the headers, but because they’re not differentiated,
a screen reader might treat them as normal cells, read them once, and then continue reading
the remainder of the data. (If it doesn’t do this, it still has to assume which cells are
headers, and it might guess wrong.) When using table headers, the data is usually read in
context (header/data, header/data, and so on), enabling the user to make sense of everything.
Things can be sped up slightly by using the abbr attribute—long table headers can
be cut down, reducing what needs to be repeated when a table’s data is being read out.
An example of table header cells and a row of data cells follows:
<th>Country</th><th abbr="Capital">Capital city</th>
<td>France</td><td>Paris</td>
In this case, a screen reader should read the headers and then provide them with the data
of each cell (Country: France, Capital: Paris, etc.). But even with screen-based browsers, the
inclusion of headers proves beneficial for users, because table header cell content by
default is styled differently from data cell content, meaning the two cell types can be
easily differentiated.
Although headers are often at the top of a table, they may also be aligned down the lefthand
side. Therefore, you also need to specify whether the header provides header information
for the remainder of the row, column, row group, or column group that contains
it. This can be done with the scope attribute, which is added to the table header start tag
and given the relevant value (row, col, rowgroup, or colgroup). It’s also possible to use the
headers attribute in conjunction with id values. See the following “Scope and headers”
section for more information.
Vertical alignment of table cell content in Css
If you set your table’s width to a small value, or if you have a
lot of content in one cell and relatively little in an adjacent
one, something else becomes apparent: web browsers vertically
align content in the middle of cells. (Generally, horizontal
alignment is, as with other text, to the left.) See the image
on the right for an example.
Historically, designers have used the valign attribute to
override this vertical-centering behavior—the attribute can
be added to a row or cell start tag, and set to top:
valign="top". Other values are middle (the default) and
bottom, the results of which are shown in the adjacent
screenshot.
The problem with valign is that it’s presentational markup and shouldn’t really be used; in
fact, because it’s a deprecated attribute—which means it can’t be used if you’re creating
valid XHTML Strict documents—you should instead work with the CSS alternative, the
vertical-align property, which provides practically identical results.
As an example of vertical-align in use, say you wanted all cells within a table that had a
class value of priceList to be vertically aligned to the top; you could add the following
rule to your CSS:
table.priceList td {
vertical-align: top;
}
This results in the same effect as valign="top", as discussed earlier. Likewise, you can set
the vertical-align property to middle, bottom, and various other values, as outlined
in Appendix D, “CSS Reference.”That’s pretty much where many web designers leave tables; however, there are other elements
and attributes that should be used when creating tables, which will be covered in
the following sections.
lot of content in one cell and relatively little in an adjacent
one, something else becomes apparent: web browsers vertically
align content in the middle of cells. (Generally, horizontal
alignment is, as with other text, to the left.) See the image
on the right for an example.
Historically, designers have used the valign attribute to
override this vertical-centering behavior—the attribute can
be added to a row or cell start tag, and set to top:
valign="top". Other values are middle (the default) and
bottom, the results of which are shown in the adjacent
screenshot.
The problem with valign is that it’s presentational markup and shouldn’t really be used; in
fact, because it’s a deprecated attribute—which means it can’t be used if you’re creating
valid XHTML Strict documents—you should instead work with the CSS alternative, the
vertical-align property, which provides practically identical results.
As an example of vertical-align in use, say you wanted all cells within a table that had a
class value of priceList to be vertically aligned to the top; you could add the following
rule to your CSS:
table.priceList td {
vertical-align: top;
}
This results in the same effect as valign="top", as discussed earlier. Likewise, you can set
the vertical-align property to middle, bottom, and various other values, as outlined
in Appendix D, “CSS Reference.”That’s pretty much where many web designers leave tables; however, there are other elements
and attributes that should be used when creating tables, which will be covered in
the following sections.
Monday, September 27, 2010
The great table debate
Tables were initially intended as a means of displaying tabular data online, enabling web
designers to rapidly mark up things like price lists, statistical comparisons, specification
lists, spreadsheets, charts, forms, and so on.
designers to rapidly mark up things like price lists, statistical comparisons, specification
lists, spreadsheets, charts, forms, and so on.
It wasn’t long, however, before web designers realized that you could place any web content
within table cells, and this rapidly led to web designers chopping up Photoshop layouts
and piecing them back together in table-based web pages, often by using automated
tools. CSS should have put an end to that, but many web designers continue to use tables
for layout because they’re simple to set up—even though they cause problems (see the
“Tables for layout” section later in the chapter).
The strong will of CSS advocates, who typically shout that tables are evil, sometimes leads
designers to believe that tables should be ditched entirely—however, that’s not the case at
all. As mentioned, tables have a specific purpose in HTML, and one that’s still valid.
Therefore, the bulk of this chapter is going to look at tables in the context for which
they’re intended: the formatting of tabular data. Web page layout will be looked at in the
next chapter, which concentrates on CSS layout.
within table cells, and this rapidly led to web designers chopping up Photoshop layouts
and piecing them back together in table-based web pages, often by using automated
tools. CSS should have put an end to that, but many web designers continue to use tables
for layout because they’re simple to set up—even though they cause problems (see the
“Tables for layout” section later in the chapter).
The strong will of CSS advocates, who typically shout that tables are evil, sometimes leads
designers to believe that tables should be ditched entirely—however, that’s not the case at
all. As mentioned, tables have a specific purpose in HTML, and one that’s still valid.
Therefore, the bulk of this chapter is going to look at tables in the context for which
they’re intended: the formatting of tabular data. Web page layout will be looked at in the
next chapter, which concentrates on CSS layout.
Subscribe to:
Posts (Atom)