@import url("type.css");
/* One type base for jewishinsandiego.org: public pages, the back office, and
 * every staff tool.
 *
 * Sharon, 8 September: the site only felt readable at 150% zoom on a wide
 * monitor. Sharon, 10 September, still zooming: "why is ther staff dashboard
 * not optimized i have to zoom into 150% every single back page, public page,
 * our new staging site, staff dashboartd all of itr should be optimized to
 * 100% on all devices".
 *
 * The first pass raised the root size and never reached her, for two reasons
 * that had nothing to do with the numbers in this file.
 *
 *   1. EIGHT STAFF SURFACES NEVER LOADED IT. The staff dashboard, My Giving,
 *      seating, analytics, check-in, the point of sale, sign-in and the event
 *      manager each carried their own scale and ignored this one entirely.
 *      Raising a base nobody reads changes nothing.
 *
 *   2. THE TEXT WAS IN PIXELS. A rem base only moves rem type, and 660 font
 *      sizes across those files were hardcoded in px. Even on admin.html,
 *      which did load this, most of the text could not respond to it.
 *
 * Both are fixed alongside this. What is left here is the ramp.
 *
 * WHY A RAMP AND NOT A NUMBER. 16px is right on a phone, held close, where
 * every extra pixel costs a line of layout. It is small on a 27-inch monitor
 * an arm's length away. The viewing distance changes, so the size should.
 * Below 1100px nothing moves at all, so phone and tablet layouts are exactly
 * as they were.
 *
 * The ceiling went from 18px to 20px because 18 was still not enough on an
 * extended monitor, which is what the person working in this all day uses.
 *
 * WHY em AND NOT px. font-size:16px on html overrides the browser's own text
 * size setting, silently, for everyone who has ever turned it up. That is the
 * one way this file could make things worse for exactly the people it is meant
 * to help. 1em here means "whatever this reader already asked for", and the
 * ramp scales from there: somebody who set their browser to 20px gets 20 on a
 * phone and 25 on a wide monitor, instead of being quietly reset to 16.
 *
 * Pages that set body { font-size: 16px } are overridden to 1rem so they track
 * html rather than pinning themselves.
 *
 * Chrome pages receive this inlined from partials/ubar.html (STYLE_GUIDE: no
 * extra stylesheet on those pages). Grants import it from chrome.css. The back
 * office, the staff tools and chrome-exempt public faces link this file.
 */
html{font-size:100%}
@media (min-width:1100px){
  html{font-size:clamp(1em, .5vw + .625em, 1.25em)}
}
/* THE STAFF APP DOES NOT RIDE THE PUBLIC RAMP.
 *
 * Sharon, 28 September, on the Back Office at 2,560px: "why everything looks
 * so weird and big and bold?" The ramp above takes the root to 20px on her
 * monitor, and the staff scale was written against a 16px root (type.css:
 * "15px at a 16px root"). So every staff size came out a quarter larger than
 * it says: a 15px body at 18.75, a 34px title at 42. A public page is read
 * from across the desk; a working app is read at arm's length all day, and at
 * that size it stops looking like a desktop app and starts looking like a
 * phone layout blown up.
 *
 * Staff pages (body[data-staff-only]) get their own ramp: 16px up to about
 * 1,440px, reaching 17px at 2,560. Body is then 15-16px everywhere from 1280
 * to 2560. Settings, Text size still multiplies it for anyone who wants more,
 * and 1em still honours the browser's own text size. :where() keeps this at
 * the specificity of the plain html rule, so it wins here by order and a
 * page's own html rule (Settings, Text size) still wins over it. */
@media (min-width:1100px){
  html:where(:has(> body[data-staff-only])){font-size:clamp(1em, .125vw + .875em, 1.0625em)}
}
body{font-size:1rem}
/* Back Office body is .9375rem Outfit. That rule lives in type.css on
   body[data-staff-only] and outranks this 1rem. Public pages have no such
   attribute, so they stay on 1rem Outfit. Do not drop html below 1em. */