/* Mann Studios · one definition, and nothing else.
 *
 * Every visual rule lives in Elementor: Global Colors, Global Fonts, Theme
 * Style, and per-element controls. Where Elementor had no control we added
 * one, rather than writing CSS here. See inc/kit-controls.php:
 *
 *   Site Settings > Buttons > Motion    hover lift, press scale, transition
 *   Site Settings > Layout              square corners, no shadows, reveals
 *   Site Settings > Layout              footer sits at the bottom
 *   Container > Layout                  aspect ratio
 *   Container / any widget > Advanced   cursor
 *
 * If you need something this file seems like the place for, add a control in
 * kit-controls.php instead. Then it is visible and editable in the panel,
 * not buried in a stylesheet.
 *
 * The one thing below is a definition, not a style, in the same way @font-face
 * is: CSS has no way to name a set of keyframes from a control, so the
 * Marquee widget has nothing to point its animation at without this. Every
 * value the marquee actually uses, how fast, which way, how wide, how far
 * apart, how much the edges fade, is a control on the widget. Nothing here
 * decides how anything looks.
 */

@keyframes studio-marquee {
	from { transform: translateX( 0 ); }
	to   { transform: translateX( -50% ); }
}

/* ---------------------------------------------------------------------------
 * @keyframes, the second unavoidable exception after @font-face.
 *
 * A keyframes block is not a property, so it cannot be an Elementor control.
 * Which element animates, for how long, and whether at all, all stay in the
 * panel: see "Marquee" in a container's Advanced tab. Only the frames live
 * here, and there is exactly one set of them.
 *
 * `dist/` writes this inline; it is copied verbatim.
 * ------------------------------------------------------------------------- */

@keyframes marquee {
  from { transform: translateX(0); }
  to   { transform: translateX(-50%); }
}

/* A strip that never stops moving is the usual complaint from people who have
 * asked their system for less motion. `dist/` has no guard, so this is ours:
 * the strip simply stands still. Nothing else about the layout changes. */
@media (prefers-reduced-motion: reduce) {
  [style*="marquee"] { animation: none !important; }

  /* The Marquee widget does not write its animation inline - it comes from a
   * control, so it lands in Elementor's stylesheet and the selector above
   * never sees it. Name the track itself, or the widget is the one strip on
   * the site that ignores the request. The colour change on hover goes with
   * it: it is a transition, and this is the setting that asks for none. */
  [data-marquee-track] { animation: none !important; }
  [data-marquee-item] img { transition: none !important; }

  /* The team card's hover, same reasoning: the wash and the photograph's
   * scale are both transitions written by controls, so they arrive whole
   * instead of travelling. The hover still happens - it just does not move. */
  [data-team-glow],
  [data-team-photo] img { transition: none !important; }
  [data-team-card]:hover [data-team-photo] img { transform: none !important; }

  /* The corner mark on a card, same again: the card still answers the hover
   * with its wash and its border, the drawing just does not grow into it. */
  [data-corner-mark]::after { transition: none !important; }
  [data-corner-mark]:hover::after { transform: none !important; }
}

/* will-change on a team portrait promotes it to its own compositor layer so the
 * hover scale is smooth. It buys nothing else, and a layer costs roughly
 * width x height x 4 bytes at the device's pixel ratio - across twelve
 * portraits that is tens of megabytes held for as long as the page is open.
 * A touch screen never fires the hover it is paying for, and a visitor who
 * asked for less motion has had the scale removed above, so neither should be
 * charged for it.
 *
 * This lives here rather than inline on the <img> - inc/widgets/team.php has
 * the reason it belongs on the image and not the card - because an inline
 * style cannot ask whether the device can hover. */
@media (hover: hover) and (prefers-reduced-motion: no-preference) {
  [data-team-photo] img { will-change: transform; }
}

/* The legal pages' Contents card is a sticky left rail beside the text, and on
 * a phone there is no beside: the two-column grid has already collapsed to one
 * (measured 342px at 390px wide), so the card lands as a box of links above the
 * document the reader came to read. Desktop keeps it.
 *
 * Keyed off the widget, not the container's Elementor id: the same card is
 * lgtoc06 on all three legal pages today, but an element id does not survive a
 * page being rebuilt and this rule should. The first rule hides the card
 * everywhere; the second removes the container it sat in, so the grid does not
 * keep an empty row. Support for :has() is not assumed - without it the
 * container simply stays, empty and collapsed.
 *
 * 900px, not the 640px mobile breakpoint: the card is only a rail while the
 * grid beside it has two columns, and lggrid35 carries
 * grid_columns_grid_tablet = 1fr, which Elementor writes at max-width:900px -
 * this site's breakpoints are custom (mobile 640, mobile_extra 760, tablet
 * 900, tablet_extra 1000, laptop 1180). Measured: one column at 900 and below,
 * two at 920 and above. So between 641 and 900 the card was the same
 * full-width box of links on top of the document that it was on a phone, just
 * wider. Matching the container's own breakpoint means the two cannot drift
 * apart if the grid is re-pointed at a different one later. */
@media (max-width: 900px) {
  .elementor-widget-studio-contents { display: none; }
  .e-con:has(> .elementor-widget-studio-contents) { display: none; }
}