Context-aware Markdown panels via attribute value of antecedent element and attribute selector in custom CSS?

Elastic Stack Kibana
1

I have a TSVB Markdown panel that consists of a list of links to related dashboards. I'm inserting that panel at the top of each of the related dashboards.

I'm in denial about having to create a separate version of that panel for each dashboard, just to unlink/highlight the item for the "current" dashboard. If life is too short to stuff mushrooms, then it is definitely too short for this malarkey. No, I don't want to write a script to automate generating those per-dashboard panels. I'd rather work on my mushroom-stuffing automaton.

If only:

  • An antecedent element in the page, such as <div id="kibana-body">, had an attribute that contained the dashboard ID, such as data-dashboard="8a9ed5e0-a899-11eb-b38d-7b8e5ab9c938", and
  • Kibana didn't limit the scope of all custom CSS rules for a TSVB Markdown panel by prepending them with the ID of the <div> parent of <div class="kbnMarkdown__body">

then I'd be able to specify CSS rules like this:

div[data-dashboard="8a9ed5e0-a899-11eb-b38d-7b8e5ab9c938"] a[href$="dashboard/8a9ed5e0-a899-11eb-b38d-7b8e5ab9c938"] {background-color: #006600}

which, while not "unlinking" the item for the current dashboard, would at least highlight it.

Thoughts?

To any Kibana developers reading this: a quick way to painlessly euthanize this idea would be to quickly implement the following feature request: "Custom nested (cascading, flyout) menus of links in the Kibana sidebar".

2

@devon.thomson do you have any inputs here?

Thanks
Bhavya

3

While I don't have any ideas particularly about how you can hack this behaviour together using custom css on a markdown panel, I read through your issue and can imagine some of these features being implemented.

This issue, doesn't cover all your feature requests but it could be extended to include pinning of individual dashboards, and could be made capable of being edited via stack management to set defaults for the whole space.

Changing the dashboard breadcrumbs to be context aware in this situation would be possible, but would require more effort.

Overall, this seems like a clear area of improvement for Kibana.

4

Having Kibana inject a CSS variable containing the dashboard ID might also work—I'll play with this and report back—and would remove the need to change how the current CSS is scoped by that prepended div id.

5

Native CSS variables don't work for this use case, because you can't refer to them in selectors.

However, this works, using a LESS variable:

@dashboard-id: "6fc76160-9dae-11eb-b38d-7b8e5ab9c938";

a[href$="dashboard/@{dashboard-id}"] {background-color: #006600;}

which is much nicer than having to explicitly cite each dashboard ID.

So, if Kibana could be enhanced to inject that LESS variable into the custom CSS, then we have a solution for context-aware Markdown panels.

I acknowledge that I'm assuming the containing dashboard ID is known before LESS variables get resolved, and that I might be wrong about that.

Related thought: Is there, or could Kibana introduce, a Handlebars expression that resolves to the dashboard ID ({{ dashboard-id }})?

6

The @document CSS at-rule would have helped here, but I don't want to wait to see if that gets resurrected.

7

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.