firefox table captions

[Johnny]

In MSIE table captions are displayed at the same size as content. But
in Firefox the text displays at browser default, It also exceeds the
width of the table and the excess is hidden if the table is enclosed in

a bounding div.

If caption is given a font-size (eg 0.8em) with CSS text it displays
correctly, however MSIE then shows the text too small.
Is there any way of applying a font-size to firefox table caption text
while keeping the correct display in other browsers? And also of
preventing the caption width exceeding that of the table?

[VK]

In MSIE table captions are displayed at the same size as content. But

in Firefox the text displays at browser default, It also exceeds the
width of the table and the excess is hidden if the table is enclosed in

Gecko browsers (incliding Firefox) implement W3C table box model. In
this (rather weird) model <captionand <tableare two separate
elements floating in an abstract "table frame" box which is not visible
and not DOM-accessible. That is despite the fact that you still have to
put <captioninsid e <tabletag. There is a number of glitches caused
by this not-so-bright standard, see for instance
"table caption 1px jog"
<https://bugzilla.mozill a.org/show_bug.cgi?id =333643- or your own
case.

You may try:

TABLE CAPTION {
font-size: 0.8em;

/* this will be parsed by IE only: */
font-size: expression("1em ");
}

[Patient Guy]

"VK" <sc**********@y ahoo.comwrote in
comp.infosystem s.www.authoring.stylesheets:

>In MSIE table captions are displayed at the same size as content. But
in Firefox the text displays at browser default, It also exceeds the
width of the table and the excess is hidden if the table is enclosed in

Gecko browsers (incliding Firefox) implement W3C table box model. In
this (rather weird) model <captionand <tableare two separate
elements floating in an abstract "table frame" box which is not visible
and not DOM-accessible. That is despite the fact that you still have to
put <captioninsid e <tabletag. There is a number of glitches caused
by this not-so-bright standard, see for instance
"table caption 1px jog"
<https://bugzilla.mozill a.org/show_bug.cgi?id =333643- or your own
case.

You may try:

TABLE CAPTION {
font-size: 0.8em;

/* this will be parsed by IE only: */
font-size: expression("1em ");
}

Text of an interactive HTML page posted as a Bugzilla comment which
demonstrates the Table Caption defect in Firefox/Mozilla browsers.

https://bugzilla.mozilla.org/show_bu...omment_text_10
Is there a "official" test suite that even bothers to determine the
correct styling of table captions, or is it every browser maker for
himself in the world of Undefined Recommendations ?

[VK]

Is there a "official" test suite that even bothers to determine the

correct styling of table captions, or is it every browser maker for
himself in the world of Undefined Recommendations ?

<http://www.w3.org/TR/CSS21/tables.html#q5>
"...the table box generates an anonymous box that contains the table
box itself and any caption boxes (in document order). The caption boxes
are block-level boxes that retain their own content, padding, margin,
and border areas, and are rendered as normal blocks inside the
anonymous box."

The idiots who invented this even bothered to draw a picture
illustrating their "creative" ideas (see the link). I hold my breath
that they were co-called "invited expert" ant that they are by now back
to the bar or wherever the hell they were invited from.
This way there cannot be any complains to Mozilla: they did exactly and
literally what W3C told them to do. Anyone doesn't like: address your
complains to W3C first.

The other producers simply have chosen common sense over specs.

[Patient Guy]

"VK" <sc**********@y ahoo.comwrote in
comp.infosystem s.www.authoring.stylesheets:

>Is there a "official" test suite that even bothers to determine the
correct styling of table captions, or is it every browser maker for
himself in the world of Undefined Recommendations ?

<http://www.w3.org/TR/CSS21/tables.html#q5>
"...the table box generates an anonymous box that contains the table
box itself and any caption boxes (in document order). The caption boxes
are block-level boxes that retain their own content, padding, margin,
and border areas, and are rendered as normal blocks inside the
anonymous box."

The idiots who invented this even bothered to draw a picture
illustrating their "creative" ideas (see the link). I hold my breath
that they were co-called "invited expert" ant that they are by now back
to the bar or wherever the hell they were invited from.
This way there cannot be any complains to Mozilla: they did exactly and
literally what W3C told them to do. Anyone doesn't like: address your
complains to W3C first.

The other producers simply have chosen common sense over specs.

Really???

Look the figure in section of your cited link.

It shows the bottom margin of the caption being measured with respect to
the first row of table cells.

Now you set the bottom margin of the caption to zero. Do you get the
caption box (its extent seen by using a background-color so that you can
see it?) touching the first row of table cells?

Should that NOT be the case?

The "official" caption TOP margin is coincident with the table TOP margin,
which does NOT happen to be the top margin of the first row of table cells
(which ought to drive anyone crazy: because the W3C recommendation
simultaneously seems to be saying that the caption is independent of the
table and also part of the table!!).

So should the extent of the caption be the space that it fills up
dependent upon its (textual) content? Or should it be with respect to
its obligations to be part of the table, and certainly with respect to its
position relative to the first row of table cells with top-positioned
captions?

This is probably not a problem for people who use captions and table cells
with IDENTICAL background colors which are also identical with the
background color of the table's (parent) container.

But when people actually want to use color (background colors), they are
in for a nightmare in styling things in a way that they look not just
nice, but even comprehensible, in 99% of the browsers used.

Again the question is put to you: if the caption bottom margin is zero,
then the caption should touch the top row of table cells and FF violated
the recommendation, right?

[VK]

This way there cannot be any complains to Mozilla: they did exactly and

literally what W3C told them to do. Anyone doesn't like: address your
complains to W3C first.

Really???

Well, I guess I have to take my words back.
CAPTION is screwed very severely on Firefox. To my surprise not a damn
thing is changed on 2.0

This liquid body layout demo:
<http://jsnet.sourcefor ge.net/tmp/caption.html>
shows that Firefox simply treats CAPTION as a block element before
TABLE element w/o any connection between each of them (just like
<div>somethin g</div<div>somethi ng</divwould go).

As a consolation IE retains the expected behavior *but* the liquid
layout gets nucked completely, which is even more serious I think.

Even W3C "Sweet heart" Amaya gets choked on CAPTION.

Opera gets it in the most right way but - as seems - messes up with
collapsing margings.

I think it should be a "Acid Table" test written and any producer
should be discouraged to pass/announce Acid2 test until "Acid Table"
is passed with full success. Otherwise it is like applying to a higher
school w/o having finished junior high.

[David Stone]

In article <11************ **********@e3g2 000cwe.googlegr oups.com>,
"VK" <sc**********@y ahoo.comwrote:

This way there cannot be any complains to Mozilla: they did exactly and
literally what W3C told them to do. Anyone doesn't like: address your
complains to W3C first.

Really???

Well, I guess I have to take my words back.
CAPTION is screwed very severely on Firefox. To my surprise not a damn
thing is changed on 2.0

A number of things are seriously borked with FF's html/css rendering
of tables, in no small part because the html4 and css2 specs say
conflicting things. Fixes are a very long way off:

https://bugzilla.mozilla.org/show_bug.cgi?id=915

Comment #270 pretty much sums it up. And I quote:

It's the longest bug i'v seen...
Here is my idea:
can we introduce a new pseudo-class?

No, this bug must not be solved! Ever!

The bug is a natural paradoxon in Mozilla. There is a theory which states
that
if ever anybody discovers a solution to it, Mozilla will instantly disappear
and be replaced by something even more bizarre and inexplicable.

However, there is another theory which states that this has already happened
with one or two other weird design bugs that were irresponsibly subjected to
resolution.

[VK]

https://bugzilla.mozilla.org/show_bug.cgi?id=915

Comment #270 pretty much sums it up.

These are emotions, not a constructive answer. Any widely used software
is a regular holly mess of patches, emergency stability fixes,
compatibility workarounds, security locks etc. Usually any new item
from the list brings an avalanche of other items and so on.

A pictorial sample of this in application to say Microsoft JScript can
be found at
<http://blogs.msdn.com/ericlippert/archive/2006/09/27/774117.aspx>

Inevitably some day the moment comes then you start getting
"unexplaina ble behavior" back. Say (rather close to a real sample) if
you are typing "abrakadabr a" and pressing Ctrl key the system hangs up:
but only if the mouse pointer is off the screen. But it doesn't hand up
in any case if 3rd party X program is installed: but X program gets its
printing nuked. From this point forward you have a choice i) spend your
life time trying to find the real reason or ii) just smash everything
and start from the ground. Everyone chooses the 2nd option so far: this
is how "fully rewritten, majorly improved" versions are appearing.

Mozilla is in the most difficult situation I guess because the code is
open. It means that all mess others have hidden under respectfully
looking .exe and .dll - all this mess would be exposed to the public.
So maybe it is a (subconscious) desire to "keep the underwear clean" as
you cannot hide it. I personally still would prefer CAPTION and other
basic things working as they were for the last 10-15 years; even if
some internal C++ proc will get a funny look because of that.

At the same time I do realize that Mozilla is having hard time in
paying back for doing the initial project so strictly and literally by
W3C papers. Many (way too many IMHO) of these papers were utopias a la
Saint-Simon and Fourier: thus maybe something great to read before to
go to bed - but a total disaster if one tries to implement it in the
real life.