Gecko:Border collapse: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
Line 31: Line 31:
* <tt>position: absolute</tt> and <tt>position: fixed</tt> cells are taken out of flow, and thus have no longer influence on border conflict resolution. This is (5) above.
* <tt>position: absolute</tt> and <tt>position: fixed</tt> cells are taken out of flow, and thus have no longer influence on border conflict resolution. This is (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 <tt>position: static</tt> and when it is in <tt>position: relative</tt> without any offset, even if borders are antialiased/transparent. That seems to rule out (4) and (5) for relative positionning.
* 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 <tt>position: static</tt> and when it is in <tt>position: relative</tt> without any offset, even if borders are antialiased/transparent. That seems to rule out (4) and (5) for relative positionning.
Since when does rel. positioning of cells work? Abs. and fixed cells will be wrapped by pseudos. (Bernd)


== Who paints what ==
== Who paints what ==

Revision as of 17:53, 10 February 2006

This page aims at discussing the move of BC borders painting from table to cells. [ When I have time, I'll make and attach mockups/explanation pictures ]

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. This is (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) and (5) for relative positionning.

Since when does rel. positioning of cells work? Abs. and fixed cells will be wrapped by pseudos. (Bernd)

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 wholly paints each adjacent border (unless doesn't want to, for example if positionned and proposition 1 is choosen). Problems of overlapping to solve, especially with transparent borders. Probably slow, too. Adapted to any proposition but (2). (3) needs more work, because if the adjacent cell is positionned the border shouldn't be drawn.
  2. Each cell paints its inner half of each adjacent border. Clearly adapted to the (2)nth proposition above. Subject to the same difficulties as touching divs in an antialiased backend ?
  3. Each cell paints wholly the adjacent borders for which it is the winner, that is has the winner of conflict resolution as its own (asked for) border. Adapted to any proposition but (2). Edge cases: when the winner belongs to a positionned cell and proposition 1 or 4 is choosen, same if winner does not belong to the positionned cell and 3 or 4 is choosen.