/* assets/css/tool-pages.css * * Structural layout ONLY for the at_tool single/archive pages -- no * colors, no fonts, no backgrounds set here on purpose, so whatever * theme is active still controls the actual look (text color, link * color, font family, dark/light mode, etc. all inherit normally). * This is what lets templates/single-tool.php and templates/ * archive-tool.php look reasonable on ANY theme, not just the one this * plugin happened to be built against -- see inc/cpt/theme-compat.php's * header comment for the header/footer/sidebar side of that same goal. */ .at-tool-page-wrap, .at-tools-archive-wrap { /* FIX (didn't match the rest of the site): the theme's own content width everywhere else -- Page, Archive, Single Post templates -- is capped at 1200px (theme.json's settings.layout.wideSize). This was 1400px, 200px wider than that, for no functional reason (unlike the sidebar's fixed-vs-percentage width below, which trades this exact kind of consistency for a real fix -- see that comment). Matching 1200px here just removes an arbitrary mismatch. */ /* FIX (still ~18px narrower than the theme's own 1200px content area even after the above): two compounding causes. (1) box-sizing:border-box means this element's own left/right padding (5px + 5px below) is carved OUT of the 1200px max-width, leaving only 1190px for .at-tool-columns -- the theme's own column wrapper (.wp-block-columns) has no such padding and gets the full 1200px. Bumping max-width to 1210px cancels that out (1210 - 5 - 5 = 1200, matching the theme exactly). (2) .at-tool-columns below hardcodes gap:32px, but the theme's own column layout uses WordPress's global spacing token instead (:root{--wp--style--block-gap:24px}, applied via :where(.is-layout-flex){gap:24px}) -- so post/page/archive pages have a 24px gap between content and sidebar, not 32px. Matching that removes the second, smaller part of the mismatch. */ max-width: 1210px; margin: 0 auto; padding: 32px 5px 56px; box-sizing: border-box; /* FIX (page-wide cut-off on small screens, reported across every tool -- including Electricity Calculator, which has its own entirely separate stylesheet with no code in common with the other tools, so the cause can't be inside any one tool's own CSS). This is the one element every /tools// page shares no matter which tool is embedded: if the tool's own markup ever renders slightly wider than the viewport (a decorative element, a Tailwind/library default, a fixed-width third-party embed), this was the last place capable of containing it before it reached the theme's and forced the WHOLE PAGE to scroll horizontally -- which reads as "the edge of the screen cuts the text off" rather than a local scrollbar, because nothing here stopped it from propagating that far up. overflow-x:hidden is a hard backstop at the wrap level specifically (not a global html/body rule, which this plugin has no business setting on a theme it doesn't own): it can only ever hide a few stray pixels of something that was already a bug, never a deliberate part of this layout. */ overflow-x: hidden; } /* REMOVED (was here, caused a real regression): a blanket `.at-tool-page-wrap * { max-width:100% !important }` rule used to live here, added back when the actual overflowing element hadn't been identified yet. Since then the real, specific causes were found and fixed directly (ads-settings.php's ad wrapper, and the container/sidebar width mismatch vs. the theme). That blanket rule turned out to actively break things it was never meant to touch: individual tools' own Tailwind utility classes -- e.g. Electricity Calculator's bill-breakdown donut chart uses `max-w-[180px]` on its quite deliberately, to keep the chart a sane size next to its legend. `!important` unconditionally overrides that (any `!important` always wins over a non-important rule, regardless of selector specificity or source order), stretching the chart and squeezing the legend into the space that left it -- exactly the "legend cut off, horizontal scrollbar underneath" bug reported after this rule was added. A blanket "cap everything" rule can't tell the difference between "nothing constrains this, it needs a cap" and "a tool deliberately chose a smaller max-width" -- it will always risk breaking the second case for the sake of the first. The remaining, *targeted* containment below (the wrap's own overflow-x, the embed wrapper's overflow-x, the ad wrapper's own max-width) still holds; this file no longer reaches into every tool's own internal markup. */ .at-tool-page-wrap .at-tool-columns { display: flex !important; flex-wrap: nowrap !important; /* Matches the theme's own column gap (see the max-width comment above) -- var() with the 24px fallback so this still works if a future theme update ever changes --wp--style--block-gap. */ gap: var(--wp--style--block-gap, 24px); align-items: flex-start; box-sizing: border-box; } /* Matches the theme's own Page/Archive/Single Post column split EXACTLY (see templates/page.html, archive.html, single.html -- all three use flex-basis:70%/30%, not a fixed sidebar width), per explicit request to have the content/sidebar width be identical between a tool's own page and every other page on the site. Tradeoff, stated for the record: individual tools (see e.g. inc/tools/electricity-calculator.php, marked "DO NOT REDESIGN") ship their own internal Tailwind sm:/md:/lg: breakpoints, which key off the BROWSER VIEWPORT width, not this column's actual width. With this percentage split, the content column's pixel width is always some fraction of the viewport -- so a tool's own breakpoint can switch on at viewport widths where this column is still narrower than what that breakpoint assumed. Below 1024px this doesn't matter (the columns stack to full width, see the media query further down) -- it only applies at 1024px and up, where a tool's own layout might look squeezed compared to viewing it full-width. If that shows up on a specific tool, the fix is in that tool's own CSS (widen/simplify its desktop breakpoint), not here. */ .at-tool-page-wrap .at-tool-columns > .at-tool-content-col { flex: 1 1 70% !important; min-width: 0; /* prevents long URLs/text in a tool from blowing out the flex item */ box-sizing: border-box; } /* FIX (some tools' width exceeding the theme on mobile, cutting off the header/body): this wrapper -- the direct parent of whatever do_shortcode($shortcode) renders -- had no CSS rules at all, so it was purely trusting each tool's own markup to self-constrain to 100% width. .at-tool-content-col above already has min-width:0 so *it* can shrink, but that doesn't stop a wide-content child from pushing this specific box past the column's edge. `overflow-x: auto` (rather than hidden) means this box can never force the outer page to scroll sideways, but if a tool's content still doesn't fit at some width, it gets a small scrollbar local to the tool instead of losing content outright. */ .at-tool-page-embed { max-width: 100%; overflow-x: auto; -webkit-overflow-scrolling: touch; box-sizing: border-box; } /* FIX (content and sidebar still not starting on the same line): the earlier margin-top:0 fix (on .at-tool-content-col's first child) covered accidental MARGIN, but some tools give their own outermost wrapper top PADDING instead -- e.g. Electricity Calculator's own root markup is `
`, a deliberate 2.5rem/40px gap that makes sense standalone, but is redundant here since .at-tool-page-wrap already adds its own top padding around the whole embed. Gold & Silver Price's own root has no such padding, so it started flush while Electricity Calculator started ~40px lower -- not a fixed, predictable offset, since it depends on whichever tool happens to be embedded, which is exactly why it looked like "sometimes higher, sometimes lower" rather than a consistent gap. Zeroing top padding on .at-tool-page-embed's own first child AND that child's first child (Electricity Calculator's actual `
` is one level in -- `.ashraf-elec-calc` is the immediate child, `
` is its first child) neutralizes this for every tool the same way, without touching any tool's own markup or its later/internal spacing -- it stops two levels deep on purpose, so it can't reach into a tool's own inner cards or sections. !important because a tool's own utility class (like Tailwind's `.pt-10`) is otherwise equal specificity to this rule and could still win on source order. */ .at-tool-page-embed > :first-child, .at-tool-page-embed > :first-child > :first-child { padding-top: 0 !important; margin-top: 0; } .at-tool-page-wrap .at-tool-columns > .at-tool-sidebar-col { /* Matches the theme's own sidebar column exactly -- see the content-column rule above for why (and its stated tradeoff). */ flex: 1 1 30% !important; min-width: 0; box-sizing: border-box; } /* Some themes' sidebar.php / widget markup ships its own "width: 100%" * or "float" rules meant for THEIR normal #primary/#secondary layout. * Since we reuse that markup inside our own flex column, neutralize * anything that could push it wider than the column and force a wrap. */ .at-tool-page-wrap .at-tool-columns > .at-tool-sidebar-col > * { max-width: 100%; box-sizing: border-box; float: none !important; } /* FIX (content and sidebar not starting at the same top line): the flex row itself already aligns both columns' tops correctly (align-items:flex-start above), but whatever each column's first child happens to be can still carry its own top margin -- a heading's default margin, a widget's default spacing, etc. -- which pushes that column's VISIBLE content down below the row's actual top edge without affecting the other column. Since the two columns almost never start with the same kind of element (a tool's own markup vs. whatever's in the sidebar), their default top margins essentially never match either, so one column reliably starts looking lower than the other. Zeroing it on both sides is the same fix the theme itself already uses for this exact situation -- see site-styles-deferred.css's `.myanas-page-columns>.wp-block-column> :first-child{margin-top:0}` rule for the theme's own Page/Archive/ Single columns. */ .at-tool-page-wrap .at-tool-columns > .at-tool-content-col > :first-child, .at-tool-page-wrap .at-tool-columns > .at-tool-sidebar-col > :first-child { margin-top: 0; } /* FIX (sidebar card still sits visibly lower than the content card, even after the margin-top:0 fix above): margin-top:0 only cancels an accidental top MARGIN -- it can't fix a mismatch that's really coming from the two boxes' own different chrome/padding once the theme's own reset finishes. The theme already hit this exact problem on ITS OWN two-column templates (Page/Archive/Single Post) and compensates with a hard -31px pull on the sidebar column -- see site-styles-deferred.css's `.myanas-page-columns .wp-block-column:last-child{margin-top:-31px}` (also applied to .myanas-archive-columns/.myanas-review-columns/ .myanas-single-columns). That rule is scoped to the theme's own column classes, so it silently doesn't reach .at-tool-sidebar-col -- this plugin uses its own class names precisely so it isn't coupled to one theme's markup (see this file's header comment). Applying the theme's own -31px correction here too is what actually makes the tool page's sidebar match, instead of guessing at a new number that would only be right for this one theme's current widget markup. Scoped to the same width the two-column layout is actually active (>1024px, matching the stacking breakpoint below) so it doesn't do anything once the columns have already stacked. */ @media (min-width: 1025px) { .at-tool-page-wrap .at-tool-columns > .at-tool-sidebar-col { margin-top: -31px; } } /* FIX (tablet / small-laptop squeeze): was 780px. That let the two-column layout switch on right as a tool's own `md:` (768px) breakpoint was ALSO switching to its desktop-oriented rules -- the worst possible overlap, since that's exactly when a tool starts assuming it has close to full viewport width available and instead got shoved into a much narrower column. Stacking all the way up to 1024px means the content column runs full width through phones, small tablets, AND standard tablets/small laptops -- covering every width a tool's own sm:/md: rules target -- and the sidebar only appears once there's enough room (1024px+ viewport, ~700px+ content column at 70%) for it to sit alongside a tool without cramping it. */ @media (max-width: 1024px) { .at-tool-page-wrap .at-tool-columns { flex-direction: column !important; } .at-tool-page-wrap .at-tool-columns > .at-tool-sidebar-col { flex-basis: auto !important; max-width: none; } } /* Archive/hub page (templates/archive-tool.php) has no sidebar by * design -- .at-tool-content-col--full overrides the normal 70% flex * basis so it fills the whole width instead of leaving a 30% gap where * a sidebar would've been. */ .at-tool-content-col.at-tool-content-col--full { flex: 1 1 100% !important; max-width: 100%; } /* Page title and breadcrumb stay in the DOM (and in the accessibility * tree, unlike display:none) so they still count for SEO/screen * readers and internal-link crawling, they're just not shown visually. * Standard "visually-hidden" clip technique. */ .at-tool-page-title, .at-tool-page-breadcrumb { position: absolute; width: 1px; height: 1px; padding: 0; margin: -1px; overflow: hidden; clip: rect(0, 0, 0, 0); white-space: nowrap; border: 0; } .at-tool-page-intro { margin-bottom: 28px; } .at-tool-related { margin-top: 48px; padding-top: 24px; border-top: 1px solid currentColor; border-top-color: rgba(128, 128, 128, 0.25); } .at-tool-related h2 { font-size: 1.1em; margin-bottom: 12px; } .at-tool-related ul { display: flex; flex-wrap: wrap; gap: 10px; list-style: none; padding: 0; margin: 0; } .at-tool-related a { display: inline-block; padding: 8px 14px; border: 1px solid rgba(128, 128, 128, 0.3); border-radius: 8px; text-decoration: none; } /* Archive / hub page */ /* Visible hero for the root /tools/ page only (see the "Archive Headline * (H1)" / "Archive Description" fields on the Configuration Hub's * General Settings tab) -- deliberately NOT using the visually-hidden * .at-tool-page-title treatment above, since showing this text is the * entire point of that setting. No color/font set here either, for the * same theme-agnostic reason as the rest of this file. */ .at-tools-archive-hero { margin-bottom: 28px; } .at-tools-archive-hero-title { margin: 0 0 8px; } .at-tools-archive-hero-desc { margin: 0; opacity: 0.75; } .at-tools-category { margin-bottom: 36px; } .at-tools-category h2 { font-size: 1.2em; margin-bottom: 14px; } .at-tools-grid { display: grid; /* Default 220px, overridable per-site via the "Card Min Width" * field on the Configuration Hub's Appearance tab -- see the inline * style on .at-tools-archive-wrap printed by archive-tool.php. This * is layout, not color/font, so it doesn't conflict with this file's * theme-agnostic design. */ grid-template-columns: repeat(auto-fill, minmax(var(--at-tools-card-min-width, 220px), 1fr)); gap: 16px; } .at-tools-card { display: block; padding: 16px; /* Follows the active theme's own accent color instead of a fixed * one, so this looks native on any theme: tries the block-theme * standard preset slots (primary, then accent) that theme.json * themes commonly define, and only falls back to a neutral grey * border if neither exists (classic themes with no color presets). */ border: 1.5px solid var(--at-tools-card-accent, var(--wp--preset--color--primary, var(--wp--preset--color--accent, rgba(128, 128, 128, 0.35)))); border-radius: 16px; text-decoration: none; transition: border-color 0.15s ease, transform 0.15s ease; } .at-tools-card:hover { border-color: var(--at-tools-card-accent, var(--wp--preset--color--primary, var(--wp--preset--color--accent, rgba(128, 128, 128, 0.6)))); transform: translateY(-2px); } .at-tools-card-icon { display: flex; align-items: center; justify-content: center; aspect-ratio: 16 / 10; font-size: 2em; margin-bottom: 10px; border-radius: 10px; /* Same theme-accent tint as the border, just faint, as a * "thumbnail" background behind the icon -- color-mix() keeps this * theme-native rather than a hardcoded color; browsers without * color-mix() just fall back to no background, which still looks * fine. */ background: color-mix(in srgb, var(--at-tools-card-accent, var(--wp--preset--color--primary, var(--wp--preset--color--accent, currentColor))) 12%, transparent); } .at-tools-card-title { font-size: 0.95rem; font-weight: 700; line-height: 1.35; margin-bottom: 4px; } .at-tools-card-desc { display: block; font-size: 0.8rem; opacity: 0.8; } @media (min-width: 480px) { .at-tools-card-title { font-size: 1rem; } }