Gecko:Border collapse

Revision as of 00:42, 10 February 2006 by Frnchfrgg (talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

This page aims at discussing the move of BC borders painting from table to cells.

Rationale

The current way Gecko handles border-collapse: collapse tables is to let the table paint all borders. Thus, the table paints its background, then tells its cells to repaint their background and content, but not their borders, and finally draws borders on top of cells.

This approach has several drawbacks:

  1. The borders of the table always are on top (for an example of problem, a relatively positionned cell with appropriate z-index to put it on top shouldn't have the collapsed borders over it)
  2. The borders do not scroll with the cells (see https://bugzilla.mozilla.org/show_bug.cgi?id=135236)
  3. Border painting must rely on ad-hoc, complicated code to decide which borders must be redrawn in a paint event
  4. visibility: collapse does not reflect on borders (see https://bugzilla.mozilla.org/show_bug.cgi?id=242997)
  5. Because successive borders with same style are grouped together in the border chunks cache, a local change (e.g. border color of hovered cell) must trigger a recalculation of the borders chunks

Overall, the code is complicated; it is hard to fight one's way through BCMapIterator logic, for instance.

The Right Way (TM)

Cells will paint their borders, so the current calculation of border chunks will disappear, but Gecko will still be calculating wining borders and store them in the cellmap during reflow: this calculation is too slow to be afforded during paint.

Positionned cells

Discussion about the rendering of positionned cells is put here because possible implementations aren't equally adapted to each choice here.

When a cell is positionned, it can

  1. Leave adjacent borders where they are, and move without them
  2. Move with its inner half of adjacent borders, leave the other half in place
  3. Take the whole adjacent borders with it
  4. Leave borders, but draw a copy (or the inner half of the copy) of them around itself
  5. Behave as if it were alone in another table, that is in conflict resolution for the rest of the table, (asked for) borders of positionned cell are ignored, and the cell draws its (or the inner half of its) borders around itself

People in the know (e.g. roc, bernd, etc) seem to agree on those:

  • position: absolute and position: fixed cells are taken out of flow, and thus have no longer influence on border conflict resolution. Thus (5) above.
  • There shouldn't be any difference of rendering of the table (apart from what depends on the cell being a positionned ancestror) when the cell is in position: static and when it is in position: relative without any offset, even if borders are antialiased/transparent. That seems to rule out (4).


Who paints what

In the collapsed borders model, borders are shared among cells; thus there are several possibilities to consider for painting:

  1. Each cell paints its inner half of each adjacent border.