/***    Sun Decor Fabrics :: FABRICS MODULE STYLESHEET
        Built by EJFIIIWebDesign.com
        Loads AFTER the site's main style.css -- reuses its variables,
        color palette (#C14F22 accent), fonts, and hover/grayscale language
        so this module looks native to the rest of the site.            ***/


/***    *******************************************************
                       FABRICS NAV PANEL -- the shared slide-in skeleton
                       (position, size, background, box-shadow, base
                       typography, .menuHead/a/li) now lives in your main
                       style.css under the shared .menuPanel class (both
                       #menu and #fabricsMenu carry that class) -- only
                       Fabrics-specific INNER content classes stay here.
        *******************************************************   ***/

        .menuPanel .menu-divider          { border: 0; border-top: 1px solid #ededed; margin: 14px 0 14px 20px; }
        .menuPanel .menu-groupings-label  { font-size: 0.85em; letter-spacing: 0.1em; text-transform: uppercase; color: #999999; margin: 10px 0 6px 20px; display: block; }


/***    *******************************************************
                       MASTER FABRICS PAGE
        *******************************************************   ***/

        .fabrics-page               { width: 94%; margin: 0 auto 6%; }
        .fabrics-hero                { text-align: center; margin-bottom: 3%; }
        .fabrics-hero h1             { font-size: 3.4em; }
        .fabrics-hero p              { max-width: 900px; margin: 0 auto 15px; text-align: center; }

        /* .fabrics-layout itself no longer needs any rule at all --
           position:relative used to live here, but #filtersPanel is a
           direct child of this element, and since its own
           position:absolute needs to match .menuPanel's real behavior
           (measured from the document root, confirmed by checking your
           actual Style.css -- #wrapper never sets position:relative
           either), this element can't establish its own containing block.
           This is what was actually causing the panel to land lower and
           further right than the main menu -- not a sizing issue at all,
           an origin-point one. Nothing else in this stylesheet depended
           on it, and .fabrics-results (width:100%, next) doesn't need
           anything from its parent either, since #filtersPanel being
           absolutely positioned already takes it out of normal flow. */
        .fabrics-results            { width: 100%; }

        .fabrics-results-bar         { display: flex; justify-content: space-between; align-items: center; margin-bottom: 20px; }
        .fabrics-results-count       { font-size: 1.3em; color: #999999; }
        .fabrics-sort select         { font-size: 1.2em; border: 1px solid #cccccc; padding: 6px 10px; }


/***    *******************************************************
                       FILTERS PANEL (slide-in, same mechanism
                       as #menu/#fabricsMenu -- see js/fabrics.js)
        *******************************************************   ***/

        .fabrics-filters-toggle      { display: inline-block; margin-bottom: 20px; padding: 10px 24px; font-size: 1.3em;
                                        text-transform: uppercase; letter-spacing: 0.05em; background-color: #333333; color: #ffffff;
                                        border: none; cursor: pointer; }
        .fabrics-filters-toggle:hover { background-color: #C14F22; }

        #filtersPanel                { font-size: 0.7em; font-family: Roboto, 'Century Gothic', sans-serif;
                                        position: absolute; top: 240px; left: -800px; z-index: 999;
                                        width: 330px; height: auto; box-sizing: border-box; overflow-y: auto;
                                        margin-left: 13px; padding: 20px; background: #ffffff;
                                        border: 5px solid #ffffff; box-shadow: 5px 5px 10px 0px rgba(0,0,0,0.5); transition: all 1s; }
        /* Matched directly against your real Style.css's .menuPanel rule
           (position, top, height:auto instead of a forced bottom:0,
           margin-left, border, box-shadow, transition) rather than
           estimated -- confirmed exact values from the uploaded file.
           width is 330px here, not .menuPanel's literal 300px -- .menuPanel
           doesn't use box-sizing:border-box, so its actual rendered width
           is 300 (content) + 20 (padding-left, its only padding side) + 10
           (5px border, both sides) = 330px total. This DOES use
           border-box, where the width value already includes padding and
           border -- so 330px here is what actually produces a matching
           330px rendered size, even though the property values
           themselves don't match verbatim. left:-800px (not a percentage)
           is safe here specifically BECAUSE width is fixed -- a fixed
           offset only risks leaving an edge visible when the panel's own
           width scales with the viewport, which this no longer does at
           the widest breakpoint (though it still does at ≤980px below,
           same as .menuPanel's own #menu override does).

           One thing I can't fully verify without seeing this actually
           render: .menuPanel uses position:absolute, and #wrapper never
           sets position:relative anywhere in your Style.css -- so
           .menuPanel's top:240px is most likely measured from the top of
           the whole document, not some nearby container. This panel
           renders from a different place in the DOM (inside the page
           content, not <header>), so if some OTHER ancestor along its
           own path happens to set its own position, the visual result
           could land differently than .menuPanel's. Worth confirming
           side by side once it's live rather than assuming a perfect
           match.

           padding is 20px on every side here, not just padding-left like
           .menuPanel -- that rule only ever holds a simple link list, so
           a left-only inset was enough; this one holds swatches and
           accordion headings that need room on every edge. This value is
           also hardcoded in js/fabrics.js's toggle/close handlers -- keep
           both in sync. */

        .filters-panel-header        { display: flex; align-items: baseline; border-bottom: 1px solid #dcdcdc; padding-bottom: 14px; margin-bottom: 14px; }
        .filters-panel-header h3     { font-size: 2.6em; font-weight: 400; color: #C14F22; text-transform: uppercase; letter-spacing: 0.05em; margin: 0; }
        .filters-panel-close         { background: none; border: none; font-size: 2.8em; line-height: 1; color: #999999; cursor: pointer; padding: 0; margin-right: 16px; }
        .filters-panel-close:hover   { color: #C14F22; }
        /* margin-left: auto pushes this (and anything after it) to the far
           right of the header row, without needing a separate footer
           section at all -- was previously at the bottom of the panel. */
        .filters-panel-header .filters-clear { margin-left: auto; font-size: 1.45em; color: #C14F22; text-decoration: none; cursor: pointer; white-space: nowrap; }

        .fabrics-search              { width: 100%; margin-bottom: 10px; }
        .fabrics-search input        { width: 92%; height: 38px; padding-left: 6%; border: solid 1px #cccccc; font-size: 1.4em; }

        /* ---- Filter accordion: one collapsible pane per dimension ----
           Deliberately its own, self-contained styling rather than
           reusing .collapsible/.panelContent from the detail page's specs
           accordion -- those rules live in your real Style.css, tuned for
           a different context (specs on a full-width page section), and
           I don't have that file to confirm they'd behave the same way
           repurposed inside a narrow slide-in panel. Built from scratch
           here instead, so nothing about this depends on unseen rules
           behaving a certain way in a new context. */
        .filter-accordion-item       { border-bottom: 1px solid #dcdcdc; }
        .filter-accordion-heading    { display: flex; align-items: center; width: 100%; text-align: left;
                                        background: none; border: none; cursor: pointer; padding: 14px 0;
                                        font-size: 1.75em; font-weight: 400; color: #666666; text-transform: uppercase;
                                        letter-spacing: 0.05em; }
        .filter-accordion-heading:hover { color: #C14F22; }
        .filter-accordion-heading::after { content: '+'; margin-left: auto; font-size: 1.3em; font-weight: 300; color: #999999; transition: transform 0.2s; }
        .filter-accordion-heading[aria-expanded="true"]::after { content: '\2212'; } /* minus sign, not a hyphen -- renders as a proper flat dash at this font-weight instead of a barely-visible sliver */
        .filter-accordion-content    { overflow: hidden; max-height: 0; transition: max-height 0.3s ease; }
        .filter-accordion-content.is-open { max-height: none; }
        /* Fixes the real bug: the base rule's max-height:0 applied
           unconditionally to every pane, INCLUDING the server-rendered
           Color pane, which only ever had aria-expanded="true" going for
           it -- nothing actually counteracted the CSS default unless JS's
           restoreAccordionState() ran with an existing sessionStorage
           entry, which never exists on a genuinely fresh session. This is
           why Color consistently looked collapsed despite the "-" showing
           correctly -- not a session-restore quirk at all, confirmed from
           your screenshot. is-open only matters for this initial,
           un-animated render -- max-height:none isn't transition-safe
           (transitions can't animate to/from a keyword like "none"), but
           JS's own setPaneOpen() always sets an explicit inline pixel
           value via scrollHeight on every later toggle, which correctly
           overrides this class regardless. */
        .filter-count-badge          { margin-left: 10px; font-size: 0.75em; font-weight: 400; color: #C14F22; text-transform: none; letter-spacing: 0; }

        /* Text-filter dimensions (everything except Color): 2 columns,
           per your Item 5 request -- was a single column per .filter-
           column before, back when each dimension had a whole grid
           column of its own width to work with. */
        .filter-group-columns        { display: grid; grid-template-columns: 1fr 1fr; gap: 0 4%; padding-bottom: 10px; }
        .filter-group                { margin-bottom: 14px; }
        .filter-group label          { font-size: 1.55em; font-weight: 300; text-transform: none; letter-spacing: 0;
                                        display: flex; align-items: center; gap: 10px; margin: 6px 0; padding: 4px 0; cursor: pointer; color: #666666; }
        .filter-group label:hover    { color: #C14F22; }
        .filter-group input[type=checkbox] { width: 20px; height: 20px; margin: 0; flex-shrink: 0; }

        /* Color swatches: clickable colored shapes rather than a checkbox +
           text row. The checkbox itself is visually hidden (not display:none,
           so it stays keyboard/screen-reader accessible) -- clicking the
           swatch shape works because it's wrapped in the same <label>.
           25% (4 per row), not 20% (5) -- now that the panel's real width
           is confirmed at a fixed 300px (not the earlier 420px estimate),
           5 per row means roughly 52px per slot, which risks the same
           label-collision issue flagged before at an even tighter width
           than where it happened last time. 4 per row gives more breathing
           room per swatch; still worth confirming visually, since this is
           exactly the kind of thing that's looked fine on paper before. */
        .swatch-grid                 { display: flex; flex-wrap: wrap; gap: 4px 0; padding-bottom: 10px; }
        .swatch-option                { display: inline-flex; flex-direction: column; align-items: center; width: 25%;
                                         margin: 10px 0; padding: 6px 0; cursor: pointer; text-align: center; }
        .swatch-checkbox              { position: absolute; width: 1px; height: 1px; padding: 0; margin: -1px; overflow: hidden;
                                         clip: rect(0,0,0,0); white-space: nowrap; border: 0; }
        .swatch-option .filter-swatch { display: block; width: 30px; height: 30px; border-radius: 50%; border: 2px solid #ffffff;
                                         box-shadow: 0 0 0 1px #cccccc; transition: box-shadow 0.15s; }
        .swatch-option:hover .filter-swatch { box-shadow: 0 0 0 1px #999999; }
        .swatch-checkbox:checked ~ .filter-swatch { box-shadow: 0 0 0 3px #C14F22; }
        .swatch-checkbox:focus-visible ~ .filter-swatch { outline: 2px solid #333333; outline-offset: 2px; }
        .swatch-label                 { font-size: 1em; color: #666666; margin-top: 6px; line-height: 1.2; }
        .swatch-option:hover .swatch-label { color: #C14F22; }

        /* Tone/Lightness -- deliberately quiet, sitting below the color
           swatch grid rather than as their own accordion panes, so a
           visitor scanning the pane sees Color first and only notices
           these on the way down. Both start disabled/faded (server-
           rendered that way in fabrics_render_filter_panel(), kept in
           sync afterward by js/fabrics.js's syncToneLightnessUI()) until
           at least one color is selected.
           A soft background box (rather than a divider line) marks this
           as its own little zone within the Color pane without a hard
           visual break -- no rounded corners, generous bottom margin so
           it doesn't crowd whatever border sits below this whole pane.
           Label size/weight matches the panel's own established
           .filter-group label convention (1.55em) rather than an
           invented value, with the Tone/Lightness words themselves bold
           to read as their own small labels next to the lighter-weight
           option text beside them.
           The real fix for alignment: .tl-row is display:contents, not a
           grid of its own -- two SEPARATE per-row grids can never share
           a column width with each other no matter how that width is
           chosen, since each one sizes independently to its own content.
           Making both rows' label/options spans direct children of ONE
           shared grid (.filter-tone-lightness itself) lets max-content
           size that first column to whichever label is actually widest
           ("Lightness"), with Tone's row correctly ending up with extra
           leftover space in that same column -- exactly the "there's a
           lot of space" observation, kept rather than removed, since
           that space is what lets both rows' radios start at the same
           X position regardless of the two labels' different lengths. */
        .filter-tone-lightness        { display: grid; grid-template-columns: max-content 1fr; column-gap: 10px; row-gap: 8px;
                                         background: #f2f2f2; padding: 10px 10px 14px; margin: 6px 0 16px; }
        .tl-row                       { display: contents; }
        .tl-label                     { font-size: 1.55em; font-weight: 700; color: #888888; }
        .tl-options                   { display: flex; flex-wrap: wrap; align-items: center; gap: 10px; align-self: center; }
        .tl-row label                 { font-weight: 300; color: #888888; display: inline-flex; align-items: center; gap: 10px; cursor: pointer; }
        .tl-row input[type=radio]     { width: 15px; height: 15px; margin: 0; }
        .tl-row.tl-disabled .tl-label,
        .tl-row.tl-disabled label     { color: #cccccc; cursor: not-allowed; }
        /* Small red "x" -- takes the place of an "Any" radio option among
           the real choices; only shown once that specific group actually
           has a selection (toggled via display:none/inline, matching the
           inline style this same markup is server-rendered with). */
        .tl-clear-icon                { font-size: 1.05em; color: #C0392B; cursor: pointer; line-height: 1; }
        .tl-clear-icon:hover          { color: #922B21; }


/***    *******************************************************
                       ACTIVE FILTER CHIPS (above the results grid)
        *******************************************************   ***/

        .active-filter-chips         { display: flex; flex-wrap: wrap; gap: 8px; margin-bottom: 20px; }
        /* Whole chip is the click target now, not just the "x" -- same
           behavior at every breakpoint (no separate mobile treatment),
           since a small "x" alone was a fat-finger problem everywhere,
           not just on small screens. padding widened a bit from before to
           give the larger tap target some real room; min-height keeps it
           comfortably tappable even for a short one-word chip. */
        .filter-chip                  { display: inline-flex; align-items: center; gap: 6px; background-color: #ededed;
                                         color: #444444; font-size: 1.2em; padding: 8px 16px; border-radius: 3px;
                                         min-height: 20px; cursor: pointer; transition: background-color 0.15s; }
        .filter-chip:hover,
        .filter-chip:focus-visible    { background-color: #e0d0cb; outline: none; }
        .chip-remove                  { color: #b23b3b; font-weight: bold; font-size: 1.2em; line-height: 1; }

        /* The fabric grid itself reuses your site's native .full-width /
           .polaroids classes directly in the markup (sizing/responsiveness
           inherited from your real breakpoints, not duplicated here) --
           EXCEPT the grayscale-until-hover thumbnail treatment
           (`.full-width .polaroids li { filter: grayscale(100%); }` in
           your real Style.css), which is deliberately turned back off
           below -- seeing the actual fabric color matters for these
           specifically, unlike generic product photography where the
           grayscale/color-on-hover effect is just a stylistic flourish.
           More specific than the real rule (3 classes vs. 2), so this
           wins on its own without needing !important -- and since only
           Fabrics pages load this file, the real Roller Shades pages
           keep the grayscale effect exactly as before. */
        .fabrics-page .full-width .polaroids li { filter: none; }
        .polaroids small.fabric-color-label { display: block; text-transform: uppercase; letter-spacing: 0.04em; color: #999999; font-size: 0.85em; margin-top: 2px; }
        /* Confirmed root cause (thank you for tracking this down in
           Firefox's inspector): your real Style.css's own
           `.full-width .polaroids span { padding: 10px 0; ... }` was
           landing on this swatch too, since it's a <span> nested inside
           .polaroids -- 10px top/bottom padding turned a 10x10 circle
           into an oblong ~10x31 shape (padding adds to height, not width,
           since there's none on the sides), and border-radius:50% on a
           non-square box renders an ellipse, not a circle.
           Same fix as the .fabrics-page .full-width .polaroids li rule
           just above -- 3 classes beats the master rule's 2, so this
           wins reliably without !important, and it's scoped to fabrics.css
           only, not touching Style.css or any other page that rule
           applies to. */
        .full-width .polaroids .fabric-color-swatch { display: inline-block; width: 10px; height: 10px; padding: 0; border-radius: 50%; border: 0.5px solid rgba(0,0,0,0.15); vertical-align: -1px; margin-right: 4px; }
        /* Solid by default (background-color set inline per card, from the
           colorway's own primary_color_hex). The split variant overrides
           this with a two-color diagonal gradient instead -- only ever
           applied when 2+ colors are actively filtered AND this specific
           colorway genuinely has a secondary color set (see
           fabrics_render_card()), so a split circle is a real, always-true
           statement about why this fabric matched, never decorative. */
        .full-width .polaroids .fabric-color-swatch-split { border-color: rgba(0,0,0,0.25); }
        /* Extra pairing circles (3+ colors filtered, a fabric matching on
           more than one distinct color pair) sit right after the main
           circle, slightly overlapped so they read as a small cluster
           rather than a second unrelated row. Purely informational --
           no href, no hover state, unlike the main circle's link. */
        .full-width .polaroids .fabric-color-swatch-extra { margin-left: -3px; margin-right: 1px; }
        .full-width .polaroids .fabric-color-swatch-more { display: inline-block; font-size: 0.85em; color: #999999; vertical-align: 1px; margin-left: 1px; margin-right: 2px; }

        .fabrics-empty                { text-align: center; padding: 8% 0; color: #999999; font-size: 1.6em; width: 100%; }
        .fabrics-loading              { text-align: center; padding: 4% 0; color: #cccccc; font-size: 1.4em; }

        .fabrics-load-more            { text-align: center; margin-top: 20px; }


/***    *******************************************************
                       SEO GROUPING (LANDING) PAGES
        *******************************************************   ***/

        /* Vignette slideshow -- 600x600 square, same square-crop/breakpoint-
           scaling approach as the detail page's #keyImage. Scoped to
           .group (grouping.php's real pageRef -- see that file's header
           comment for why) so this never touches any other page.

           Your real `.media-column { width: 40%; margin: 50px 4%; }` is a
           FIXED PERCENTAGE here -- a genuinely different situation from
           the detail page's width:auto, which was competing with
           .text-column for space. Overridden with fixed pixel sizing
           instead, matching the vignette images' own intended display
           size directly. NivoSlider's images are position:absolute (they
           don't contribute to their container's natural size the way a
           normal <img> would), so both the container AND the images
           themselves need an explicit size -- !important on the <img>
           rule is defensive, in case NivoSlider's own JS sets inline
           width/height styles directly (common for slideshow plugins). */
        .group .media-column                 { width: auto; max-width: 640px; margin: 50px 4%; }
        .group .media-column .slider,
        .group .media-column .nivoSlider     { width: 600px; height: 600px; }
        .group .media-column .nivoSlider img { width: 600px !important; height: 600px !important; }

        .key-benefits b    { font-size: 1.7em; }


/***    *******************************************************
                       FABRIC DETAIL PAGE
                       Uses pageRef=="detail" now, so the shared skeleton
                       (.text-media, .media-column, .text-column,
                       #keyImage base sizing, .breadcrumb, #specs,
                       .button) comes entirely from your real Style.css --
                       everything below is a Fabrics-only ADDITION layered
                       on top, never a redeclaration of something your
                       real CSS already owns. Only takes effect on pages
                       that also load this file (i.e. only Fabrics pages),
                       so none of this touches the real Roller Shades
                       product pages even though they share pageRef=="detail".
        *******************************************************   ***/

        /* Your real rule is `.detail #keyImage { width: 480px; height: auto; }`,
           sized for the site's existing VERTICAL product photos. Fabric
           photos are square, so the same treatment makes them look
           squat/small next to that reference. Flipping to a fixed height
           with width:auto keeps a comparable visual weight -- scaled down
           at each breakpoint below so a fixed height doesn't overflow
           narrow screens (width:auto alone won't shrink to fit the way
           max-width does, since height is no longer "auto"). */
        .detail #keyImage              { width: auto; height: 600px; max-width: 100%; border: 1px solid #C14F22; }
        .detail #keyImage.zoomable     { cursor: pointer; } /* only clickable when the active colorway actually has a zoom variant -- see detail.php's $zoomUrl check */

        /* Without this, .media-column's width:auto (your real rule) has
           nothing to wrap the colorway thumbnails AGAINST -- with more
           than ~6 colorways, the thumbnail row just keeps growing wider
           instead of wrapping, dragging the whole box wider than the
           keyImage along with it (confirmed symptom: keyImage shrinking
           relative to an over-wide box, uneven padding on the right).
           This caps the box at the keyImage's own width (matching each
           breakpoint's height below, since the image is square) plus a
           little headroom for the real .media-column padding -- with that
           actually enforced (box-sizing: border-box, same fix as the
           filter panel needed earlier for the same underlying reason:
           percentage padding computes against the flex container, not
           this element's own capped width, so without border-box the
           cap doesn't actually hold), the thumbnails now have a real
           width to wrap within, and stay perfectly centered under an
           image that's exactly as wide as its container. This same
           max-width is *also* the fix for your text-column measurements
           below -- .text-media is a flex row, and .media-column's old
           unbounded width:auto was competing with .text-column's nominal
           34% for space (a flex item's declared `width` is only a
           starting basis, not a hard floor, when its sibling also wants
           more room) -- capping media-column stops it from crowding
           text-column out, letting it settle back to its own real 34%,
           which should now land at the same pixel width as the window
           side at every breakpoint, matching what you found firsthand
           with Firefox's inspector. */
        .detail .media-column           { max-width: 640px; box-sizing: border-box; text-align: center; }
        .gallery-thumbs                 { text-align: center; margin-top: 20px; padding: 0; display: flex; flex-wrap: wrap; justify-content: center; width: 100%; }
        .gallery-thumbs a               { display: inline-flex; flex-direction: column; align-items: center; margin: 8px; text-decoration: none; }
        .gallery-thumbs img             { width: 70px; box-sizing: border-box; padding: 3px; border: 1px solid #ffffff; box-shadow: 5px 5px 10px 0px rgba(0,0,0,0.4); cursor: pointer; transition: all 0.4s; }
        .gallery-thumbs a:hover img,
        .gallery-thumbs img.active      { border-color: #C14F22; }
        .gallery-thumbs .colorway-label { display: block; text-align: center; font-size: 1.1em; margin-top: 4px; color: #666666; }
        .gallery-thumbs a:hover .colorway-label { color: #C14F22; }
        /* Adjusting Margin Setting for Gallery Thumbnails on Fabrics Detail
           This Style Sheet loads after Style.css so overwrites Style Rule for margin */
        .detail .gallery-thumbs img         { margin: 0; }

        /* Fabric name (h1) now correctly inherits your real 3.0em/3.1em
           .text-column h1 sizing. Meta Theme sits in the same visual slot
           the colorway name used to occupy -- a generic, non-product-
           specific search phrase (set per-fabric in the admin), not tied
           to whichever colorway happens to be active, so it doesn't
           change when swapping colorways below. */
        .meta-theme                     { font-size: 1.2em; font-style: italic; color: #777777; margin-bottom: 10px; display: block; }

        .fabric-tags                    { list-style: none; padding: 0; margin: 20px 0; }
        .fabric-tags li                 { display: inline-block; font-size: 1.15em; background-color: #ededed; color: #666666; padding: 6px 16px; margin: 0 6px 6px 0; text-transform: uppercase; letter-spacing: 0.04em; }

        /* Your real `#specs th { text-decoration: underline; }` -- removed
           here (only takes effect on Fabrics pages, since only they load
           this file) and replaced with a colon, which reads more like a
           label than an underline does. */
        #specs th                       { text-decoration: none; }
        #specs th::after                { content: ': '; }

        /* Your real `#specs ul li::before` is tuned for a DIFFERENT use
           case elsewhere in #specs (a floating grid of small icon
           thumbnails, per `#specs ul li { float:left; } #specs ul li img
           { width:60px; }`) -- it zeroes out the bullet's allocated width
           (`width:0; margin-left:2px;`) for that context, which is exactly
           right there but collides with the general
           `.detail .text-column ul li::before` bullet (content, color)
           still applying underneath it for a plain text list like
           Recommended Uses -- the dot still renders but has almost no
           room, landing on top of the first letter instead of beside it.
           Scoped to .fabric-uses-list specifically so this doesn't touch
           the real icon-grid use case anywhere else in #specs. */
        #specs .fabric-uses-list li::before { width: 2em; margin-left: 1em; }

        .specs-disclaimer { text-align: center; font-size: 0.90em !important; color: #999999; margin-top: 16px; }

        /* Your real Scripts.js (case "detail") auto-appends "Request Info"
           and "Email a Friend" buttons into #spreading-the-word on every
           page using pageRef=="detail" -- including fabric pages, since
           they share that pageRef now (see detail.php's header comment).
           .info (Request Info) is re-enabled per your Item 2 request --
           .friend (Email a Friend) stays hidden for now since you only
           asked to activate Request Info specifically; say the word if
           you'd like that one turned on too. Hidden via CSS rather than
           via a second body class, since Scripts.js's page-type switch
           compares the FULL class string against "detail" -- a second
           token ("detail fabrics") would break that match entirely and
           lose FancyBox/the specs accordion too, not just this button.
           This only loads on Fabrics pages, so the real Roller Shades
           product pages still show both normally. */
        #spreading-the-word .friend     { display: none; }
        #spreading-the-word             { text-align: center; }
        .detail #spreading-the-word .button { width: 70%; }
        /* Centers the button(s) within #spreading-the-word regardless of
           how many are visible -- text-align works here since Scripts.js's
           appended <a class="button"> links are inline-level elements. */


/***    *******************************************************
                       RESPONSIVE
        *******************************************************   ***/

        @media only screen and (max-width: 1700px) {
            /* Matches your real #wrapper narrowing at this tier (1760px -> 1380px) --
               #keyImage's fixed height needs to shrink to match, same idea as
               your real #keyImage's width:480px naturally fitting via
               max-width:100% (this one needs explicit steps since height
               isn't auto). */
            .detail #keyImage { height: 500px; }
            .detail .media-column { max-width: 540px; }
            .group .media-column                 { max-width: 540px; }
            .group .media-column .slider,
            .group .media-column .nivoSlider     { width: 500px; height: 500px; }
            .group .media-column .nivoSlider img { width: 500px !important; height: 500px !important; }
        }

        @media only screen and (max-width: 1380px) {
            .detail #keyImage      { height: 420px; }
            .detail .media-column  { max-width: 460px; }
            .group .media-column                 { max-width: 460px; }
            .group .media-column .slider,
            .group .media-column .nivoSlider     { width: 420px; height: 420px; }
            .group .media-column .nivoSlider img { width: 420px !important; height: 420px !important; }
        }

        @media only screen and (max-width: 980px) {
            /* .text-text/.media-column/.text-column stacking on narrow
               screens is already handled by your real Style.css (the
               `.text-text, .text-media { display: inherit; }` rule at
               this same breakpoint) -- so the media-column/text-column
               flex-competition issue this max-width otherwise fixes
               doesn't apply here (they're stacked, not side by side) --
               matches your own measurements showing the two sides
               already landing within 1px of each other at this tier.
               Still capping media-column's width here regardless, for
               the separate thumbnail-wrapping fix, which applies either
               way. */
            .detail #keyImage      { height: 340px; }
            .detail .media-column  { max-width: 380px; }
            .group .media-column                 { max-width: 380px; }
            .group .media-column .slider,
            .group .media-column .nivoSlider     { width: 340px; height: 340px; }
            .group .media-column .nivoSlider img { width: 340px !important; height: 340px !important; }
            /* Removed a .menuPanel override that lived here before --
               that was a mistake made without the real Style.css to check
               against. .menuPanel is shared by BOTH #menu and
               #fabricsMenu, so touching it here was silently changing the
               real site's own main menu behavior, not just anything of
               mine, and it wasn't even necessary -- the real base rule
               already sets left:-800px on its own. Your real site's own
               mobile adjustment for #menu specifically happens at 580px,
               not this breakpoint -- left alone now.
               #filtersPanel doesn't need its own left override repeated
               at any breakpoint either -- the base rule's -800px reliably
               hides it regardless of how wide the panel itself gets at a
               narrower breakpoint below, since even a width:100% panel on
               a mobile viewport stays well under 800px. */
        }

        @media only screen and (max-width: 580px) {
            /* .polaroids already has its own 580px rules in your real
               style.css (li width 21%, no image border, etc.) -- nothing
               fabric-specific needs overriding at this breakpoint. */

            /* Your real site drops body to 50% font-size at this
               breakpoint (`body { font: 50.0%/1.25 ...}`), which
               #filtersPanel's own 0.7em inherits from -- meaning without
               this, panel text would end up HALF as large (relatively)
               on mobile as everywhere else, the opposite of "don't lower
               the font size on mobile." 0.7 / 0.5 = 1.4em keeps the
               EFFECTIVE rendered size the same as desktop rather than
               literally doubling it from where it'd otherwise land.
               One thing worth flagging: .menuPanel has NO equivalent
               compensation in your real Style.css, so the main menu's own
               text genuinely does get smaller on mobile -- this rule is a
               deliberate departure from matching it exactly, prioritizing
               readability over an exact match. Remove it if you'd rather
               this panel's mobile text shrink the same way the main
               menu's does. */
            #filtersPanel           { font-size: 1.4em; }
            /* Two-column layout kept at every viewport now, per your
               explicit note -- the max-width:none 1-column override that
               used to live here is gone. */

            .detail #keyImage      { height: 280px; }
            .detail .media-column  { max-width: 320px; }
            .group .media-column                 { max-width: 320px; }
            .group .media-column .slider,
            .group .media-column .nivoSlider     { width: 280px; height: 280px; }
            .group .media-column .nivoSlider img { width: 280px !important; height: 280px !important; }
        }