Bugzilla

(In reply to Lenka Pelechova from comment #36)
> Could that be problem (in regards to table behavior) that the <thead> is within <tbody> ?

That is **a** problem, yes. I don't know if it's an important part of the main problem that you're investigating here, but it's definitely kinda-broken.

Specifically: let's ignore the extra `position:absolute` wrinkle for a minute....  The table nesting that you diagrammed above means that we actually end up with **two nested tables** here, because the inner `table-header-group` finds itself without the correct type of table-part parent box that it expects to have. So, it reacts to that by generating an **anonymous** `display:table` box to wrap itself in.  And in the frame tree, that anonymous box ends up being the child of the `table-row-group`, and the parent of the `table-header-group`.

Now, if we take the `position:absolute` into consideration, the misparenting is still there (but now our `table-header-box` is just parented by a `block` rather than the wrong sort of table-part) -- so the `table-header-group` still ends up generating an anonymous `display:table` wrapper box, either way.

So your intuition is right, I think, that it's probably saner for the thead to not be a child of the tbody.  (Having said that, there may be organizational reasons that the current structure depends on the grouping that it's got, but I imagine those could be addressed by other tweaks.)

(In reply to Lenka Pelechova from comment #36)
> Could that be problem (in regards to table behavior) that the <thead> is within <tbody> ?

That is **a** problem, yes. I don't know if it's an important part of the main problem that you're investigating here, but it's definitely kinda-broken.

Specifically: let's ignore the extra `position:absolute` wrinkle for a minute....  The table nesting that you diagrammed above means that we actually end up with **two nested tables** here, because the inner `table-header-group` finds itself without the correct type of table-part parent box that it expects to have. So, it reacts to that by generating an **anonymous** `display:table` box to wrap itself in.  And in the frame tree, that anonymous box ends up being the child of the `table-row-group`, and the parent of the `table-header-group`.

Now, if we take the `position:absolute` into consideration, we've still got a version of that same misparenting issue (but now our `table-header-box` is just parented by a `block` rather than the wrong sort of table-part) -- so the `table-header-group` still ends up generating an anonymous `display:table` wrapper box, either way.

So your intuition is right, I think, that it's probably saner for the thead to not be a child of the tbody.  (Having said that, there may be organizational reasons that the current structure depends on the grouping that it's got, but I imagine those could be addressed by other tweaks.)

(In reply to Lenka Pelechova from comment #36)
> Could that be problem (in regards to table behavior) that the <thead> is within <tbody> ?

That is **a** problem, yes. I don't know if it's an important part of the main problem that you're investigating here, but it's definitely kinda-broken.

Specifically: let's ignore the extra `position:absolute` wrinkle for a minute....  The table nesting that you diagrammed above means that we actually end up with **two nested tables** here, because the inner `table-header-group` finds itself without the correct type of table-part parent box that it expects to have. So, it reacts to that by generating an **anonymous** `display:table` box to wrap itself in.  And in the frame tree, that anonymous box ends up being the child of the `table-row-group`, and the parent of the `table-header-group`.

Now, if we take the `position:absolute` into consideration, we've still got a version of that same misparenting issue (but now our `table-header-box` is just parented by a `block` rather than the wrong sort of table-part) -- so the `table-header-group` still ends up generating an anonymous `display:table` wrapper box as its parent, either way.

So your intuition is right, I think, that it's probably saner for the thead to not be a child of the tbody.  (Having said that, there may be organizational reasons that the current structure depends on the grouping that it's got, but I imagine those could be addressed by other tweaks.)

(In reply to Lenka Pelechova from comment #36)
> Could that be problem (in regards to table behavior) that the <thead> is within <tbody> ?

That is **a** problem, yes. I don't know if it's an important part of the main problem that you're investigating here, but it's definitely kinda-broken.

Specifically: let's ignore the extra `position:absolute` wrinkle for a minute....  The table nesting that you diagrammed above means that we actually end up with **two nested tables** here, because the inner `table-header-group` finds itself without the correct type of table-part parent box that it expects to have. So, it reacts to that by generating an **anonymous** `display:table` box to wrap itself in.  And in the frame tree, that anonymous box ends up being the child of the `table-row-group`, and the parent of the `table-header-group`.

Now, if we take the `position:absolute` into consideration, we've still got a version of that same misparenting issue (but now our `table-header-box` is just parented by a `block` rather than the wrong sort of table-part) -- so the `table-header-group` still ends up generating an anonymous `display:table` wrapper box as its parent, either way.

So your intuition is right, I think, that it's probably saner for the `thead` to **not** be a child of the ``tbody`` (to avoid generating unexpected extra nested tables).  Having said that, there may be organizational reasons that the current structure depends on the grouping that it's got, but I imagine those could be addressed by other tweaks.