A Styled Variables Gotcha

[RStreets]

I've upgraded to 2020r2 and, whilst I imminently intend to, I haven't yet done anything with styled variables. But, before I've had a chance to do it myself, all my variables have styled themselves!

Every variable, previously unstyled, has been italicized.

I've combed through my stylesheet for the MadCap|variable style. Nothing has been set. I looked in the stylesheet using a text editor and again, got nothing. I checked the other stylesheets in the project in case I had some weird inheritance going on. Again nothing. Eventually, I searched the stylesheet for other occurrences of "variable" and found a Character style called variable which I use to indicate variable text in inputs. It's italicized. It's also now--temporarily--called "fred". With the renaming, the unwanted italicization is gone.

So, this is a quick heads-up to anyone who might have a Character style called "variable" (I can't be the only one, can I?) that odd things might occur to the formatting of MadCap variables with the 2020r2 update.

[NorthEast]

Yep, if you look at the output, variables are in span tags like this:

Code: Select all

<span class="mc-variable VariableSet.VariableName variable">Variable</span>

So if you already had a .variable style, then that will style all your variables too.

The same can happen whenever you use a tag/class name that's used in the output - e.g. "breadcrumbs", "dropdown", "toggler", "sub-menu", etc.
You'll only see these styles in the output though, so won't see them anywhere in your source project.

[RStreets]

They're highly specific, too: variables is OK and doesn't interfere, and .Variable.

I'm now wondering if this actually at all useful. Would it ever be helpful to see in a published output just how much of it is variables?

[homer]

Another thing to note is that the new variable name is a concatenation of the variable set name (e.g., card) and the definition (e.g., title) with a period between them.

So for a variable like card.title, it formerly surrounded the resolved variable like so:

Code: Select all

<span class="cardtitle">Responsible Sourcing</span>

and now, it resolves to:

Code: Select all

<span class="mc-variable card.title variable">Responsible Sourcing</span>

This invalidates any styles created for the previous variable style and, since a period is not allowed in a style element name (it tells the css to look for an element with both "card" and "title" applied), it can't be trapped.

The best one can do is to get as specific as needed by using surrounding elements (e.g., div.card .variable), but that doesn't work if you use multiple variables within a paragraph or other element where you might want to apply a specific style (italics?) to one of the variables.

Any other workarounds?

This unwelcome change causes heartache and wasted time as we use snippet variables throughout the sites.

[NorthEast]

This invalidates any styles created for the previous variable style and, since a period is not allowed in a style element name (it tells the css to look for an element with both "card" and "title" applied), it can't be trapped.

I agree that using a full-stop/period in the class name is a bad idea.

But if you style a variable via Flare, and then look at it's generated CSS, you'll see it replaces the "." in the class name with "\00002E":

Code: Select all

span.mc-variable.Variables\00002ECompanyName { background: #ff0000; }

As a side note, Flare will only let you set up styles for individual variables. But if you want to style all the variables in a variable set, you can use something like this, where "Variables" is the variable set filename:

Code: Select all

MadCap|variable[class*="Variables\00002E"] { background: #ff0000; }

[homer]

I'll check that, Dave. I don't normally use the gui style editor. It must create that pattern on a compile/build.
Still.... it seems like a mistake.

I have to say that as past Flare versions already had concatenated the variable set/definition into a style class, it would have been *infinitely* better to retain that pattern rather than change it. Then you'd have additional styling options rather than completely different ones.

We haven't yet upgraded to 2020r2; where this got us was with the automatic builds on Central, which evidently has been upgraded. Fortunately we can still build locally and push our published output to Central.

[RStreets]

We haven't yet upgraded to 2020r2; where this got us was with the automatic builds on Central, which evidently has been upgraded. Fortunately we can still build locally and push our published output to Central.

No that's a very interesting point. I'm adding it to my growing list of "things to watch out for with Central".

[NorthEast]

I'll check that, Dave. I don't normally use the gui style editor. It must create that pattern on a compile/build.
Still.... it seems like a mistake.

I have to say that as past Flare versions already had concatenated the variable set/definition into a style class, it would have been *infinitely* better to retain that pattern rather than change it. Then you'd have additional styling options rather than completely different ones.

We haven't yet upgraded to 2020r2; where this got us was with the automatic builds on Central, which evidently has been upgraded. Fortunately we can still build locally and push our published output to Central.

Yeah, styled variables are a new feature in 2020R2. The variable editor has a button to create a style, which adds the CSS (for that individual variable) to your stylesheet. (So it's in the source, not at compile/build time.)

Mind, prior to 2020R2, Flare didn't support styles for variables, so styling them was always a bit of a manual 'hack'. I use a lot of these sort of hacks myself, and it's always a risk that MadCap might change the output styles, and break whatever CSS that you've set up. So whilst it's a pain when it happens, it's not really MadCap's fault.

I agree that the naming convention is a bit odd - I don't think I've sever seen a full-stop/period used in a class name, which seems like it's asking for trouble.