Home Forums General XMetaL Discussion attribute display and styling Reply To: attribute display and styling

Derek Read

Reply to: attribute display and styling

Regarding the 2^N problem, I don't believe there is a better solution to your particular issue if CSS is how you feel you must render them. Perhaps you need to be a little bit picky about which attributes you choose to expose to the author. If there are a large number of attributes in the schema it might be a good idea to ask the authors which ones they really feel the need to see all the time and then let them check the status of the rest by using the standard methods:
a) Hover over the opening or closing tag in TagsOn view.
b) Use the Attribute Inspector.
c) Use an XFT form you design.
d) Use Plain Text view.

I can think of other more complicated ways to expose these values to the author. They would likely take a considerable amount of work for you to implement. Essentially the Resource Manager can host ActiveX controls so if you wish to provide an alternative rendering completely independent of XMetaL Author's rendering engine you might do that there. For example, you might try to render your XML with all the attributes exposed inside Internet Explorer, which can be hosted in the Resource Manager. You could use CSS or XSLT there to get the rendering you like. Or you might even write a completely new COM object (ActiveX control) and host that in the Resource Manager instead.

You are correct to assume that if your CSS is overly complex you may see a performance hit. You will need to test this to be sure with your particular schema and everything else you have in your customization to see if that is acceptable.

Regarding your (latest) question #1:

By default both Tags On and Normal view use the same CSS for styling. In order to have different CSS for these two different views you will either need to swap the CSS file (by changing the name of it) in the On_View_Change event or use one of the more advance techniques to inject CSS via script that is new to 6.0.

One example of how to do this is provided with the Journalist demo, accessible via the Help > Samples menu. Macros are connected to a special toolbar called “Structure View Examples”. This does not demonstrate making changes to CSS for Tags On and Normal view, it shows how it can be done for Structure View. However, the same technique can be used with the only difference being that you would put similar code into an event like On_View_Change.

Another example is provided with the DocBook demos that are accessible via the Help > Samples menu. Use the menu items within the sub menu called “Document Display” that is contained within the “DocBook” menu to run the scripts provided with the demo.

A third option might be to use the Selection.ContainerStyle or Range.ContainerStyle APIs. This API (it is the same for both Selection and Range objects) allows you to style individual elements in the document over and above the CSS that is set for the selector representing that element (ie: this API essentially cascades more CSS after any other CSS is rendered). However, this API does not currently let you style :before or :after pseudo-elements because there is no way to get to those via DOM or Range objects and this API is a property of the Range object. You can use it to render alternative content for an entire element however, which is why I mention it. The Journalist demo includes script that demonstrates this when a element is present in the document.

A fourth option might be add the CSS containing your :before content for attribute display to the Structure View CSS file and leave it out of the regular CSS file altogether. Your authors could then open the Structure View when they want to see their attributes and not need to worry about switching between Tags On and Normal view at all, they could choose their preferred view for editing. You could even provide alternative views for the Structure View as with the Journalist demo, one where certain attributes are displayed, another where others are displayed, one specifically for navigating between large sections of the document, a more granular “show all elements” view, etc.

Regarding your latest question #2:

I think this is what was being suggested, yes. However, there are many other options (as I have listed above).