Sent from my Phone From: don kretz Sent: 11/28/2012 11:29 PM To: Lee Passey Subject: RE: HTML rules and poetry I would pass it along but I wouldn't dare. I tried exactly that and got this as a typical response: <pre> (or white-space: pre) is a very bad idea. [i]Very[/i] bad. Period. To wide acclaim. And had my post excised from the conversation as "off topic." And accused of being too "philosophical" - apparently one of their strongest pejoratives. Not an open-minded group I'm afraid. Keep in mind those Best Practices are a fait-accompli imposition by a small group hand-picked by the GM who tends not to react well to disagreement or talking about reasons for things (philosophy). Sent from my Phone From: Lee Passey Sent: 11/28/2012 2:52 PM To: don kretz Subject: HTML rules and poetry I've been working on the section of my HTML rules which apply to poems. Of course, I've been comparing my thoughts to the new "HTML Best Practices" at DP, as I believe that consistency is more important than absolute correctness. I have a few comments that I would like you to convey to whomever is the primary author of the poetry "Case Study." According to the best definitions I can find online, poetry is a composition generally involving emotional or lofty thoughts expressed in imaginative words. Verse is any expression in words which simply conforms to accepted metrical rules and structure. A poem is simply poetry in verse. Thus, when one encounters a poem in source materials I prefer classifying it as <tag class='poem'> instead of <tag class='poetry'> It seems to me that in books we usually encounter "poems" not "poetry," so the former classification seems more accurate. Further, a cursory look at current HTML practice at PG seems to indicate that "class='poem'" is more commonly used than "class='poetry'"; prior practice should not bind us, but we should let it guide us. Secondly, when poems are encountered which have varying indentations of lines the "Case Study" recommends enclosing each line in a <div> with varying classifications as to how far that particular line should be indented (e.g. <div class="indent1">, <div class="indent2">, etc.). I dislike using classifications to indicate style instead of semantics, especially when the classifications have no global meaning outside of the specific text. But even more important is the overarching goal that presentation should be preserved, as much as possible, even when a style sheet is lost, or a User Agent has a poor implementation of CSS. In HTML, (including HTML5) the W3C suggests that the <pre> element is the preferred method of marking poems. A common hack is to not use the <pre> element, but to do indentation with a variable number of non-breaking spaces. I can't say I'm particularly enamored with either of these solutions, but they do both have the virtue that the desired effect is preserved when CSS is lost. In the end, I think I would follow the W3C and use: <pre class="poem"> The classification is added so that CSS-aware User Agents can override the default presentation of <pre> if desired.
On Thu, November 29, 2012 12:32 am, don kretz wrote:
I would pass it along but I wouldn't dare. I tried exactly that and got this as a typical response:
<pre> (or white-space: pre) is a very bad idea. [i]Very[/i] bad. Period.
To wide acclaim.
And had my post excised from the conversation as "off topic."
And accused of being too "philosophical" - apparently one of their strongest pejoratives.
Not an open-minded group I'm afraid.
Keep in mind those Best Practices are a fait-accompli imposition by a small group hand-picked by the GM who tends not to react well to disagreement or talking about reasons for things (philosophy).
I apologize for asking. Reviewing the DP discussion threads about the "HTML Best Practices" it quickly became apparent that not only are the recommendations less than best, but there is apparently little to no interest in actually establishing /Best/ practices. It appears, rather, to be an attempt to create "Community Practices", which may be less than optimal, but which are more or less uniform and predictable. While not as compelling as Best Practices, Community Practices are still valuable. It will require an extra processing step to transform a file matching the "DP Community Standard" to a true "Best Practice," but if the DP Community Standard is uniform, predictable and specific then the transformation process should be straight-forward. I would recommend surrendering gracefully when it becomes apparent that facts are not welcome, but gently promoting specificity, even excessive specificity, whenever possible.
In the end, I think I would follow the W3C and use: <pre class="poem">
The pre suggestion is so bad that I think that those who read it at DP assumed you have not seriously studied the issue of how to code poetry in HTML. In general the "poetry" problem is how to reliably wrap lines of text on small machines according to common poetry standards, and to do so in a manner that actual runs correctly on the great majority of reader devices. And to do so in a manner that doesn't require an excess of gimcrackery while coding the HTML. This problem is an unsolved, and presumably unsolvable problem. One approach is the DP gimcrackery which is a pain to code and maintain, and assumes that reader devices actually correctly code negative indents. Some reader devices from major manufacturers actually crash on negative indents in some situations. Another approach that comes close is "white-space: pre-wrap" -- except that it is not widely supported. And while it correctly wraps, it does not correctly "poetry" indent on wrap. One partial suggestion is to minimize indents and margins when doing poetry in order to minimize the wrap problem. And recognize when the poetry in the original book was wrapped to begin with. Liz Castro had an intelligent discussion on the problem about a year ago: http://www.pigsgourdsandwikis.com/2012/01/media-queries-for-formatting-poetr y-on.html Of course some poetry "breaks all the rules" and then none of these "solutions" apply. IE poetry as visual art. My general suggestion is that when you see poetry run the other way -- there be dragons.
Hi James, All, Am 30.11.2012 um 01:16 schrieb James Adcock <jimad@msn.com>:
In the end, I think I would follow the W3C and use: <pre class="poem">
The pre suggestion is so bad that I think that those who read it at DP assumed you have not seriously studied the issue of how to code poetry in HTML.
In general the "poetry" problem is how to reliably wrap lines of text on small machines according to common poetry standards, and to do so in a manner that actual runs correctly on the great majority of reader devices. And to do so in a manner that doesn't require an excess of gimcrackery while coding the HTML. Excuse me, poetry standard!!!!! There is no such thing! There are different forms of poetry, but a standard. Then, there are the semantic tags, that tell a user agent that maybe you need to mangle the TEXT for display. but a standard.
In a true standard, you would need to mark-up the fact that you have pentameter, hexamters, etc. This information would be needed to properly mangle the text, so that it can be read in all its glory. Yet, that is not in the standard. I do admit that it is not so much a problem of mark-up, but the poor quality of user agents. Soo
This problem is an unsolved, and presumably unsolvable problem.
regards Keith.
Excuse me, poetry standard!!!!! There is no such thing! There are different forms of poetry, but a standard. Then, there are the semantic tags, that tell a user agent that maybe you need to mangle the TEXT for display. but a standard.
Here we go again around in circles with the TEI semantic markup crowd. "Standard" poetry in the sense that it is written in lines, with one or two indents, and those lines need to wrap if they are too long to display, and the wrap ideally needs to indent relative to the indent of the start of that line. Which is pretty much what everyone talks about, and disagrees how to code, in HTML. As to the "Non-standard" stuff [visual poetry, eastern stuff, etc.] -- I wouldn't claim to know enough to even state how to not do it -- although I'm sure if people were to post examples I would be happy to say "That's not how to do it!" As a practical suggestion on how to test one's ideas start with a standard web browser but then make the page width very wide, and very narrow. If either "breaks" then you have coded the poetry wrong. If either requires or "turns on" horizontal scrolling then its coded wrong -- many reader devices don't support horizontal scrolling. Next try it on a reader device that supports margin subtraction -- aka margin trimming -- not the more common margin additions. If the device crashes or shreds your work, well, I guess it didn't like your coding.
On Thu, November 29, 2012 5:16 pm, James Adcock wrote:
In the end, I think I would follow the W3C and use: <pre class="poem">
The pre suggestion is so bad that I think that those who read it at DP assumed you have not seriously studied the issue of how to code poetry in HTML.
Ahhh, a blanket rejection without supporting analysis. You ought to feel right at home with PGDP.
In general the "poetry" problem is how to reliably wrap lines of text on small machines according to common poetry standards, and to do so in a manner that actual runs correctly on the great majority of reader devices. And to do so in a manner that doesn't require an excess of gimcrackery while coding the HTML.
If I understand this run-on sentence correctly, you believe that the primary problem of encoding poems is how to make them wrap correctly. While I agree that that is /one/ of the problems, it is not the only problem, nor even the most important problem. In my mind, the most important problem is making lines end where the author wanted them to end, as that has the greatest impact on rhyme and meter. The second most important problem is making lines begin where the author wants them to begin. /Now/ we are faced with the problem of how to wrap lines given dynamic screen sizes in such a way that the line endings and beginnings are apparent without being distracting. Two overarching concerns here are 1. how to accomplish these goals when /CSS is not supported/; and 2. how to accomplish these goals in the simplest and cleanest fashion.
This problem is an unsolved, and presumably unsolvable problem.
Unlike you, I do not live in a binary world, where you either have total success or total failure. Sometimes good enough is good enough, and a good as you can get is as good as you can get. The inability to achieve perfection is not an excuse for abandoning the attempt. So, if you don't have CSS (like Mobipocket and 1st generation Kindles), <pre> is probably as good as you can get. At one time, Mobipocket did have some sort of proprietary markup which would cause poetry to wrap with subsequent wrapping to be right justified. If you were to mark poetry with something recognizable, such as <pre class="poem"> a post processing program could easily transform that into whatever Mobipocket is expecting before passing the file to your Kindle program. Now, if you allow CSS then, and only then, can "DP gimcrackery" come into play. But once you allow CSS, the actual element that the CSS is assigned to starts to become less relevant. For example, I can certainly create a CSS rule such that <pre class'para'> would behave exactly like <p>; I don't recommend this, I'm simply saying that it's possible. So my approach is to use <pre class='poem'> and to add all the "gimcrackery" to a pre.poem {...} rule. If you've got a UA that doesn't do CSS (like the Kindle) or which doesn't do it well, the default <pre> presentation is probably as good as it's going to get. But if you've got a UA that supports CSS, you override the default presentation of <pre class="poem"> to give you whatever presentation you want. [snip]
One partial suggestion is to minimize indents and margins when doing poetry in order to minimize the wrap problem. And recognize when the poetry in the original book was wrapped to begin with.
A trick I particularly like is to add inter-word non-breaking spaces to lines of poetry, placing ordinary spaces only at those points in the phrasing where word wrapping should be allowed. It requires a lot of intelligent evaluation, and is not necessary in most cases, but it is an interesting tool to have in the tool belt.
Liz Castro had an intelligent discussion on the problem about a year ago:
http://www.pigsgourdsandwikis.com/2012/01/media-queries-for-formatting-poetr y-on.html
In general I tend not to be very impressed with Ms. Castro's advice. In this case, she settles on increasing the left margin and then adding a negative ("hanging") indent to the beginning of each line, just as the "HTML Best Practices" working group at DP advocates. And of course, the negative indentation trick can be confusing on poems where different spacing is applied at the beginning of each line (e.g. Percy Bysshe Shelly's "To a Skylark"). So far, I have not yet been convinced that <pre class='poem'> is not the best way to indicate the beginning of a poem. At the same time, I've not yet made up my mind as to the best way to construct the CSS rule for pre.poem.
I did a book of Vidyapati poems for PG: http://www.gutenberg.org/files/38174/38174-h/38174-h.htm I let guiguts put in <span>s with margins to format the poetry and it looks OK in HTML but not at all well on a Kindle. I made a Kindle version using non-breaking spaces and making some modest formatting changes. Instead of the speaker of the lines (Krishna) being listed on the same line as the words I put him on his own line. The text did NOT wrap the way we'd all like but the result was readable on a Kindle and I don't think the Kindle could do better with any other format. EPUB and Kindle versions are here: http://archive.org/details/VidyapatiBangiyaPadabali I sell the same Kindle version on Amazon, but not many. James Simmons On Fri, Nov 30, 2012 at 2:29 PM, Lee Passey <lee@passkeysoft.com> wrote:
On Thu, November 29, 2012 5:16 pm, James Adcock wrote:
In the end, I think I would follow the W3C and use: <pre class="poem">
The pre suggestion is so bad that I think that those who read it at DP assumed you have not seriously studied the issue of how to code poetry in HTML.
Ahhh, a blanket rejection without supporting analysis. You ought to feel right at home with PGDP.
In general the "poetry" problem is how to reliably wrap lines of text on small machines according to common poetry standards, and to do so in a manner that actual runs correctly on the great majority of reader devices. And to do so in a manner that doesn't require an excess of gimcrackery while coding the HTML.
If I understand this run-on sentence correctly, you believe that the primary problem of encoding poems is how to make them wrap correctly. While I agree that that is /one/ of the problems, it is not the only problem, nor even the most important problem.
In my mind, the most important problem is making lines end where the author wanted them to end, as that has the greatest impact on rhyme and meter. The second most important problem is making lines begin where the author wants them to begin. /Now/ we are faced with the problem of how to wrap lines given dynamic screen sizes in such a way that the line endings and beginnings are apparent without being distracting.
Two overarching concerns here are 1. how to accomplish these goals when /CSS is not supported/; and 2. how to accomplish these goals in the simplest and cleanest fashion.
This problem is an unsolved, and presumably unsolvable problem.
Unlike you, I do not live in a binary world, where you either have total success or total failure. Sometimes good enough is good enough, and a good as you can get is as good as you can get. The inability to achieve perfection is not an excuse for abandoning the attempt.
So, if you don't have CSS (like Mobipocket and 1st generation Kindles), <pre> is probably as good as you can get. At one time, Mobipocket did have some sort of proprietary markup which would cause poetry to wrap with subsequent wrapping to be right justified. If you were to mark poetry with something recognizable, such as <pre class="poem"> a post processing program could easily transform that into whatever Mobipocket is expecting before passing the file to your Kindle program.
Now, if you allow CSS then, and only then, can "DP gimcrackery" come into play. But once you allow CSS, the actual element that the CSS is assigned to starts to become less relevant. For example, I can certainly create a CSS rule such that <pre class'para'> would behave exactly like <p>; I don't recommend this, I'm simply saying that it's possible.
So my approach is to use <pre class='poem'> and to add all the "gimcrackery" to a pre.poem {...} rule. If you've got a UA that doesn't do CSS (like the Kindle) or which doesn't do it well, the default <pre> presentation is probably as good as it's going to get. But if you've got a UA that supports CSS, you override the default presentation of <pre class="poem"> to give you whatever presentation you want.
[snip]
One partial suggestion is to minimize indents and margins when doing poetry in order to minimize the wrap problem. And recognize when the poetry in the original book was wrapped to begin with.
A trick I particularly like is to add inter-word non-breaking spaces to lines of poetry, placing ordinary spaces only at those points in the phrasing where word wrapping should be allowed. It requires a lot of intelligent evaluation, and is not necessary in most cases, but it is an interesting tool to have in the tool belt.
Liz Castro had an intelligent discussion on the problem about a year ago:
http://www.pigsgourdsandwikis.com/2012/01/media-queries-for-formatting-poetr
y-on.html
In general I tend not to be very impressed with Ms. Castro's advice. In this case, she settles on increasing the left margin and then adding a negative ("hanging") indent to the beginning of each line, just as the "HTML Best Practices" working group at DP advocates. And of course, the negative indentation trick can be confusing on poems where different spacing is applied at the beginning of each line (e.g. Percy Bysshe Shelly's "To a Skylark").
So far, I have not yet been convinced that <pre class='poem'> is not the best way to indicate the beginning of a poem. At the same time, I've not yet made up my mind as to the best way to construct the CSS rule for pre.poem. _______________________________________________ gutvol-d mailing list gutvol-d@lists.pglaf.org http://lists.pglaf.org/mailman/listinfo/gutvol-d
I let guiguts put in <span>s with margins to format the poetry and it looks OK in HTML but not at all well on a Kindle. I made a Kindle version using non-breaking spaces and making some modest formatting changes. Instead of
the speaker of the lines (Krishna) being listed on the same line as the words I put him on his own line. The text did NOT wrap the way we'd all like but the result was readable on a Kindle and I don't think the Kindle could do better with any other format. Yes, this is pretty much indicative of the problems one runs into. In the Kindle case one is seeing a disconcerting series of indents and (accidental) outdents. One can mentally parse it - but I think not enjoy the poetry at the same time. Lest everyone think that I am just a Grinch, note that 12242 is actually quite successful - including on the Kindle. Though I would love to have a page break at the start of each poem so as to not needlessly widow them. These poems are a joy to read. Why does 12242 "work?" Well, the poems "naturally" avoid the wrap problems we are talking about, please the transcriber was smart enough to not indent the poems, thus avoiding self-inflicted wounds.
Ahhh, a blanket rejection without supporting analysis. You ought to feel right at home with PGDP.
Again, this issue has been hashed over many times in many forums with much better analysis that what one will find here. I think most people who try <pre> will rapidly come to the conclusion that it just doesn't cut it. Let someone who cares more about poetry than I have an argument with Lee. Google for a while on "html poetry" and you will see pretty much the full range of ideas -- most of them very bad.
participants (5)
-
don kretz -
James Adcock -
James Simmons -
Keith J. Schultz -
Lee Passey