« Around The World In 22 Days | Main | Avalon Lockdown »
June 16, 2005
display:inline and tables
<div>Hello <table style="display:inline">...</table> Kitty</div>
The intent seems to be to create an inline table. Unfortunately
the CSS spec currently says otherwise:
- "display:inline" turns the table element into a regular inline element, not a table at all.
- The presence of table rows and columns causes an anonymous table box to be created to wrap them. This happens to be in roughly the same place as the original table element.
- The spec is quite clear that this anonymous table box has "display:table". (It says "a box corresponding to a 'table' element will be generated between P and T", and the default style sheet is clearly "table { display: table }".)
- This is a block-level box inside an inline box, which causes complicated splitting to happen. But the important thing is that this table box will be on its own line, not inline.
Currently, in Gecko we have a bug which effectively causes the anonymous table to be treated as an inline-table, usually (but not always!). Because we don't really support inline-table, it probably doesn't work the way an inline-table should.
What should we do? There are a few possibilities:
- Fix our code so that the anonymous table is a block-level table, according to spec. Then get everyone who relies on our behaviour to fix their sites --- soon, before Firefox 1.1 is released. One big problem here is that because we don't support inline-table or inline-block, there may be no way to work around the removal of this feature/bug.
- Get the spec changed so that when the parent box is an inline box, the anonymous table is made an inline-table. Then change our code to support inline-table as best we can before release.
- Leave the spec as is, but implement inline-table so people can get the old behaviour.
I'm leaning towards the second option, but any feedback would be helpful.
Posted by roc at June 16, 2005 1:39 PM
Comments
Ideally the third one, if there is contributor who is able to make such changes...
Posted by: minghong at June 16, 2005 4:11 PM
Option 1 would require a split between standards and quirks mode. This thing is pretty common, so we would need to have a quirk for it. I would say the spec is contradictory to what one would expect, as if I specify display:inline on something I do it just to avoid a new block context and the creation of a new line. At least it did never come to my mind that we should move the table onto a new line.
Option 1 without option 3 is not an option.
Fixing bug 18217 seems like a good idea anyway, but moving people to untested code seems like a bad idea to me, when the tree is already frozen. In the last time I worked on the fallout from the scrollframe landing, so I know what I am talking about.
Posted by: Bernd at June 16, 2005 4:50 PM
Safari turns display:inline into inline-table. We had a bunch of bugs on this from sites that coded to WinIE. I highly recommend using inline-table as the solution to this problem.
Posted by: hyatt at June 16, 2005 5:01 PM
Forgive me if i've misunderstood, but am i right to understand that you're suggesting a change to the spec just because one browser is broken?
What is the state of other browsers supporting this feature?
Posted by: Anko at June 16, 2005 5:07 PM
hyatt: I assume you mean you make the anonymous table box an inline-table, rather than make the actual element an inline-table, which would be rather egregious...
bernd: I agree
Anko: you misunderstood. What IE is doing is broken. And because of that, current usage and implementations are inconsistent with the spec. I'm suggesting we change the spec so that what every major browser currently does, and what Web authors expect, is correct.
Posted by: Robert O'Callahan at June 16, 2005 5:30 PM
As others have stated, I think updating the spec to meet the behaviour of the current implementations is probably the best option. It wouldn't be the first time it was done; CSS2.1 changes the default value for border-collapse from collapse to separate based on the default used by "several popular browsers".
http://www.w3.org/TR/2005/WD-CSS21-20050613/changes.html#q19
Posted by: Andrew Smith at June 16, 2005 6:58 PM
hyatt, roc: I think turning automagically 'inline' into 'inline-table' is not a good solution, impacting people who *need* to flatten tables that way for accessibility reasons. Please remember that's the kind of things I do for small screen rendering in Minimo.
Posted by: Daniel Glazman at June 16, 2005 7:14 PM
The overflow:auto fails in table element, too (and others)
Posted by: delaPipol at June 16, 2005 10:02 PM
Daniel: I am not proposing to turn 'inline' into 'inline-table'. I am proposing that when an anonymous table box is generated (e.g., when we encounter a naked element with 'display:table-cell' or 'display:table-row'), it be given "display:inline-table" if its parent box is an inline box, "display:table" otherwise. So your table-flattening stylesheet would not be affected. This is a *very* small change to the spec.
I'm not sure exactly what hyatt is proposing, or what Safari does.
Posted by: Robert O'Callahan at June 16, 2005 10:12 PM
I like option 2.
Is this something what could be generalized in css?
When you have this for example:
<div style="display:inline;">
<div style="display:table-cell;"></div>
</div>
you also get display:inline-table; for the generated anonymous table?
Posted by: Martijn at June 16, 2005 10:33 PM
roc: yes, yes, no worries, I was more replying to hyatt's suggestion.
Posted by: Daniel Glazman at June 17, 2005 12:28 AM
I'd prefer just sticking to the spec and implelenting inline-*.
Posted by: ant at June 17, 2005 2:11 AM
Martijn: my proposal #2 would do that.
ant: that requires a lot of web sites to be changed. I also think the proposed change is both simple and more intuitive for web authors and is therefore a good idea even if web authors weren't already depending on it.
Posted by: Robert O'Callahan at June 17, 2005 8:32 AM
We, too, are depending on the current behavior to solve a problem which is caused by the lack of ability to use inline-block, and solution 1 would cause breakage of that, with no way to fix.
With regard to solution 3, that would mean we have to change our current code:
table {
display:inline;
}
into:
table {
display: inline;
display: table-inline;
}
Where the display inline is there in order to make it still work in FF 1.0. So I guess that’s feasible.
So I am personally in favour of solution no. 2, because that makes the most sense and would cause the least trouble with existing sites, but I wouldn’t mind solution 3 either, if the standards people want that.
~Grauw
Posted by: Laurens Holst at June 18, 2005 5:05 AM
I *strongly* support solution no 3.
btw something seems to be wrong with the preview feature - when I selected it the Comments box didn't populate.
Posted by: Carl Parrish at June 23, 2005 3:33 PM
If I'm not misunderstanding things here, option 2 has been approved by the CSSWG at the last telecon.
Posted by: fantasai at July 12, 2005 4:32 PM