I am trying to clean up the appearance of user-generated documentation in 11.1. I believe in some cases I need to set options based on the front end version: use one value for 10.0-11.0 and a different value for 11.1 or later.

What is the best way to do this?

From this post, I learned that we can use FEPrivate`Switch to set a different value for each specific version. However, I would prefer to simply decide based on whether the version is less than 11.1 or not. Is this possible? Is there a way to test for inequality, even through FEPrivate`$ProductVersion appears to be a string?

The best I could come up with so far is

   FEPrivate`MemberQ[{"10.0", "10.1", "10.2", "10.3", "10.4", "11.0"}, FEPrivate`$ProductVersion], 

As described in the linked post, you can see the output with

   FEPrivate`MemberQ[{"10.0", "10.1", "10.2", "10.3", "10.4", "11.0"},
     FEPrivate`$ProductVersion], 1, 2]]

This still requires listing each existing version separately, so it is not ideal.

Here is something I tried that did not work:

  FEPrivate`If[FEPrivate`Less[FEPrivate`$ProductVersion, 11.1], 1, 2]

It returns Null instead of 1 or 2.

I think it does not work because $ProductVersion is a string, not a number.

Why do I need this? You can see that the appearance of the See Also section is not correct in user-generated doc pages:

enter image description here

This is because they have FontFamily -> "Verdana" hard-coded. Removing this fixes the appearance in 11.1, but breaks it for earlier versions.

Is there a better way to deal with this than to have an explicitly conditional FontFamily setting in each of these cells? Note that I can't even just change the RefLink style, as that is used elsewhere as well. Is there perhaps a way to change the RefLink style only within the SeeAlso style?

  • 1
    I like this question. More generally, I'd very much like to update my documentation pages to reflect the style of v11.1. I'm hoping to ask a question about something more comprehensive, like @jkuczm 's WWBCommon project. Are you working on something similar? – QuantumDot Mar 25 '17 at 13:58
  • @QuantumDot The problem is keeping the pages compatible with earlier versions. This is very important for those of us who create packages. But I think (I am not sure) that Wolfram's internal documentation tools are designed to produce pages only for the current version. Those pages would not work correctly in previous versions. At one point they accidentally released a WB update that included some of the new 11.1 styles (though they were unfinished). The documents generated with it did not work in 11.0 (they did partially work in the 11.1 prerelease I had at the time). – Szabolcs Mar 25 '17 at 19:30
  • I also think (again not sure) that the doc tools they released with Workbench are primarily made for internal use, and are released (without too much polish) only because so many of us were asking for them. Put perhaps the priority is still on internal use, i.e. having it work with 11.1 only (and not 11.0 or earlier). In the letters I wrote to support I emphasized multiple times that for me it is very important that whatever doc tools they release, they should work well at least back to v10.0. I would rather have usable but ugly doc pages in 11.1 than have unusable pages in 11.0. – Szabolcs Mar 25 '17 at 19:32
  • @QuantumDot What I am doing here is just a minor aesthetic improvement for my documentation in 11.1, without breaking it in 11.0. The only serious usability issue was the missing group openers on the section headings. I could fix these with a stylesheet modification. The rest is only about aesthetics. I thought of asking more question about this topic, but I would like to wait for 11.1.1 (if there will be one), there might very well be some improvements. Perhaps they'll also release a Workbench update by then. – Szabolcs Mar 25 '17 at 19:35
  • @Szabolcs Indeed, retaining backwards compatibility with pervious versions (up through at least v8.0.4) while updating the style to v11.1 documentation is exactly what I'm looking for. – QuantumDot Mar 25 '17 at 19:44
up vote 5 down vote accepted


Investigation with LinkSnooper shows that the FrontEnd knows the $VersionNumber:


And even though it is not listed in Names["FEPrivate`$*"], the symbol FEPrivate`$VersionNumber works.

Try this with any notebook, save it and open in V11.1 and pre V11.1. Same syntax can be used in a stylesheet.

  , StyleDefinitions -> Notebook[{
        Cell[StyleData[StyleDefinitions -> "Default.nb"]]
      , Cell[StyleData["Notebook"]
          , Background -> FEPrivate`If[
                FEPrivate`Less[ FEPrivate`$VersionNumber, 11.1]
              , RGBColor[1, 0, 0]
              , RGBColor[0, 1, 0]

enter image description here

Old workaround

It is redundant here but knowing this technique may help in future.

The trick is to calculate condition when the stylesheet is opened and use this value via CurrentValue in your style definitions:

Try this on a regular notebook, save it and open in V11.1 and pre V11.1:

  , StyleDefinitions -> Notebook[
      { Cell[StyleData[StyleDefinitions -> "Default.nb"]]
      , Cell[StyleData["Notebook"]
          , Background -> FEPrivate`If[
                , {TaggingRules, "NewStyles"}
                , True
            , RGBColor[1, 0, 0]
            , RGBColor[0, 1, 0]
      , TaggingRules -> {}
      , NotebookDynamicExpression :> Refresh[
                 EvaluationNotebook[], {TaggingRules, "NewStyles"}
            ] = TrueQ[ $VersionNumber >= 11.1 ]
          , None

The notebook should have a green background in V11.1 and red in earlier versions.

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.