[3.0] Theme split (wave 2, part 7) — Use logical properties for the float and alignment utilities

[albertlast]

Description

Part of the #7933 split, wave 2 part 7 — the first of the RTL parts. Stacked on #9350 through #9355, in that merge order.

rtl.css exists to flip physical properties. Where a rule can say inline-start and inline-end instead of left and right, it follows the writing direction on its own and the override is not needed. This does that for the float and alignment utilities:

.floatright { float: inline-end; }
.floatleft  { float: inline-start; }
.clear_left { clear: inline-start; }
.clear_right{ clear: inline-end; }
.righttext  { margin-inline-start: auto; margin-inline-end: 0; text-align: end; }
.lefttext   { margin-inline-start: 0; margin-inline-end: auto; text-align: start; }
.bbc_list   { text-align: start; }

Seven overrides drop out of rtl.css, which goes from 686 to 665 lines. #7933 ends up at 414, so this is the first bite of that.

Left to right is untouched, right to left gets a fix

LTR is unchanged: twelve geometry probes, no differences.

RTL changes in one place, and it is a repair. .righttext and .lefttext set an auto margin as well as a text alignment, and rtl.css only ever flipped the alignment:

/* index.css */          .righttext { margin-left: auto; margin-right: 0; text-align: right; }
/* rtl.css, today */     .righttext { text-align: left; }

So in an RTL forum a .righttext block has been hugging the right edge — the start side — while its own text aligns left. Measured in a 400px container, the box sat 300px from the left before and sits at 0 now, which is the end side, where its text already was.

The alignment itself does not move. The same run measured where the text lands inside the block, for .righttext, .lefttext and .bbc_list, and reports no change in either direction — only the box position changed.

Testing

Fresh install on MySQL, Docker environment, with lang_rtl set on en_US to get dir="rtl". Captured on both branches, in both directions.

Geometry rather than computed styles, deliberately: getComputedStyle returns float: inline-end as authored rather than resolving it, so a computed-style comparison reports a difference for every converted declaration and proves nothing either way. getBoundingClientRect measures what actually happened. Each probe records the box's distance from both edges of a fixed 400px parent, its vertical offset and its width — so a float that lands on the wrong side, a clear that fails to clear, and an alignment that does not move all show up as numbers.

	probes	differences
LTR	12	0
RTL	12	2 — .righttext and .lefttext box position, described above

Error log clean. The unit suite does not reach CSS, so there is no test to add here.

Issues References (Fixes|Related|Closes)

Related to #7933, #9350, #9351, #9352, #9353, #9354, #9355

[albertlast]

There is now an alternative for anyone who would rather take wave 2 as a single unit: #9358 carries all eight parts, merged and verified together against plain release-3.0.

It is an either/or, not an addition — merging #9358 means closing this one, and vice versa. Whichever suits the review better.

[Sesquipedalian]

This PR does what it is supposed to do, so the following issue is not a problem with the PR itself. Rather, this PR has brought to my attention an issue that already existed and that we might as well fix now.

The [float] BBCode takes a parameter to indicate whether it should float to the left or the right (i.e. [float=left] or [float=right]). End users writing their posts generally expect that the left/right parameter value will function as described regardless of the writing direction of the text in which the BBCode is inserted. For that reason, we should add the following additional CSS rules to index.css:

.bbc_float.floatleft {
	float: left;
}
.bbc_float.floatright {
	float: right;
}

This is a change that should probably also be implemented in SMF 2.1, but that is outside of the scope of this PR.

[Sesquipedalian]

I have implemented my suggested changes myself.