Styles in XQuestion

XQuestion extends the QTI 1.2 specification to allow every single element to have a 'class' attribute. (In the QTI specification, only the flow elements have a class attribute). XQuestion also allows styles to cascade down through the structure - if you define an assessment as having red text for text elements, then every piece of text will be red. You could redefine a particular item in that assessment to have blue text for text elements - then every piece of text in that item would be blue, but the rest of the assessment would use red text.

Let's see how that works...(many elements and attributes omitted for brevity)

<assessment class="redtext">
 <section>
  <item/>
  <item class="bluetext"/>
  <item/>
 </section>
</assessment>

In the example above, items 1 and 3 will be rendered as red text, and item 2 as blue text. Item 2 overrides the assessment setting.

The Style Document

The style document is usually called styles.xml and has this kind of structure..

<cascadingstyles>
 <style id="redtext">
  <pair name="textcolor" value="#FF0000"> (what does "#FF0000" mean?)
 </style>
 <style id="bluetext">
  <pair name="textcolor" value="#0000FF">
 </style>
</cascadingstyles>

The label 'redtext' really is just that, it references the style to use. You could quite happily reverse the labels so that the assessment labelled 'redtext' would display in blue and vice versa (you wouldn't be happy if you did this, you'd be sick). The meaning that 'redtext' has is defined by the styles document.

Labels Can Reference Many Styles

Let's say we want all the red text to be left aligned and to have a point size of 16, we'd do this...

<cascadingstyles>
 <style id="redtext">
  <pair name="textcolor" value="#FF0000">
  <pair name="textalignment" value="left">
  <pair name="textsize" value="16">
 </style>
</cascadingstyles>

In fact, usually you want to define every possible style as the label, 'default' and then apply this to assessment. This gives your assessment all the default styles that it needs and then you can over-ride the defaults as and when you need to. That structure is used in all the example files. It looks like

(test.xml)
<assessment class="default">
..
..
</assessment>

(styles.xml)
<cascadingstyles>
 <style id="default">
  <pair name="language" value="en">
  .

  .(many, many pairs)

   .
  <pair name="renderchoicecheckboxbuttondownstateroll" value="components/checkboxdown.swf">
 </style>
</cascadingstyles>

Elements Can Have Many Labels

As if it weren't complicated enough, elements can have many labels. You can happily ignore this bit if your head is beginning to hurt - you won't need it for ages.

Let's say we've got an item and we'd like all the mattext to appear black, 18 point size, and we've got another item where we'd like the text to appear black, 18 point size and in italics, we can define a style for the 'black and 18 point size' and another for the 'italics'. That might look like this...

(test.xml)
<item class="black18"/>
<item class="black18,italic"/>

(styles.xml)
<cascadingstyles>
 <style id="black18">
  <pair name="textcolor" value="#FFFFFF">
  <pair name="textsize" value="18">
 </style>
 <style id="italic">
  <pair name="textitalic" value="true">
 </style>

The Exception to the Rule

You definitely don't need to know this. Don't even read it.

You'll remember earlier that I mentioned that flow elments already have a 'class' attribute. They also have a default of 'Block' defined. That's Block with a capital 'B' - style labels are case-sensitive. Usually you should use all lower-case for styles, but this is already defined. So what effect does this have? It means that if you don't define a class for a flow element, it will have one anyway, and anything it defines will not cascade through safely. This is usually a good thing - putting something in a flow is meant to force it to be rendered in some particular way.

Here's an example

(test.xml)
<flow class="horizontal">
 <flow><material/><material/><material/></flow>
 <flow><material/><material/></flow>
 <flow><material/></flow>
</flow>

(styles.xml)
<style id="horizontal">
 <pair name="flowaction" value="horizonatal">
</style>
<style id="Block">
 <pair name="flowaction" value="block">
</style>

The flow contains three flow elements - each has some material in it. The flow action for the outside flow is 'horizontal' so it will lay these three out side by side. Now, you'd expect the flows inside to inherit the flowaction but they don't. They use their own default, 'Block' and the materials are laid out block style, one after the other.

If you're having difficultly grasping this concept, then just imagine that a pre-processor does this to the test.xml...

convert <flow> to <flow class="Block">

thus giving us

(test.xml)
<flow class="horizontal">
 <flow class="Block"><material/><material/><material/></flow>
 <flow class="Block"><material/><material/></flow>
 <flow class="Block"><material/></flow>
</flow>

And that's it. That's all there is to know about how style works.