/**
 * oollyBugs front end.
 *
 * Deliberately unopinionated. Fonts, colours and button styling are inherited
 * from the theme rather than set here, so the form looks like part of the site
 * it is dropped into instead of like a plugin.
 */

/* The honeypot.
 *
 * Positioned off-screen rather than display:none. A hidden field is trivially
 * skipped by anything parsing the DOM, whereas a field that is present, laid
 * out and focusable looks like every other input to a form-filling bot. It is
 * out of the tab order and aria-hidden in the markup, so nobody using a
 * keyboard or a screen reader will ever meet it.
 */
.oollybugs-hp {
	position: absolute !important;
	left: -9999px !important;
	top: auto !important;
	width: 1px !important;
	height: 1px !important;
	overflow: hidden !important;
}

/* The [hidden] attribute is only display:none in the browser's own stylesheet,
   which any author `display` rule below outranks. Several elements here are
   flex containers and are hidden by script, so [hidden] has to be restated at
   author level or they stay visible. */
.oollybugs-panel [hidden] {
	display: none !important;
}

/* Canvas and CanvasText are a matched system pair and must be used together.
   `color: inherit` here was the bug: on a dark theme the dialog inherited the
   page's near-white text while its background stayed Canvas, giving white on
   white. Inheriting is wrong in principle too — this is a panel floating over
   the page, not part of it, so it needs its own surface and its own text
   colour, and the pair keeps them consistent in light and dark alike. */
.oollybugs-dialog {
	width: min(38rem, calc(100vw - 2rem));
	max-height: calc(100vh - 4rem);
	padding: 0;
	border: 1px solid rgba(128, 128, 128, 0.3);
	border-radius: 6px;

	/* Opts the dialog into following the visitor's OS preference. Without this
	   the system colours resolve to their light values whatever the visitor has
	   chosen, so a dark-mode user on a dark site gets a bright white panel.
	   Because Canvas/CanvasText and Field/FieldText each flip as a pair,
	   legibility holds in both directions by construction. */
	color-scheme: light dark;
	color: CanvasText;
	background: Canvas;
}

.oollybugs-dialog::backdrop {
	background: rgba(0, 0, 0, 0.55);
}

/* The embedded form is the exact opposite case to the dialog above, and so
   takes the opposite decision: it is part of the page rather than floating over
   it, and gets no surface of its own. No background, no border, and colours
   left to inherit from whatever it was placed in — the behaviour that was a bug
   for a panel is the correct one here. The width cap only stops fields
   stretching to the full measure of a wide layout. */
.oollybugs-embed {
	max-width: 38rem;
}

.oollybugs-form {
	padding: 1.5rem;
	overflow-y: auto;
	max-height: calc(100vh - 4rem);
}

/* The dialog's form scrolls inside a viewport-sized panel. An embedded one is
   as tall as its content and lets the page scroll instead, so the cap and the
   padding that framed it both come off. */
.oollybugs-embed .oollybugs-form {
	padding: 0;
	overflow: visible;
	max-height: none;
}

.oollybugs-title {
	margin: 0 0 1rem;
	font-size: 1.25em;
}

.oollybugs-field {
	margin: 0 0 1rem;
	display: flex;
	flex-direction: column;
	gap: 0.25rem;
}

/* Field and FieldText are the system pair for form controls specifically, and
   are used rather than a transparent background so a control is still legible
   if anything ever changes the surface underneath it. */
.oollybugs-field input,
.oollybugs-field select,
.oollybugs-field textarea {
	width: 100%;
	font: inherit;
	color: FieldText;
	padding: 0.5em;
	border: 1px solid rgba(128, 128, 128, 0.5);
	border-radius: 4px;
	background: Field;
	box-sizing: border-box;
}

.oollybugs-field textarea {
	resize: vertical;
}

.oollybugs-hint,
.oollybugs-hint-inline,
.oollybugs-privacy {
	font-size: 0.85em;
	opacity: 0.75;
}

.oollybugs-required {
	opacity: 0.6;
}

/* Deliberately not dimmed like the hints above. This one is the difference
   between a form and a picture of a form, and someone about to type out a real
   bug report needs to read it before they start, not after. currentColor keeps
   it legible on whatever the form was dropped into. */
.oollybugs-demo-note {
	margin: 0 0 1rem;
	padding: 0.5em 0.75em;
	border: 1px dashed currentColor;
	border-radius: 4px;
	font-size: 0.9em;
}

/* Version fields sit on one row on anything wider than a phone. */
.oollybugs-bugfields {
	display: flex;
	flex-wrap: wrap;
	gap: 0 1rem;
}

.oollybugs-field--third {
	flex: 1 1 8rem;
}

.oollybugs-turnstile {
	margin: 0 0 1rem;
}

.oollybugs-status:empty {
	display: none;
}

.oollybugs-status {
	margin: 0 0 1rem;
	padding: 0.6em 0.8em;
	border-radius: 4px;
	border: 1px solid rgba(128, 128, 128, 0.4);
}

.oollybugs-status.is-error {
	border-color: #c0392b;
}

.oollybugs-actions {
	display: flex;
	gap: 0.75rem;
	align-items: center;
	justify-content: flex-end;
	margin: 0;
}

/* Neither button had any rules at all, so both fell back to the browser's
   default button font — around 13px, visibly smaller than everything else in
   the dialog and unrelated to the theme. Applies to both styles. */
.oollybugs-cancel,
.oollybugs-submit {
	font: inherit;
	cursor: pointer;
}

/* buttons="plain" — ordinary buttons, sized to the dialog's typography. Depends
   on nothing, so it looks the same on every theme. */
.oollybugs-panel--plain .oollybugs-cancel,
.oollybugs-panel--plain .oollybugs-submit {
	padding: 0.5em 1.1em;
}

/* buttons="theme" — Send also carries wp-element-button, so a block theme
   styles it as one of the site's own buttons. Cancel is demoted to a quiet
   link: left as an equal-weight button it competes with the primary action, and
   beside a fully styled Send it reads as an oversight rather than a choice. */
.oollybugs-panel--theme .oollybugs-cancel {
	background: none;
	border: 0;
	padding: 0.5em 0.25em;
	color: inherit;
	text-decoration: underline;
	opacity: 0.8;
}

.oollybugs-panel--theme .oollybugs-cancel:hover,
.oollybugs-panel--theme .oollybugs-cancel:focus-visible {
	opacity: 1;
}

/* Fallback padding for Send in theme mode, at zero specificity so any real
   theme rule beats it. :where() is doing the work: an ordinary selector here
   would outrank .wp-element-button and override the theme's own padding, which
   is the exact opposite of the point. In practice this only takes effect on a
   classic theme, where wp-element-button styles nothing. */
:where( .oollybugs-panel--theme .oollybugs-submit ) {
	padding: 0.5em 1.1em;
}

/* The default. Reads as a hyperlink without giving up the button semantics
   screen readers need, and sits in running text — the baseline alignment is
   what stops it riding high against the prose around it.

   display:inline is declared but does not take effect: browsers blockify
   button elements, so the used value stays inline-block. Checked against a
   bare <button> to be sure nothing here was overriding it. It still flows
   inline within a paragraph, which is the part that matters; the only thing
   lost is that a multi-word label cannot break across two lines, and will wrap
   whole instead. Left in place as a statement of intent, and harmless.

   Structural only. If a theme overrode any of this the button chrome would
   come back and the whole treatment would fall apart, so it keeps ordinary
   specificity. Appearance is separated out below. */
.oollybugs-trigger--link {
	display: inline;
	vertical-align: baseline;
	background: none;
	border: 0;
	padding: 0;
	margin: 0;
	font: inherit;
	cursor: pointer;
}

/* Appearance, at zero specificity so a theme's own rule always wins.

   :where() is load-bearing here. A theme writing
   .oollybugs-trigger--link { color: … } has exactly the same specificity as a
   plain rule would, so which one applied came down to stylesheet order — and
   this stylesheet is enqueued by the shortcode, which is late. Measured on
   woolly.dev: the theme's colour was winning on ordering alone, and would have
   silently reverted the day that order changed.

   The trigger cannot pick up a link colour by itself, because themes colour
   links by targeting <a> and this is a <button> — it opens a dialog rather than
   navigating, so it has to be. Setting the colour is therefore the site's job,
   and this is what makes doing so reliable rather than lucky. */
:where( .oollybugs-trigger--link ) {
	color: inherit;
	text-decoration: underline;
}

/* Hover. Drops the underline, which is what WordPress links conventionally do —
   Twenty Twenty-Three sets textDecoration: underline on links and none on
   :hover, and themes built on it inherit that.

   An earlier version thickened the underline instead, reasoning that removing
   it takes away the only affordance when no colour has been set. That reasoning
   was wrong in a way worth recording: Twenty Twenty-Three colours links with
   `contrast`, the same value as body text, so a stock install already has
   body-coloured underlined links that lose the underline on hover. The case the
   thickening protected against is the one WordPress itself ships, and matching
   the convention beats out-reasoning it. The pointer cursor carries the
   affordance meanwhile.

   Focus is deliberately left alone: the underline stays, and the browser draws
   its own focus ring on a button, so keyboard users keep two signals where a
   mouse user has one. */
:where( .oollybugs-trigger--link:hover ) {
	text-decoration: none;
}

/* style="button" carries wp-element-button as well, which is where a block
   theme's own button styling comes from. Nothing here sets a colour, a border
   or a radius: the point is to look like the theme's buttons, not like ours. */
.oollybugs-trigger--button {
	cursor: pointer;
}

/* Themes are expected to define this, but nothing guarantees it, and an
   undefined rule would print "(opens in a new tab)" on the page. */
.oollybugs-panel .screen-reader-text {
	position: absolute !important;
	width: 1px;
	height: 1px;
	padding: 0;
	margin: -1px;
	overflow: hidden;
	clip-path: inset(50%);
	white-space: nowrap;
	border: 0;
}

.oollybugs-noscript {
	font-size: 0.9em;
	opacity: 0.8;
}