As threatened, I have started preparing a CSS file that will allow TEI files, at least PG-TEI files, to be displayed natively in a web browser. I started with html4.css, which can be found on the w3c web site, and which purports to be a style sheet reflecting the prevailing implementation of HTML styles by common web browsers. I began replacing HTML tags with their more-or-less-corresponding TEI tags, and continued by tweaking the actual styles associated with them, principally by replacing absolute sizes (e.g. 1.17) with relative sizes (e.g. 125%). By the time I got done, there was virtually nothing left of the original HTML styles. The principal work in creating the style sheet was in determining which TEI tags suggested a block presentation, which tags suggested an inline presentation, and which tags are primarily "metadataish" and which should not be displayed at all (but which are useful, if not essential, for creating catalogs). Most of the tags fell easily into one of these three categories (ignoring, for the moment, tables) but some are somewhat ambiguous; I made a judgement call with these tags, recognizing that someone else's judgment is probably equally valid. Of particular interest are quotations. TEI has two tags for quotations, one apparently for long quotations (<quote>) and one apparently for short quotations, (<q>). I opted to treat <quote> as block-level tags (similar to the HTML <blockquote>) and <q> as inline (similar to the HTML <q>). To test the CSS file, I grabbed Mr. Perathoner's version of _Alice in Wonderland_ from http://www.gutenberg.org/tei/marcello/0.3/examples/alice/, and added an 'xml-stylesheet' declaration including 'pgtei.css'. There were a few constructs in the file which needed styling, so I also created a document-specific CSS file (alice.css) and linked to that as well. While Mr. Perathoner's version of _Alice_ has a fairly complete <teiHeader> section, it did not have a title page; in my pgtei.css file I set <teiHeader> to "display:none", and added a <titlePage> to the file. I also fixed a small number of abuses of the <p> tag, and changed the tag for block-style quotations from <q> to <quote>. The resulting file can be found at http://www.passkeysoft.com/~lee/alice.xml. The resulting XML+CSS renders quite nicely in both Opera 7.4 and Firefox 1.0.4. It does _not_ render quite so well in Internet Explorer 6.0.29. Apparently IE does not support the CSS :before or :after pseudo-selectors, causing the file to lose quotation marks, nor does it correctly interpret the *[attribute~="value"] syntax, making such markup as 'rend="italic"' or 'rend="center"' inoperative. The biggest obstacle remains how to make the images appear; I haven't yet found anything in the CSS spec that will permit this. The CSS file can be found at http://www.passkeysoft.com/~lee/pgtei.css. Comments are solicited.
Lee Passey wrote:
The resulting XML+CSS renders quite nicely in both Opera 7.4 and Firefox 1.0.4. It does _not_ render quite so well in Internet Explorer 6.0.29. Apparently IE does not support the CSS :before or :after pseudo-selectors, causing the file to lose quotation marks, nor does it correctly interpret the *[attribute~="value"] syntax, making such markup as 'rend="italic"' or 'rend="center"' inoperative.
Safari gives the following errors: his page contains the following errors: error on line 195 at column 264: Entity 'nbsp' not defined error on line 199 at column 293: Entity 'mdash' not defined error on line 200 at column 299: Entity 'nbsp' not defined error on line 208 at column 333: Entity 'nbsp' not defined error on line 210 at column 362: Entity 'mdash' not defined error on line 213 at column 371: Entity 'nbsp' not defined error on line 399 at column 973: Entity 'nbsp' not defined error on line 414 at column 41: Entity 'emsp' not defined error on line 415 at column 59: Entity 'emsp' not defined error on line 416 at column 89: Entity 'emsp' not defined error on line 446 at column 196: Entity 'nbsp' not defined error on line 470 at column 289: Entity 'nbsp' not defined error on line 473 at column 302: Entity 'nbsp' not defined error on line 477 at column 315: Entity 'nbsp' not defined error on line 479 at column 347: Entity 'nbsp' not defined error on line 482 at column 369: Entity 'nbsp' not defined error on line 487 at column 416: Entity 'emsp' not defined error on line 489 at column 434: Entity 'emsp' not defined error on line 494 at column 470: Entity 'emsp' not defined error on line 496 at column 496: Entity 'emsp' not defined error on line 509 at column 538: Entity 'nbsp' not defined error on line 570 at column 748: Entity 'nbsp' not defined error on line 571 at column 774: Entity 'nbsp' not defined error on line 596 at column 892: Entity 'nbsp' not defined error on line 597 at column 918: Entity 'nbsp' not defined Apart from that it looks rather nice. Regards, Walter
Walter van Holst wrote:
Lee Passey wrote:
The resulting XML+CSS renders quite nicely in both Opera 7.4 and Firefox 1.0.4. It does _not_ render quite so well in Internet Explorer 6.0.29. Apparently IE does not support the CSS :before or :after pseudo-selectors, causing the file to lose quotation marks, nor does it correctly interpret the *[attribute~="value"] syntax, making such markup as 'rend="italic"' or 'rend="center"' inoperative.
Safari gives the following errors:
his page contains the following errors:
error on line 195 at column 264: Entity 'nbsp' not defined error on line 199 at column 293: Entity 'mdash' not defined
[etc.] This problem is not related to CSS, but rather to parsing the DTD. Mr. Perathoner's original version used the —, and entities, but did not define them, relying instead on the entity definitions included from the chain of DTD includes. I discovered that neither Firefox nor Opera actually read or processed the doctype declaration, and therefore any entity definitions from included files, aren't. I attempted to solve this problem by defining these entities as part of the internal doctype declaration for alice.xml itself, and for those two browsers it appears to have worked. Apparently, not only does Safari fail to parse external DTDs, it also fails to parse _internal_ declarations. A more universal solution probably involves replacing _all_ named entities with numeric entities. I note that Bowerbird did not comment on this problem, and when it comes to fault-finding one can usually rely on Bowerbird. Perhaps this problem is version dependant; what version of Safari were you using?
Apart from that it looks rather nice.
Thank you.
Regards,
Walter _______________________________________________ gutvol-d mailing list gutvol-d@lists.pglaf.org http://lists.pglaf.org/listinfo.cgi/gutvol-d
On Mon, 19 Sep 2005, Lee Passey wrote:
interest are quotations. TEI has two tags for quotations, one apparently for long quotations (<quote>) and one apparently for short quotations, (<q>). I opted to treat <quote> as block-level tags (similar to the HTML <blockquote>) and <q> as inline (similar to the HTML <q>).
These two "quotation" tags do have slightly different usages. My understanding is that <q> is used for direct speech, ie, when a character in a book is saying something: John said <q>"I never saw a butterfly that color."</q> And the <quote> tag is used to mark material quoted from some external source: The weather reminds me of Dylan Thomas, who wrote: <quote>Especially when the October wind With frosty fingers punishes my hair</quote> The second one will often be block-level, but probably not always. Depending, as you mention, on what choises are made by who is doing the markup. Andrew
On Monday 19 September 2005 01:14 pm, Lee Passey wrote:
The resulting XML+CSS renders quite nicely in both Opera 7.4 and Firefox 1.0.4. It does _not_ render quite so well in Internet Explorer 6.0.29. Apparently IE does not support the CSS :before or :after pseudo-selectors, causing the file to lose quotation marks
Known, and they apparently do not plan to fix it.
The biggest obstacle remains how to make the images appear; I haven't yet found anything in the CSS spec that will permit this.
Use the url("your/path/to/file.img") syntax.
Lee Passey wrote:
The principal work in creating the style sheet was in determining which TEI tags suggested a block presentation, which tags suggested an inline presentation,
TEI does not specify this, and many tags are 'ambivalent' about whether the do represent a block or not. The examples in the TEI specs often use the same tag in a different manner. Most of the time you just have to decide from context, ie. a <figure> inside a <p> is inline, a <figure> insid a <div> is block.
TEI has two tags for quotations, one apparently for long quotations (<quote>) and one apparently for short quotations, (<q>). I opted to treat <quote> as block-level tags (similar to the HTML <blockquote>) and <q> as inline (similar to the HTML <q>).
This is quite a departure from TEI philosphy, which requires that all presentational attributes be segregated into the rend attribute. Also TEI defines a semantical difference between <q> and <quote>. <q> is for direct speech and <quote> is for citation of sources.
While Mr. Perathoner's version of _Alice_ has a fairly complete <teiHeader> section, it did not have a title page;
It does not need a title page. A title page can easily be generated from the data in <teiHeader>.
I set <teiHeader> to "display:none", and added a <titlePage> to the file. I also fixed a small number of abuses of the <p> tag, and changed the tag for block-style quotations from <q> to <quote>. The resulting file can be found at http://www.passkeysoft.com/~lee/alice.xml.
This very much confirms my assertion that you have to tweak the TEI source not indifferently if you want to make it work with CSS. -- Marcello Perathoner webmaster@gutenberg.org
Marcello Perathoner wrote:
Lee Passey wrote:
The principal work in creating the style sheet was in determining which TEI tags suggested a block presentation, which tags suggested an inline presentation,
TEI does not specify this, and many tags are 'ambivalent' about whether they do represent a block or not. The examples in the TEI specs often use the same tag in a different manner. Most of the time you just have to decide from context, ie. a <figure> inside a <p> is inline, a <figure> insid a <div> is block.
Yes, one of the drawbacks of TEI is its ambiguity, and this problem comes into play as much in XSL Transformations as in Cascading Style Sheets. I think the holy grail of markup is to be able to perform all sorts of transformations, including transformation for presentation purposes, without human intervention. It appears that TEI has not yet solved this problem. Your comment about <figure>s is helpful, however. In the next iteration of pgtei.css I'll change the definition so that figures inside of paragraphs are rendered as inline, and all other figures are rendered as block.
TEI has two tags for quotations, one apparently for long quotations (<quote>) and one apparently for short quotations, (<q>). I opted to treat <quote> as block-level tags (similar to the HTML <blockquote>) and <q> as inline (similar to the HTML <q>).
This is quite a departure from TEI philosphy, which requires that all presentational attributes be segregated into the rend attribute.
A rule which is more often stated than observed.
Also TEI defines a semantical difference between <q> and <quote>. <q> is for direct speech and <quote> is for citation of sources.
A prime example. Looking at the TEI spec, I think you are probably right, although the academese of the spec leaves some doubt in my mind. ("<quote> contains a phrase or passage attributed by the narrator or author to some agency external to the text."?? What the heck does _that_ mean?) Previously, my curiousity having gotten the better of me, I went out to the TEI Listserve archives and looked at the threads on "floating divs." In those cases where the petitioner was looking for a way to indicate a distinct block of text inside a paragraph, the recommendation was almost always to use the <quote> tag, even in those cases where the 'quotedness' of the block was fairly tenuous. I would venture to say that after <p>, <quote> is probably the next most abused tag in TEI. On the other hand, if people would be willing to consistently use <q type="block"> or <q rend="block"> for block quotes, that would be fine too. (I personally think 'type="block"' is preferable, as I see block quotes has having significance beyond merely the way they are rendered). If TEI is to become useful as a master format for PG, it will require a consistent usage to reduce or eliminate ambiguity, beyond that which is required by the TEI spec itself.
While Mr. Perathoner's version of _Alice_ has a fairly complete <teiHeader> section, it did not have a title page;
It does not need a title page. A title page can easily be generated from the data in <teiHeader>.
I'm not yet proficient enough with CSS to be able to do this, but if you could show be how I would appreciate it.
I set <teiHeader> to "display:none", and added a <titlePage> to the file. I also fixed a small number of abuses of the <p> tag, and changed the tag for block-style quotations from <q> to <quote>. The resulting file can be found at http://www.passkeysoft.com/~lee/alice.xml.
This very much confirms my assertion that you have to tweak the TEI source not indifferently if you want to make it work with CSS.
I disagree. I believe that if the appropriate discipline is practiced at the time the TEI source is created it can work for both CSS and XSLT, and I believe the new version of _Alice_ demonstrates that. That the file needed to be modified only demonstrates that at the time of its creation the required discipline was not practiced.
Lee Passey wrote:
Yes, one of the drawbacks of TEI is its ambiguity, and this problem comes into play as much in XSL Transformations as in Cascading Style Sheets. I think the holy grail of markup is to be able to perform all sorts of transformations, including transformation for presentation purposes, without human intervention. It appears that TEI has not yet solved this problem.
It wasn't designed for presentation at all. It was designed to make old documents accessible electronically to the scholar. They don't care much about fonts and point sizes, but very much about semantics.
This is quite a departure from TEI philosphy, which requires that all presentational attributes be segregated into the rend attribute.
A rule which is more often stated than observed.
I have heard this assertion more often than I have seen it proved.
On the other hand, if people would be willing to consistently use <q type="block"> or <q rend="block"> for block quotes, that would be fine too. (I personally think 'type="block"' is preferable, as I see block quotes has having significance beyond merely the way they are rendered). If TEI is to become useful as a master format for PG, it will require a consistent usage to reduce or eliminate ambiguity, beyond that which is required by the TEI spec itself.
Running in a quote or displaying it is a purly presentational matter. As for the presentational stuff in the rend attribute, it now follows the CSS2 specs. So that ambiguity source has been eliminated.
It does not need a title page. A title page can easily be generated from the data in <teiHeader>.
I'm not yet proficient enough with CSS to be able to do this, but if you could show be how I would appreciate it.
I know how to do it in XSL. I don't know how to do it in CSS.
This very much confirms my assertion that you have to tweak the TEI source not indifferently if you want to make it work with CSS.
I disagree. I believe that if the appropriate discipline is practiced at the time the TEI source is created it can work for both CSS and XSLT, and I believe the new version of _Alice_ demonstrates that. That the file needed to be modified only demonstrates that at the time of its creation the required discipline was not practiced.
`Discipline' in this case is to nudge the encoder into using only those TEI constructs that will work with CSS and forbidding him to use all those TEI constructs that don't work with CCS. None of the things you `fixed' were violating the TEI spec. You just had to `fix' them because CSS is too weak to support them. eg. You had to move the entity decarations into an internal subset because browsers don't support external subsets yet. But nothing in the TEI spec requires internal subsets. Actually internal subsets just take up more space in the files and are much harder to maintain. -- Marcello Perathoner webmaster@gutenberg.org
Lee wrote:
As threatened, I have started preparing a CSS file that will allow TEI files, at least PG-TEI files, to be displayed natively in a web browser....
Great work!
The principal work in creating the style sheet was in determining which TEI tags suggested a block presentation, which tags suggested an inline presentation, and which tags are primarily "metadataish" and which should not be displayed at all (but which are useful, if not essential, for creating catalogs). Most of the tags fell easily into one of these three categories (ignoring, for the moment, tables) ...
Have you looked at how to handle the contents of the inline TEI <note> tag? http://www.tei-c.org/P4X/CO.html#IDX-22 Here's some of what this section says: "A note is any additional comment found in a text, marked in some way as being out of the main textual stream. All notes should be marked using the same tag, <note>, whether they appear as block notes in the main text area, at the foot of the page, at the end of the chapter or volume, in the margin, or in some other place. "Notes may be in a different hand or typeface, may be authorial or editorial, and may have been added later. Attributes may be used to specify these and other characteristics of notes, as detailed below. "Where possible, the body of a note should be inserted in the text at the point at which its identifier or mark first appears. This may not be possible for example with marginal notes, which may not be anchored to an exact location..." So, to directly render (with CSS) TEI documents containing inline <note> content, it's best the note be removed from the mainflow and floated in its own box (such as to one side). A year ago I experimented with this, and got it to work for Opera and Firefox (but not IE6 which does not support the required CSS), and was even able to insert a note reference number. Something to explore. Unfortunately, I recently looked for the test files and somehow lost them. <arghh/> For the planned OpenReader, I want to look at how to implement this in a generic sense (such as adding a custom CSS 'display' property value) so OpenReader User Agents can treat the contents of inline annotative content in any markup vocabulary in one or more ways (e.g., render it in a popup, move it to a special notes page, etc.) Interestingly, XHTML 2.0 is planning an attribute which can be used to make an inline object an annotative "note", but whether user agents will implement it in a proper manner is still unclear. XHTML 2.0 is not being very "pushy" about this attribute -- the specese in the draft is pretty weak (need to write Steven Pemberton on this.)
The biggest obstacle remains how to make the images appear; I haven't yet found anything in the CSS spec that will permit this.
Not sure if you've looked at the Fahrner Image Replacement method. http://www.stopdesign.com/articles/replace_text/ Essentially, a tag can be given a background image using CSS: background-image:url(imagename.png); then you set the *contents* of that tag to be display:none (you have to have an inner tag to set to display:none -- you can't set to display:none the tag which will contain the background image!) I believe it is possible to make this method generic, so CSS will read the image name string from an attribute (this *can* be done if things are structured right), then substitute the string back into the CSS property to specify the background image. It may be necessary to specially tailor the TEI markup to make sure one has an outer and an inner tag -- the outer will be assigned the background image, and the inner will be set to display:none. The cool thing about the FIR method is that in the absence of CSS, it is possible to get something to render, such as the text describing the image, which is what you already do in your test TEI of Alice in Wonderland. Of course, the ultimate method for embedding images and objects, and to enable hypertext linking in any XML document is XLink, but XLink support in the major browsers is limited to Mozilla and Firefox and to hypertext linking only (not image/object inclusion.) Here's a little test I whipped up a while back on hypertext linking in browsers using XLink (which should also be of interest for direct rendering of TEI): http://www.windspun.com/demoxml/demolink.xml As noted above, the hypertext link will work only for Mozilla and Firefox browsers -- the link is not activated in IE6 and Opera 7/8. (Note that CSS does not contain a 'display' value to assign HTML "anchor" properties to any tag, and upon thinking about it, it is obvious that trying doing so will get messy very fast -- e.g., how does one recognize and assign the URI link in an arbitrary XML document?) This also explains why there's no generic support in CSS 'display' for image and object inclusion -- again it is messy to think how to do this using a set of CSS 'display' properties. XLink is definitely the long-term, vocabulary independent solution anyway. Jon
participants (6)
-
Andrew Sly -
D Garcia -
Jon Noring -
Lee Passey -
Marcello Perathoner -
Walter van Holst