hi all, i'm here again.
i couldn't find/understand this on w3c css2 recommendation and
documentation, then here i ask.

i decided to still use some tables in my pages for some forms. i
played around with divs and whatever else for some time, but getting
things done correctly across multiple browsers requires too much time.
with tables, things come pretty easy and, since i'm using these only
inside our company, this is 100% ok. i mean: for this application this
is the best and easiest way to do the things, even if i know there are
better ones.

i'm using css2 for colours, paddings, margins, sizes and so on because
of their flexibility and comfort when needing to change something.
being w3c-anything-compliant at the moment isn't important --even if
my pages are validated by w3c, just to loose few minutes to check.

i have some classes for tables and td's that i'm using for the tables
containing the forms; however, i couldn't understand how to specify
number of columns in the tables' classes.

i seem to understand that there is no attribute for a td class to tell
the browser that those cells needs to span over a number of columns
(or rows, sometimes), then that i have to keep the rowspan's and
colspan's inside the html.

in other words, i need the css "equivalent" for the attribute
"cols=xx" of a <tabletag and, if it exists (but i don't think so),
the css "equivalents" for the attributes "colspan=xx" and "rowspan=yy"
of a <tdtag.

as always, i'll appreciate any suggestion.

we're closed for holidays during these days, then i may not be able to
read your replies (and to thank you) until next week. i'll do my best
to use some online news service like google groups (even if with a
mobile it's all but easy here in italy :)

regards,
--
Gianni Rondinini (31, tanti, RA)
Nikon user - Bmw driver
http://bugbarbeq.deviantart.com

Gianni Rondinini wrote:

i have some classes for tables and td's that i'm using for the tables
containing the forms; however, i couldn't understand how to specify
number of columns in the tables' classes.

The number of colums that a given cell spans is a matter of semantics
("This bit of data relates to both these columns of data"), not a
matter of presentation, so CSS is the wrong tool to specify this.

Gianni Rondinini schrieb:

in other words, i need the css "equivalent" for the attribute
"cols=xx" of a <tabletag

There is no cols attribute for the table element in HTML.
--
Johannes Koch
In te domine speravi; non confundar in aeternum.
(Te Deum, 4th cent.)

Gianni Rondinini <bugbarbeq@icem.itwrote:

>in other words, i need the css "equivalent" for the attribute
>"cols=xx" of a <tabletag and, if it exists (but i don't think so),
>the css "equivalents" for the attributes "colspan=xx" and "rowspan=yy"
>of a <tdtag.

If tables are used correctly, then colspan and rowspan provide
structural information that belongs in the markup, not in an optional
styling language such as CSS. There are no equivalents for these table
properties in CSS.

--
Spartanicus

Gianni Rondinini wrote:

i have some classes for tables and td's that i'm using for the tables
containing the forms; however, i couldn't understand how to specify
number of columns in the tables' classes.

You don't. Rowspan and colspan aren't just presentational suggestions.
They are an intrinsic structural property of a table cell defining the
relationship of its content to the remaining data in the table. They
belong in the HTML and will remain there as attributes of the TD and TH
elements.

Spartanicus wrote:

Gianni Rondinini <bugbarbeq@icem.itwrote:
>
If tables are used correctly, then colspan and rowspan provide
structural information that belongs in the markup, not in an optional
styling language such as CSS. There are no equivalents for these table
properties in CSS.

In CSS you can replicate a typical newspaper layout with a headline
spanning two (or more) columns, but in CSS you have to force floating
divs to make it happen which is why CSS is actually not perfect for
mark-up.

What you would do is:

<h1 style="width: 100%">Title for this area</h1>
<div style="width:100%">Summary paragraph ...</div>
<div style="width: 49%; float: left">Column 1</div>
<div style="width: 49%; float:left">Column 2</div>

As can be seen, this is clearly a style issue and not a semantic one
since semantically it reads perfectly. However to make sense on the
displayed page,you have to control the break point for the column in
the content - which therefore involves making a styling decision within
the content - not a true style/semantic separation (yes I know tables
force this on you too).

For spanning rows (eg for a sidebar) you can float the side bar:

<div style='width:20%; float: right'>Sidebar contents</div>
<p>Main text paragraph1</p>
<p>Main text paragraph2</p>

However this floating divs solution now forces the problem that the
semantically the side bar comes before the content, when you would
expect it to be maintext1 maintext2 sidebar.

Ideally you would use:

<p>Main text paragraph1</p>
<p>Main text paragraph2</p>
<div style='width:20%; float: right'>Sidebar contents</div>

But it won't work as the right float will happen after display the
paragraphs. You can use absolute positioning but I really advise
against it as a layout method (eg what happens if someone wants a
larger font size). Again CSS is forcing a style decision into the
content.

The other thing is the sidebar will only be the length of the text it
contains. You can force the height of the sidebar to try to get a
tabular display but you don't know the height of the text in the
paragraph - which will depend on the font size. If I remember sometimes
height: 100% might work within a containing div holding the whole of
the page, but I don't think it's consistent across browsers.


Saul
www.notanant.com

hi all.

i've read all your replies and thank everybody for explanations.

i'm happy i was right about the impossibility to specify colspan and
rowspan in css's: i'm not completely stupid, then :)

about the first question, that is the one in the subject, i want to
say that once there was the possibility to specify a table this way:
<table class="blah" cols="nn">
to tell the browser that the number of columns of that table is nn.
this allowed (and still works) the browser to show the table *while*
it was loading and not only after the whole thing was received by the
browser.
this is still useful because unfortunately broadband dsl's still
aren't available everywhere (in italy, at least) and seeing a table
growing while you receive it may be a nice thing for the user.

i'm working on some heavy pages that are used only by my workers, but
they see them both when inside our company and when they're somewhere
else and are using our intranet with a mobile phone, which offers a
very limited bandwitdh.

this is why i always used the "cols=nn" attribute in html (perhaps
it's deprecated, but still does its work) and wanted to move it in
css, since it makes my pages non-html-strict. being validated doesn't
add any real value to my intranet, but this is something i would have
liked.

thanks in advance, as usual.
--
Gianni Rondinini (31, tanti, RA)
Nikon user - Bmw driver
http://bugbarbeq.deviantart.com

Gianni Rondinini schrieb:

this is why i always used the "cols=nn" attribute in html (perhaps
it's deprecated, but still does its work)

It's not deprecated because it never existed in HTML (as defined by the
specification).

and wanted to move it in
css, since it makes my pages non-html-strict. being validated doesn't
add any real value to my intranet, but this is something i would have
liked.

Maybe you should have a look at the table-layout property
(<http://www.w3.org/TR/REC-CSS2/tables.html#propdef-table-layout>).

--
Johannes Koch
In te domine speravi; non confundar in aeternum.
(Te Deum, 4th cent.)

Johannes Koch wrote:

Maybe you should have a look at the table-layout property
(<http://www.w3.org/TR/REC-CSS2/tables.html#propdef-table-layout>).

This is rarely supported for CSS rendering of HTML.

It came about because of possible past intentions of using CSS to
render non-HTML XML directly. As HTML already has a <tableelement to
use, there's no real need for it and so it didn't get used or
implemented. I'd recommend avoiding it.