Scholarship, (X)HTML, and CSS: The Problems

The Problem: The <blockquote> Element

Block quotations have normally been reserved for directly quoted material that exceeded roughly fifty words. In the past, researchers singlespaced and indented a block quotation and referenced the source with a superscripted note. The current World Wide Web Consortium (W3C) HTML 4.01 specification for a block quotation (blockquote) specifies that the blockquote element enclose a block-level element, usually a paragraph element (p). When a blockquote envelopes a block-level p, however, the block quotation inherits the p style. Since standard digital paragraphs usually employ leading (line-height) to increase legibility and readability, the enclosed p often ends up with inappropriate leading, perhaps a first line indent, and no indentation. From a humanities scholar’s perspective, the problem lies in a misunderstanding of the semantics of a block quotation. A block quotation is different from a standard paragraph terms of its content; it is not an instance of a paragraph but a different structure entirely. A block quotation signals to the reader that the material is a long passage from another work, and the reader is advised, thereby, to read carefully because the passage documents an assertion or a constituent part of the argument. Its visual presentation underscores its special status. A block quotation is simply not an indented paragraph of textual argument. And then there's XHTML Strict. The XHTML Strict specification does not allow the use of the cite or sup elements within a blockquote element. A blockquote in humanities requires a citation. To include a superscripted reference mark or a cite element will invalidate the markup; to exclude a citation mark or citation risks censure.

The Problem: The <q> Element

The q element (quotation) might be very useful to humanities scholars for two reasons: elimination of special character insertion and cataloging by bots or specialized engines. According to the W3C specification, user agents should insert “curly” quotation marks appropriate to the language around the text enclosed by the q element, obviating the need to manually insert the quotation marks or worry about unicode entities. Unfortunately, the q element is not supported by all browsers or well-implemented in others. While modern browsers, such as Firefox 1.5 fully support the q element in its proper form, Safari 2.0 and Opera 8.5 substitute foot marks for “curly” quotes. Similarly, Mac IE 5.x supports the q element after a fashion; if the the text is not left-aligned, the quotation marks have minds of their own and appear willy-nilly. Finally, the Win IE family does not support the q element at all. Since a majority of user agents are members of the Win IE group, most handbooks advise against using the q element and recommend manually inserting the proper punctuation to ensure consistent presentation across user agents. So much for the q element. Scholars could use the :before and :after CSS pseudo-elements to insert quotation marks before and after a quotation but, again, the Win IE family does not support :before and :after pseudo-elements. Finally, the XHTML 2.0 draft specification outlines a scheme that substitutes the quote element for the q element. In this scenario, scholars will have to insert the correct “curly” quotes and avoid using the sup element (superscript).

The Problem: The <cite> Element

In a similar vein, the cite element (citation) has apparent utility. After all, scholarly works are chock a block with cites of one kind or another. And, again, having cite elements correctly marked semantically would allow several kinds of analysis, and having cite display correctly would also be a boon. The cite element is not up to the task, however. User agents generally display the cite element in italics. Although it may not always be the case, citations include more structures than the cite element can accommodate: an author’s name, a book title, an article title, and a page number or a URL—many of which are not proper candidates for italics. As Tantek Çelik points out, XHTML lacks the building blocks to capture a citation’s complexity. (Well, I can't find the citation from his presentation.)

The Problem: The <hr> Element

Finally, there is the poor <hr> element or rule. The rule has a structural role, functioning in much the same way as its smaller cousin the em dash. It marks off sections or signals a break in the narrative or argument. A rule's most common use is separating the body text from the endnotes or footnotes. Alas, the <hr> element has been deprecated, and writers are advised to use stylesheets. Employing stylesheets mean using borders, and borders occupy the entire width of a container. A designer can either use a border and run the rule the entire width of the containing div and across the page or create a smaller, empty div and deal with the problems of empty divs.

Conclusions

These are but a few examples. Both the <sup> element and paged media properties, for example, deserve separate discussions. The fact remains that both HTML and XHTML define and describe a language, a language that circumscribes (or undermines) the correct presentation of online scholarship in the humanities. One of the most fundamental qualities of text is its dual nature. In some important instances, especially in the humanities, text is both structural and presentational. This nuance has, however, been lost in the over-zealous segregation of structure and presentation. Why is this the case? And what is to be done? (Part 2 of 3)