[css-tables] Let *-gap properties apply to tables

[SebastianZ]

In order to harmonize gap handling between all layouts, row-gap, column-gap and gap should also apply to tables.

This would deprecate border-spacing like it was done for the grid-*-gap properties before.

Sebastian

[Loirooriol]

Note that border-spacing only accepts lengths, while gap also accepts percentages. Given the madness of table layout, it may not be obvious how percentages should behave. Also, border-spacing has no effect with border-collapse: collapse, would it be the same for gap?

[SelenIT]

Probably even more important difference between border-spacing and *-gap is that the former also adds spacing outside the cells, while the latter adds it only between them. Also, the gap shorthand and border-spacing have different component orders.

It might be worth noting that initially adding *-gap to tables was considered, but this idea was then rejected presumably due to complexity.

[Loirooriol]

So unless you think there is anything new to be said about this, I guess Wontfix by CSSWG resolution.
https://logs.csswg.org/irc.w3.org/css/2017-08-04/#e847611

[SebastianZ]

Thank you for the hints, @Loirooriol and @SelenIT!

So it looks like the *-gap properties cannot simply replace border-spacing.

From what I read, the technical issues are that in opposite to the *-gap properties border-spacing is inherited, it adds spacing outside the cells, it only accepts lengths, and it is affected by border-collapse. And there was the question when the *-gap properties would apply and when border-spacing.

From my point of view, the answer to the first three issues is to let them apply exactly like in the other layouts where they can be used, i.e. they don't inherit, they don't add spacing outside the cells (can be done by setting a padding if needed), and they also accept percentages the same way as defined now, meaning they resolve against the box’s content box when laying out its contents.
Regarding whether border-collapse should affect them I tend to say yes in order to keep the possibility to avoid double borders between cells.
As for when the *-gap properties apply, I go with @fantasai's note that they are used when set to a length or percentage. If they are set to normal, border-spacing is used.

All the technical issues aside, I guess the bigger issue here is probably that implementers seem to be reluctant to change their table layout implementations.

Sebastian

[FremyCompany]

My purpose for this discussion is two-folds:

1. Is the existence of an improved table spec sufficient to reassure implementers to attempt changes to their table layout behavior in well-scoped scenarios?
   a. If the answer is no, then I will go ahead and shelve this type of issue for now (move to css-tables-4).

2. If the answer is yes, would adding “gap” behavior to table be meaningful and desirable?
   a. One reason why it could be undesirable is that “gap” behavior would not insert spacing between the border of the table and the border of the first cells of the tracks.
   b. If the answer is no, then I will go ahead and close the issue.

3. If the answer is yes, we would be discussing details about the proposal:
   a. How to resolve percentages?
   - Should we only enable them on tables with explicit width and treat them as 0% otherwise?
   b. How to resolve the conflict with border-spacing?
   - Should the effects override each other?
   - Should the effects stack?

[SebastianZ]

2. If the answer is yes, would adding “gap” behavior to table be meaningful and desirable?

As an author, I'd say that's definitely desirable for consistency and simpler behavior. And it would also open up the way for features like gap styling.

2. a. One reason why it could be undesirable is that “gap” behavior would not insert spacing between the border of the table and the border of the first cells of the tracks.

As mentioned in my last comment, from an author's point of view, this is not really a disadvantage because the effect can still be achieved via padding.

3. If the answer is yes, we would be discussing details about the proposal:
a. How to resolve percentages?
- Should we only enable them on tables with explicit width and treat them as 0% otherwise?

I guess, authors would expect the same behavior as for other layout types, i.e. they should always apply. If they only applied under certain conditions, it very likely will cause confusion.

b. How to resolve the conflict with border-spacing?
- Should the effects override each other?
- Should the effects stack?

I slightly tend to let gap overwrite border-spacing. The reason for that is that against the definition of 0px 0px in the spec., the initial value in browsers is 2px 2px. So if you want to use gap and don't want them to stack, you also have to set border-spacing: 0;. Though I don't have a strong opinion on that.

In any case, web compatibility should be checked. Maybe there are already some pages setting gap on tables, which would cause layout changes once it applies.

Sebastian

[SebastianZ]

Also the behavior of gap in combination with border-collapse should be discussed.

Sebastian

[css-meeting-bot]

The CSS Working Group just discussed 'gap' on tables, and agreed to the following:

• RESOLVED: Define 'gap' working on Table layout, precise details tbd
• RESOLVED: Put the 'gap' effects in Tables 3

The full IRC log of that discussion

<TabAtkins> Topic: 'gap' on tables
<TabAtkins> github: https://github.com//issues/4848
<TabAtkins> fremy: First goal is to figur eout if we can actually apply new featues to tables, especially applying common layout features other display modes have now
<TabAtkins> fremy: gap is easiest
<TabAtkins> fremy: border-sapcing is very similar, but it's super unfortunate, because it inherits
<TabAtkins> fremy: Setting border-spacing on a table also changes the spacing of nested tables.
<TabAtkins> fremy: Seems like there's no good reason, just historical.
<TabAtkins> fremy: 'gap' doesn't have this problem, and is supported for Grid and Flexbox.
<TabAtkins> fremy: So, can we specify 'gap' for Table?
<TabAtkins> fremy: Is there implementor interest?
<TabAtkins> fremy: For authors, it's easy; there's likely not compat issues since 'gap' is fairly recent.
<emilio> q+
<hober> q+
<TabAtkins> fremy: So is this something people are confident we might want to do?
<Rossen_> ack emilio
<hober> q-
<TabAtkins> emilio: Seems reasonable, tho it needs definition of interaction with border-spacing
<TabAtkins> fantasai: There's a proposal for that
<TabAtkins> emilio: Does 'gap' support anything border-spacing doesn't?
<TabAtkins> fremy: One, but it's very manageable
<TabAtkins> fremy: gap allows %
<TabAtkins> fremy: Imo, we can quickly decide that % on tables in gap only works for definite-sized axis, otherwise is 0. Similar to %s in many other table contexts.
<TabAtkins> Rossen_: metapoint is that these details have been worked out in the proposal
<fantasai> honestly, even if we resolve it to zero unconditionally, that would probably be fine and still useful
<TabAtkins> florian: Is this driven by theory or use-case?
<TabAtkins> florian: If you'e using tables for data, in my experience, data tables don't use border-spacing all that much.
<TabAtkins> fremy: I didn't open the issue, Sebastian did but isn't here to defend the point.
<iank_> q+
<TabAtkins> fremy: imo, border-spacing is terrible design, and gap works everywhere and is cheap to do, so get a cheap consistency
<TabAtkins> fremy: But this is more theoretical for me, yeah.
<miriam> q+
<Rossen_> ack iank_
<TabAtkins> iank_: As long as this is a drop-in replacement for border-spacing, this is okay.
<TabAtkins> iank_: 'gap' today only works on a single flexbox or grid; border-spacing is more complex because it punches thru and affects things in the rows, the sections, the table itself. Lots of plumbing.
<TabAtkins> iank_: As long as it's specified to basically directly override border-spacing
<TabAtkins> fremy: Yes. Initial value of 'gap' is normal; we define that it defers to border-spacing.
<TabAtkins> iank_: Right, so next is defining that %s don't resolve to something strange and don't re-resolve.
<Rossen_> ack miriam
<TabAtkins> miriam: To respond to Florian, I don't see peole using border-sapcing a lot, I see people using padding a lot
<TabAtkins> miriam: My expectation is because border-spacing is a weird name that I forget about regularly.
<TabAtkins> miriam: 'gap' I wouldn't forget about.
<iank_> q+
<TabAtkins> miriam: I'd use it anywhere I'd use padding
<emeyer> It makes sense to me that ‘gap’ would apply to tables, but mostly for completeness’ sake and author convenience. And agree with miram about the use of inline padding.
<Rossen_> ack fantasai
<TabAtkins> fantasai: Another thing is that it's between the borders of the cells. Any time I use a data table, I'm using collapsed borders, so there is no space.
<TabAtkins> fantasai: So there I'd have to use padding bc both border-spacing *and* gap wouldn't do anything.
<Rossen_> ack iank_
<TabAtkins> iank_: Right, last point was we can't make 'gap' magically work in collapsed borders.
<TabAtkins> dbaron: I was also going to mention collapsed borders.
<TabAtkins> dbaron: Also think it's worth being extra caqreful about %s.
<Rossen_> ack dbaron
<Rossen_> ack fantasai
<TabAtkins> dbaron: Don't remember what 'gap' supports in %s, but with border-spacing we're in a position where the Tables model makes it very difficult to support %s in a good way, but any lesser way would be inconsistent with using 'gap' elsewhere.
<TabAtkins> fantasai: My suggestion would be to make %s resolve only when table-layout is fixed; for table-layout:auto they resolve to 0 unconditionally
<TabAtkins> iank_: I agree on the auto case, i'll have to think on fixed. It's not as special if you think it is
<TabAtkins> fremy: Idea is if the table width is definite...
<TabAtkins> iank_: That's not what was discussed
<TabAtkins> fremy: Right, that's my idea tho
<TabAtkins> iank_: I agree that's easier than basing it on table-layout fixed
<TabAtkins> fantasai: I'm fine iwth it rsolving to 0 *all* the time
<TabAtkins> iank_: Me too
<TabAtkins> Rossen_: We're over time. Seems there's some interest, but we're lacking motivation.
<TabAtkins> Rossen_: Leave it to the WG to decide. Call for consensus?
<TabAtkins> fantasai: I'd be happy to spec it, think it makes sense, but it's a low prio.
<emilio> +1 to fantasai
<florian> +1 to fantasai
<TabAtkins> Rossen_: So is this something we want to adopt? Objections?
<emeyer> +1 to fantasai
<TabAtkins> RESOLVED: Define 'gap' working on Table layout, precise details tbd
<TabAtkins> fremy: Can we put this in Tables 3?
<TabAtkins> fantasai: Yeah it's small
<TabAtkins> RESOLVED: Put the 'gap' effects in Tables 3
<TabAtkins> fantasai: mark it at-risk