Hi Nathan, In order to be sure, I've also tested ${frameworkDir} in the CSS and I obtained the expected result: we don't expand it to the framework directory. For your CSS rule at least, it is as if you don't have ${frameworkDir} at all. The system id of the CSS is used as the base URI and I'm guessing that the relative path '../../../../../' it's actually relevant starting from the location of the CSS. I'm guessing there is nothing in the XML instances that differentiates between different versions? Possible solutions: 1. From an Workspace Access [1][2] plugin you can add an URIResolver, intercept the CSS resolving [3] and resolve there the editor variables: /** * @see ro.sync.exml.plugin.workspace.WorkspaceAccessPluginExtension#applicationStarted(ro.sync.exml.workspace.api.standalone.StandalonePluginWorkspace) */ @Override public void applicationStarted(final StandalonePluginWorkspace pluginWorkspaceAccess) { pluginWorkspaceAccess.getXMLUtilAccess().addPriorityURIResolver(new URIResolver() { @Override public Source resolve(String href, String base) throws TransformerException { System.out.println("href " + href); if ("http://www.oxygenxml.com/extensions/author/css/userCustom.css".equals(href)) { String versionPath = pluginWorkspaceAccess.getUtilAccess().expandEditorVariables("${test}", null); String frameworkURL = pluginWorkspaceAccess.getUtilAccess().expandEditorVariables("${framework}", null); String imageURL = frameworkURL + versionPath + "/"; return new StreamSource(new StringReader( "*[class~=\"topic/image\"][href]{\n" + " content:oxy_url('" + imageURL + "', 'attr(href)');\n" + "}")); } return null; } }); This goes hand in hand with your idea to tell the user to change a custom editor variable in options and then perhaps perform a refresh in the editor. 2. This idea is based on a custom form control implementation [4]. You add this this form control, for example, on the root of the document. In this form control the user writes something that identifies the version of the document. The form control saves this value in a fake attribute using the API : authorAccess.getDocumentController().setAttribute("myVersion", new AttrValue("patch21", "patch21", false), element); The CSS must contain a rule that uses that attribute, something like this: *[myVersion] *[class~="topic/image"][href]{ content:oxy_url('${frameworkDir}', '../../../../../', oxy_xpath('/topic/@myVersion'), 'app/main/core/sfdc/htdocs/img/', attr(href)); } If you are interested I can send you the source code for the built-in text field form control. It would take minimal changes to make it behave like above. [1] http://oxygenxml.com/doc/ug-editor/#concepts/workspace-access-plugin.html [2] http://www.oxygenxml.com/oxygen_sdk.html#Developer_Plugins [3] http://oxygenxml.com/doc/ug-editor/#references/handling-css-imports.html [4] http://oxygenxml.com/doc/ug-editor/#topics/implementing-custom-form-controls... Best regards, Alex -- Alex Jitianu <oXygen/> XML Editor, Schema Editor and XSLT Editor/Debugger http://www.oxygenxml.com On 13-May-14 3:32 AM, Nathan wrote:

Hi Alex, Here is the use case scenario I am targeting:

In the CSS, I have

*[class~="topic/image"][href]{ content:oxy_url('${frameworkDir}', '../../../../../', 'app/main/core/sfdc/htdocs/img/', attr(href)); }

Here, the built-in variable "frameworkDir" works fine. The above path is valid when the file is in the "main" branch. When the input xml file is in another branch (say "/patch/21"), I would like to change the "app/main/core...." to "app/patch/21/core...". My first idea was to have a custom variable defined (say $BRANCH) which would be set to "/main" by default and could be reset to "/patch/21" by the user when they change the branch.

However, while the built-in variable was accepted, the custom variable is not accepted here. Also, with respect to creating pseudo classes, it would be a maintenance issue since I would need to put in every release number (since theoretically XML files from any release could be opened) in the CSS and also the CSS would need to be updated after every release.

Could you provide some alternatives?

Thanks, Nathan

_______________________________________________ oXygen-sdk mailing list oXygen-sdk@oxygenxml.com http://www.oxygenxml.com/mailman/listinfo/oxygen-sdk