Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.
Sign upHandle table cell backgrounds during display list generation for <table> #20034
Conversation
highfive
commented
Feb 13, 2018
|
Heads up! This PR modifies the following files:
|
highfive
commented
Feb 13, 2018
3b5ea02
to
32ece4d
|
Okay, I've gotten something working. Tables with styled columns/colgroups/rowgroups/rows/tables, that use colspan work. There are a couple of missing pieces:
For the last one, it's a bit tricky. I can handle it for row/rowgroup backgrounds by using the stackingcontext-relative position of the element for drawing the background, and then clipping it with the regular element's position. But for columns/colgroups, we don't store the positions anywhere. We kinda calculate these during border-collapse layout; so it might be worth adding a layout pass to compute these and store them on ColGroupFlow. Thoughts? |
|
Oh, also, a lot of this is made complicated by the fact that build_display_list needs a mutable reference, but looking through the code that may not actually be necessary. |
Yes, seems like this will be necessary (though this can be a follow-up if you want).
Yeah... many of the individual builder methods only take Does
Yes, this will need to be addressed. I haven't looked at your code in detail yet, but it seems there's not a clear place to fit this in, since I think row borders should be drawn after the backgrounds but before the cell contents? Or does this even matter – is it possible for the borders and backgrounds to overlap? If not, then we could draw the row borders in separate loop iterating over the rows... |
Yes. I can handle this by explicitly doing the damage (and nothing else) in TableCellFlow's build_display_list |
I think not -- however, it is possible for the border and content to overlap since content can spill out. Hmm. |
|
Made stuff immutable which lets me handle currentcolor easily |
|
@bors-servo try let's see what we get |
[WIP] Handle table cell backgrounds during display list generation for <table> Very WIP, currently just contains half the iterator work necessary to do this. Fixes #19788 <!-- Reviewable:start --> --- This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/servo/20034) <!-- Reviewable:end -->
|
|
|
Rowspan "done". Given that we don't actually render rowspans where we should, it's a bit lackluster. But if we did, they would have working backgrounds. |
|
Turns out borders are not skipped; table rows don't draw collapsed borders anyway, they delegate to cells! I'm pushing bg positioning to a different bug. There's one missing bit -- restyle damage doesn't get correctly applied here. I guess I should propagate it up in layout/incremental.rs? |
|
So we fail css/cssom-view/elementFromPoint-dynamic-anon-box.html . I thought this was due to restyle damage, but I tried fixing that in incremental.rs and this still occurs. |
|
|
||
| self.block_flow.build_display_list_for_block(state, border_painting_mode); | ||
| fn build_display_list(&mut self, _: &mut DisplayListBuildState) { | ||
| // handled in TableCellStyleInfo::build_display_list |
This comment has been minimized.
This comment has been minimized.
| if self.visible { | ||
| // we skip setting the damage in TableCellStyleInfo::build_display_list() | ||
| // because we only have immutable access | ||
| self.block_flow.fragment.restyle_damage.remove(ServoRestyleDamage::REPAINT); |
This comment has been minimized.
This comment has been minimized.
mbrubeck
Feb 16, 2018
Contributor
This should probably be unconditional. (I think this was a bug in the old code.)
f15cead
to
3dc3683
| if !self.cell.visible || self.cell.block_flow.fragment.style() | ||
| .get_inheritedbox().visibility != Visibility::Visible { | ||
| return | ||
| } |
This comment has been minimized.
This comment has been minimized.
mbrubeck
Feb 16, 2018
Contributor
I believe for empty cells (cell.visible == false), we should still draw the column and row backgrounds, just not the cell background and contents, per the spec: https://drafts.csswg.org/css2/tables.html#table-layers
This comment has been minimized.
This comment has been minimized.
Manishearth
Feb 16, 2018
Author
Member
I tested this in Firefox, it doesn't work for columns at least. The cell disappears entirely.
This comment has been minimized.
This comment has been minimized.
Manishearth
Feb 16, 2018
Author
Member
Or rows. It only works for the surrounding table, and we still handle that
|
@bors-servo r+ Thanks especially for factoring these traversals out into iterators. |
|
|
|
@bors-servo retry
|
Handle table cell backgrounds during display list generation for <table> Fixes #19788 <!-- Reviewable:start --> --- This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/servo/20034) <!-- Reviewable:end -->
|
|
|
Error in linux-rel-nogate error[E0425]: cannot find value `handle` in this scope
--> components/script/dom/xmlhttprequest.rs:1068:47
|
1068 | self.global().unschedule_callback(handle);
| ^^^^^^ not found in this scope
error: aborting due to previous error
error: Could not compile `script`. |
|
@bors retry new failures, probably intermittents
|
|
@bors-servo retry (I guess @Manishearth called wrong bors XD?) |
Handle table cell backgrounds during display list generation for <table> Fixes #19788 <!-- Reviewable:start --> --- This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/servo/20034) <!-- Reviewable:end -->
|
|
|
@bors-servo retry
|
|
|
|
|
|
@bors-servo retry
|
|
|
|
|
Manishearth commentedFeb 13, 2018
•
edited
Fixes #19788
This change is