Book HomeCascading Style Sheets: The Definitive GuideSearch this book Monday 24th of November 2014 12:52:17 PM

10.7. Tables

Perhaps as a result of a generic need to be able to describe table layout -- something CSS1 lacks -- CSS2 includes a handful of features that apply directly to tables and table cells. First, there are 10 new table-related values for display:

table
inline-table
table-column-group
table-column
table-row-group
table-row
table-cell
table-caption
table-header-group
table-footer-group 

While the effects of most of these are obvious from their names, at least two may not be familiar to you. table-header-group and table-footer-group are used to mark the header and footer of a table. These are displayed, respectively, above or below all the rows of the table, but not outside of the table's caption.

list-style-type

Values

disc | circle |square | decimal |upper-alpha | lower-alpha |upper-roman | lower-roman |none

Another interesting effect is that you can align text on a character by using the text-align property. For example, if you wanted to line up a column of figures on a decimal point, you might declare:

TD { text-align: "." }

As long as a set of cells are grouped into a column, their content will be aligned so that the periods all line up along a vertical axis.

Far from relying on existing properties, CSS2 provides a whole array of brand-new properties in the table section. Here are a few of them:

  • border-spacing, which influences the placement of borders around cells

  • border-collapse, which can be used to influence how the borders of various table elements interact

  • table-layout, which tells the browser whether or not it can resize the table as necessary

There are also properties describing how visibility and vertical-align are applied to tables. There is also a caption-side property, which functions exactly the same as the ALIGN attribute on the <CAPTION> tag, and the property speak-header-cell, which controls how header cells are handled by speech-generating browsers (more on that later).



Library Navigation Links

Copyright © 2002 O'Reilly & Associates. All rights reserved.


<P>&nbsp;<P>&nbsp;<P>

 

Also paragraph breaks. 

But making extra space with multiple P tags doesn't work 

Use multiple BR tags, or insert special non-breaking space charactersbetween P tags instead:

 

DOM and SAX are open, language-independent set of interfaces

By defining a set of programming language independent interfaces that allow the accessing and mutation of XML documents, the W3C made it easier for programmers to deal with XML. Not only does XML address the need for a standard information encoding and storage format, it also allows programmers a standard way to use that information. SAX is a very low level API, but it is more than what has been available before it. DOM is a higher level API that even provides a default object model for all XML documents (saving time in creating one from scratch if you are using data is document data).

SAX, DOM and XML are very developer friendly because developers are going to decide whether this technology will be adopted by the majority and become a successful effort towards the goal of interoperable, platform, and device independent computing.

XML is web enabled

text is already set to bold. If there is no bolderface available, then the user agent sets the weight ofB text within an H1 to800, since that is the next step up from700 (the numeric equivalent tobold). Since 800 is assigned tothe same font face as 700, there is no visibledifference between normal H1 text and boldfacedH1 text, but nonetheless the weights aredifferent. edges. The variations may seem subtle, but the odds are thatyou'll have reason to use both approaches at some point in yourdesign career.

In case you're wondering, there is no way to control the repeatany more than we've already discussed. There is norepeat-left, for example, although it couldcertainly be added in some future version of CSS. For now, you getfull tiling, horizontal tiling, vertical tiling, or no tiling at all.

The classes that import and export information from your ApplicationML file must use the parser and SAX or DOM API in order to import the information. These classes can access this information by using one of the following strategies:

  1. Use DOM to directly manipulate the information stored in the document (which DOM turns into a tree of nodes). This document object is created by the DOM XML parser after it reads in the XML document. This option leads to messy and hard-to-understand code. Also, this works better for document-type data rather than just computer generated data (like data structures and objects used in your code).
  2. Create your own Java object model that imports information from the XML document by using either SAX or DOM. This kind of object model only uses SAX or DOM to initialize itself with the information contained in the XML document(s). Once the parsing and initialization of your object model is completed, DOM or SAX isn't used anymore. You can use your own object model to accessed or modify your information without using SAX or DOM anymore. So you manipulate your information using your own objects, and rely on the SAX or DOM APIs to import the information from your ApplicationML file into memory (as a bunch of Java objects). You can think of this object model as an in-memory instance of the information that came was "serialized" in your XML document(s). Changes made to this object model are made persistent automatically, you have to deal with persistence issues (ie, write code to save your object model to a persistence layer as XML).
  3. Create your own Java object model (adapter) that uses DOM to manipulate the information in your document object tree (that is created by the parser). This is slightly different from the 2nd option, because you are still using the DOM API to manipulate the document information as a tree of nodes, but you are just wrapping an application specific API around the DOM objects, so its easier for you to write the code. So your object model is an adapter on top of DOM (ie, it uses the adapter pattern). This application specific API uses DOM and actually accesses or modifies information by going to the tree of nodes. Changes made to the object model still have to be made persistence (if you want to save any changes). You are in essence creating a thin layer on top of the tree of nodes that the parser creates, where the tree of nodes is accessed or modified eventually depending on what methods you invoke on your object model.