The following is a status report on browser status for rendering XML graphically using CSS. Example grammar used is DTBOOK - however, principles apply arbitrarily.
Note that CSS is not limited to graphic rendering - theoretically, the issues discussed here apply equally to screenreaders, embossers, et al.
Only problematic/buggy findings are reported. There is no guarantee that all possible CSS syntax exploit variations have been exhausted in this test.
Refer to "dtbook.basic.css" for actual sheet used.
Browsers used for testing:
The reason for selecting these browsers is that they are both likely candidates for embedding in DAISY playback/reading devices with textual display interfaces.
Two methods for generating orientation aids for the the ordered and unordered list were tested.
li {
display: list-item;
list-style-position: inside;
}
list[type="ol"][enum="1"] {
list-style-type: decimal;
}
list[type=ul] {
list-style-type: disc;
}
An element with 'display: list-item' generates a principal box for the element's content and an optional marker box. A second property 'list-style-type' specifies appearance of the list item marker. For numbered lists, autoincrement is specified by the spec as a default behavior.
list[type="ol"][enum="1"] {
counter-reset: olItem;
}
list[type="ol"] li:before {
display: marker;
content: counter(olItem) ". ";
counter-increment: olItem;
}
New method in CSS2, (display: marker dropped in CSS 2.1). Markers are created by setting the 'display' property to 'marker' inside a :before or :after pseudo-element. Counters are used to specify increments.
| method | IE 6.0.2800.1106 | Mozilla |
|---|---|---|
| display:list-item | Doesnt work. IE displays a bullet in front of any <li> element when display:list-item. The list-style-type property is supported, but IE does not support the elem[att="value"]syntax and can therefore not select subsets of list elements. |
Works for unordered, but not for ordered. Autoincrement of counters does not happen. |
| automatic counters and numbering | Doesnt work at all. | Doesnt work at all. |
The table rendering test was done using the designated display property values, inherited in CSS2 from the HTML table model.
table {display: table;}
table > caption {display: table-caption;}
tr {display: table-row;}
[etcetera]
| method | IE 6.0.2800.1106 | Mozilla |
|---|---|---|
| display: table-x | Doesnt work at all. Display is total overlap chaos. | Basic rendering works. A box with horizontally and vertically aligned childboxii is created.
|
CSS2 does not provide any generalized mechanism for instructing user agents how to handle external objects. Although a construct such as
img:before {
content: url(attr(src));
}
is concievable, it doesnt work, and is a hack anyway. Note however that something similar is becoming a recommended method i the CSS3 Generated and Replaced Content Module, where a fallback mechanism is implemented:
figure[alt] { content: attr(href, url), attr(alt); }
figure:not([alt]) { content: attr(href, url), contents; }
In previous DTBOOK stylesheets, one of the authors had added the selector
\HTML:img and similar. It is not known what spec or recommendation this syntax came from (backslash is a token for character escapes) - in either case, it did not seem to affect the behavior of the tested browsers.
The overarching problem with XML external object inclusion is that there as yet is no cross-application method for a browser/processor to know when an element is an object reference, and after that, what type of object it is. Although MIME types is the way to declare this, a processor would not know where to look for the MIME declarations. Thus, the problem does not lie within the scope of browser compatibility, but at a considerably more general level.
Would it in the meantime be appropriate to extend the imggroup content model to include a required MIME type declaration? For further information on this, and an interesting fallback implementation, see XHTML 2 Object Module.
Mozilla has adressed the situation by extending the CSS2 syntax - this to be used internally by Mozilla's user interface language XUL, and in anticipation of CSS3. An example for image display is:
object[data] {
-replace: attr(data);
-moz-binding:url(xhtml2.xbl.xml#object);
}
CSS 2 does not explicitly adress links (ie activatable, with a target URI to be resolved). In a W3C Working Draft from 04 Aug 1999, Behavioral Extensions to CSS , an outline methodology was proposed. The behavior property links an element to a component that may handle or cause dynamic behavior by accessing the element's object model, or may provide its own properties, methods and events exposed on the element. Example:
a {
behavior:url(file.htc);
}
This method has been experimentally implemented, where the htc file recieves java- or ecmascript events. IE supports this method (the utc proposal was originally submitted by microsoft).
Using the Mozilla XUL extensions the same is expressed as:
*[href] {
-set-link-source: attr(href);
-use-link-source: current;
cursor: pointer;
-moz-binding:url(xhtml2.xbl.xml#link);
}
These tests indicate the following situation re current (pre CSS3) support in browsers for CSS graphic shaping of xml:
This report does not touch on user agent behavior beyond that of @media=screen. Needless to say, the situation becomes even more critical for non-visual user agents, where intelligent semantically mapped behavior is the key component for feasible information consumption.
Could a playback device with a text display interface embed another type of control, or a control written specifically for DAISY purposes? The answer to this question depends on the nature of the desired functionality.
There is nothing in a generic SMIL rendering approach that says that any context needs to be rendered simultaneously to the currently active text object. If this approach is taken, the need for embedded browser functionality is minimal.
If a second approach is taken, where the active text object is regarded as focused element within a document, the need for embedded browser functionality is technically and economically difficult, or even impossible, to bypass. Developing a text rendering control including only the minimally required support for CSS (box shaping, text sizing, table rendering) is in itself complex and expensive. Adding to this the need for i18n support (rtl, ltr, bdo, ruby, unicode combining chars, etc) and the possible inclusion of additional modules with complex rendering logic, such as MathML.
At this point in time, z3986 playback device implementors planning to include textual display functionality may end up choosing dynamic conversion to XHTML to circumvent the problems described above.
This document does not adress the question whether CSS3 is likely to improve the situation over time. It would seem reasonable to claim that improvement is not dependent on spec versioning as such, but rather on factors such as: