----- Original Message ----- From: "David A. Desrosiers" <hacker@gnu-designs.com>
Well, in a perfect world, we could guarantee that the separate CSS file is accessible and life is good. Unfortunately, since we can't guarantee the CSS file is there, we decided to embed the CSS inside the HTML.
If you can guarantee the HTML is there, you can guarantee that the CSS is there. If the CSS is missing, it shouldn't "break" the usability of the HTML document.
I can guarantee that CSS file is in the PG directory. I can't guarantee that Joe Sixpack will download that when he grabs the HTML file. Overall, this makes things simpler for the consumer of the e-text.
It bloats it somewhat, but it is still smaller than the obligatory PG header information, so I don't feel TOO badly about it. And now we get a fully self-contained file.
I don't understand the correlation. What does your CSS size have to do with the obligatory PG header size?
The CSS adds to the size of the etext, and on some level that feels ... wrong. I can't explain why, it just does. However, whenever PG posts a new e-text, they add a great big header and footer to the document for legal reasons. That thing absolutely dwarfs the CSS style header is size, so I don't feel AS badly as I might otherwise. It was mostly a throw-away comment, so don't read too much into it.
Now that I think about it, you may be right... In Firefox (which is what I have on this machine), there is no View -> Use Style menu option, but there is the icon in the bottom left corner. *shrug*
For those that want to see this in a much-more expanded version, go to http://w3.org/Style/ in a Gecko-based browser, and click on the icon, or go to View -> Use Style, and try the various stylesheets listed there.
I have a big aversion to taking an electronic document and presenting it as "pages." First and foremost, it is ugly.
I submit that having page numbers in an unintuitive place (left-side margins, which doesn't appear in any printed work I can find), is just as ugly.
The original page breaks were necessitated by the size of paper the publisher used. There is almost never a functional meaning to the page breaks in a book (except things like chapter breaks, which are easily marked up with horizontal rules or something to that effect). The page numbers in the margins are small and fairly unobstrusive, yet give the information in the easiest manner I could devise. Furthermore, they are completely hidden unless the read WANTS to have that information.
Second, it is going to wreck havoc whenever the user wants to change font sizes, page sizes, etc.
Having the border at the bottom of page 423 with a font size of 1.0em is still going to put the border at the bottom of the page when the font is 2.8em.
I think I'm missing your allegory here. Can you explain?
If you put visible page breaks into an HTML document, the user is going to expect that document to print to his printer at exactly those page breaks. Good luck. Also, page breaks would only make sense if you broke them into "visual" chunks. By that, I mean sizes that fit into one screen at a time -- no scrolling. However, if the user has a different resolution than you, it ain't gonna work. If he changes the font size, it ain't gonna work. Basically, using visual page dividers is getting into typography, something you want to avoid. Good HTML lets the browser and the user format the text. You just tell them what KIND of text it is. The page numbers are not meant to give you visual indication of page breaks as much as contextual information regarding the original source... which some people find very important and as it's fairly easy for me to include that information without disturbing the other readers, I do. Josh PS None of this is an argument for my CSS based HTML over TEI-Lite. I would LOVE if we have TEI-Lite capabilities right now... But we don't.