Closed Bug 61125 Opened 25 years ago Closed 25 years ago

Box edge properties without explicit width do not suffice for tables

Categories

(Core :: Layout: Tables, defect, P3)

Product:
Core
Component:
Layout: Tables
Platform:
x86
Windows NT
Type:
defect

Tracking

()

Status:
RESOLVED INVALID

People

(Reporter: decoy, Assigned: karnaze)

References

(
URL
)

Details

(Keywords: css2, testcase)

Attachments

(3 files)

Testcase showing current behaviour and describing the behaviours as I understand them.
562 bytes, text/html
Details
A better testcase for bug (?) 61125, with CSS props completely determined
1.40 KB, text/html
Details
Test case showing IE's incorrect behaviour
958 bytes, text/html
Details
As per CSS2, the width of a block level box should be equal to content-width+left-margin+right-margin+left-padding+right-padding+left-border+right-border. This would mean that setting style="margin:0; border:0; padding:0" without touching width should produce width=100%. With tables, this does not seem to happen at least in Mozilla m18. Using table-layout:fixed with column widths set in percent, and a stylesheet heavy with overloaded property assignments (at http://www.iki.fi/~decoy/shared/style/dc-mono/dc-mono.css).
hmm... The problem here is that you feel that because you set table-layout:fixed and padding and margins to zero means that the width value is set to 100%? My first reaction is that this is wrong because not setting width does not mean size to 100% rather it means IMO 'auto'. And auto just sets column width to the widest content cell. BTW, I like your table renderings. :-) I think I suggest INVALID here.
Stylesheet changed and now at http://www.iki.fi/~decoy/shared/style/dc-mono/dc-mono-10.css. After looking once more at the CSS2 spec, I still feel this has to do with general confusion inside CSS itself. In CSS, tables can either be used as something with an intrinsic width (calculated through the autosizing algo) or as usual blocks with the width set from outside. The spec does not unambiguously tell which principle is used to set the width in my case. Logically, the difference should come from table-layout:fixed/auto. I think the verbiage on fixed layout and width:auto implying automatic layout has to be more or less a slip in the CSS spec.
ccing hixie to get his opinion on this one
I think this is INVALID. CSS2 special cases tables so that width:auto with tables does _not_ mean "fill the parent" it means "use my intrinsic width". In fact IIRC width:auto actually overrides table-layout:fixed -- you can only trigger fixed layout if your table width is specified.
Keywords: css2
Whiteboard: INVALID?
The spec indeed says this for tables. *But it never explicitly states that this overrides the width calculation specified for blocks.* Plus, IE does it my way and you lose in both expressivity and regularity if tables are treated as a special case even when table-layout:fixed. It seems pretty clear that with the latter, tables were meant to behave more or less like blocks. I'm questioning whether the language on width:auto was meant to be in the CSS spec, and failing that, the spec's internal consistency.
From CSS2, 17.5.2: # Automatic table layout # In this algorithm (which generally requires no more than two passes), the # table's width is given by the width of its columns (and intervening borders). # [...] UAs are not required to implement this algorithm to determine the table # layout in the case that 'table-layout' is 'auto'; they can use any other # algorithm. Are you _sure_ that Windows IE treats width:auto on a table as meaning that the table should have the width of the containing block? This surprises me greatly. In fact, in my testing it does not. See attached testcase.
Keywords: testcase
Did you read the original report? You haven't set margin:0;border:0;padding:0. Go see the URL in the report with IE5.5 for an example to the contrary. I feel that the language on (table-layout:fixed;width:auto == table-layout:auto) was added to get fallback in case the width is not completely determined from box edge properties - in this case it is sensible that tables, with their special property of having a sort of intrinsic width as well, would have their width calculated by the auto layout algo. I think somebody forgot that width:auto alone does not mean that the width isn't fully determined. What we end up with if we go the current Mozilla way is that if I want table width to be 100%-2ex reserved for absolute margins, I have to insert a div around the table, scale the table to 100% of the div and use the div to get the desired effect, which works since it's a box. But this is presentational markup, the necessity of which could hardly have been the purpose of the CSS2 designers.
What you have found is a bug in IE. See my new testcase -- the only difference between the two tables is the value of 'table-layout', but since 'width' is set to 'auto' the value of 'table-layout' should be ignored, so the tables should display identically. This does not occur in IE. This is per CSS2:17.5.2 which reads: # A [width] of 'auto' (for both 'display: table' and 'display: inline-table') # means use the automatic table layout algorithm.
Status: UNCONFIRMED → RESOLVED
Closed: 25 years ago
Resolution: --- → INVALID
Nope. Please fine comb the preceding discussion - I think this is a bug in CSS2, not IE. The spec does say precisely what you tell it says, where you say it says it. But it also says that display:table makes the element a (non- replaced) block element and gives an explicit algorithm form calculating the width of the latter in my example. In my situation, then, you have two contradictory ways of determining the width, and no verbiage in the spec to resolve the inconsistency. As I think the IE way is by far the better one and more consistent with CSS's block model (for reasons cited above), I think it is not at all clear that the part of the spec you cite above should be followed, even while it is clearly more specific than the block width calculation part.
Do you agree that in the last testcase I attached, both tables should, according to the specification, be rendered the same way?
No, I don't. This is precisely the case I'm worrying about. Even though the section on table width calculation says your table "a" should be rendered with the auto layout algo, I read the spec from the standpoint of tables being blocks and the standard block width calculation applying. In this case, the edge properties determine the width, which is pretty useful and generally fits better with CSS2's handling of the block model. I still haven't found anything in the spec to tell unambiguously which of these two ways is the right one. The effect in the test case I posted (fixed margins on a stretchy table) cannot be achieved *at all* if we go with what the table layout section says. For normal blocks this is possible and enjoys applicability. But I'm repeating myself on a bug marked as "resolved invalid". I think I'll stop stealing your time and try to get a hold of the CSS2/3 people. 'Have any ideas who is responsible for the table rendering model?
Keep stealing my time, I'm a member of the CSS working group. ;-) I do not understand how you can interpret this paragraph in any way that does not mean that the two tables in the last test case should be drawn differently: # The table's width may be specified explicitly with the 'width' property. A # value of 'auto' (for both 'display: table' and 'display: inline-table') means # use the automatic table layout algorithm. I am not arguing about _what_ layout is correct, merely that they should be the same for both tables. Both tables should use the same algorithm, no?
Whiteboard: INVALID?
CSS WG, eh? Beautiful. That is not the only paragraph I'm interpreting - that one means precisely what you say. But it does not explicitly say is that it overrides the width calculation rules for generic blocks, even while tables are blocks. So the spec effectively lets you do it *both* ways, and does not explicitly address which way is the correct one. Specs aren't supposed to let you guess. I've already explained why I think going by the paragraph you cite is harmful, even if it is explicitly spelled out in the spec - relevant only because what I'm saying is in the spec *as well*. So my view is that we should, in this particular circumstance, treat tables as normal blocks and calculate the width the way we do for blocks in general. That leads to width:100%;. And no, I don't think the algo should be the same as that loses some semantics compared to my preferred interpretation, and there is room for liberal interpreation when a spec is (? I'm still not sure...) self-contradictory.
Ok, so far I was just trying to ascertain that there is no way that the two tables in my last test case should ever be done differently, as IE, in fact, does. In other words, IE is buggy in that respect. I believe we are now agreed on that issue. (Yes?) However, this does not address the issue of exactly _which_ rendering, given the two possible ones, should be used for both of those tables. Since the layout algorithm that is specified is the Automatic Layout Algorithm, let us look in that section of the spec (17.5.2.automatic). The first thing we see is: # UAs are not required to implement this algorithm to determine the table # layout in the case that 'table-layout' is 'auto'; they can use any other # algorithm. Assuming that we _do_ use the given algorithm, though: # If the 'table' or 'inline-table' element has 'width: auto', the computed # table width is the greater of the table's containing block width and MIN. # However, if the maximum width required by the columns plus cell spacing or # borders (MAX) is less than that of the containing block, use MAX. ...where MIN and MAC are defined in the paragraphs immediately prior to the quoted paragraph. This seems to me to explicitly override section 10 of CSS2. No?
My whole point has been that the two tables should ideally render differently: one sized as a normal block, one sized by the auto layout algorithm. We're nowhere near agreement yet. The funniest thing is that you quote CSS2 on auto layout: "UAs are not required to implement this algorithm to determine the table layout in the case that 'table-layout' is 'auto'; they can use any other algorithm." We could say that IE uses some other algorithm, and is well within the spec, no? Effectively, the handling of {table-layout:fixed;width:auto} is not specified in CSS2, so why not go with the nicest possible solution? Again, I've already explained why I think the IE approach is just that... Then you quote further and say: "This seems to me to explicitly override section 10 of CSS2. No?" No. My view is that if section 10 does not explicitly say "tables are an exception", you shouldn't be able to override it AT ALL. Failing that, you would have to state very explicitly and visibly that this particular later utterance overrides section 10. CSS2 does not. This is standards text; I think it's supposed to be taken precisely as written. When standards say one thing and then another, they become self-contradictory and must be corrected, not interpreted.
CSS2's description of tables requires interpretation. That's the sad truth...
Indeed. What I'm really saying is that after one has established that a standard is ambiguous, all bets are off - one simply cannot assume without very good extra arguments that one thing said by an ambiguous standard is better than another. Even if the thing is very explicit, as in this case. I've been trying to point out the ambiguity and that its existence justifies radically reinterpreting the intention behind a specific CSS2 clause (namely, that table- layout:fixed and width:auto implies automatic layout).
Just because there is one unclear statement in the spec, it doesn't mean that the entire spec is ambiguous. I agree that in the automatic layout mode, correct behaviour is ambiguous. It is *explicitly* so -- only a suggested algorithm is given, the entire section is informative not normative. However that does not in any way invalidate the previous, totally clear and unambiguous statement saying that 'table-layout' is treated as 'auto' if 'width' is 'auto', and if you use the same layout mode in both cases, I cannot see _any_ way in which the layout algorithm could end up with two DIFFERENT renderings in the testcase for each table. The *only* difference between the two tables is 'table-layout', and the spec says to treat it as 'auto' both times. Since you come to a different conclusion, at which point in this line of reasoning do you think I made my mistake?
The mistake is in the part saying "totally clear and unambiguous statement saying that 'table-layout' is treated as 'auto' if 'width' is 'auto'". It is ambiguous, because it's already been said that tables are blocks. They have their own width rule which, by my reasoning, you cannot override; the text in the tables section *creates* the inconsistency. In my mind this gives us lots of room for interpretation. So I considered the intent behind the spec instead of what is spelled out, and the only sane reason I find for treating tables as they are is that there is some tension between laying tables out as non-replaced blocks and treating them rather like pictures with an intrinsic size. As the latter happens only when using auto layout, it seems sound to assume that the intent has been to regard tables as normal blocks when using fixed layout, and more or less lay them out as replaced blocks with auto. Why else would we have a table-layout property? I can't see any reason for the table-layout:fixed;width:auto part other than to provide a separate, better than usual fallback in case the width is not completely determined. But it can be even when width:auto, since the edge properties could still be used to calculate the width in the usual way. So I'm lead to conclude that what was meant to be said is that if table-layout is fixed and the width is *underdetermined*, then use automatic layout. That at least makes sense, though my own preference would be to go by the reasoning in the previous paragraph and remove the clause altogether. But I'm not the one in the CSS WG. I think something akin to the above is behind IE's behavior. In the first drafts of my stylesheet, I tried what I'm doing now and it didn't fly. So I went with width:100% and couldn't get 1ex margins. This is not nice at all, since the only way to get around it is to use what amounts to presentational markup. How could that be CSS's intent?
The CSS working group is discussing this as we speak, stay tuned...
INVALID. Please see the CSS2 errata, which now reads (clarification section): # Section 17.5.2 Table width algorithms # Add the following paragraph after the initial paragraph of this section: # # Note that this section overrides the rules that apply to calculating widths # as described in section 10.3. In particular, if the margins of a table are # set to '0' and the width to 'auto', the table will not automatically size to # fill its containing block. However, once the calculated value of 'width' for # the table is found (using the algorithms given below or, when appropriate, # some other UA dependenant algorithm) then the other parts of section 10.3 do # apply. Therefore a table can be centered using left and right 'auto' margins, # for instance. # # The WG may introduce ways of automatically making tables fit their containing # blocks in CSS3. - http://www.w3.org/Style/css2-updates/REC-CSS2-19980512-errata.html#table-width Please REOPEN this bug if you feel this issue has not been clearly resolved. Thanks!
QA contact update
QA Contact: chrisd → amar
*** Bug 15248 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: