fix(theme): rail-btn-block must use an explicit width (0.4.1)
0.4.0's rail-btn-block used display:block + width:auto, which fills for an <a> but SHRINK-WRAPS a <button> — a form control does not take the fill-available behaviour a non-replaced block box gets. Measured in one 197px rail-foot container: <a> filled to 177.42px (0 short), <button> came up 114px short. That matters because a rail foot normally holds both element types: Sign In is an anchor, Sign Out is a form-submit button. So 0.4.0's modifier got one right and one wrong, and the wrong one is what signed-in operators see — worse than the width:100% overflow it was meant to replace (~10px of visible clipping). Fixed with an explicit calc(100% - 1.2rem) + box-sizing:border-box, which measures 0px short for both element types. Both rejected shorthands and their measured failures are recorded in the CSS so neither is reintroduced as a 'simplification'. Found by HistorianGateway while evaluating adoption; it held off adopting rather than trading one defect for a larger one. No consumer had adopted the modifier, so nothing shipped broken. The .btn half of 0.4.0 is unaffected and is already live-verified in three apps. Build 0 errors, 48/48 tests.
This commit is contained in:
@@ -4,7 +4,7 @@
|
||||
<Nullable>enable</Nullable>
|
||||
<ImplicitUsings>enable</ImplicitUsings>
|
||||
<LangVersion>latest</LangVersion>
|
||||
<Version>0.4.0</Version>
|
||||
<Version>0.4.1</Version>
|
||||
<ManagePackageVersionsCentrally>true</ManagePackageVersionsCentrally>
|
||||
</PropertyGroup>
|
||||
</Project>
|
||||
|
||||
@@ -226,14 +226,29 @@
|
||||
text-decoration: none;
|
||||
}
|
||||
/* Full-width modifier for a rail-foot action (sign in / sign out), composed as
|
||||
class="rail-btn rail-btn-block". Block + width:auto fills the rail inside the
|
||||
same 0.6rem inset .rail-btn already carries. Deliberately NOT width:100% —
|
||||
that resolves against the containing block and then *adds* the 1.2rem of side
|
||||
margin, overflowing the rail. Apps that hand-rolled this override hit exactly
|
||||
that. */
|
||||
class="rail-btn rail-btn-block".
|
||||
|
||||
The width is explicit — calc(100% - 1.2rem) — and NOT one of the two obvious
|
||||
shorthands, because a rail foot typically holds BOTH element types: Sign In
|
||||
is an <a>, Sign Out is a form-submit <button>. Each shorthand breaks one:
|
||||
|
||||
width: 100% overflows. It resolves against the containing block and then
|
||||
.rail-btn's 0 0.6rem side margins are ADDED on top, pushing
|
||||
the control ~1.2rem past the rail edge (measured: 10px of
|
||||
visible clipping on a 197px rail).
|
||||
width: auto shrink-wraps a <button>. A form control does not take the
|
||||
fill-available behaviour a non-replaced block box like <a>
|
||||
gets, so the anchor filled and the button came up 114px short
|
||||
in the same container. That asymmetry is worse than the
|
||||
overflow it replaced, because the button is the one signed-in
|
||||
operators see.
|
||||
|
||||
calc() gets both right (measured 0px short for <a> and <button> alike). The
|
||||
1.2rem must stay in step with .rail-btn's side margins above. */
|
||||
.rail-btn-block {
|
||||
display: block;
|
||||
width: auto;
|
||||
box-sizing: border-box;
|
||||
width: calc(100% - 1.2rem);
|
||||
text-align: center;
|
||||
}
|
||||
|
||||
|
||||
Reference in New Issue
Block a user