w3c
[css-tables] Allow 'order' on table columns
Posted in https://lists.w3.org/Archives/Public/www-style/2022Jun/0005.html :
I recently wondered why the order property only exists for flexbox and grid. Imo it makes a lot of sense for the table element as well. Sometimes you want to reorder columns and other is no convenient way to do so besides changing the whole dom structure.
Adding an order property to td would tackle that issue. An obvious problem is that you can easily create conflicts by setting different orders for tds of the same column. That's why the better place to define this is probably colgroup. However, it seems like the spec moved away of using colgroup at all because all attributes (including width) seem to be deprecated. I find this a bit strange because it allows a convenient way to define column properties. Since tables are defined column-wise but are rendered row-wise, it becomes hard to define column props without writing nth-child selectors all the time. As written above, for ordering, nth-child doesn't seem to be a proper solution anyway. Hiding or rearranging columns are powerful features needed in a lot of rich web applications and providing an easy way to do it in CSS would be awesome.
What do you think?
The attributes are deprecated because they are presentational markup (which doesn't belong in HTML), but CSS properties are not deprecated (because presentational instructions is what CSS is for). If we were to apply order to table columns, I think using <col> and <colgroup> for it would make perfect sense.
The main open question I think is what happens to colspanning cells:
- Suppose we have a cell spanning two columns. If their order is reversed, is that cell still spanning the same two columns?
- What if the first column is reordered to be the 5th column (non-adjacent)?
My purpose for this discussion is two-folds:
-
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).
-
I think we all agree this sounds useful, but is this presentational?
-
If we agree on the idea, we should spec the details:
My proposal here is to find any group of columns that are tied together by spanning cells. These groups of columns act as one column for the purpose of reordering. They use the order value of the first column of that group (the value of other spanned columns of the group would be ignored).
One interesting question is the accessibility aspect. Is that a visual effect, or should it also change the a11y tree (for what benefit? clarity might be one, for partially sighted users for instance)
The CSS Working Group just discussed order on table columns.
The full IRC log of that discussion
<fantasai> Topic: order on table columns<TabAtkins> ScribeNick: TabAtkins
<fantasai> github: https://github.com/w3c/csswg-drafts/issues/7340#issuecomment-1247390415
<iank_> I don't think this will take 5 mins
<TabAtkins> fremy: can summarize, maybe can't resolve
<TabAtkins> fremy: So we have some props that apply to grid-ish layout modes bu tnot tables
<TabAtkins> fremy: we discussed 'gap' earlier
<TabAtkins> fremy: But 'order', think it makes sense to be able to swap columns
<TabAtkins> fremy: Right now you have to change every single row to swap columns
<TabAtkins> fremy: So you'd bea ble to apply 'order' to columns and it will swap them around. Sounds reasonable, but raises some questions
<TabAtkins> fremy: column groups, spanning cells, etc
<TabAtkins> fremy: There's a concrete proposal - you glue together columns that are part of a column group or have spanning cells, and they can't be moved separately
<TabAtkins> fremy: Seems doable, but is it something we want to do?
<iank_> q+
<PaulG> q+
<Rossen_> ack masonf
<Rossen_> ack iank_
<TabAtkins> iank_: My concern - this sounds ok - but this is slightly special and new because it sin't how order works in the other properties
<TabAtkins> iank_: Like flex and grid, it just literally reorders the items as you lay them out
<TabAtkins> iank_: This has a second-order effet
<TabAtkins> iank_: So a littl emor complexity
<TabAtkins> iank_: Also want to spend more time thinking about how columns move when they're spanning
<Rossen_> ack PaulG
<TabAtkins> PaulG: Table semantics often ahve grid controls like arrow keys, focus groups, etc
<TabAtkins> PaulG: Reordering columns means devs also have to udnerstand the impact on those, and adjust
<TabAtkins> PaulG: Seems quite complex and fraught
<TabAtkins> PaulG: If it doesn't adjust, the arrow keys will jump columns and not match visual order
<TabAtkins> PaulG: If we adopt focus group controls, it'll get more complicated
<TabAtkins> fremy: Agree, but we're just talking about data tables. If you use for anything else you're doing wrong
<TabAtkins> fremy: But this is same for Flexbox generally, if you change the order you have to worry about keyboard order.
<Rossen_> Zakim, close queue
<Zakim> ok, Rossen_, the speaker queue is closed
<TabAtkins> fremy: But I do think this is a valid concern
<TabAtkins> fremy: I think if we assume it's just data tables it's ok
<TabAtkins> dbaron: In terms of column spans/groups, I think reordering in a way that doesn't break them is probably desirable
<TabAtkins> dbaron: But it's not especially clear ot me what you do to keep them together
<TabAtkins> dbaron: Can maybe be flusehd out in the issue
<TabAtkins> dbaron: Also concerned with same things as PaulG, whether there are *good* use-cases that justify the problematic with keyboard a11y
<TabAtkins> fantasai: Question really is not whether this is correct righ tnow, but if this is something we potentially care about at all. If we think it's bad we can just drop it.
<TabAtkins> fremy: Suggest we give everyone a week to think about it.
<TabAtkins> Rossen_: agreed
<fantasai> s/this is correct/this is ready to adopt/
The CSS Working Group just discussed [css-tables] Allow 'order' on table columns, and agreed to the following:
RESOLUTION: Close the issue. Lack of interest.RESOLVED: Close the issue. Lack of interest.
The full IRC log of that discussion
<Rossen_> q?<Rossen_> ack jensimmons
<JakeA> my bad, I thought we'd moved to another issue
<fantasai> fantasai: question is whether to ask fremy to draft up a specific proposal for applying order to tables
<fantasai> fantasai: would be restricted within boundaries of a rowspan/colspan, can't shuffle those, but in any case we need a detailed proposal
<fantasai> fantasai: and question to WG is do we want a detailed propsoal
<Rossen_> q?
<fremy> q+
<smfr> q+
<fantasai> -> https://github.com/w3c/csswg-drafts/issues/7340#issuecomment-1247390415
<JakeA> Rossen_: opinons?
<Rossen_> ack fremy
<JakeA> fremy: I think it's a good time to think about it. I'll spend time in December working it - eg the table spec & this
<JakeA> fremy: I think I agree. It doesn't feel like a huge amount of work
<JakeA> fremy: I think this is a reasonable thing to do
<Rossen_> ack smfr
<JakeA> smfr: I think webkit has a low level of enthusiasm to do this.
<PaulG> q+
<dholbert> +1 to smfr, I have the same feeling RE Gecko's table code
<JakeA> smfr: col order has semantic value. I don't think we'd implement this any time soon.
<Rossen_> ack PaulG
<JakeA> PaulG: MS's spec for focus groups may be impacted by this
<Rossen_> q?
<JakeA> PaulG: Different things may be correct depending on perspective
<iank_> q+
<JakeA> Rossen_: I see similar reservation from Mozilla
<Rossen_> ack iank_
<JakeA> iank_: Q: Would this logic be pre or post col sizing?
<JakeA> fremy: Before I guess
<JakeA> iank_: We have the newest impl right now. Our proposal would be fine. Table code is tricky due to legacy.
<JakeA> iank_: eg how do mergeable columns work? If it's like the order prop in grid & flex, that's simpler
<JakeA> iank_: If it's pre sizing, it may have unintended effects on space distribution
<JakeA> iank_: If there's a simple way that's clean, that would be fine
<JakeA> iank_: tables are complicated :D
<JakeA> fremy: Can we move this to tables 4? That gives time for folks to reconsider. Does that make sense?
<JakeA> iank_: That's fine by me
<JakeA> Rossen_: Freshness of impl doesn't impact complexity due to legacy behaviour.
<JakeA> Rossen_: Let's put it on the backlog. Deal with it later.
<JakeA> Rossen_: Legacy things aren't going to be removed before then
<JakeA> Rossen_: if anyone wants to reopen it, we can
<JakeA> fantasai: we can reconsider it in the next level
<JakeA> (not 100% I heard the above correctly)
<JakeA> fantasai: the problem with closing it is it falls off the radar, and we lose context.
<JakeA> jensimmons: What's the usecase? We want to reorder the table without impacting the semantic order?
<JakeA> Rossen_: That's exactly where there's pushback. I'm in favour of closing. Objections?
<JakeA> Rossen_: Sorry, resolution? It's not a path forward we want to adopt
<JakeA> Rossen_: Hearing no objections. Let's close it, and not generate activities on it, that won't have impact.
<jensimmons> Giving authors a way to more easily reorder columns & rows is something the web should do! But not in CSS.
<fantasai> s/context/context, if we don't want to actually reject it we should defer rather than closing/
<JakeA> RESOLUTION: Close the issue. Lack of interest.
<fremy> @ jensimmons, I think I agree
<astearns> RESOLVED: Close the issue. Lack of interest.
Closing this issue due to lack of implementer interest to work out the details, as this might be both complex to implement and affect accessibility negatively.
I would like to point out in particular point by @jensimmons which I think is particularly relevant:
Giving authors a way to more easily reorder columns & rows is something the web should do! But not in CSS.
Indeed, changing the order of columns would probably have an impact on accessibility, and this type of change might be more suited for markup edits than CSS edits.