/* Tab panel visibility for the family's tabbed settings pages.
 *
 * The nav uses the WordPress core classes (nav-tab-wrapper, nav-tab,
 * nav-tab-active), which core already styles, so only the panels need rules.
 *
 * The first panel is marked .active server-side, so the correct tab is painted
 * before the script runs and there is no flash of every section at once. With
 * JavaScript disabled only that first tab is reachable; the WordPress admin is
 * not usable without JavaScript anyway.
 */
.creator-assistant-hub-tab-content {
	display: none;
}

.creator-assistant-hub-tab-content.active {
	display: block;
}

/* Same "correct before the script runs" idea as the panels above, applied to
 * the submit button: without this, the button (rendered unconditionally by
 * core's submit_button(), outside Settings_Tabs' control) is visible for one
 * frame on a page whose initially active tab has hide_submit, then hidden by
 * settings-tabs.js's own activate() call - a flash. The nav carries
 * data-hide-submit-initial only in that case (Settings_Tabs::render_nav()),
 * and the form always immediately follows the nav in every caller's markup,
 * so this sibling+descendant selector reaches the button without needing
 * Settings_Tabs to render the form itself. settings-tabs.js strips the
 * attribute as soon as it runs, handing control to its own submit.hidden
 * toggling from then on - this rule only ever governs the pre-JS paint. */
.creator-assistant-hub-tab-nav[data-hide-submit-initial] + form .submit {
	display: none;
}