/* tt360/section's own CSS (docs/PLAN.md §7). Replaces the prototype's old convention of every
   page hand-setting its own section's padding/background in its own layout/*.css file (.value,
   .lifecycle, .comparison, .features all independently declared "padding: 96px 0" plus their own
   background) with one shared recipe driven by the block's two attributes. */

.tt360-section {
    padding: 96px 0;
}

/* Editor-only, scoped under .editor-styles-wrapper (a class that only ever exists in the block
   editor's own iframe body — this selector cannot match on the front end, in this file or any
   other, regardless of where the CSS text itself is loaded): this block is a full-bleed
   <section>, with only its own .container child ever constrained, but theme.json's presence
   now makes the editor apply its own default content-width centering to any block — root-level
   or nested inside another block's InnerBlocks — that isn't explicitly aligned "full".
   "layout": false in block.json doesn't stop this — that support only governs how a block lays
   out its OWN children, not how it's treated by ITS OWN parent context. Found the real rule
   causing it by checking which loaded CSS rules actually matched this element in a live editor
   session: GeneratePress's own editor-style.css sets a real `--content-width` custom property
   on <body> (`calc(1200px - 40px - 40px)`, its own sidebar-aware layout math, nothing to do
   with this theme's own `--container-width`) and applies it to any bare `.wp-block` via
   `body .wp-block { max-width: var(--content-width) }`. An earlier version of this fix used a
   `body .wp-block-tt360-section` selector, which also matches this exact class on the front
   end (even though it was a harmless no-op there, since .tt360-section never had its own
   max-width) — replaced with this .editor-styles-wrapper-scoped version so the rule can never
   reach the front end at all, not just happen not to change anything there. */
.editor-styles-wrapper .block-editor-block-list__layout .wp-block-tt360-section {
    max-width: none;
}

.tt360-section-bg-white {
    background-color: rgba(var(--white), 1);
}

.tt360-section-bg-cream {
    background-color: rgba(var(--cream), 1);
}

.tt360-section-bg-green {
    background-color: rgba(var(--terra-green), 1);
}

/* bg-none: no background-color at all, the page's own background shows through, same as the
   homepage's Team section today. */

/* Flush top: no gap from whatever sits directly above (a testimonial, an archive teaser row),
   bottom padding stays normal. Matches components/testimonial.css's .testimonial-section
   (padding: 0 0 96px) exactly. */
.tt360-section.tt360-section-flush-top {
    padding-top: 0;
}

/* Flush bottom: no gap to whatever sits directly below, top padding stays normal. Independent
   of flush-top (a section can have either, or both at once), since they touch different
   properties on desktop. */
.tt360-section.tt360-section-flush-bottom {
    padding-bottom: 0;
}

/* sm: half the desktop padding, same convention already used sitewide ("Section
   padding on phones is half the desktop value" rule). Flush top stays 0, nothing to halve. */
@media (max-width: 575.98px) {
    .tt360-section {
        padding: 48px 0;
    }

    .tt360-section.tt360-section-flush-top {
        padding-top: 0;
        padding-bottom: 48px;
    }

    /* Must come after the flush-top rule above: both selectors share the same specificity
       (two classes each), and when a section has both flush-top and flush-bottom, this one
       needs to win the padding-bottom tie so flush-top's own padding-bottom: 48px (restoring
       the base mobile bottom padding, see above) doesn't bring it back. */
    .tt360-section.tt360-section-flush-bottom {
        padding-bottom: 0;
    }
}