/* eventDetails.css -- styles for the Event Detail dialog/page (listView/php/eventDetails.inc, /eventDetail.php)
Deploy to: /CSS/eventDetails.css
Generated: 2026-07-24 13:50 UTC
Session 326: added #wtdActionIcons/.wtdIconBtn and friends for the new
unified icon action row; marked #wtdShareBlock rules dead (see their own
comment). No header existed on this file before this revision -- added per
the mandatory Generated-timestamp convention (WTD_README.md, File timestamp
convention).
Session 326 follow-up (same day), per Robert: bumped .wtdIconBtn/.wtdIconBtnFb
from 56px to 64px and glyph font-size from 28px to 46px -- larger, but still
short of the Facebook badge's own near-edge-to-edge fill. Added #sendMessage
to shrink the "Contact WTD Support" button now that its label is just an
icon + "WTD".
Session 326 follow-up #3 (same day): the #sendMessage shrink didn't actually
change the button's WIDTH, because CSS/contactForm.css (separate, older,
site-wide stylesheet) forces `.contactForm input, textarea { width: 95%; }`
and `.sendMsgButton { width: 14em; }` on this exact button -- neither was
touched by font-size/padding alone. Added explicit `width: auto` to
#sendMessage, which as an ID selector outranks those class-level rules
regardless of load order. This file's own consumer (listView/php/
eventDetails.inc) bumped its cache-bust query string to ?v=2 accordingly.
Session 326 follow-up #4 (same day), per Robert: the dancer emoji
specifically still looked too small in its circle even at 64px/46px, and
all icons needed upsizing again. Bumped .wtdIconBtn/.wtdIconBtnFb to 72px
and glyph font-size to 58px (~81% fill). Cache-bust query string bumped to
?v=3 in listView/php/eventDetails.inc accordingly.
Session 326 follow-up #5 (same day), per Robert: the 72px box/circle size
is right -- left unchanged -- but the glyph itself still read too small
relative to it. Font-size bumped 58px->68px (~94% fill), independent of
box size. Cache-bust bumped to ?v=4 accordingly.
Session 326 follow-up #6 (same day): 68px was an overshoot once the
LiteSpeed page-cache issue was bypassed and Robert could see the real
size -- dialed back to 62px (~86% fill), between the 58px that was too
small and the 68px that was too large. Cache-bust bumped to ?v=5.
Session 326 follow-up #7 (same day): even 62px measured at only ~1/5 of
the circle live (should be ~1/2) -- font-size was never actually reaching
these glyphs on this page, regardless of value. Switched to `transform:
scale(2.5)` on a new .wtdIconGlyph wrapper span (and on the existing
.wtdDancerSlashWrap composite), which enlarges whatever renders
independent of the font-size override mystery. Cache-bust bumped to ?v=6.
Session 326 follow-up #8 (same day): confirmed working, but Robert
measured the result 20% larger than wanted. Scale factor dialed down
proportionally, 2.5 / 1.2 = 2.08. Cache-bust bumped to ?v=7.
CORRECTION, follow-up #9 (same day): #8 misread Robert's "Now 20% larger"
-- he wanted it 20% larger STILL, not that it had overshot. Corrected:
scale factor now 2.5 * 1.2 = 3.0, up from 2.5, not down to 2.08.
Cache-bust bumped to ?v=8.
Session 348: root cause of follow-up #7's font-size mystery finally found --
it's specific to which HOST page loads this content. The AJAX dialog wraps
it in a jQuery UI dialog (.ui-dialog/.ui-widget), which silently resets the
inherited font-size feeding .wtdIconGlyph/.wtdDancerSlashWrap to something
small regardless of .wtdIconBtn's own font-size -- confirmed via a live
Computed-tab measurement there: 15.36px. /eventDetail.php (Session 322) has
no such wrapper, so those same spans were instead inheriting .wtdIconBtn's
raw 62px uncontested, then tripling it via transform -- ~186px, wildly
oversized and overlapping, which is what actually produced this session's
"ugly icons" report on that page. Fixed by hard-coding font-size: 15.36px
!important directly on .wtdIconGlyph and .wtdDancerSlashWrap, so both hosts
compute the same size regardless of what does or doesn't wrap them --
.wtdIconBtn's own font-size: 62px is now dead weight, left in place. Cache-
bust bumped to ?v=9. */
table.eventDetails {
	padding:0px 5px 4px 2px; 
	width:400px;
	margin-left:auto;
	margin-right:auto;
}
tr.eventDetails {
    vertical-align:text-top;
	padding:4px 10px 4px 2px; 
}

td.eventDetails {
    vertical-align:text-top;
	padding-top:10px;
	padding-bottom:10px;	
}

div.logo {
	float: left;
	vertical-align: middle;
}

img.logo {
	max-height: 100px;
}

.alignRight {
	text-align: right;
	padding-top:10px;
	padding-right:10px;
	padding-bottom:10px;	
}
.picture {
	text-align: center;
}
.bold {
	font-weight:bold;
}
.sendMsgButton {
	display:block;
	position:absolute;
	bottom:20px;
	right:10px;
}
/* Session 326 follow-up, per Robert: shrink the "Contact WTD Support"
   button itself, not just its label -- was a full-text input sized to fit
   "Contact WTD Support"; now a small icon+"WTD" pill. #sendMessage is a
   page-unique id (this button only appears once per render of
   eventDetails.inc), so scoping here doesn't touch any other page's
   buttons even if they happen to share the .sendMsgButton class.
   Session 326 follow-up #2 -- REAL ROOT CAUSE of the width not changing:
   CSS/contactForm.css (a separate, older, site-wide stylesheet neither of
   us had re-checked) sets `.contactForm input, textarea { width: 95%; }`
   and `.sendMsgButton { width: 14em; }` -- both apply here since this
   button's wrapping <div> carries both classes, and neither rule was ever
   touched by font-size/padding alone. Explicit `width: auto` below (on the
   #sendMessage id, which outranks those class-level rules regardless of
   stylesheet load order) is what actually lets the button shrink to fit
   its new short label instead of being stretched to ~95% of a 14em box. */
#sendMessage {
	font-size: 13px;
	padding: 6px 12px;
	border-radius: 16px;
	width: auto;
}

.submitAdFeeBtn
{
  display: block;
  position: absolute;
  bottom: 20px;
  left: 10px;
  width: 14em;
}

.tzNote 
{
	font-size: 75%;
}

.callerArray
{
	display: table;
	margin: auto;
}
.callerPic
{
	margin-right: 20px;
}
.flexContainer
{
	display: -webkit-flex;
	display: flex;
	flex-direction: row;
}
.leftTable {
	width: 400px;
	margin-right: 10px;
}

div.leftTable
{
	-webkit-flex: initial;
			flex: initial;
	margin: 20px;
}
div.rightTable
{
	-webkit-flex: none;
			flex: none;
}

#popTitle 
{
	vertical-align:middle;
	padding-right:5px;
	height:25px;
	width:25px;
}
#paymentMsg
{

}
/* #fb / .fb-like were the old, silently-broken Facebook XFBML "Like" widget
   (Session 323 -- removed, see listView/php/eventDetails.inc's own comment
   for the full investigation). Rule left here, unused, only because
   removing a CSS rule nobody references is zero-risk either way and this
   avoids touching a line with no bearing on the new share block below. */
#fb
{
	float: left;
	position: static;
}

/* Share / Like block (Session 323) -- Copy Link, Share to Facebook, and the
   iframe-based Like button. Session 326: this whole block (and the markup
   that used these rules) was retired from listView/php/eventDetails.inc in
   favor of the unified icon row below (#wtdActionIcons) -- Robert's own
   complaint was that the page had gotten button-heavy, and the Like iframe
   is dropped entirely rather than kept alongside the new Facebook icon.
   Rules left here, unused, same "zero-risk to leave, not worth touching a
   line with no bearing on the new work" reasoning as the #fb rule above. */
#wtdShareBlock
{
	text-align: center;
	margin: 10px 0 18px;
}
#wtdShareBlock #wtdCopyLinkBtn,
#wtdShareBlock #wtdShareFbBtn
{
	display: inline-block;
	vertical-align: middle;
	margin: 4px 8px;
	padding: 9px 16px;
	border-radius: 8px;
	font-weight: bold;
	font-size: 13px;
	text-decoration: none;
	cursor: pointer;
	border: none;
}
#wtdShareBlock #wtdCopyLinkBtn
{
	background: #2471a3;
	color: #fff;
}
#wtdShareBlock #wtdShareFbBtn
{
	background: #3b5998; /* Facebook's own long-standing brand blue */
	color: #fff;
}
#wtdShareBlock #wtdFbLikeFrame
{
	vertical-align: middle;
	margin: 4px 8px;
}

/* Unified action-icon row (Session 326) -- replaces the #wtdShareBlock
   share/like buttons above plus Session 108's partner-interest button and
   Session 324's Going/Not-Going buttons with one row of large circular
   icon buttons. Sized generously (64px) per this site's senior-citizen-
   first, mobile-majority audience -- a comfortable touch target rather
   than a compact icon-bar. flex-wrap lets the row break onto two lines on
   narrow phones instead of squeezing five 72px circles into one row.
   Session 326 follow-up, per Robert: the emoji glyphs originally read much
   smaller than the solid Facebook badge (a 28px glyph centered in a 56px
   circle is only ~50% fill, versus the Facebook SVG's circle which is
   drawn almost edge-to-edge). Bumped the button box to 64px and the glyph
   font-size to 46px (~72% fill) -- deliberately still short of the
   Facebook badge's near-total fill, per Robert's own "larger, but not as
   big as the Facebook Thumb."
   Session 326 follow-up #4 (same day): even at 64px/46px, Robert reported
   the dancer emoji specifically still looked too small inside its (active/
   green) circle, and asked for all the icons upsized again. Some emoji
   glyphs (the dancer in particular) render with more internal whitespace
   in their own glyph box than others, so the same font-size can look
   smaller depending on which glyph it is -- bumped again regardless, box
   64px->72px, font-size 46px->58px (~81% fill), closing more of the gap
   with the Facebook badge's own near-100% fill.
   Session 326 follow-up #5 (same day): per Robert, the 72px circle itself
   is the right size -- box left unchanged -- but the glyph inside still
   read too small relative to it. Font-size bumped again, 58px->68px
   (~94% fill), independent of box size this time.
   Session 326 follow-up #6 (same day): 68px turned out to be an overshoot
   -- once a LiteSpeed page-cache issue (see WTD_README.md) was bypassed
   and Robert could actually see the real rendered size, he reported it too
   large. Dialed back to 62px (~86% fill), a middle point between the
   58px that was "too small" and the 68px that was "too large." Box left
   at 72px throughout -- only the glyph font-size has moved this round. */
#wtdActionIcons
{
	display: flex;
	flex-wrap: wrap;
	align-items: center;
	justify-content: center;
	gap: 14px;
}
.wtdIconBtn
{
	display: inline-flex;
	align-items: center;
	justify-content: center;
	width: 72px;
	height: 72px;
	border-radius: 50%;
	background: #eef3f7;
	border: 2px solid #d5dee5;
	font-size: 62px;
	line-height: 1;
	text-decoration: none;
	cursor: pointer;
	color: inherit;
	padding: 0;
	box-sizing: border-box;
}
/* Session 326 follow-up #7 -- REAL root cause of the "glyph won't upsize no
   matter what font-size I set" mystery, per Robert's own measurement (~1/5
   of the circle, not the ~1/2 requested): something on this page (loaded
   inside index.php's full RapidWeaver theme stack, unlike /eventDetail.php)
   is silently overriding font-size on these elements -- the exact rule
   wasn't pinned down after checking styles.css/custom.css/the font-size
   reset module, but the *symptom* (font-size having zero visible effect
   across five different values, 28px through 68px) makes some override
   certain. Rather than keep guessing at specificity across theme files
   this codebase doesn't even keep local copies of, `transform: scale()`
   sidesteps the problem entirely -- it enlarges whatever actually renders,
   regardless of what font-size resolved to. `display: inline-block` is
   required for transform to apply predictably to inline content;
   `transform-origin: center` keeps the enlarged glyph centered in the
   circle rather than growing off to one side. */
.wtdIconGlyph
{
	display: inline-block;
	/* Session 348: explicit, non-inherited font-size -- see the long comment
	   above this rule (Session 326 follow-up #7) for the original mystery.
	   That writeup only ever tested this on the AJAX dialog side, where
	   something (most likely jQuery UI's own .ui-dialog/.ui-widget CSS,
	   which only wraps content on that host) was quietly resetting the
	   inherited font-size feeding into this span down to something small,
	   regardless of what .wtdIconBtn's own font-size below said -- which is
	   exactly why changing THAT value never visibly did anything there.
	   /eventDetail.php has no such wrapper, so this span was instead
	   inheriting .wtdIconBtn's raw font-size: 62px uncontested, then
	   multiplying it 3x below -- ~186px, wildly oversized and overlapping,
	   which is what actually produced the "ugly icons" report. Confirmed via
	   a live Computed-tab measurement on the working dialog (Session 348):
	   the effective inherited size actually producing today's correct look
	   there is 15.36px -- hard-coded directly here (with !important, since
	   an inherited value has already been observed silently winning against
	   an explicit but lower-priority declaration in this exact spot) so both
	   hosts compute the identical size regardless of whatever does or does
	   not wrap this content. .wtdIconBtn's own font-size: 62px below is now
	   dead weight from before this rule existed -- left in place rather than
	   removed, same "zero-risk to leave" reasoning as #fb/#wtdShareBlock
	   above, since nothing inherits it anymore once this is explicit. */
	font-size: 15.36px !important;
	transform: scale(3.0);
	transform-origin: center;
}
.wtdIconBtn:disabled
{
	opacity: 0.6;
	cursor: default;
}
/* Active/selected state -- shared by the Going icon and the Partner icon
   (both use the same "you're signed up for this" meaning), and separately
   by the Not-Going icon. Distinct border+background rather than only a
   color swap, so the state reads clearly even for colorblind users. */
.wtdIconActiveGoing
{
	background: #27ae60;
	border-color: #1e8449;
	color: #fff;
}
.wtdIconActiveNotGoing
{
	background: #c0392b;
	border-color: #922b21;
	color: #fff;
}
.wtdIconBtnFb
{
	background: none;
	border: none;
	width: 72px;
	height: 72px;
	padding: 0;
}
.wtdIconBtnFb svg
{
	display: block;
}
/* "Not going" composite icon -- a dancer glyph with a red "no" circle
   overlaid on top, built from two stacked characters rather than a single
   emoji (no single Unicode glyph combines the two), per Robert's own
   description: "the dancer with a slash through it." */
.wtdDancerSlashWrap
{
	position: relative;
	display: inline-block;
	/* Session 348: same fix as .wtdIconGlyph above, same reason -- this
	   composite's own width/height are in em, relative to ITS inherited
	   font-size, so it was subject to the exact same host-dependent
	   inheritance mismatch. Hard-coded to the same 15.36px so the "Not
	   Going" composite icon sizes identically to every other glyph on both
	   hosts. .wtdSlashOverlay's own font-size: 0.85em (below) is relative to
	   THIS explicit value, so it needs no separate change. */
	font-size: 15.36px !important;
	width: 1em;
	height: 1em;
	transform: scale(3.0);
	transform-origin: center;
}
.wtdSlashBase
{
	display: block;
}
.wtdSlashOverlay
{
	position: absolute;
	top: 0;
	left: 0;
	font-size: 0.85em;
	color: #c0392b;
	text-shadow: 0 0 2px #fff, 0 0 2px #fff;
}