[Feature Request]: DataTable ability to add (non-AI) slugs to column headers

[wkeese]

The problem

Our app needs to add info tooltips to column headers:

So I want a DataTable option to do that.

Workaround

DataTable (and @carbon/ibm-products' Datagrid) support adding "AI labels" to column headers and rows.

But then Carbon inserts a blue gradient in the data cells, and the blue bar at the top:

In order to add a slug without the table style changing, I need to disable Carbon's AI styling. This is not trivial, because DataTable has styling for selected rows, hovered rows, hovered + selected rows, child rows, etc. This is what worked for me but it's not complete:

// Override the top blue line and background gradient that Carbon applies to <th> and <td> with slugs (i.e.
// the headers and cells in columns where we have the (i) icon).  We don't want any special styling there.
th {
  background: themes.$layer-accent !important;
  box-shadow: none !important;
}
td {
  background: themes.$layer !important;
}
:global(.#{prefixes.$carbon}--data-table--selected) td {
  background: themes.$layer-selected !important;
}
tr:hover > td {
  background: themes.$layer-hover !important;
}
.#{prefixes.$carbon}--data-table--selected:hover > td {
  background: themes.$layer-selected-hover !important;
}

The solution

Technically speaking, you could implement this by only enabling the blue styling for AI slugs, for example:

<TableCell aiStyling>

But I want to be clear that I am not asking to change the styling. I am asking for the opposite: To add a slug to column headers without changing the table styling.

Examples

No response

Application/PAL

IKC

Business priority

None

Available extra resources

No response

Code of Conduct

• I agree to follow this project's Code of Conduct

[github-actions]

Thank you for submitting a feature request. Your proposal is open and will soon be triaged by the Carbon team.

If your proposal is accepted and the Carbon team has bandwidth they will take on the issue, or else request you or other volunteers from the community to work on this issue.

[ljcarot]

@wkeese To make a change to styling, I suggest you bring to up with Adam Cutler and/or Ramiro Galan. We are following a very specific AI implementation from their work across all product team. There aren't supposed to changes without review and approval by them. They do host a weekly call every Wednesday at 9am ET for designs to be presented. Perhaps your team's designer could attend that by reaching out to Adam. cc @oliviaflory @matthewgallo @elycheea

[wkeese]

@ljcarot - But I'm not asking to change the styling. That's the opposite of what I want.

[sstrubberg]

I like this idea, but it feels like a back-door solution. We should think about this more systematically. Can you stop Dev Office Hours so we can chat about it more? Thanks for submitting this!

[wkeese]

@sstrubberg - I could try, but there's no time listed on that page, only a day. No one is there right now (probably it's around midnight in America). What time do people come?

[sstrubberg]

@wkeese it's at 10am ET. If you subscribe to the YourLearning, it'll send you all the time and date details. We run office hours once a sprint.

[tay1orjones]

We need to figure out how to avoid nested interactive elements in the header cells before we can look at expanding support beyond the AILabel #16031

[wkeese]

Yes, presumably the buttons should be next to each other, but with CSS so they visually overlap (position:relative, negative margin, etc.)

[tay1orjones]

Thanks for coming to office hours today @wkeese! A recap of what we discussed:

• Nested interactive elements aren't a blocker here - they're not a violation, just an incorrect/invalid authoring practice that we should be mindful of and ensure screenreaders properly surface these triggers.
• Placing a tooltip within a table column header is a seemingly common usage pattern and I think it's a good idea to open up this "slot" prop slug to be used with a normal tooltip/toggletip in addition to the slug/ailabel.
• To do this we'll need to decouple the gradient styling from this prop, and only apply the gradient when the child is specifically an AILabel

@laurenmrice @aagonzales do you have any objections to this? This is one of those instances where it would be nice if this prop was named something more open ended rather than slug or aiLabel.

@ariellalgilmore was looking at refactoring the slug props to be named aiLabel. Is there a chance we could redirect that work to name that prop something else across the system? Something that isn't so component-specific?

Some ideas:

• trailingElement
• trailingAction
• trailingControl
• suffix
• addon
• decorator
• endAdornment
• trailingAdornment