At present, the breadcrumb reads "section>subsection>content".From some documentation I saw, you can change this rendering using cc_config.xml, and although it supports `${i18n(key)}` I'd really need it to use `${xpath_eval(expression)}`.

In this instance I'd want the breadcrumb to read "section 1>subsection a)>content", I assumed it would be as simple as.

But no dice, it displays literally "section ${xpath_eval(@num)}>subsection ${xpath_eval(./num/text())}>content".I've tried without the "section/subsection"-prefix (in case there was some concatenation syntax), and with various xpaths (in case I'm not writing them correctly, like `text()` not being a thing).The config itself is functional, given the breadcrumb text is changing, but only to literals.In fact none of the other editor variables seem to operate dynamically, only the localisation one (which was mentioned in the docs) is able to evaluate.

So I'm guessing this is a limitation, and dynamic breadcrumbs aren't done via `cc_config.xml`, if that's so, where can I achieve what we need?

Currently, the display string for an element in the breadcrumb can be computed based on the element name and its attributes. For example, to display the ID of the element in the breadcrumb, the following code snippet may help [1]:

Making the breadcrumb text depend on children text is not supported currently. The reason is that the text for the "subsection" element is update only when the element itself is edited, but not for edits in child nodes. While for the breadcrumb text this may not be a big problem, the same text is used for element sentinels in "Full Tags" mode.

Thanks for that cristi.Hmm, okay. Going back to cc_config.xml, let's consider a different scenario.

Say there's only a specific set of attribute values that are possible, is it possible to capture these in the `element` attribute in <render> similar to what you can do in `path` from <elementProposals> in the same config file?

You can use the same JS API as above to specify a custom element name for the element. Unfortunately, there is no such support in cc_config. We have some other requests this feature and I added your vote for it. We will update this forum thread once we add support in the cc_config file for such an use-case.

No worries, Cristian.I was just seeing if there was another way to achieve it without adding anything programmatic ("if oxygen supports it, why add it", don't reinvent the wheel, after all).I understood the config couldn't evaluate on the document every time we wanted to display something (as=$xpath_eval) but was just checking if the inverse of simply checking on the document for every select (the much less powerful, and thus more-probably implemented, element={selector}) was possible.

I'll give your original response a crack. I have a feeling that using that I could even get the child-text thing working if there's a synchronous way to get at the document and cursor position (but it'd probably fail for ancestor elements, idk, my first time with oxygen, it's out of scope to talk about it here, haha).