[sourcejedi]

I'm not sure what your code is trying to accomplish here? You've effectively set all the <span>s to outdent by 2em ... I think you'd either have to use a :first-child pseudo-selector

Try it yourself - literally, just c&p my code into a file. It works as a hanging indent for me.

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].

Originally Posted by ATDrake

...I think... 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.

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.

Interesting, I hadn't tested DIV. That's almost plausible, but CSS doesn't say anywhere "but P is special, ATDrake's explanation doesn't apply to P". Note that the default spacing on P is defined as a margin, not as an extra line break. That's not a de jure standard, because the default layout of P isn't set in stone by a standard. But it's described that way in non-normative parts of various standards, and that's how everyone implements it. If you only refer to CSS, DIV with a margin would work exactly the same as P -- but it doesn't.

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.

In this case, I would go with <p>s for containing and visually separating the separate stanzas, and <div>s for keeping each line individual, as well as a <div> as a whole-poem container*. Less breakage that way, because if the CSS styling doesn't get copy-pasted, <span>s are going to collapse into single lines without the <br>s to separate them, display: block or no.

1) Document type does not allow element "div" here; missing one of "object", "ins", "del", "map", "button" start-tag: <p><div>line1</div></p>. (W3C validator in html fragment mode and XHTML doctype; the HTML doctype also disagrees: it automatically closes the P when it sees the DIV, and then complains about the extra closing P tag).

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>&nbsp;</div> de-facto standard invented by MS Word.

* It's a flow element, so go with the flow†…

<reads>. Flow is almost the most general category, which excludes only funky meta stuff like HEAD. Um, that is, it works as a joke, but it's too general to help as an explanation .

† I will refrain from making a "use the Source, Luke…" joke here.

That's where my alias comes from .