Quote:
Originally Posted by sourcejedi
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).
|
Ah. I was fooled by there only being one very long line that indented at the wrap, and the rest following being too short for my lazy brain to notice the effect at a cursory glance. That makes sense now.
Quote:
Originally Posted by sourcejedi
That's almost plausible, but CSS doesn't say anywhere "but P is special, ATDrake's explanation doesn't apply to P".
|
Honestly, it's all just handwavy guessing anyway. I think the real reason is that browsers apply a set default style to <p> and <p> in conjunction with <br> to match people's expectations of how they should work, but don't do it with <div> beyond putting in the obligatory block-level break from sibling content.
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:
Originally Posted by sourcejedi
If I took that approach, I'd insert blank lines using flow content.
|
Only we're not supposed to do any of that anymore. Along with many of the more useful workarounds for the intersection of markup and presentation limitations. Sigh.
Quote:
Originally Posted by Jellby
I think you are not addressing the core problem. Having poetry lines is easy, the tricky thing is having each line wrap independently and with a hanging indent when the block width is small.
|
You're right; I mistook the OPs' code as being intended to produce the more usual type of typographical hanging indent, rather than a line offset type. Sorry for the confusion.
Quote:
Originally Posted by sourcejedi
=> 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.
|
If it weren't for the cut-and-paste compatibility issue, I think I'd choose to go with appropriately classed and nested <div>s myself.
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:
Originally Posted by sourcejedi
- which is why I think I prefer using inline boxes with negative margins.
|
Well, you've got things working the way you want them to with only one minor concern.
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.