(In reply to Emilio Cobos Álvarez [:emilio] from comment #1) > Daniel, do you happen to know some of the context behind having colgroups (but not rowgroups!) in a separate list? It seems we could probably deal with them similarly to rowgroups which just are on the principal list... No, I don't know the context -- sorry -- but I think I found some. Doing a bit of searchfox archeology, it looks like they got split out from the principal list here in 1998: searchfox view: https://searchfox.org/firefox-main/commit/2c2bdfb430c7256038ab94e93e04d39c33ff6409 github view: https://github.com/mozilla-firefox/firefox/commit/2c2bdfb430c7256038ab94e93e04d39c33ff6409 (Prior to that, it looks like they were part of the main child frame list.) And the commit message there offers some context, which suggests it was just for convenience to avoid having to check frame types to separate out the different categories: > the inner table frame now maintains 2 child lists: the main child lists that holds rowgroups and unknown frame > types, and mColGroups. Besides being cleaner and easier to maintain, this should speed some things up slightly > because I don't have to check display types every time I iterate through colgroup frames. I *know* > mColGroups contains only colgroups. I might do the same for rowgroups (that is, keep unknown frame types > in their own list as well.) But that's optional. > > the inner table frame used to incorrectly create actual content objects for anonymous colgroups and cols. Now, > it just creates frames as appropriate, not content. To support this, I added some pseudo style contexts and > related atoms.
Bug 343048 Comment 2 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
(In reply to Emilio Cobos Álvarez [:emilio] from comment #1) > Daniel, do you happen to know some of the context behind having colgroups (but not rowgroups!) in a separate list? It seems we could probably deal with them similarly to rowgroups which just are on the principal list... No, I don't know the context -- sorry -- but I think I found some. Doing a bit of searchfox archeology, it looks like they got split out from the principal list here in 1998: searchfox view: https://searchfox.org/firefox-main/commit/2c2bdfb430c7256038ab94e93e04d39c33ff6409 github view: https://github.com/mozilla-firefox/firefox/commit/2c2bdfb430c7256038ab94e93e04d39c33ff6409 (Prior to that, it looks like they were part of the main child frame list.) And the commit message there offers some context, which suggests it was just for convenience to avoid having to check frame types to separate out the different categories: > the inner table frame now maintains 2 child lists: the main child lists that holds rowgroups and unknown frame > types, and mColGroups. Besides being cleaner and easier to maintain, this should speed some things up slightly > because I don't have to check display types every time I iterate through colgroup frames. I *know* > mColGroups contains only colgroups. I might do the same for rowgroups (that is, keep unknown frame types > in their own list as well.) But that's optional. > > the inner table frame used to incorrectly create actual content objects for anonymous colgroups and cols. Now, > it just creates frames as appropriate, not content. To support this, I added some pseudo style contexts and > related atoms.
(In reply to Emilio Cobos Álvarez [:emilio] from comment #1) > Daniel, do you happen to know some of the context behind having colgroups (but not rowgroups!) in a separate list? It seems we could probably deal with them similarly to rowgroups which just are on the principal list... No, I don't know the context -- sorry -- but I think I found some. Doing a bit of searchfox archeology, it looks like they got split out from the principal list here in 1998: searchfox view: https://searchfox.org/firefox-main/commit/2c2bdfb430c7256038ab94e93e04d39c33ff6409 github view: https://github.com/mozilla-firefox/firefox/commit/2c2bdfb430c7256038ab94e93e04d39c33ff6409 (Prior to that, it looks like they were part of the main child frame list.) And the commit message there offers some context, which suggests it was just for convenience to avoid having to check frame types to separate out the different categories (and there wasn't any big reason that we only did it for colgroups but not rowgroups): > the inner table frame now maintains 2 child lists: the main child lists that holds rowgroups and unknown frame > types, and mColGroups. Besides being cleaner and easier to maintain, this should speed some things up slightly > because I don't have to check display types every time I iterate through colgroup frames. I *know* > mColGroups contains only colgroups. I might do the same for rowgroups (that is, keep unknown frame types > in their own list as well.) But that's optional. > > the inner table frame used to incorrectly create actual content objects for anonymous colgroups and cols. Now, > it just creates frames as appropriate, not content. To support this, I added some pseudo style contexts and > related atoms.