cellspace in css

is it possible to set the cellspace of a table in a stylesheet ?

bat wrote on 20 aug 2003 in comp.infosystems.www.authoring.stylesheets:

is it possible to set the cellspace of a table in a stylesheet ?

Please define "cellspace"


--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

bat wrote:

is it possible to set the cellspace of a table in a stylesheet ?

If you mean the equivalent of the HTMl cellspacing attribute: in CSS2
it's border-spacing.
--
Johannes Koch
In te domine speravi; non confundar in aeternum.
(Te Deum, 4th cent.)

Brian <usenet1 (AT) mangymutt (DOT) com.invalid-remove-this-part> wrote:

equivalent of the HTMl cellspacing attribute: in CSS2 it's
border-spacing.

And note that this property takes effect only when border-collapse
has the value separate. Besides, IE does not support this
property, so the HTML attribute is often the practical choice at
present.

IE does not support border-spacing? Or does not support
border-collapse?

Sorry, my wording was obscure. I meant that IE does not support
the border-spacing property, and should have said this first, since
it's the most important point in practice. There's Microsoft's own
information about CSS support in IE at
<http://msdn.microsoft.com/library/default.asp?
url=/workshop/author/css/reference/attributes.asp>
and it does not mention border-spacing. It describes border-collapse
as supported by IE from version 5.0 onwards.

Note that the initial value of border-collapse is collapse, according
to the CSS 2.0 specification. Browsers (including IE) usually behave as
if the initial value were separate - which is permissible if we think
that this results from a browser's style sheet, but the CSS 2.1 draft
proposes that the specification be retrofitted to the industry
standard. Anyway, if you set border-spacing and really mean it, you
should set border-collapse too.

And do you know if the lack of support is limited
to IE/Win, or is IE/Mac the same?

According to http://macedition.com/cb/resources/a...sssupport.html
IE/Mac does not support border-spacing - or even border-collapse!

--
Yucca, http://www.cs.tut.fi/~jkorpela/

In article <Xns93E168A8E31DEjkorpelacstutfi (AT) 193 (DOT) 229.0.31> in
comp.infosystems.www.authoring.stylesheets, Jukka K. Korpela
<jkorpela (AT) cs (DOT) tut.fi> wrote:

There's Microsoft's own
information about CSS support in IE at
http://msdn.microsoft.com/library/default.asp?
url=/workshop/author/css/reference/attributes.asp

Does anybody besides me see a bunch of circumflexed capital A's
following many of the property names? (I'm using Moz 1.4 on Windows
98.)

--
Stan Brown, Oak Road Systems, Cortland County, New York, USA
http://OakRoadSystems.com
"In its default setup, Windows XP on the Internet amounts to a car
parked in a bad part of town, with the doors unlocked, the key in
the ignition and a Post-It note on the dashboard saying, 'Please
don't steal this.'" -- Washington Post, 24 Aug 2003

Stan Brown <the_stan_brown (AT) fastmail (DOT) fm> wrote:

http://msdn.microsoft.com/library/default.asp?
url=/workshop/author/css/reference/attributes.asp

Does anybody besides me see a bunch of circumflexed capital A's
following many of the property names? (I'm using Moz 1.4 on Windows
98.)

Me too. I don't think they were there when I last looked at the page,
but then again I'm accustomed to expecting unexpected things on
Microsoft's pages - they surely should not be taken at face value even
as describing IE behavior.

It seems that those characters precede the notes "(proposed)", and I
guess they result from some wrong conversion of data from another
format.

--
Yucca, http://www.cs.tut.fi/~jkorpela/

On Sun, Aug 24, Stan Brown inscribed on the eternal scroll:

http://msdn.microsoft.com/library/default.asp?
url=/workshop/author/css/reference/attributes.asp

Does anybody besides me see a bunch of circumflexed capital A's
following many of the property names?

Sure thing. The frame in question, whose URL is

http://msdn.microsoft.com/workshop/a...attributes.asp

is sent without an HTTP charset attribute, but it contains a
"meta" which purports its charset to be Windows-1252.

But in fact, the encoding of the content is evidently utf-8.

If you view the individual framed document and then manually set the
view coding to utf-8, it comes out right.

The overall frameset has a "meta" which is trying to set the charset
to utf-8, but this is useless in as much as the frameset document
itself doesn't have any content that's displayed on the framed page.

Strangely, if you view the whole frameset in Mozilla and then manually
set the view coding to utf-8 (even though it's already showing as
utf-8), it seems Mozilla makes it come out right. But of course this
is no solution, I'm only exhibiting it as a diagnostic technique.
And the trick doesn't seem to work in IE.

Even if the individual frame documents were to come without any meta
charset of their own, I don't know of any interworking specification
that would call for them to inherit the character encoding from the
frameset document's meta. AFAIK the regular interworking rules are
applied *individually for each framed document*, independent of the
overall frameset:

- the charset specified in the HTTP header takes priority, if present
- in its absence, any meta...http-equiv charset is used

And indeed that is only logical, since the encoding is a property of
the content of each framed document, and doesn't miraculously change
when it's incorporated into this or that frameset.

cheers