Eyes Above The Waves

Robert O'Callahan. Christian. Repatriate Kiwi. Hacker.

Thursday 16 June 2005

display:inline and tables

We have run into a problem. Some important Web sites have HTML like this:

<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:

  1. 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.
  2. 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.
  3. 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.


Comments

minghong
Ideally the third one, if there is contributor who is able to make such changes...
Bernd
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.
hyatt
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.
Anko
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?
Robert O'Callahan
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.
Andrew Smith
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
Daniel Glazman
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.
delaPipol
The overflow:auto fails in table element, too (and others)
Robert O'Callahan
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.
Martijn
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?
Daniel Glazman
roc: yes, yes, no worries, I was more replying to hyatt's suggestion.
ant
I'd prefer just sticking to the spec and implelenting inline-*.
Robert O'Callahan
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.
Laurens Holst
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
Carl Parrish
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.
fantasai
If I'm not misunderstanding things here, option 2 has been approved by the CSSWG at the last telecon.