Martin Underwood wrote:
You have no way of knowing what the "chosen font" and chosen font size
of the user will be. So any value you give may be wrong for some users.

Yes.

If you use pixel widths for all cells then the table width should equal
the some of those pixel widths.

If you have a table of variable overall width then you can't specify
every cell width in pixels, at least one cell must be unspecified in
order to allow the table the flex. Or you can specify all the cell
widths as percentages.

<td class=head width="10% align="center">Year</td>
<td class=head width="35%">Surname</td>
<td class=head width="35%">Forenames</td>
<td class=head width="10%" align="center">Age</td>
<td class=head width="10%" align="center">Sched</td>

Oh, and why <td class="head> instead of <th> ?

No. Table cell widths are treated as suggestions towards a _minimum_
width for the cell (IE gets this slightly wrong, hence your initial
problem). They will be amongst the first things ignored by browser if
it can't format the table as specified.

Steve

Del wrote:

align is not deprecated when used as an attribute of COL, COLGROUP,
TBODY, TD, TFOOT, TH, THEAD, TR. It is deprecated when used as an
attribute of CAPTION, APPLET, IFRAME, IMG, INPUT, OBJECT, LEGEND,
TABLE, HR, DIV, H1, H2, H3, H4, H5, H6, P

Steve

Martin Underwood mumbled the following on 17/02/2006 19:43:
Have a gander at <http://garyjones.co.uk/development/table.html>

The code for the second table should suit your needs.
--
Gazza
Mobile Number Network Checker - http://mnnc.net/
Leovanna Leonbergers - http://leovanna.co.uk/
Scarlet Town - http://scarlettown.co.uk/

Stevie D wrote in message
pqkdv1dmjbe2cgr54iel62ca8i1ds2pnpf@4ax.com:

Ah. I didn't know you could combine classes using the syntax <td class="one
two">. That answers the question perfectly. Does a definition in the
last-mentioned class (eg "two") override a definition of the same attribute
in an earlier-mentioned class (eg "one")?

Stevie D wrote in message
a3ncv1do6qmcfjmelpnt4t1lfvgnam147h@4ax.com:

Because I particularly want to make sure that the column widths don't extend
arbitrarily wide on a large screen.

What I've done now, having removed the rogue "width=100%" from the <table>
tag, is to embed this table in a containing table in which it is centralised
widthways:

http://fp.martinunderwood.f9.co.uk/B...ensusIndex.htm

Similarly for the other table that is linked to from here

http://fp.martinunderwood.f9.co.uk/B...1851census.htm



I've found another funny, connected with <a> styles. It's not important but
just weird. In my table.css file, I've got

a:link, a:visited, a:active
{
color:"blue";
font-size:10.0pt;
font-weight:normal;
font-style:normal;
text-decoration:none;
font-family:Arial, sans-serif;
}

a:hover
{
color:"red";
font-size:10.0pt;
font-weight:normal;
font-style:normal;
text-decoration:underline;
font-family:Arial, sans-serif;
}

For IE, the colour of the link changes from blue to red (as well as the
words becoming underlined) when I hover over a link. But for Opera and
Firefox, the link remains in blue but does become underlined. Weird!

On Sat, 18 Feb 2006, Stevie D wrote:

That's a complex question. The HTML spec says rather vaguely that

/
Column groups allow authors to create structural divisions within a
table. Authors may highlight this structure through style sheets or
HTML attributes
\

( http://www.w3.org/TR/REC-html40/stru....html#h-11.2.4 )

Despite what it says there, CSS is very limited in what can be styled
from COL or COLGROUP, for this reason:

/
Table cells may belong to two contexts: rows and columns. However, in
the source document cells are descendants of rows, never of columns.
Nevertheless, some aspects of cells can be influenced by setting
properties on columns.
\

( http://www.w3.org/TR/CSS21/tables.html#q4 )

And if you look at what properties can be applied in that way in CSS,
alignment isn't one of them. So, if you want to specify alignment via
col/colgroup so as to avoid specifying it on every cell of the
column, you're going to need to do with the HTML attributes, whether
one likes them or not. (No matter that you might find a browser-like
object that propagates the CSS alignment from col/colgroup even though
the CSS spec doesn't call for it.)

That's off-topic for this group, you know ;-)

best

Martin Underwood wrote:

The order of the class names in HTML is irrelevant - they have equal
weight and any conflicts will be resolved via the CSS specificity
rules.
http://www.w3.org/TR/CSS21/cascade.html#specificity
So if everything else is equal the order of the class rules in the CSS
will determine which is applied.

Steve

Martin Underwood wrote:

Don't set a table or cell width at all. The table will then be only as
large as it needs to be. If you might have very long entries in some
cells, which you would prefer to wrap, set a max-width on the table.

There's the problem. Blue is a keyword, so should not be in quotes,
just like serif should not be in quotes when looking at font-family.
Keywords must not be quoted.

So the *standards compliant* browsers are ignoring the colour
attributes altogether, and are showing it as the browser default, which
happens to be blue, in all cases. A certain ba$tardised browser merrily
does it's own thing and does what it is not told to, and so reads the
blue and red instructions.

That's your other problem.

_*NEVER*_ specify a font size for screen display in pt. Keywords, em,
percentage - or even px if you absolutely have to. But _*never*_
points.

All of those are redundant. They are already specified for a:link, and
the link is still a link even when you're hovering, so they are
automatically passed on to the hover state. You only need to specify
here anything that is different from the standard link state.

google@sjd117.freeserve.co.uk wrote in
1140359477.188412.223550@o13g2000cwo.googlegroups. com:

I want to be sure that the column widths for various different tables of
similar data are consistent, to avoid the column widths changing from table
to table, which looks unprofessional.

Thanks. I discovered that after I posted the question, when I checked again
in a CSS book and saw that all the examples for RGB values and keyword
values had no quotes around them. I was thinking of the tag attribute syntax
such as width="10" and align="center" where quotes *are* used - though
you've got me wondering whether they are required and/or officially legal in
this case as well.


Why is it wrong to specify a font size in points but OK to specify it in ems
which are also a unit of typographical size? If it's so wrong, why is it
included in the HTML spec? Given that most word processors and other
software specify font sizes in points, why should it be different for
browsers? If you specify the font size as a percentage, where do you define
the base size that the percentages relate to?

Oh, I didn't realise that they were inherited in this situation - I thought
you had to restate everything that was not the default. OK, so weight and
style probably *are* set to their default values but font usually defaults
to Times. I've learned something else today!

Martin Underwood wrote:

It's different in HTML and CSS.

In an HTML file, any attribute containing a space or non-alphanumeric
character must be quoted. *Any* attribute may be quoted.
(In XHTML, of course, all attributes must be quoted)

In CSS, a single value containing a space (eg Times New Roman) must be
quoted, but font names are about the only times you will need to worry
about this.

Keywords - ie, those defined by the CSS specs - must not be quoted. In
general, it's best to avoid quoting anything other than font names with
spaces in them.

The time yo use points is when you are specifying a print stylesheet.
Points are precisely defined for print. Different browsers and
platforms may interpret points in different ways according to screen
size - so it is far from a standardised system.

Word processors are designed to produce text for print. The dimensions
of the page and all objects on it are in fixed-size units, such as
points or cm. That doesn't work when you are designing for the web -
where it needs to be flexible and adaptable.

Ems are just another way of writing percentages, so are good for web
use.

The percentage is a size of the base font. This is whatever the user
defines it to be, to suit their viewing requirements. Forcing people to
read at font sizes other than what they are most comfortable with is
bad practice, and shows disrespect for the people reading your site.