Csswg-drafts: [css-text] Propose 'text-indent: previous-line' or similar

[robinwhittleton]

There’s a use-case for text-indent from traditional print layout that is not being met by the current specifications: a line indented to the end of the previous paragraph’s line. For example, this Keats poem:

or this poem from Wordsworth:

text-indent: previous-line could work like this:

1. Find the preceding generated line box in the DOM
2. Measure its width
3. Apply an indent in the natural language direction of the element the rule applies to that matches the width of the previous element.

Obviously as with anything like this there are a bunch of interactions that would need to be discussed:

• _Flexbox reordering:_ this should presumably be ordering-aware.
• _Not applying to first block of a separate section:_ can be reset using typical declarations (e.g. p:first-child { text-indent: 0; }) or only applied to following elements (p + p { text-indent: previous-line; }).
• _RTL issues:_ boxes that share a direction will both work fine. Boxes with separate directions probably don’t have a use case for this, so a naive solution of simply applying the same indent in the opposite direction feels fine.

As far as I can work out there’s nothing in any of the existing css-text specifications that would allow this. It’s not important enough for inclusion in CSS Text 3, but is it a valid use case for CSS Text 4?

I’ve not tried to suggest an extension to the specs before so I’m not sure this is the best way to go about it; if I should be making a proposal on a mailing list I’ll happily do that instead.

[Loirooriol]

I think this should be restricted to the previous line box inside the same block formatting context. Or maybe inside the same column box.

[robinwhittleton]

Incidentally it looks like this typographical arrangement might be called ‘dropline paragraphs’. An alternative value could be text-indent: dropline? That feels a little less readable to me though.

[frivoal]

I think this is commonly found in longform text in verse. Not the most common form of writing currently, but certainly one with lots of existing content.

I cannot comment about how browsers would prioritize this, but I'd support having it.

+1 to scoping it per BFC, but I don't see why it should be limited to a single column box. I don't think this really simplifies anything, and even if it ends up in a different column, it is still the later half of a verse.

[Loirooriol]

How should this behave in the presence of floats?

[frivoal]

@Loirooriol great question. I suspect we might actually be quite free to chose what we prefer here, because as far as I know the traditional use case is not used together with floats.

My personal expectation would probably be:

• line 1: column 2
• line 2: column 2
• line 3: column 1
• line 4: unsure. Maybe column 1, maybe neither and push either the float or the new line down so that the new line can start where the previous one ended.

[robinwhittleton]

Agreed that whatever is easiest for browser manufacturers to implement, the simplest algorithm, is probably the preferred option here. In that case, I’d vote for column 2 in every case I think.

[patrickdark]

@Loirooriol I'd say the rule should be to always horizontally align text which should lead to a result of left/right/left/left.

Aligning to the last line would also be fine, which would lead to a result of left/left/left/left.

Simply measuring the preceding text width only and matching that seems to defeat the point of the feature if it results in a misalignment.