XML and CSS

CSS is a W3C standard that can be used to provide styling information to a document. While CSS is used mainly with HTML there is no such restriction to the standard itself and it can be used also with any XML document.

The advantage of using CSS for XML editing was the fact that we were able to use the XML tree itself as the model and just compute the styles for rendering each node, there is no transformation and mapping between an output format and the XML tree. This allows to provide feedback to the user on the editing context at the caret position in the document and to combine that with the schema information to compute the DTD/schema valid markup that can be inserted at that location in the document.

Simple editing concepts

As the position in the visual editing environment matches the position in the XML tree it is possible to have only 2 simple concepts that an author needs to learn in order to edit any XML document. The user needs to go to the position where he want to change the document and then:

  • type to change the content

  • press "Enter" to enter markup

With these simple concepts an author can change any XML document.

To help locate the current position in the document when the XML tags are not displayed oXygen provides a number of helpers

  • location tooltip

  • breadcrumb

  • synchronized views: Outline, Model, Attributes, etc.

  • highlight the elements at caret position

  • element range marker

All these help the user understand what is the current location in the document and then the user can perform content and markup changes at that position.

Alternate CSS stylesheets

The specification for associating a CSS with an XML document allows to specify multiple CSS stylesheets as alternate stylesheets - thus it is possible to switch between different renderings of the XML documents and create specific CSS stylesheets focused on different tasks that need to be performed on the XML document.

Elements can be also completely removed from the visual interface using a display : none; property on that element - thus an alternate stylesheet can provide also a reduced view on the document.

As en example we provide for DocBook 3 CSS stylesheets

  • the default stylesheet

  • a stylesheet that hides column specifications for tables

  • a stylesheet that highlights the content marked with DocBook specific revision markup

CSS support

The CSS support covers CSS version 1, 2 and 3.

From CSS 3 we absolutely needed support for namespaces and the attr function to provide access to attribute values and thus be able to provide links or to present attribute information in the visual editor. We support also the additional attribute type parameter for the attr function that makes this function usable to provide dynamic values for CSS properties, values taken from the XML document itself.

Note

The attr function gives the attribute information as read only in the content property - to be able to edit that we needed to add an extension.

Other CSS 3 functionality supported covers transparent colors and support for custom fonts using the @font-face at-rule.

Show/hide XML tag information

By default the XML tags are not visible but sometimes it is useful to have them visible in the visual editing interface. oXygen provides 6 different levels of showing markup information in the visual editing interface, from no tags at all to full tags with attributes:

  • no tags - no tags are visible

  • partial tags - inline elements are presented with small tag markers that just signal the presence of a tag

  • inline tags - the tags are visible for inline elements

  • block tags - the tags are visible for block elements

  • full tags - the tags are visible for all elements

  • full tags with attributes - both tags and attributes are visible for all elements

Custom actions

Custom actions are part of the editing experience as they provide easy access to inserting comment fragments in XML documents. People are used with using similar actions in word processing applications and they expect similar support from XML authoring tools.

In oXygen we developed an architecture that allows defining custom actions mainly through configuration. We offer a library of common operations that should cover most of the processing needs, but user defined operations can also be added. Then, in order to define a custom action one can specify it like 

     if (condition1) then operation1 
else if (condition2) then operation2 
else if (condition3) then operation3
...

Where condition1, condition2, etc. are XPath expressions evaluated in the current editing context and operation1, operation2, etc. are custom operations configured by setting values to their parameters.

Example of common operations are InsertFragmentOperation, ChangeAttributeOperation, "UnwrapTagsOperation" etc. and even XSLTOperation and XQueryOperation - these last two allowing to use XSLT or XQuery scripts to define the logic of the action.

Form controls and inline actions

This makes possible to create a unified editing area where the user has access to all XML content, markup and attributes as well as to document specific actions added in the context they should be used from - no need for additional side views or toolbars.

The CSS styles allow the XML document to be nicely rendered and the users can easily change the content and the structure. The attribute information however it is not accessible in a similar way - it can go only into read-only labels and in order to change attributes the user needs to access them though a side panel or invoking the in-place attribute editor.

Similarly, the custom actions are generally available on the toolbar, together with all the other actions, or added to a menu or to a contextual menu.

In order to improve the editing of attribute values and to allow easier access to custom actions we added a few extension functions that can be used to bind an attribute value to a form control or to bind a button to a custom action and then put these directly in the authoring interface. These allow creating simple user interfaces that combine the visual CSS based authoring useful for mixed content editing with the simplicity of form controls and custom actions put directly in the authoring view.

Sample user interfaces

Here you can see a few sample user interfaces.

A DocBook document

All the specific support for an XML vocabulary is just a configuration and a set of resources that are packaged together is a document type or framework. oXygen provides such frameworks for many popular XML vocabularies and DocBook is one of them. You can see in the following figure the rendering of a fragment of a DocBook article.

Figure 1: The visual rendering of a DocBook document

A I-90 form fragment

Here it is a standard I-90 form fragment, implemented in XML.

Figure 2: The XML that represents the form data

Figure 3: The rendered form

A travel guide

These user interfaces, if carefully designed, allow non technical users to encode information in XML without actually knowing anything about the underlying XML format - they surely need to know the subject domain of the information they encode.

Figure 4: The XML source for a point of interest in a travel guide

Figure 5: The visual rendering of the point of interest from the travel guide

George Bina

Syncro Soft

George Bina is one of the founders of Syncro Soft, the company that develops oXygen XML Editor. He worked with XML since 1998, initially using XML for different projects and, starting with 2001, on the development of oXygen XML Editor, a tool for XML authoring and development. George is actively involved in the XML related projects contributing to XML related open source projects: Jing (the validation engine for Relax NG, NVDL)