/*
 * ACTIVITY_LIFE_SOCIAL_LOGIN_BUTTON_SHELL_V1
 *
 * Facebook (data-height="48px"), Google (GIS default) and X/Twitter
 * (height:40px, parent theme) render at three different outer heights,
 * so the "or continue with" stack looks inconsistent. Normalize only the
 * OUTER shell HEIGHT to 44px for all three, via !important CSS on the
 * visible iframe/div box. Radius (10px) and each provider's own width
 * behavior are left untouched by this file.
 *
 * Google's WIDTH is handled separately, natively, at the actual call
 * site (activity-life-tools/assets/js/google-social-login-secure.js,
 * ACTIVITY_LIFE_GOOGLE_NATIVE_WIDTH_V1) via GIS's own supported
 * renderButton({width}) option, not CSS - see that file for why: CSS
 * forcing the iframe box wider leaves Google's cross-origin content
 * pinned at its original size, a real dead gap, confirmed live.
 */
.buttonDiv iframe,
.buttonDivSignUp iframe {
    height: 44px !important;
}

.fb-login-button iframe {
    height: 44px !important;
}

#button-twitter {
    height: 44px !important;
}

/*
 * ACTIVITY_LIFE_SOCIAL_LOGIN_COLUMN_WIDTH_V1
 *
 * .social-login is the shared wrapper around the Google/Facebook/X row
 * in the login and register panels. Left at the panel's full width
 * (~508px desktop), it let Google's own renderButton width computation
 * (ACTIVITY_LIFE_GOOGLE_NATIVE_WIDTH_V1, capped at 400 + GIS's own
 * ~20px chrome offset) settle narrower than its container, producing a
 * visible grow-then-shrink and a dead gap either side of the Google
 * button while Facebook/X stayed full width.
 *
 * Capping the wrapper itself to 400px means the container Google
 * measures at render time is already ~400px, so its own math
 * (min(400, containerWidth-20)) requests ~380px and settles at its
 * native ~400px actual iframe width - filling the wrapper from first
 * paint, no shrink - and Facebook/X, already 100% of this wrapper,
 * land in the same visual column. width:100% (not a fixed px) keeps
 * narrow/mobile containers filling whatever space is actually
 * available. No provider markup, JS behavior, or auth flow touched -
 * container width only.
 */
.social-login {
    width: 100%;
    max-width: 400px;
    margin-left: auto;
    margin-right: auto;
}

/*
 * ACTIVITY_LIFE_SOCIAL_LOGIN_LANDSCAPE_WIDTH_V1
 *
 * In a short landscape viewport (e.g. 832x390) the 400px cap above
 * left Google settling narrower (~290-300px, its own render-time
 * container measurement in that compact modal layout) while
 * Facebook/X stayed at 400px - same mismatch as the portrait case,
 * different landscape-only trigger. Lower the shared cap only for
 * short/landscape viewports so all three land at the same value;
 * portrait (this rule's condition false) is untouched.
 */
@media (orientation: landscape) and (max-height: 500px) {
    .social-login {
        max-width: 300px;
    }
}

/*
 * ACTIVITY_LIFE_SOCIAL_LOGIN_X_CONTENT_CENTER_V1
 *
 * #button-twitter is already display:flex; align-items:center
 * (vertical centering via parent theme), and justify-content:center
 * was added here first - but the icon still painted at the button's
 * true left edge with the label centered independently, because
 * #button-twitter .text (parent theme) computes to ~100% of the
 * remaining row width (display:block, no explicit width - resolves
 * from a parent-theme rule, not flex-grow), with its own
 * text-align:center. That gives the label its own near-full-width
 * box to center within, orphaning the icon at the true left edge
 * instead of the two being treated as one group.
 *
 * Fix: constrain .text back to its own content width (width:auto;
 * flex:0 0 auto) so icon + label return to their natural sizes: only
 * then does the parent's justify-content:center + a small explicit
 * gap center them as one visual group, matching Facebook's
 * composition. No DOM, click handler, or OAuth behavior touched -
 * layout of the two existing spans only.
 */
#button-twitter {
    justify-content: center;
    gap: 10px;
}

#button-twitter .text {
    width: auto;
    flex: 0 0 auto;
}