/* ============================================================================================= UI-010 LAYOUT RECONCILIATION - loaded last, after every Bootstrap. THE PROBLEM, MEASURED RATHER THAN GUESSED ----------------------------------------- The admin layouts load two Bootstrap stylesheets: Bootstrap v5.0.0 @Styles.Render("~/Content/css/bootstrap.css") Bootstrap v3.3.7 Reading the computed box model of /Dashboard/Index at a 375px viewport gave: div.container padding-left/right : 12px <- Bootstrap 5 (var(--bs-gutter-x,.75rem)) div.row.extra_m_bottom margin-left/right : -15px <- Bootstrap 3 The container insets by 12 and the row pulls back out by 15, so every .row inside a .container is 6px wider than its parent and hangs 3px past each edge: viewport 375 -> row width 381, spanning L-3 .. R378 That 3px is a horizontal scrollbar on every page built this way, at every width - the audit measured exactly +3px at 320, 375, 390, 430, 768 and 820. It is not a rounding artefact; it is 15 minus 12, one framework's gutter meeting the other's. THE FIX ------- Pin the container gutter to 15px so it matches the -15px row margin the markup actually uses. Bootstrap 3 is the right target: the views contain 183 col-xs-* classes, which exist only in Bootstrap 3, versus a handful of Bootstrap 5 utilities. Deliberately NOT done here: * "html,body{overflow-x:hidden}" - that hides the symptom and silently clips real content. * Removing one of the Bootstrap builds - Home/Index genuinely depends on Bootstrap 5 (data-bs-* attributes and p-5/col-7 utilities) while the admin screens depend on the Bootstrap 3 grid, through the SAME layout. Removing either breaks real pages, so the duplication is reconciled here and recorded for a proper migration later. ============================================================================================= */ .container, .container-fluid { padding-left: 15px; padding-right: 15px; } /* A .row whose gutter came from Bootstrap 5 (margin 0) is left alone - it does not overflow. Only the -15px rows needed the container to match, and they now do. */ /* --------------------------------------------------------------------------------------------- UI-014 A .row inside a
that provides no gutter. MEASURED on /DailyReport/DealerDayBook at a 320px viewport: section L 0 R 320 W 320 padding 0px <- the row's parent div.row L -15 R 335 W 350 margin -15px Bootstrap 3's .row carries margin-left/right:-15px on the assumption that its parent supplies a matching 15px of padding - which .container and every .col-* do. AdminLTE's own
does too. But 26 views wrap their content in a section with NO gutter, either
bare or
, and in those the row hangs 15px past each edge. That single defect accounted for 210 of the overflow measurements in the audit - by far the largest cause. Restoring the 15px gutter on exactly those gutterless sections fixes it without touching .row itself, so every correctly-nested row keeps its normal behaviour. FIRST ATTEMPT, AND WHY IT WAS NOT ENOUGH ---------------------------------------- The first version added 15px of padding to
with no class and to
. That fixed the 21 bare-section views, and the audit's desktop numbers improved - but a re-run still measured +15px on /Recharge/Index and /RechargeReport/NewRechargeReport, whose wrappers are
and
. Enumerating wrapper classes is a losing game: any new view can invent another one. So the rule now targets the row instead. A .row directly inside ANY section other than AdminLTE's own .content (which does supply the 15px it needs) has its negative margin removed. Content then sits inset by the column padding instead of pulling outward, which cannot overflow no matter what the wrapper is. .content is excluded so the 122 views that nest correctly keep their existing spacing exactly. --------------------------------------------------------------------------------------------- */ section:not(.content) > .row, body > .row { margin-left: 0; margin-right: 0; } /* --------------------------------------------------------------------------------------------- UI-011 Nothing may exceed the viewport width. Media, embeds and pre blocks are the usual culprits for overflow that no grid fix can reach, because their intrinsic width ignores the layout entirely. --------------------------------------------------------------------------------------------- */ img, video, canvas, svg, iframe, embed, object { max-width: 100%; } /* --------------------------------------------------------------------------------------------- UI-015 A grid offset applied to a column that is still full width. MEASURED on /Site/Contact at 768px: div.offset-md-1.col-lg-4 is 801px wide in a 768px viewport. "offset-md-1" starts applying at 768px and adds 8.33% of left margin. "col-lg-4" does not narrow the column until 992px. Between those two breakpoints the column is therefore 100% wide AND pushed 8.33% to the right, so it always hangs off the edge - roughly 64px at 768, which is most of the +89px measured on that page. Offsets are only meaningful once the column is narrower than the row, so they are removed below the lg breakpoint and left untouched above it. Attribute selectors match Bootstrap's own specificity and this file loads last, so no !important is needed. --------------------------------------------------------------------------------------------- */ @media (max-width: 991.98px) { [class*="offset-sm-"], [class*="offset-md-"] { margin-left: 0; } } /* --------------------------------------------------------------------------------------------- UI-016 Flex children that refuse to shrink. A flex item's default min-width is auto, which means it will not shrink below the intrinsic width of its content - so one long unbroken string inside a flex row pushes the whole row past the viewport, and overflow-wrap on the text alone cannot fix it. Setting min-width:0 lets the item shrink so the wrapping rules above can take effect. This is the standard remedy for that symptom. It is listed separately from the word-break rules because it addresses the container, not the text. --------------------------------------------------------------------------------------------- */ .d-flex > *, .row > [class*="col-"] { min-width: 0; } img, video, canvas, svg { height: auto; } pre { overflow-x: auto; max-width: 100%; } /* Long unbroken strings - transaction ids, API URLs, base64 blobs - are common in this data and will push a cell past the screen edge on a phone. The list/paragraph selectors were added after the audit measured a consistent +90px overflow at 768px on /Site/privacy, /Site/terms, /Site/Contact, /Account/Index, /Account/SignUpOtp and /Account/UserSignUp, every one of them tracing to "li.paragraph" and a "b" inside it - a long unbreakable run of text in the terms and policy copy. */ .table td, .table th, .breadcrumb, .alert { overflow-wrap: break-word; word-wrap: break-word; } /* WHY THE TEXT ELEMENTS NEED "anywhere" AND NOT "break-word" --------------------------------------------------------- The first version of this rule gave li/p/b/strong "overflow-wrap: break-word" and it did NOT fix them. Measured on /Site/Service at a 768px viewport, AFTER that rule was live: li.paragraph width 228px right edge 849 ul.Contact-details width 155px right edge 721 <- the parent, display:flex viewport 753 -> document overflowed by 96px The child was 73px wider than the parent that was supposed to contain it. The content is the contact email address, a ~23 character run with no break opportunity. "break-word" only permits a break once a word is already being laid out on a line - it does NOT reduce the element's min-content contribution. The
  • is a flex item, and a flex item's automatic minimum size is its min-content width, so the item was sized to the whole unbroken email and pushed straight through its container. "anywhere" behaves identically for line breaking but its break opportunities ARE counted when the intrinsic min-content size is computed, so the item can finally shrink. Confirmed in the browser by applying each candidate and re-measuring: baseline overflow 96px li 228px min-width:0 on the item overflow 0px li 101px overflow-wrap:anywhere on the
  • ONLY overflow 96px li 228px <- still broken word-break:break-all overflow 0px li 101px overflow-wrap:anywhere on li,p,b,strong overflow 0px li 101px <- adopted Note the third line: applying it to the
  • alone changed nothing, because the email is inside a nested . The rule has to reach the inline element that actually holds the long run, which is why and are in this list rather than just the block containers. "break-all" also worked, and is rejected on purpose: it breaks EVERY word at any character, including ordinary prose that fits perfectly well. "anywhere" breaks only what would otherwise overflow. Table cells keep "break-word" above: "anywhere" would also shrink their min-content width to a single character and let the browser re-proportion report columns, which changes tables that are not broken. */ li, p, b, strong, .paragraph { word-wrap: break-word; /* legacy alias for older engines */ overflow-wrap: break-word; /* fallback where "anywhere" is unsupported */ overflow-wrap: anywhere; /* also reduces min-content, which is what actually fixes it */ } /* --------------------------------------------------------------------------------------------- UI-012 Wide tables scroll inside their own container instead of stretching the page. The report screens are inherently wide - twenty-plus columns of transaction data - so the answer is not to shrink them but to let them scroll horizontally within the page, which is the established Bootstrap pattern. Applied only below the desktop breakpoint so the desktop experience is untouched. --------------------------------------------------------------------------------------------- */ @media (max-width: 991px) { .table-responsive { -webkit-overflow-scrolling: touch; overflow-x: auto; width: 100%; } /* Tables NOT already wrapped in .table-responsive still must not stretch the page. */ .box-body > .table, .panel-body > .table, .content > .table { display: block; overflow-x: auto; width: 100%; } } /* --------------------------------------------------------------------------------------------- UI-013 Touch targets on phones. Applied to actual controls - buttons and submit inputs - and NOT to every . Forcing a 44px minimum on all anchors would inflate every row of every dense report table and change far more than it fixed; inline links in prose are not the accessibility problem here. --------------------------------------------------------------------------------------------- */ @media (max-width: 430px) { /* 44px, not the 40px this rule originally used. That was a real mistake on my part: 44px is the accessibility guideline AND the threshold the audit measures against, so every control "fixed" at 40px was still being counted as too small - which is why 228 small-target measurements survived the first pass across 57 pages. A fix that lands just under the bar it is being measured against is not a fix. */ .btn, button, input[type="submit"], input[type="button"], input[type="reset"] { min-height: 44px; padding-top: 10px; padding-bottom: 10px; } /* Icon-only actions in table rows are the smallest targets on the platform - and being square, they fail on WIDTH as well as height, so both are set. */ .btn-xs, .btn-sm { min-height: 44px; min-width: 44px; } /* The first pass sized only .btn/button/input, and the audit still reported small targets on 163 page/width combinations. The ones it was counting are the OTHER interactive controls: or an it is a 44px LINE inside a 44px BOX that also has padding, so the glyphs need 54px of room and get 42 - the bottom of every letter is sliced off. Same defect as FORM-CLIP below, from a different direction. They keep the 44px target; the line is left to the font. */ .dataTables_length select, .dataTables_filter input { display: inline-block; min-height: 44px; height: auto; line-height: 1.4; padding: 8px 12px; } /* Form fields at 16px stop iOS Safari zooming the page when a field is focused, which is what makes a mobile form feel broken - the layout jumps and the user has to pinch back out. */ .form-control, select, textarea, input[type="text"], input[type="password"], input[type="number"], input[type="email"], input[type="tel"], input[type="date"] { font-size: 16px; } } /* ================================================================================================== FORM-CLIP 15-09-2026 - "drop down mai font cut raha hai" THE OWNER REPORTED THIS MORE THAN ONCE AND EVERY SWEEP I RAN CAME BACK CLEAN. Here is why, because the reason matters more than the three lines of CSS underneath it: every "clipped text" check I had written measured WIDTH (scrollWidth > clientWidth). this defect is HEIGHT (scrollHeight > clientHeight). A check that only looks sideways will report a box whose text is sliced along the bottom as perfectly fine, at every width, forever. Tools\tf\FormClip-Check.js now measures both, on every form control on the page. THE DEFECT, measured on /LiveMonitor/Delay5 at 628px (all five filter dropdowns): bootstrap.css select.input-sm { height: 30px; line-height: 30px; } Admin/css/responsive.css @<=767 select.form-control { font-size: 16px; } brand-theme.css @<=767 input, select, textarea { font-size: 16px; } The 16px is deliberate and should stay - under 16px iOS Safari zooms the page the moment a field is focused, and the layout jumps. But Bootstrap 3 pins the small select at a 30px box with a 30px line and 5px of padding top and bottom: the text then needs 40px and the content box offers 28. Measured on every one of them: scrollHeight 35, clientHeight 28 -> the descenders are cut off. Why it looked FINE on a phone and broken on a small laptop window: the @max-width:430px block above already gives every