04-19-2011, 01:34 PM | #1 |
Groupie
Posts: 155
Karma: 200000
Join Date: Dec 2009
Location: Britania
Device: Android
|
Semantic formating for simple poetry: any comments on my code?
Code:
<p>1<br/> 2<br/> 3</p> <p>a<br/> b<br/> </p> Code:
p { text-indent: 0.5in; margin-left: 0.5in } <p>1</p> <p>2</p> <p>3</p> <p><br /></p><!-- blank line --> <p>second stanza... Code:
p .line { display:block } <p> <span class="line">1<br/></span> <span class="line">2<br/></span> <span class="line">3</span></p> <p> <span class="line">Second stanza... The BR's at the end of the 'display:block' SPANs are puzzling me. If I put a BR at the end of a P, I get an extra blank line -- but it doesn't seem to happen with the SPANs. innerHTML says the BRs are still there -- so it's not a parsing quirk. And it shouldn't be a quirks mode quirk; I used a HTML5 doctype on my test page. Is this actually standardized anywhere? CSS shows a "default" styling for BR using generated content, which in theory could be overridden in case future renderers adopt a more uniform treatment. (br:after, br:before {content:none}). But that doesn't work in current browsers, so there's no guarantee it would help. Which suggests that this hasn't been formalized in a standard. |
04-19-2011, 01:41 PM | #2 |
Groupie
Posts: 155
Karma: 200000
Join Date: Dec 2009
Location: Britania
Device: Android
|
Aha! If I remove the BR's, the line breaks go away too. I'm clearly missing something about how CSS works.
|
04-19-2011, 02:00 PM | #3 |
Wizzard
Posts: 11,517
Karma: 33048258
Join Date: Mar 2010
Location: Roundworld
Device: Kindle 2 International, Sony PRS-T1, BlackBerry PlayBook, Acer Iconia
|
<span>s are an inline element. Whatever you're using to view seems to ignore the CSS display setting and only apply the <br>s.
I think you're getting extra linespacing with your combo <p><br> because unless you explicitly set to override, <p>s are usually rendered with a default line-break and linespace anyway. I would advise the use of <div> for your stanza lines. It comes with a built-in linebreak but no linespace and should give you the display result you want in a reasonably semantic way without having to tweak the CSS too much or add extra markup that might be superfluous. |
04-20-2011, 04:24 AM | #4 |
frumious Bandersnatch
Posts: 7,533
Karma: 19000001
Join Date: Jan 2008
Location: Spaniard in Sweden
Device: Cybook Orizon, Kobo Aura
|
You can use plain <div>, with something like:
Code:
<div class="poetry"> <div class="stanza"> <div>line 1</div> <div>line 2</div> <div>line 3</div> </div> <div class="stanza"> <div>line 4</div> <div>line 5</div> <div>line 6</div> </div> </div> Code:
div.poetry { /* set margins for the whole poetry block */ } div.stanza { /* set margins for each stanza */ } div.poetry div { /* set hanging indent for poetry lines */ } |
04-21-2011, 11:05 AM | #5 |
Groupie
Posts: 155
Karma: 200000
Join Date: Dec 2009
Location: Britania
Device: Android
|
How about negative margins on inline boxes?
Thanks for helping a newbie sort himself out! All your technical points look correct. It's interesting that the default styling of DIV is so convenient for lines of poetry; I hadn't realized that. You're also right that it's a slight improvement on P for my purposes: better to use a more semantically neutral element than to lie outright.
1. Even after re-fixing my test environment so my SPANs were actually displayed as block elements, I still see the mystery that a single BR at the end of the display:block SPAN has no effect. This is exactly what I want, but I can't rely on it unless I know why. 2. Thinking about it, I don't want to literally "disable" BR when the CSS is enabled. I realized I could do that simply using display:none, but then I break copy+paste -- it looks like Firefox very sensibly skips display:none elements during copy+paste. 3. The third solution, avoiding all the issues so far, would be to use display: inline-block (and put the BRs just outside the span). But it's not supported by EPUB 2.0. 4. That's pretty much everything you could do to get text-ident to work, but what about other properties? How about using negative margins on inline boxes: Code:
<!DOCTYPE html><!-- complete (though technically invalid) document --> <style> .basic-poetry { margin-left: 2em; } .basic-poetry > p > span { margin-left: -2em; } /* P may well be styled with an indent, e.g. iBooks default stylesheet, so we'd better reset it */ .basic-poetry > p { margin-top: 0; margin-bottom: 1em; text-indent: 0 } </style> <div class="basic-poetry"><!-- consider replacing DIV with SECTION or BLOCKQUOTE, according to context --> <p> <span>this is a very long line, a very long line, to i-i-i-ndicate the use, the usefulness of hanging indents to us all, except it's not real poetry so the point is probably lost, never mind, tra-la;</span><br /> <span>line 2</span><br /> <span>line 3</span></p> <p> <span>line 4, which starts a new stanza</span><br /> <span>line 5</span></p> </div> |
04-21-2011, 11:09 AM | #6 |
Groupie
Posts: 155
Karma: 200000
Join Date: Dec 2009
Location: Britania
Device: Android
|
Rant: reliance on CSS
Relying on CSS to provide essential information is a pet peeve of mine. If the UA ignores the CSS in your example, it's going to lose the stanza boundaries.
In the past, I've heard this "justified" with <but we're talking about EPUB, and CSS support is mandatory for conformant EPUB reading systems>. But in this case, I think it would also break copy+paste. If I want to copy a few short verses into an email to a friend, copy+paste will only see the selected HTML, right? It's not guaranteed to see the CSS that sets margins for each stanza. Last edited by sourcejedi; 04-21-2011 at 11:09 AM. Reason: fix posting markup ;) |
04-21-2011, 04:32 PM | #7 | |||
Wizzard
Posts: 11,517
Karma: 33048258
Join Date: Mar 2010
Location: Roundworld
Device: Kindle 2 International, Sony PRS-T1, BlackBerry PlayBook, Acer Iconia
|
Quote:
A <br> inside a <span> counts as part of the <span>, and when you display: block it, it's included inside the new block box boundaries and can only "stack" according to default new display: block rules, which say 1 linebreak, no extra space unless declared elsewhere in the CSS. So a single <br> creates a linebreak, which is "folded" inside the linebreak created when the <span> becomes a block, and sort of squishes into just the one linebreak as they stack directly on top of one another. Whereas a <br> outside the <span> adds an extra, because it's like a wedge stuck in between the new blocks, providing new linespace. You can see this exact same effect with plain <div>s. A single <br> inside the <div> will not increase the linespace separating the <div>s, but more than one will, as will one outside. Quote:
For a classic hanging indent with just the first line outdented, I think you'd either have to use a :first-child pseudo-selector on .basic-poetry > p, or just mark up the first lines of each stanza or poem (depending on how you want it to look) with a new class to target. Possibly you might be able to use negative values on text-indent (which is supposed to be a block-level style) on the <p> and just push in the .basic-poetry block entirely and skip applying a margin to the <span>s, if that's what you want to achieve. Quote:
Hope this helps. * It's a flow element, so go with the flow†… † I will refrain from making a "use the Source, Luke…" joke here. |
|||
04-22-2011, 04:55 AM | #8 |
frumious Bandersnatch
Posts: 7,533
Karma: 19000001
Join Date: Jan 2008
Location: Spaniard in Sweden
Device: Cybook Orizon, Kobo Aura
|
Except that <p>s cannot contain block-level elements, such as <div>. Which is a pity, because sometimes a block (of poetry, a centered line, a blockquote, etc.) is semantically inside a paragraph, and is visually marked so because the first line after the block is not indented, and sometimes even starts with a lowercase letter. This would be ideally coded with <p>...<div>...</div>...</p>, but due tho this restrictions it has to be: <p>...</p><div>...</div><p class="noindent">...</p>.
|
04-22-2011, 05:22 AM | #9 | |||||
Groupie
Posts: 155
Karma: 200000
Join Date: Dec 2009
Location: Britania
Device: Android
|
Quote:
The trick is that the left margin on inline boxes only applies to their first line. (Similarly, the right margin applies only to their last line). The old O'Reilly files I came across pointed out that you also see this with borders on inline boxes. [No link -- I don't think it was supposed to be online. But it all seems very nice and consistent]. Quote:
What CSS does say is: BR is special; its behaviour cannot be described by CSS. It also hints that it's a replaced element. I did refer to the CSS2.1 stylesheet earlier, which includes an attempt at default styling for BR. But it's non-normative, so it's not necessarily subject to the same scrutiny. Firefox (v4) and at least one other still treat it as a replaced element which can't really be styled. And the suggested default style uses generated content and 'white-space: pre-line'; so it should be fully defined by the appropriate section, which doesn't justify this behaviour at all. So I think it's unsafe to rely on. For someone developing a new reading system, they're unlikely to put extra effort into matching browser rendering when it's not part of the spec. Quote:
2) Confirmed. I can certainly see why people like DIV for lines of poetry. If I took that approach, I'd insert blank lines using flow content. Either the deprecated <div><br/></div>, similar to what Sigil generates if you leave a blank paragraph, or the old <div> </div> de-facto standard invented by MS Word. Quote:
Quote:
Last edited by sourcejedi; 04-22-2011 at 05:31 AM. |
|||||
04-22-2011, 05:31 AM | #10 | |
Wizzard
Posts: 11,517
Karma: 33048258
Join Date: Mar 2010
Location: Roundworld
Device: Kindle 2 International, Sony PRS-T1, BlackBerry PlayBook, Acer Iconia
|
Quote:
I guess <p>+<span><br> is the way to go for cut-and-paste comptibility, then. Mind you, I wouldn't bother putting display: block on the the <span>s, since the <br>s accomplish the task of visually separating them, and I think a hanging indent is best handled by using a negative text-indent value on the containing block. Though alternatively, one could be perverse and add padding-left to the <span>s and no padding-left to the :first-child <span> of the containing <p>. Assuming a sufficient quantity of rendering agents recognize the more difficult pseudo-class selectors, which I would personally not bet upon. I suppose marking up the first lines with special classes would be the way to go. |
|
04-22-2011, 05:40 AM | #11 | |
Groupie
Posts: 155
Karma: 200000
Join Date: Dec 2009
Location: Britania
Device: Android
|
Quote:
=> once you've got block boxes, <br> at the end is going to leave blank lines, which you need to nullify somehow. - you either have to rely on this undefined "a single <br> at the end of a block box has no effect on layout, unless the block box is a P element" - or you have to do something even crazier like fixing the line-height and then setting a negative margin-top on br+span. - which is why I think I prefer using inline boxes with negative margins. |
|
04-22-2011, 05:47 AM | #12 | |
frumious Bandersnatch
Posts: 7,533
Karma: 19000001
Join Date: Jan 2008
Location: Spaniard in Sweden
Device: Cybook Orizon, Kobo Aura
|
Quote:
Code:
'You are old, Father William', the young man said, 'And your hair has become very white; And yet you incessantly stand on your head-- Do you think, at your age, it is right?' Code:
'You are old, Father William', the young man said, 'And your hair has become very white; And yet you incessantly stand on your head-- Do you think, at your age, it is right?' |
|
04-22-2011, 06:28 AM | #13 | ||||||
Wizzard
Posts: 11,517
Karma: 33048258
Join Date: Mar 2010
Location: Roundworld
Device: Kindle 2 International, Sony PRS-T1, BlackBerry PlayBook, Acer Iconia
|
Quote:
Quote:
There's probably no actual consensus because the W3C's never bothered setting down even suggested base guidelines for how stuff might present itself in particular types of user agents for some form of lowest common denominator visual compatibility, and then kind of relied on CSS to automagically fix presentation issues across the board, and then people have to come up with various workarounds when it doesn't. Quote:
Quote:
Quote:
Your example code works exactly the way it originally displayed after I changed all the <p> and <span> to <div>, got rid of the <br>, and changed the now .basic-poetry > div > div from a margin-left to a text indent. It would seem to avoid the uncertainty you describe above, without having to worry about much in the way of rendering agent incompatibility. Quote:
Possibly you could just test your example file in as many browsers/reader apps as you can try out and see if they're reasonably consistent in giving the no-extra-linespace after <span>+<br> for reassurance. They probably will, since everybody really just wants to look-and-feel like everyone else*. After that, full speed ahead and damn the torpedos! * Except Microsoft, who want everyone else to look-and-feel like them. |
||||||
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Formatting, code, simple help needed | panda6855 | Sigil | 43 | 01-13-2011 06:37 PM |
request for comments on my poetry | Joebill | Writers' Corner | 24 | 11-14-2010 06:25 PM |
erm, simple question , hope for simple answer! | al zymers | Amazon Kindle | 5 | 09-25-2010 01:01 PM |
Let's create a source code repository for DR 800 related code? | jraf | iRex | 3 | 03-11-2010 12:26 PM |
Simple question for a simple mind :) | PKFFW | OpenInkpot | 6 | 08-27-2009 09:00 PM |