/*
 * Editor named block formats — "Title" and "Description" from the Widget Title / Title
 * Description rich text editor (fe-ckeditor, Task 123470).
 *
 * AB#134725 — those two formats are a CSS CLASS on a <p>, not a tag: the editor applies
 * .utop-rte-title / .utop-rte-description and deliberately STRIPS any inline text-align, so the
 * whole look lives in a stylesheet. fe-ckeditor's index.html states the contract in as many words:
 *
 *     CANONICAL CSS = SINGLE SOURCE OF TRUTH. The front-end that renders CMS content MUST ship
 *     these SAME declarations (scoped to its own container) so the live page matches the editor.
 *
 * The public site never shipped them. So "Title" showed centred, 28/36, SemiBold in the editor and
 * came out at the heading container's own alignment and size on the page — left, in the Video
 * widget QC filed this against, and in every dynamic widget (they share one title block,
 * DynamicWidgetAdapter.BuildInstanceTitleHtml → h2.uiw-widget-title).
 *
 * Values mirror fe-ckeditor/deploy-azure-static/index.html (.jodit-wysiwyg .utop-rte-*) and the
 * RTE_BLOCK_STYLES table beside it, which drives the dropdown preview. Keep all three in step.
 *
 * ── Why alignment goes through a custom property ──────────────────────────────────────────────
 * Centre is the editor's answer and therefore the default. But AB#133055 established that a widget
 * container may own its heading alignment responsively — short-article-listing centres its header
 * on desktop and left-aligns it under 767px — and a plain `text-align` on this span would beat that
 * media query, because a value set ON the element always wins over one inherited from the h2.
 * `var(--utop-rte-align, center)` keeps the editor's default while letting such a container state
 * its intent declaratively, in the same rule where it sets its own text-align.
 *
 * Global on purpose (not scoped per widget): the classes are emitted only by
 * WidgetTitleHtmlNormalizer, from markup only this editor produces, so there is nothing else they
 * can match — and one home means adding a widget never means remembering to ship this again.
 * Same reasoning as the .uiw-widget-title spacing rule in layout-shell.css (AB#131811).
 *
 * The normalizer rewrites the author's <p> to <span style="display:block">, so these need no
 * display of their own.
 */

.utop-rte-title {
    font-family: 'UMobileDisplay', 'Unbeatable', Arial, sans-serif;
    font-weight: 600;
    font-size: 28px;
    line-height: 36px;
    letter-spacing: -0.01em;
    text-align: var(--utop-rte-align, center);
    margin: 0;
}

.utop-rte-description {
    font-family: 'UMobileDisplay', 'Unbeatable', Arial, sans-serif;
    font-weight: 400;
    font-size: 16px;
    line-height: 24px;
    letter-spacing: 0;
    text-align: var(--utop-rte-align, center);
    margin: 0;
}

/*
 * AB#134725 — rhythm between description paragraphs.
 *
 * WidgetTitleHtmlNormalizer rewrites the author's <p> into <span style="display:block">, which
 * drops the margin <p> was getting from Bootstrap Reboot (p{margin-bottom:1rem}) and from the
 * browser default. Margin OUTSIDE the run — above the first block, below the last — is dropped on
 * purpose: the subtitle containers (.bt-subtitle, .udd-subtitle…) already declare margin:0, that
 * 16px was leaking out of the inner <p> where no designer put it, and the named format
 * .utop-rte-description declares margin:0 too. The gap BETWEEN paragraphs is content structure,
 * not decoration — losing it runs the paragraphs together, which is a reading defect — so it is
 * restored here.
 *
 * 16px, not 8px: the editor declares no margin for cms-variant-body (only the heading variant has
 * margin:0 0 8px), so there is no canonical number to copy. 16px is what the page shows today on
 * both AEM-migrated and non-AEM pages after margin collapse; preserving the status quo is the
 * lowest-risk choice absent a source of truth.
 *
 * Marker is emitted ONLY by NormalizeDescription, so the title path is untouched.
 */
.uiw-rte-block + .uiw-rte-block {
    margin-top: 16px;
}