: that inline box wraps exactly
the text plus the triangle (which is why the triangle is attached to the span
— see the submenu-indicator block below), so the line starts at the first
character and ends at the triangle. Items without a submenu, like "Domov",
get a line the width of the word and nothing more.
padding-bottom sets the gap; on an inline box it does not affect line height. */
/* Hover added 2026-08-06. The skin resolves menu hover to
--theme-color-text_link, which is #DE3241 in this skin — the red. Killing it
here leaves the brown underline below as the only hover signal, which is
still a non-colour cue, so nothing is lost for anyone who cannot separate the
two shades. Submenu links are untouched: their hover is
--theme-color-extra_hover (#ffffff), not the red. */
.sc_layouts_menu_nav > li > a:hover,
.sc_layouts_menu_nav > li.sfHover > a,
.sc_layouts_menu_nav > li.current-menu-item > a,
.sc_layouts_menu_nav > li.current-menu-parent > a,
.sc_layouts_menu_nav > li.current-menu-ancestor > a {
color: var(--theme-color-text_dark) !important; /* same as non-active items (no red) */
text-decoration: none !important;
}
/* 2026-08-06: 6px (was 3px, then 4px) and #B08751 (was #FFBC00), and the same
line now appears on hover — the theme only tinted hovered items #efa758 and
drew no line at all, so there was nothing to thicken. .sfHover is included
alongside :hover to match the theme's own colour rule, keeping the line up
while an open submenu holds the pointer.
No layout shift when it appears: border-bottom + padding-bottom on an inline
box do not affect line height. */
.sc_layouts_menu_nav > li.current-menu-item > a > span,
.sc_layouts_menu_nav > li.current-menu-parent > a > span,
.sc_layouts_menu_nav > li.current-menu-ancestor > a > span,
.sc_layouts_menu_nav > li > a:hover > span,
.sc_layouts_menu_nav > li.sfHover > a > span {
border-bottom: 5px solid #B08751; /* 3px -> 4px -> 6px -> 5px (2026-08-06) */
padding-bottom: 4px; /* gap to the text; was 6px (2026-08-06) */
}
/* ================================================================================= */
/* ===== Two-tier header: cart + search ABOVE the main menu (2026-07-30) ===== */
.top_panel .sc_layouts_column_align_right {
display: flex !important;
flex-wrap: wrap !important;
align-items: center !important;
justify-content: flex-end !important;
row-gap: 6px;
}
/* cart + search -> top line (right-aligned) */
.top_panel .sc_layouts_column_align_right > .sc_layouts_item:has(.sc_layouts_cart),
.top_panel .sc_layouts_column_align_right > .sc_layouts_item:has(.search_wrap) {
order: 1;
}
/* main menu -> its own full-width line, below the icons */
.top_panel .sc_layouts_column_align_right > .sc_layouts_item:has(.menu_main_nav_area) {
order: 2;
flex-basis: 100%;
display: flex;
justify-content: flex-end;
}
/* ========================================================================== */
/* Two-tier header — align BOTH tiers (menu + cart/search) flush to the right of .content_wrap */
.top_panel .sc_layouts_column_align_right { justify-content: flex-end !important; }
/* push the menu block to the right edge and right-align its items */
.top_panel .sc_layouts_column_align_right .menu_main_nav_area { margin-left: auto !important; width: auto !important; }
.top_panel .sc_layouts_column_align_right ul.sc_layouts_menu_nav { justify-content: flex-end !important; flex-wrap: wrap; }
/* Remove the header right-column's ~1.5em right padding (the ~40-50px gap) so
the menu + cart/search sit flush to the right edge of content_wrap / columns_wrap. */
.top_panel .sc_layouts_column_align_right { padding-right: 0 !important; }
/* Flush the header right-side content to content_wrap's right edge: zero every
right-spacing source in the header (grid negative margin + column + item padding). */
.top_panel .columns_wrap { margin-right: 0 !important; }
.top_panel .sc_layouts_column_align_right { padding-right: 0 !important; margin-right: 0 !important; }
.top_panel .sc_layouts_column_align_right > .sc_layouts_item { margin-right: 0 !important; padding-right: 0 !important; }
/* The right column was content-width (stopped ~40px short of columns_wrap's edge).
Make the header row flex and let the right column grow to fill to the edge. */
.top_panel .top_panel_navi .columns_wrap { display: flex !important; align-items: center; flex-wrap: nowrap; }
.top_panel .top_panel_navi .columns_wrap > .sc_layouts_column_align_right { flex: 1 1 auto !important; }
/* Align the last main-menu item flush-right with the search button above it
(remove its trailing item margin / link right padding). */
.top_panel .sc_layouts_menu_nav > li:last-child { margin-right: 0 !important; padding-right: 0 !important; }
.top_panel .sc_layouts_menu_nav > li:last-child > a { padding-right: 0 !important; margin-right: 0 !important; }
/* Main menu font (theme default 17px -> 19px -> 23px -> 16px -> 17.6px).
Reduced 30% on 2026-09-02, per request: 23px x 0.7 = 16.1px, set to 16px.
Enlarged 10% on 2026-09-18, per request: 16px x 1.1 = 17.6px.
Global, not inside a media query, so the mobile menu follows too.
The submenu size is set on its link further down; it does not follow this
variable, so keep the two equal by hand. */
:root { --theme-font-menu_font-size: 17.6px !important; }
/* Gap between main-menu items (2026-08-21).
The spacing used to come from the link's own padding — trx_addons/css/
__styles.css sets `.sc_layouts_menu_nav > li > a { padding: 1em }`, so each
gap was two paddings: 2 x 1em = 38px at the old 19px font.
The gap is no longer set as a fixed number. It is now derived from the
header layout, so that the first item lines up with the left edge of the
search field on the tier above — see the `space-between` block in the
@media (min-width: 1024px) section further down.
Kept here only for the vertical padding, which the theme uses to give the
header row its height; the horizontal half is zeroed down there. */
/* ===== Header search = Domased Live Search plugin field (2026-07-31) ===== */
/* Hide the theme's fullscreen-search icon; our live-search field is injected in
the same header search slot via child functions.php. */
.top_panel .search_wrap { display: none !important; }
.top_panel .domased-header-search { display: flex; align-items: center; width: 100%; }
/* 600px, up from 280px (2026-08-05). Overrides the plugin's own 340px default.
This alone is not enough — the whole chain from the header column down to the
field has to carry a definite width, or the field is sized by its content and
this ceiling is never reached. See the .domased-hdr-search rule further down. */
.top_panel .domased-search {
width: 100%;
max-width: 600px;
}
/* Field height/border live in the plugin stylesheet (assets/search.css), which
now prints after this file — don't set them here or the two fight. */
/* ========================================================================= */
/* ===== Header layout + keyboard focus order (2026-07-31) ================== */
/* The child template skins/default/templates/header-navi.php emits the right
column as search -> cart -> menu. DOM order *is* the tab order, giving:
logo -> search field -> cart -> main menu items
The menu sits on its own second line underneath search/cart, so the visual
order matches the focus order exactly — no `order` juggling needed. */
@media (min-width: 1024px) {
.top_panel .top_panel_navi .sc_layouts_column_align_right {
display: flex !important;
align-items: center;
justify-content: flex-end;
flex-wrap: wrap; /* lets the menu drop to its own line */
gap: 14px 33px; /* row-gap column-gap — flex drops the inline
whitespace these items used to be separated
by. Column-gap only ever applies between the
search field and the cart, since the menu
takes a full-width row of its own.
This is the space from the search button to
the divider rule. Settled at 18px after
measuring the rendered header; its partner
is .domased-hdr-cart's padding-left, which
sets the space on the far side of the rule
(21px). Measure, don't eyeball the CSS —
the theme has a margin here that only shows
up once the cascade resolves. */
}
/* The search item needs a DEFINITE width. With `flex: 0 0 auto` it was sized
by its content, so the field's own `width:100%` resolved against an
auto-width parent and its max-width was a ceiling it never reached —
raising that max-width alone changed nothing on screen.
Both !important because trx_addons' layouts.css pins every
`.sc_layouts_column .sc_layouts_item` to `width: auto !important`, at the
same specificity as this rule — without !important the winner would come
down to stylesheet order, which this theme reshuffles. flex-basis is what
actually sizes it; the width is the fallback if the flex row ever isn't. */
.top_panel .top_panel_navi .sc_layouts_column_align_right > .domased-hdr-search {
flex: 0 1 600px !important;
width: 600px !important;
max-width: 100%;
min-width: 0;
/* trx_addons gives every .sc_layouts_item `margin-right: 1.5em`. That
stacked on top of the 18px column-gap, so the divider below sat ~42px
from the field but only 18px from the cart. Spacing is handled by
`gap` here, so the margin just goes. !important because that theme
rule ties this one on specificity (both 0,4,0) and would otherwise win
on source order. */
margin-right: 0 !important;
}
.top_panel .top_panel_navi .sc_layouts_column_align_right > .domased-hdr-cart {
flex: 0 0 auto; /* cart stays sized to its content */
position: relative;
/* trx_addons has a right-aligned-column variant that flips its item
spacing to the other side:
.sc_layouts_column_align_right .sc_layouts_item { margin-left: 1.5em }
which is 27px at the header's font size. Measured, that was sitting
between the search button and the rule — 8px gap + 27px margin = 35px,
against 18px on the cart side. Zeroing margin-right elsewhere never
touched it, because for this column the theme does not use
margin-right at all. Spacing here comes from `gap` + the padding
below, so the margin goes. */
margin-left: 0 !important;
padding-left: 33px; /* space from the rule to the cart. Its partner
is the container's column-gap, which sets the
space from the search button to the rule —
the two together position the line. */
}
/* 2px rule separating the search field from the cart (2026-08-06).
A pseudo-element rather than border-left on the cart: the cart item's own
height depends on whatever markup WooCommerce puts inside it, so a border
would be however tall that happens to be. This pins the line to 28px,
centred on the row, so it stays deliberate regardless. Note the theme
pins .sc_layouts_item to `width: auto !important` — that only affects the
item, not this ::before, so no !important is needed here. */
.top_panel .top_panel_navi .sc_layouts_column_align_right > .domased-hdr-cart::before {
content: '';
position: absolute;
left: 0;
top: 50%;
transform: translateY(-50%);
/* Design comp (domased-home.png), measured: 1px wide, 49px tall, #000.
2px #121212 since 2026-10-19, like the search field's and the
buttons' outlines. */
width: 2px;
height: 49px;
background: #121212;
}
/* Full-width second line => the menu always wraps underneath search/cart. */
.top_panel .top_panel_navi .sc_layouts_column_align_right > .domased-hdr-menu {
flex: 0 0 100%;
width: 100%;
display: flex;
justify-content: flex-end; /* keep the menu flush right, as before */
min-width: 0;
}
/* ----- Menu spans exactly the tier above it (2026-08-21) -----------------
Goal: the first menu item starts at the same x as the search field's left
edge, and the last stays flush with the column's right edge.
Both tiers are right-aligned in the same column, so the column's own width
(and the logo's) cancels out: aligning the left edges just means giving
the menu the same width as search + gap + cart. Then `space-between` puts
the first item on that left edge and shares the slack out evenly, so the
gap is whatever alignment requires rather than a number tuned by hand —
it re-derives itself if a menu label changes.
The widths below MIRROR the rules above; keep them in step:
600px -> .domased-hdr-search flex-basis / width
33px -> this column's `gap` (the column-gap half)
33px -> .domased-hdr-cart padding-left
30px -> .sc_layouts_cart_icon width
18px -> .sc_layouts_cart_items_short margin-left
28px -> .sc_layouts_cart_items_short width
The cart's own details block (`0 items - 0,00€`) is NOT in the sum: this
row is `sc_layouts_row_type_compact`, where the theme hides it.
----- SUPERSEDED 2026-09-02 -----------------------------------------
The left-edge alignment above was dropped on request: the menu is now
sized by its own content and right-aligned as a block, with the gap set
as a number again (62px, 30% under the 88px the old rule produced at the
16px font). The two cannot both hold — spanning a fixed 742px is exactly
what forced the gap to be whatever alignment required.
So `space-between` + `width: calc(...)` became `flex-end` +
`width: max-content` + `column-gap`. The `--domased-hdr-*` custom
properties that mirrored the tier above are gone with them; the note on
which rules they mirrored is kept above only as history, and nothing
below depends on those widths any more.
What still holds: the last item stays flush with the column's right edge,
which is now the anchor the whole row hangs from.
---------------------------------------------------------------------- */
.top_panel .top_panel_navi .domased-hdr-menu ul.sc_layouts_menu_nav {
/* The theme ships this list as `display:block` with floated items, so the
`justify-content` set on it up at the flush-right rule was inert until
now. Making it a flex container is what activates both. */
display: flex !important;
flex-wrap: nowrap;
justify-content: flex-end !important;
column-gap: 62px;
width: max-content;
margin-left: auto;
}
/* The theme puts its own margin on the items; with `column-gap` owning the
spacing now, any residue would be added on top of the 62px rather than
absorbed into free space the way `space-between` absorbed it. */
.top_panel .top_panel_navi .domased-hdr-menu ul.sc_layouts_menu_nav > li {
margin-left: 0 !important;
margin-right: 0 !important;
}
/* The theme clears its floated items with a `content:" "` ::after on the list.
Harmless in block layout — but a pseudo-element of a flex container is a
flex item, so it joined the row as a seventh item and, being ~370px wide,
swallowed exactly the free space `space-between` needed. The result was
every item packed hard against the left with no gaps at all.
Dropped here only: the floats it used to clear are themselves ignored once
the list is a flex container. Scoped inside this media query, so the mobile
menu below 1024px keeps the theme's clearfix untouched. */
.top_panel .top_panel_navi .domased-hdr-menu ul.sc_layouts_menu_nav::after {
content: none;
}
/* Horizontal padding would sit between the item's text and the box edge,
pushing the first item's text inward from the line we are aligning to.
`space-between` owns the spacing now, so it goes; the vertical half is
left alone because it sets the header row's height. */
.top_panel .top_panel_navi .domased-hdr-menu ul.sc_layouts_menu_nav > li > a {
padding-left: 0 !important;
padding-right: 0 !important;
}
}
/* ========================================================================= */
/* ===== Cart count: badge on the icon -> black rectangle beside it (2026-08-06) =====
trx_addons draws the count as a pill sitting ON the basket:
.sc_layouts_cart_items_short { position:absolute; top:0; right:0;
transform:translate(50%,-33%); border-radius:8px }
Every one of those has to be undone, not just the position — leaving the
transform behind would shift the element off its new inline spot, and the
8px radius is what makes it a pill rather than a rectangle.
The parent is forced to inline-flex on purpose: as an inline box, the
whitespace between the s in the source collapses to a rendered space,
and that space would sit between the icon and the badge, making the gap
"10px + a space" rather than the 10px asked for. Flex drops it. */
.top_panel .domased-hdr-cart .sc_layouts_cart {
display: inline-flex !important;
align-items: center;
}
/* Basket glyph. The theme draws it from its icon font (trx_addons_icon-basket);
the comp uses Material Icons `shopping_basket`, which is what the extracted
30x25 bitmap traces to. Inlined as an SVG data URI rather than the extracted
PNG on purpose — the comp is 1x, so that raster would be soft on any
hi-dpi screen, whereas this stays sharp at every size.
viewBox is cropped to the glyph's own bounds (1 2 22 19) so the box is filled
edge to edge instead of carrying Material's built-in padding. */
.top_panel .domased-hdr-cart .sc_layouts_cart_icon::before {
content: none !important;
}
.top_panel .domased-hdr-cart .sc_layouts_cart_icon {
display: block !important;
position: relative;
top: 2px; /* nudged down 2px (2026-08-06) */
width: 30px; /* comp: 30 x 25 */
height: 25px;
background-image: url("data:image/svg+xml;charset=utf-8,%3Csvg xmlns='http://www.w3.org/2000/svg' viewBox='1 2 22 19'%3E%3Cpath fill='%23292929' d='M22 9h-4.79l-4.38-6.56c-.19-.28-.51-.42-.83-.42s-.64.14-.83.43L6.79 9H2c-.55 0-1 .45-1 1 0 .09.01.18.04.27l2.54 9.27c.23.84 1 1.46 1.92 1.46h13c.92 0 1.69-.62 1.93-1.46l2.54-9.27L23 10c0-.55-.45-1-1-1zM12 4.8L14.8 9H9.2L12 4.8zM12 17c-1.1 0-2-.9-2-2s.9-2 2-2 2 .9 2 2-.9 2-2 2z'/%3E%3C/svg%3E");
background-repeat: no-repeat;
background-position: center;
background-size: contain;
}
/* Count box — comp: 28x28 square, #292929 (not pure black), white digit ~15px. */
.top_panel .domased-hdr-cart .sc_layouts_cart_items_short {
/* `relative` rather than `static` only so `top` can nudge it; it is still
in normal flow, unlike the theme's absolute overlay this replaced.
Offsetting icon and badge individually rather than their shared parent —
a transform or offset on .sc_layouts_cart would make it the containing
block for the absolutely positioned cart dropdown and move that too. */
position: relative !important;
top: 2px; /* nudged down 2px (2026-08-06) */
/* The theme also sets `right: -6px` on this badge. It was inert while the
element was `absolute`-positioned as an overlay, but turning it `relative`
for the `top` nudge above made it live and shunted the badge 6px past the
column's right edge — out of line with the menu below. Both offsets are
pinned to auto so only `top` moves it. */
left: auto !important;
right: auto !important;
bottom: auto !important;
transform: none !important;
display: inline-flex !important;
align-items: center;
justify-content: center;
margin-left: 18px; /* comp: 18px from the basket */
min-width: 28px;
width: 28px;
min-height: 28px;
height: 28px;
padding: 0;
border-radius: 0 !important; /* square, not the theme's pill */
background-color: #292929 !important;
color: #fff !important;
font-size: 15px;
font-weight: 400;
line-height: 1;
box-sizing: border-box;
}
/* Hover (2026-10-19): basket and count box turn dark red together — the site's
link red #C42433 (white digit on it 5.8:1). Both open the mini-cart, so
pointing at either lights both. Keyed to the two elements, not the wrapper,
because the open dropdown panel sits inside the wrapper and hovering it
should not recolour the header. The basket is a background SVG, so hover
swaps in the same path with the red fill. Without :has() support nothing
changes colour. */
.top_panel .domased-hdr-cart .sc_layouts_cart:has(.sc_layouts_cart_icon:hover, .sc_layouts_cart_items_short:hover) .sc_layouts_cart_icon {
background-image: url("data:image/svg+xml;charset=utf-8,%3Csvg xmlns='http://www.w3.org/2000/svg' viewBox='1 2 22 19'%3E%3Cpath fill='%23C42433' d='M22 9h-4.79l-4.38-6.56c-.19-.28-.51-.42-.83-.42s-.64.14-.83.43L6.79 9H2c-.55 0-1 .45-1 1 0 .09.01.18.04.27l2.54 9.27c.23.84 1 1.46 1.92 1.46h13c.92 0 1.69-.62 1.93-1.46l2.54-9.27L23 10c0-.55-.45-1-1-1zM12 4.8L14.8 9H9.2L12 4.8zM12 17c-1.1 0-2-.9-2-2s.9-2 2-2 2 .9 2 2-.9 2-2 2z'/%3E%3C/svg%3E");
}
.top_panel .domased-hdr-cart .sc_layouts_cart:has(.sc_layouts_cart_icon:hover, .sc_layouts_cart_items_short:hover) .sc_layouts_cart_items_short {
background-color: #C42433 !important;
}
/* ================================================================================= */
/* ===== Footer, matched to domased.sk (2026-07-31) ========================= */
/* Values transcribed from the live child theme's stylesheet. The live footer
renders as `footer_wrap widget_area scheme_original`, whereas this install
uses the `footer_default` template (`footer_widgets_wrap` + a copyright row),
so the selectors are written against OUR markup rather than copied verbatim —
the resulting appearance is what matches, not the CSS text. */
/* Live: .scheme_original footer .widget_area_inner { background-color: #8BDAF8 } */
/* The theme also paints the OUTER footer element via
[class*=scheme_].footer_wrap { background-color: var(--theme-color-bg_color) }
(#F5F5F4 in this skin), so colouring only the inner left a grey frame around
the blue. Paint both, and pin the text dark — the scheme text variable is
what live's scheme_original resolves to visually. */
/* The white-background block further up this file paints a bare `.content_wrap`
white with !important, and the footer uses .content_wrap for its inner
container too — so it was covering the blue. Specificity (0,2,0) beats that
rule's (0,1,0), so these win and let the parent's colour through. */
.footer_wrap .content_wrap,
.footer_wrap .columns_wrap,
.footer_copyright_wrap .content_wrap,
.footer_copyright_wrap .copyright_text {
background-color: transparent !important;
}
/* Every wrapper in the footer gets the blue, not just the inner widget area —
the theme paints the outer element from the scheme
[class*=scheme_].footer_wrap { background-color: var(--theme-color-bg_color) }
which left a grey frame around the blue. */
footer.footer_wrap,
.footer_wrap .footer_widgets_wrap,
.footer_wrap .footer_widgets_inner,
.footer_wrap .widget_area_inner {
background-color: #8BDAF8 !important;
color: #000;
}
/* Live column widths: 1st 20%, 2nd 50%, 3rd takes the rest. Columns align to
the bottom so the logo and the illustration sit on the same baseline.
Live emits .column-1_4 (its footer_columns option is 4); this install lets the
theme auto-count and gets .column-1_3, so the widths are keyed off position
rather than the fraction class — correct either way. */
.footer_wrap .columns_wrap > [class*="column-"] { vertical-align: bottom; }
.footer_wrap .columns_wrap > [class*="column-"]:nth-child(1) { width: 20% !important; }
.footer_wrap .columns_wrap > [class*="column-"]:nth-child(2) { width: 50% !important; }
.footer_wrap .columns_wrap > [class*="column-"]:nth-child(3) { width: 30% !important; }
/* Links: black and underlined, not the theme's accent colour. */
.footer_wrap .widget_area_inner .widget_text a:not(.sc_button) {
color: #000 !important;
text-decoration: underline;
}
/* Plain lists — the theme adds bullets and indents to widget lists. */
.footer_wrap.widget_area ul li:before,
.footer_wrap .widget_area_inner ul li:before { content: none; }
.footer_wrap .widget_area_inner ul li {
padding-left: 0;
margin-bottom: 0;
}
/* The two link blocks sit side by side inside the middle column. */
.domasedinfo, .domasedspojenie { float: left; }
.domasedspojenie { margin-left: 85px; }
.clearingb { clear: both; }
.patainfo { margin-bottom: -5px; }
/* Column headings are Inter, small and bold — not the theme's serif h2.
Margins zeroed against the theme's own h2 top margin (0.77em of a 2.6em
font), which pushed the lists down; live's headings sit tight. */
.footer_wrap h2.nadpisinter {
font-family: 'Inter', Arial, sans-serif !important;
font-size: 0.9em;
font-weight: bold;
color: #000;
margin-top: 0;
margin-bottom: 2em;
}
.footer_wrap_inner,
.footer_widgets_inner { padding-bottom: 1.9em; }
.footer_wrap aside { margin-bottom: 0.9em; }
/* Copyright bar — the darker blue strip that closes the footer.
On live this is a separate .copyright_wrap element AFTER ; this
install renders it inside the footer as .footer_copyright_wrap, so the
selectors differ but the result matches. Live values:
.scheme_original .copyright_wrap_inner { background-color: #23BEF8 }
.copyright_text { color: white; font-size: 0.8em; letter-spacing: 2px }
.copyright_wrap_inner { border-top: 0; padding: 0.4em 0 }
The text itself comes from the theme's `copyright` option. */
.footer_copyright_wrap,
.footer_copyright_wrap .footer_copyright_inner {
background-color: #23BEF8 !important;
}
.footer_copyright_wrap .footer_copyright_inner {
border-top: 0 !important;
padding-top: 0.4em;
padding-bottom: 0.4em;
}
/* Black rather than live's white: on the #23BEF8 strip black gives 8.0:1
against white's 2.6:1, so the line is far easier to read. */
.footer_copyright_wrap .copyright_text,
.footer_copyright_wrap .copyright_text a {
color: #000 !important;
font-size: 0.8em;
letter-spacing: 2px;
}
/* Sticky footer, as on live: short pages still push it to the bottom. */
.page_wrap { display: flex; flex-direction: column; min-height: 100vh; }
.page_wrap > footer { margin-top: auto; }
/* ========================================================================= */
/* ===== Visually hidden utility (2026-07-31) =============================== */
/* Present for screen readers and search engines, absent visually. Used for the
front page h1, which the design has no slot for. Not `display: none` — that
would remove it from the accessibility tree and defeat the purpose. */
.domased-visually-hidden {
position: absolute !important;
width: 1px;
height: 1px;
margin: -1px;
padding: 0;
border: 0;
overflow: hidden;
white-space: nowrap;
clip: rect(0 0 0 0);
clip-path: inset(50%);
}
/* ========================================================================= */
/* ===== Slider flush under the header (2026-07-31) ========================= */
/* The theme pads the content area away from the header with
.page_content_wrap { padding-top: 7.1rem; } (~113px)
On the front page the first thing in the content is the hero slider, which
should butt straight up against the header — as it does on domased.sk. Only
the top padding is removed; the bottom padding still separates the content
from the footer. Scoped to .home so inner pages keep their breathing room.
(The stray wpautop wrapped around the slider is removed in PHP — see
Domased_Slider::unwrap_paragraph().) */
.home .page_content_wrap {
padding-top: 0 !important;
}
/* Second source of the same gap: the `custom-background` class WordPress puts
on
also switches on padding around .content in __responsive.css —
@media (max-width:1439px) .custom-background .content_wrap>.content { padding: 3em }
@media (max-width:1023px) .custom-background .content_wrap>.content { padding: var(--theme-var-grid_gap) }
3em (~48px) of that sat on top of the slider. It only applies below 1440px,
which is why zeroing .page_content_wrap alone did not look fixed on a laptop.
Same body class was behind the grey content background fixed further up. */
.home .content_wrap > .content {
padding-top: 0 !important;
}
/* The slider breaks out to the full browser width with
`width:100vw; margin-inline: calc(50% - 50vw)` (see the plugin's slider.css).
100vw counts the vertical scrollbar, so without this the page would gain a
horizontal scrollbar of ~15px. `clip` is preferred over `hidden` because it
does not turn the element into a scroll container (which would break any
position:sticky inside); `hidden` is listed first as the fallback for older
browsers. */
.home .page_content_wrap {
overflow-x: hidden;
overflow-x: clip;
}
/* ========================================================================= */
/* ===== Submenu indicator triangle (2026-07-31) ============================ */
/* Top-level items with a submenu ("Knihy") get a small filled triangle so the
submenu is discoverable before you interact with the item.
*
* The theme already has an indicator here — `content: "\e828"` in the fontello
* icon font — but it only renders if that font loads. This draws a real
* triangle out of CSS borders instead, so it is font-independent, inherits the
* menu colour via currentColor, and follows the text on hover/active.
*
* `.top_panel` and `.top_panel_default` sit on the same element, so chaining
* them outranks the theme's rule (0,4,3 vs 0,3,3) without needing !important.
*
* It is a pseudo-element with empty content, so screen readers ignore it — the
* state is carried by aria-expanded on the link (see js/header-a11y.js). */
/* Attached to the label , not the : the span's inline box hugs the text
exactly, so putting the triangle inside it means the active-page underline
(a border-bottom on that same span) covers text + triangle and stops there,
rather than running the full width of the link including its padding. */
.top_panel.top_panel_default .sc_layouts_menu_nav > li.menu-item-has-children > a > span:after {
content: "";
font-family: inherit; /* drop the fontello glyph */
display: inline-block;
/* The theme positions its own carets absolutely (right: 1.5em) for popup and
sub-level menus. Something in that cascade was still landing on this one
and parking the triangle on top of the last letter of "Knihy", so this
pins down every property that could displace it rather than inheriting
whatever is left over. Keep these — dropping them brings the overlap back. */
position: static !important;
top: auto !important;
right: auto !important;
bottom: auto !important;
left: auto !important;
float: none !important;
transform: none;
margin: 0 0 0 8px !important;
padding: 0 !important;
background: none !important;
width: 0;
height: 0;
vertical-align: middle;
border-left: 4px solid transparent;
border-right: 4px solid transparent;
border-top: 5px solid currentColor;
pointer-events: none; /* never swallow a click meant for the link */
transition: transform .15s ease;
}
/* Flip it while the submenu is open — superfish adds .sfHover on hover, and
js/header-a11y.js adds the same class on keyboard open, so this tracks both. */
.top_panel.top_panel_default .sc_layouts_menu_nav > li.menu-item-has-children.sfHover > a > span:after {
transform: rotate(180deg);
}
/* ========================================================================= */
/* ===== Submenu ("Knihy" dropdown) (2026-08-22) ============================ */
/* Bigger, white, with a domased-yellow hover/focus row.
The dropdown itself stays as the theme has it: #121212 background, 16 items.
White on that is ~18.9:1, and black on #FFBC00 is ~12.5:1 — both clear AAA. */
/* Theme submenu size is 15px (--theme-font-submenu_font-size in the skin's
__custom.css). Set on the link rather than the variable so this stays scoped
to the header menu and leaves the mobile panel alone.
2026-09-02: set to 16px to match the main menu, which came down to 16px the
same day — the dropdown had been left larger than the item it hangs off.
It is now 1px over the theme's own 15px, so this rule is very nearly a no-op;
it is kept rather than deleted because the white colour below shares it and
because 16px is a deliberate match to the parent, not a coincidence.
2026-09-18: main menu +10% to 17.6px, so this follows to 17.6px. */
.top_panel .sc_layouts_menu_nav > li li > a {
font-size: 17.6px !important; /* matches the main menu; 22.5 -> 20.5 -> 16px on 2026-09-02 -> 17.6px on 2026-09-18 */
color: #ffffff !important;
}
/* The theme sizes this dropdown as `width: 15em` — 225px, because the UL's own
font stays 15px. That was right for 15px labels; at the enlarged size "Knihy
pre deti a mládež" wrapped onto a second line.
`max-content` sizes the box to its longest label instead of to a number, so it
stays correct if a category is renamed or added. min-width keeps the dropdown
from shrink-wrapping to something narrower than the parent item; max-width is
a guard so one very long category cannot run the panel off-screen (a label
that long would then wrap, as it should). */
.top_panel .sc_layouts_menu_nav > li ul.sub-menu {
width: max-content !important;
min-width: 320px;
max-width: 460px;
}
/* Kill the black band at the top and bottom of the dropdown (2026-08-22).
The theme sets `padding: 1em 0` on the submenu UL (booklovers skin style.css
~18196). The em resolves against the UL's own 15px font, so it is a 15px strip
of the #121212 background above the first row and below the last — measured at
exactly 15.0px each. Now that hovering paints a full-width yellow row, those
strips read as unfinished edges rather than as breathing room.
Scoped to the first-level dropdown (`> li > ul.sub-menu`) on purpose: nested
flyouts are pulled up by `top: -1em` to line their first item up with the
parent row, and that offset assumes the padding is still there. There are no
third-level items in this menu today, but the rule should not become wrong if
one is added. */
.top_panel .sc_layouts_menu_nav > li > ul.sub-menu {
padding-top: 0 !important;
padding-bottom: 0 !important;
}
/* Hover/focus row. The background goes on the , which carries the padding,
so the colour fills the whole row rather than just the text. */
.top_panel .sc_layouts_menu_nav > li li > a:hover,
.top_panel .sc_layouts_menu_nav > li li > a:focus,
.top_panel .sc_layouts_menu_nav > li li.sfHover > a {
background-color: #FFBC00 !important;
color: #000000 !important;
}
/* The site-wide focus ring is #FFBC00 (see the block below), which would vanish
into this row's new yellow background. Swap it for the dark ring here, inset
so it sits inside the row instead of overlapping the neighbouring items. */
html body .top_panel .sc_layouts_menu_nav > li li > a:focus-visible {
outline: 3px solid #14110e !important;
outline-offset: -3px !important;
box-shadow: none !important;
}
/* ========================================================================= */
/* ===== Product listings: chrome removed, spacing tightened (2026-09-02) =====
Applies to every product listing — the shop, all 219 product categories,
product tags and attribute archives — not to the Knihy category alone. The
request came from the Knihy page, but it is one shared archive template:
removing the breadcrumbs there and leaving them on Detektívky would read as a
bug rather than as a decision.
Scoped by body class rather than by `:has(.domased-filter-layout)`, which was
the other candidate. `:has()` would follow the filter plugin exactly, but it
would also stop applying if that plugin were ever deactivated or bailed out
— and the spacing here is the theme's, not the plugin's. The list below does
NOT include search results (`body.search-results`), because that class also
covers searches that return pages and posts.
Product search results therefore keep the breadcrumbs and the old spacing.
Add `body.search-results` to both selector lists if they should match. */
body.post-type-archive-product .sc_layouts_title_breadcrumbs,
body.tax-product_cat .sc_layouts_title_breadcrumbs,
body.tax-product_tag .sc_layouts_title_breadcrumbs,
body[class*="tax-pa_"] .sc_layouts_title_breadcrumbs {
display: none;
}
/* The gap between the "Knihy" heading and the filter/listing was 294.6px from
the h1's baseline box to the top of the sidebar. Three separate paddings
stacked up to make it, and all three are the theme's:
95.4px .top_panel_title padding-bottom (below the breadcrumbs)
100px .page_content_wrap padding-top
54px .content padding-top
Trimmed to 32 / 24 / 0 = 56px. The heading itself does not move: the title
block's padding-TOP is left at 72px, so the h1 stays where it was and only
the space underneath it closes up. */
body.post-type-archive-product .top_panel_title,
body.tax-product_cat .top_panel_title,
body.tax-product_tag .top_panel_title,
body[class*="tax-pa_"] .top_panel_title {
padding-bottom: 32px !important;
}
body.post-type-archive-product .page_content_wrap,
body.tax-product_cat .page_content_wrap,
body.tax-product_tag .page_content_wrap,
body[class*="tax-pa_"] .page_content_wrap {
padding-top: 24px !important;
}
/* Filter sidebar flush with the logo.
`.content` carries `padding: 54px` and sits inside `.content_wrap`, whose own
left edge is already the logo's — 162px at 1440px. So the 54px was the whole
of the offset, and zeroing it puts the sidebar on 162px exactly.
The RIGHT padding goes with it, deliberately. Removing only the left would
leave the listing spanning 162 -> 1208 against a header that spans
162 -> 1262: flush on one side and 54px short on the other, which looks like
a mistake. Zeroing both makes the listing column match the header's two tiers
on both edges — together with the `ul.products` rule at the end of this block,
without which the product text still overhangs the right edge by 30px. Put
`padding-right: 54px` back here if the narrower measure is wanted on the
right.
Desktop only. Below 1024px this padding is part of what keeps the listing off
the screen edges, and the filter plugin has its own responsive rules at 900px
that assume it. The alignment being asked for is a wide-viewport concern. */
@media (min-width: 1024px) {
body.post-type-archive-product .content,
body.tax-product_cat .content,
body.tax-product_tag .content,
body[class*="tax-pa_"] .content {
padding-left: 0 !important;
padding-right: 0 !important;
padding-top: 0 !important;
}
/* `ul.products` carries the theme's `margin-right: -30px`, which offsets the
30px right padding its li's have in a multi-column grid. In list mode the
li padding is already zeroed (see the 2026-08-23 block), so that negative
margin is pure overhang: it pushed the product text to 1292px against a
header that ends at 1262px.
Invisible before today, because `.content`'s 54px padding held the whole
column 54px in from the edge and the overhang merely ate into it. With the
padding gone it is the difference between the listing lining up with the
header and missing it by 30px. Grid mode keeps the compensation. */
body.post-type-archive-product .shop_mode_list ul.products,
body.tax-product_cat .shop_mode_list ul.products,
body.tax-product_tag .shop_mode_list ul.products,
body[class*="tax-pa_"] .shop_mode_list ul.products {
margin-right: 0 !important;
}
}
/* ========================================================================= */
/* ===== Sort dropdown: bordered box, as on live domased.sk (2026-09-02) =====
The theme renders "Prednastavené zoradenie" as bare text with a chevron — no
border, no background (measured: `border: 0px none`, `background: rgba(0,0,0,0)`).
Live draws it as a filled, outlined box. Values below are the COMPUTED styles
read off https://domased.sk/kategoria-produktu/knihy/, not copied from a
stylesheet: live's own `.woocommerce select` rule in the child theme's
`css/plugin.woocommerce.css` is commented out, so the box comes from the 1.4.4
parent theme and only the rendered page is authoritative.
border 1px solid rgba(175, 178, 179, 0.62)
background rgb(245, 245, 244)
radius 0
padding 3.06px 4.59px
Deliberately NOT copied from live: font (live 15.3px/400, ours stays 16px/500
to match the menu) and width (live 273px, ours 245px — it is right-aligned to
the same edge either way).
The markup is identical on both sites — `form.woocommerce-ordering > select` —
but the chevron is not. Live draws it with `form::after` (fontello, 34px wide,
`right: 0`). Here trx_addons's JS wraps the select in `div.select_container` at
runtime and hangs the glyph off `.select_container::after`, 10px wide at
`right: 0`. That is why the arrow is nudged in below: at 10px wide against a
new 1px border it sat on the border itself, where live's 34px box gives its
glyph ~8px of clearance. */
/* Every property here is marked. The theme dresses form controls with selectors
that outrank a single class — the same situation the filter plugin's CSS
documents — and a first pass without `!important` lost the border, the
background AND the padding outright (measured: still `0px none` and
`rgba(0,0,0,0)`). Marked rather than escalated into a specificity race the
next theme update would win back. */
.woocommerce-ordering select.orderby {
border: 1px solid rgba(175, 178, 179, 0.62) !important;
background-color: #f5f5f4 !important;
border-radius: 0 !important;
height: auto !important;
/* Right padding is the theme's own 25px, kept: it is the room the chevron
sits in, and the text must not run under it. Left 6px ~ live's 4.59px,
rounded up for our slightly larger font. */
padding: 3px 25px 3px 6px !important;
}
.woocommerce-ordering .select_container::after {
right: 8px !important;
}
/* ========================================================================= */
/* ===== Listing and sidebar start on the same line (2026-09-02) =============
The top of the filter box, the first cover and the first book title all line
up. Measured before: box top 400.0, cover and title both 442.4 — the cover and
the title already agreed with each other, the sidebar was 42.4px high.
Why they differed. Both columns begin their header at the same y (362.0), but
the headers are not the same height:
sidebar "Filtre" h2 24px + 14px margin = 38px
results sort control 30px + 50.4px margin = 80.4px
------
difference 42.4px
So the fix is to make the two headers occupy the same height, and the sidebar's
38px is the one to keep: its 14px margin ties the "Filtre" label to the box it
labels, and stretching that to 56.4px to meet the listing would leave the label
floating away from its own panel. The sort control is free-standing and can
give the space up. 30 + 8 = 38, so the products start at 400.0 — exactly the
filter box's top.
Arithmetic, not a magic number: if the sort control's height changes (it is
30px because of the border added the same day) or the "Filtre" heading's size
changes, re-derive rather than nudging this value.
----- 2026-09-04: +20px of air under the sort control -------------------
Requested as "more space between the drop-down and Filtre/list of books".
Both were named, and both start on the same line, so BOTH have to move or the
alignment above is undone — pushing only the listing down would leave the
filter box 20px high again.
The invariant is unchanged: sidebar header height == results header height.
It is simply 20px larger on each side.
sidebar "Filtre" h2 24px + 34px margin = 58px (was 24 + 14 = 38)
results sort control 30px + 28px margin = 58px (was 30 + 8 = 38)
Content therefore starts at 420.0 instead of 400.0.
The sidebar half overrides `.domased-filter__head`, whose 14px lives in the
plugin's own assets/filter.css. Overridden here rather than edited there on
purpose: these two numbers are only correct as a PAIR, and splitting them
across two files is how they would drift. Change one, change the other. */
body.post-type-archive-product .woocommerce-ordering,
body.tax-product_cat .woocommerce-ordering,
body.tax-product_tag .woocommerce-ordering,
body[class*="tax-pa_"] .woocommerce-ordering {
margin-bottom: 28px !important;
}
body.post-type-archive-product .domased-filter__head,
body.tax-product_cat .domased-filter__head,
body.tax-product_tag .domased-filter__head,
body[class*="tax-pa_"] .domased-filter__head {
padding-top: 22px;
margin-bottom: 12px;
}
/* ----- 2026-09-18: "Filtre" closer to the list, set in Inter ---------------
Same 58px header, redistributed: 22px above the heading + 24px h2 + 12px
below (was 0 + 24 + 34). The label now sits with the box it names, and the
invariant above still holds, so the filter box and the first cover still
start on the same line. */
.domased-filter__title {
font-family: 'Inter', Arial, sans-serif !important;
font-weight: 700;
letter-spacing: 0;
/* 2026-09-19: 2px in, so the F sits optically on the box's left border
instead of reading as sticking out past its rounded corner. */
padding-left: 2px;
}
/* ========================================================================= */
/* ===== Loop title and author: live's typography (2026-09-02) ==============
Both read off the rendered https://domased.sk/kategoria-produktu/knihy/ with
getComputedStyle, same as the sort dropdown above — not copied from live's
stylesheets.
ours (before) live (applied)
title 19px Playfair Display 700 27.2px Inter 700, lh 35.36
author 15px Playfair Display 400 15.3px Inter 400, lh 21
The element is the same on both sites — `h2.woocommerce-loop-product__title`
— so this is only type, no markup or hook involved.
The odd numbers are live's own: it sets 1.6em and 0.9em against a 17px
context, giving 27.2 and 15.3. Written here as px because our context is not
17px, and an em would silently resolve to something else.
Inter is already self-hosted by this theme (css/font-face/Inter), so the stack
matches live's `Inter, Arial, sans-serif` with no new request.
NOT changed — colours were not part of the request and are the rebuild's own:
title #121212 (live pure #000) and author #DE3241 (live #FF0000).
Scoped to every products loop, like the author-line rule above it, so related
products under a single product page get the same treatment — which is how
live behaves. The homepage is unaffected: domased-home builds its own markup
and never fires WooCommerce's loop hooks. */
.woocommerce ul.products li.product h2.woocommerce-loop-product__title {
font-family: 'Inter', Arial, sans-serif;
font-size: 27.2px;
line-height: 1.3;
}
/* The author line is NOT restyled here. Its rule already exists further down in
the 2026-08-23 block under an identical selector, so a copy here would be a
second source of truth for one element and — being earlier in the file — the
losing one. The live values went into that rule instead; see it below. */
/* ========================================================================= */
/* ===== Loop description and prices: live's typography (2026-09-02) ========
Read off the rendered domased.sk with getComputedStyle, same method as the
title/author entry above.
ours (before) live (applied)
description 18px lh 29 #797979 15.3px lh 19.89 #000
price size 19px weight 500 22.95px weight 700
former price #8C8D93 grey #FF0000 red, struck
new price #DE3241 red #000 black
regular price #DE3241 red #000 black
NOTE THE SWAP. On live the *former* price is the red one and the current
price is black; here it was the other way round — the current price was red
and the old one grey. Both are defensible designs, but they are opposites, so
this is the one change in today's run that alters what the page emphasises
rather than just its size. Called out because it is easy to read as a bug
later.
Live nests two sizes: `.price` itself is 19.125px and the
`.woocommerce-Price-amount` inside it is 22.95px (1.2em of it). Only the
amount is visible — the wrapper's own text is the screen-reader sentence
("Pôvodná cena bola: …") — but both are set so the ratio survives a future
change to either.
The strikethrough is stated explicitly rather than left to the UA stylesheet:
the theme's own `del` was measured at `text-decoration-line: none`. */
.woocommerce ul.products li.product .post_content {
font-size: 15.3px;
line-height: 19.89px;
color: #000000;
}
/* Marks below follow this theme's convention — only the properties that were
MEASURED to lose are marked, the rest are left to cascade. What lost here:
the wrapper's size and weight, and both colours that the theme sets directly
on `.woocommerce-Price-amount` (colour on `.price` alone does not reach it,
because a rule targeting the amount beats inheritance). */
.woocommerce ul.products li.product .price {
font-family: 'Inter', Arial, sans-serif;
font-size: 19.125px !important;
font-weight: 700 !important;
color: #000000;
}
/* The visible number. Colour is stated here rather than inherited from .price
for the reason above; the del/ins rules below outrank it on specificity. */
.woocommerce ul.products li.product .price .woocommerce-Price-amount {
font-size: 22.95px;
font-weight: 700;
color: #000000 !important;
}
/* Former price — red and struck through. */
.woocommerce ul.products li.product .price del,
.woocommerce ul.products li.product .price del .woocommerce-Price-amount {
color: #FF0000 !important;
}
.woocommerce ul.products li.product .price del {
text-decoration: line-through;
}
/* Current price — black, and no inherited strike. */
.woocommerce ul.products li.product .price ins,
.woocommerce ul.products li.product .price ins .woocommerce-Price-amount {
color: #000000 !important;
text-decoration: none;
}
/* ========================================================================= */
/* ===== Archive h1 aligned to the book covers (2026-09-04) =================
"Knihy" was centred in the title bar (h1 box at L=659.5). It now starts on the
same x as the first cover image: **474.0**.
The theme centres it through a chain of centred wrappers —
`.sc_layouts_column_align_center` > `.sc_layouts_item` > `.sc_layouts_title`
> `h1.sc_layouts_title_caption` — so the fix is two parts: switch the column
to left alignment, then push the item across by the width of everything to
the left of the listing.
That distance is DERIVED, not measured-and-pinned:
268px .domased-filter flex-basis (the sidebar)
+ 44px .domased-filter-layout column-gap
-----
312px from the content column's left edge (162.0) -> 474.0
Both numbers live in the filter plugin's assets/filter.css. If either changes,
this calc has to follow — it is written as a calc() rather than as `312px` so
the arithmetic stays visible at the point of use. Same pairing caveat as the
`.domased-filter__head` override above.
Desktop only. Below 1024px the sidebar stops being a left column at all (the
plugin collapses it behind a "Filtre" button at 900px), so there is nothing to
align to and the heading should stay where the theme puts it. */
@media (min-width: 1024px) {
body.post-type-archive-product .top_panel_title .sc_layouts_column_align_center,
body.tax-product_cat .top_panel_title .sc_layouts_column_align_center,
body.tax-product_tag .top_panel_title .sc_layouts_column_align_center,
body[class*="tax-pa_"] .top_panel_title .sc_layouts_column_align_center {
text-align: left !important;
}
body.post-type-archive-product .top_panel_title .sc_layouts_item,
body.tax-product_cat .top_panel_title .sc_layouts_item,
body.tax-product_tag .top_panel_title .sc_layouts_item,
body[class*="tax-pa_"] .top_panel_title .sc_layouts_item {
margin-left: calc(268px + 44px) !important;
}
}
/* ========================================================================= */
/* ===== Visible keyboard focus (2026-07-31) ================================ */
/* The theme removes focus outlines site-wide:
* :focus, a:focus { outline: 0 } (style.css ~line 241)
* input/select/textarea:focus { outline: 0 } (~line 2903)
* Its replacement is `outline: 1px dotted #888 !important` gated behind a
* `body.show_outline` class, which js/init.js only adds on a Tab keypress while
* an a/input/textarea/select is already focused —