s in core's own comment markup (.comment-author * wraps the avatar + name, .comment-metadata is the date, immediately * after) — not one wrapper it's easy to size a flex row around. Taking the * avatar out of flow with absolute positioning sidesteps that: the two * divs are left as plain stacked blocks (their normal default), just * indented clear of the corner the avatar now occupies, and the avatar's * own height is set to match that stacked block instead of the other way * around. */ .comment-meta { position: relative; min-height: 36px; padding-left: 46px; } .comment-author img.avatar { position: absolute; left: 0; top: 0; width: 36px; height: 36px; border-radius: 8px; border-color: #ececec; margin-right: 0; } .comment-author { width: auto; } .comment-author .fn { font-size: 14px; } .comment-author .fn .url { font-size: 14px; } .comment-metadata { margin-top: 2px; font-size: 11px; } .comment-content { margin-top: 8px; } .reply .comment-reply-link { border-radius: 6px; } /* Nested replies: a visual thread guide instead of just indentation, so deep (this site allows up to 5 levels) threads stay legible without each level eating as much horizontal space. */ .comments-area ol.children { margin: 8px 0 0 20px; padding-left: 10px; border-left: 2px solid #ececec; } @media (max-width: 600px) { .comments-area ol.children { margin-left: 10px; padding-left: 8px; } } /* Collapsible threads (assets/js/comments.js). With JS disabled the toggle button is never inserted and every thread just renders fully expanded — today's behavior, nothing hidden. */ .comment.is-collapsed > ol.children { display: none; } .articlewave-comment-toggle { position: absolute; top: 12px; right: 14px; display: flex; align-items: center; justify-content: center; width: 24px; height: 24px; padding: 0; border: 1px solid #ececec; border-radius: 50%; background: #fff; color: #767575; cursor: pointer; transition: transform 0.15s ease-out, background-color 0.15s ease-out; } .articlewave-comment-toggle:hover { background: #f4f4f4; } .articlewave-comment-toggle svg { transition: transform 0.15s ease-out; } .articlewave-comment-toggle[aria-expanded="false"] svg { transform: rotate( -90deg ); } /* ========================================================================= Post-bottom author box (template-parts/partials/innerpage/author.php) Same compact/rounded-corners/small-avatar treatment as the comment cards above. Simpler here than the comment case: the avatar and the name+bio text are already two separate sibling
s under one parent (.articlewave-author-container), with nothing else interleaved, so plain flexbox aligns them directly — no need for the comment section's absolute-positioning workaround, which existed only because a comment's avatar and its date live in two different sibling elements while the avatar itself is nested inside a third. ========================================================================= */ .articlewave-author-box-wrap { margin-top: 30px; } .articlewave-author-box-label { display: block; margin: 0 0 8px; font-size: 12px; font-weight: 700; letter-spacing: 0.04em; text-transform: uppercase; color: #767575; } .articlewave-site-layout--separate .articlewave-author-container { display: flex; align-items: flex-start; gap: 16px; padding: 16px 18px; border-radius: 14px; margin-top: 0; } .articlewave-author-image { display: block; width: auto; margin-right: 0; flex: 0 0 auto; } .articlewave-author-image .avatar { width: 56px; height: 56px; border-radius: 10px; display: block; } .articlewave-author-info { display: block; width: auto; flex: 1 1 auto; min-width: 0; } .articlewave-author-info h3 { margin: 0 0 4px; font-size: 16px; } .articlewave-author-container .author-description { font-size: 13.5px; line-height: 1.55; color: #55595c; margin-bottom: 6px; } .articlewave-author-box-cta { display: inline-block; font-size: 13px; font-weight: 700; } /* ========================================================================= Comment form (#respond / #commentform, output by core's comment_form()) Same compact/rounded-corners treatment as the comment cards and author box above — no template override needed here, comment_form() itself is left alone, this is styling only. ========================================================================= */ #respond { padding: 16px 18px; margin-top: 16px; border-radius: 14px; } #reply-title { font-size: 17px; margin-bottom: 6px; } /* * "Hasan Ünver olarak oturum açılmış. Profilinizi düzenleyin. Oturum * kapatılsın mı? Gerekli alanlar * ile işaretlenmişlerdir" — core renders * the logged-in-as message and the required-fields note as one run-on * paragraph with no visual break between two unrelated pieces of * information (account status vs. form instructions). The required-fields * part is at least its own already * (core's wp_required_field_message()), reused identically in the * logged-out .comment-notes paragraph — styling that one class here fixes * both cases without needing to override comment_form()'s args just to * split up a string. */ .logged-in-as, .comment-notes { font-size: 13px; color: #767575; margin-bottom: 12px; } .required-field-message { display: block; margin-top: 4px; } #commentform .comment-form-author, #commentform .comment-form-email, #commentform .comment-form-url, #commentform .comment-form-comment { margin-bottom: 10px; } #commentform label { font-size: 13px; font-weight: 700; margin-bottom: 4px; } #commentform input[type="text"], #commentform input[type="email"], #commentform input[type="url"], #commentform textarea#comment { border-radius: 8px; padding: 8px 10px; } #commentform .form-submit { margin-top: 4px; } #commentform .form-submit .submit { border-radius: 8px; padding: 10px 22px; } /* ========================================================================= Responsive post-title typography. The parent theme only reduces .entry-title (used for both the single-post h1 and every h2 title in the blog/archive grid — see content.php) at a single breakpoint, max-width:600px, down to a still-desktop-sized 23px, and leaves widths between 601-768px at the raw h1(36px)/h2(30px) default entirely unreduced. On real phone screens (~360-430px wide, the common case, not just narrow ones) 23px bold Turkish text — which runs longer per word than English — was wrapping at roughly 3 words per line. Also applied to .page-title (category/tag/author archive headers), which the parent never reduces for mobile at all outside of the search page. ========================================================================= */ @media (max-width: 768px) { .articlewave-content-wrapper .entry-header .entry-title, .page-title { font-size: 22px; line-height: 1.35; } } @media (max-width: 600px) { .articlewave-content-wrapper .entry-header .entry-title, .page-title { font-size: 20px; } } @media (max-width: 400px) { .articlewave-content-wrapper .entry-header .entry-title, .page-title { font-size: 18px; } } /* ========================================================================= Category archive hero (category.php + category-hero.php partial) Full-bleed image with the category name and description centered over it. ========================================================================= */ .articlewave-category-hero { position: relative; display: flex; align-items: center; justify-content: center; /* Fluid rather than fixed so the same rule covers phone through desktop — no separate breakpoint needed to stop it eating a small screen. */ min-height: clamp( 260px, 34vw, 420px ); padding: 60px 0; overflow: hidden; background-color: var( --cat-color, #3b2d1b ); } .articlewave-category-hero-media { position: absolute; inset: 0; z-index: 0; } .articlewave-category-hero-media img { width: 100%; height: 100%; object-fit: cover; display: block; } /* * Scrim. Photographs vary wildly in brightness and these are chosen by hand * per category, so rather than trusting any single image to be dark enough, * this guarantees white text stays legible over all of them: a dark tint in * the category's own color (so each hero still reads as that category) * layered under a neutral vertical gradient that deepens toward the middle * where the text sits. * * Both layers must stay partly transparent — background-color here is * `color-mix(..., transparent)`, not an opaque color, precisely so the * actual underneath (a separate, lower z-index element, not part of * this pseudo-element's own background stack) still shows through. An * opaque layer here previously hid every hero image completely regardless * of what was uploaded. */ .articlewave-category-hero::after { content: ""; position: absolute; inset: 0; z-index: 1; background-color: color-mix( in srgb, var( --cat-color, #3b2d1b ) 40%, transparent ); background-image: linear-gradient( to bottom, rgba( 0, 0, 0, 0.35 ) 0%, rgba( 0, 0, 0, 0.55 ) 50%, rgba( 0, 0, 0, 0.35 ) 100% ); } /* No image set and no post image to borrow — lean on the category color instead of showing an empty dark box. */ .articlewave-category-hero--no-image::after { background: linear-gradient( 135deg, color-mix( in srgb, var( --cat-color, #3b2d1b ) 85%, black 15% ) 0%, color-mix( in srgb, var( --cat-color, #3b2d1b ) 45%, black 55% ) 100% ); } .articlewave-category-hero .articlewave-container { position: relative; z-index: 2; } .articlewave-category-hero-content { text-align: center; max-width: 780px; margin: 0 auto; } .articlewave-category-hero-title { margin: 0 0 18px; color: #fff; font-weight: 800; line-height: 1.05; letter-spacing: -0.01em; /* px, not rem: this theme sets html { font-size: 62.5% } (style.css:159, an old "10px root" IE-era convention), so 1rem here is 10px, not the usual 16px — a clamp() written in rem silently maxed out at 42.5px instead of the ~76px this was meant to reach. */ font-size: clamp( 32px, 6vw, 76px ); /* Both !important rules beat the migrated Additional CSS above, which blanket-sets `text-transform: none !important` on every h1 to undo the parent theme forcing uppercase on post titles. Here uppercase is the intended look, and it is safe for Turkish: the document is served with lang="tr-TR", so browsers map i → İ rather than i → I. */ text-transform: uppercase !important; color: #fff !important; text-wrap: balance; } .articlewave-category-hero-desc { color: rgba( 255, 255, 255, 0.92 ); /* px, not rem — same 62.5%-root issue as the title above; this was rendering at 9.5–10.6px. */ font-size: clamp( 17px, 1.3vw, 19px ); line-height: 1.65; } .articlewave-category-hero-desc p { margin: 0 0 10px; /* Overrides the site-wide `.entry-content p { color:#000 }` sibling rule's intent for body copy — this text sits on a dark image. */ color: inherit; } .articlewave-category-hero-desc p:last-child { margin-bottom: 0; } @media (max-width: 600px) { .articlewave-category-hero { padding: 44px 0; } .articlewave-category-hero-title { margin-bottom: 12px; } } /* ========================================================================= Author archive header (author.php + author-header.php partial) ========================================================================= */ .articlewave-author-header { background-color: #eff2f7; padding: 30px 0; } .articlewave-author-card { display: flex; align-items: stretch; gap: 24px; } .articlewave-author-card-avatar { flex: 0 0 auto; display: flex; } .articlewave-author-card-avatar .avatar { display: block; width: 120px; height: 120px; border-radius: 16px; object-fit: cover; } .articlewave-author-card-info { flex: 1 1 auto; display: flex; flex-direction: column; justify-content: center; min-width: 0; } .articlewave-author-card-info .page-title { margin: 0 0 4px; } .articlewave-author-card-info .articlewave-post-count { margin-bottom: 8px; } .articlewave-author-card-info .author-description { font-size: 14px; line-height: 1.6; color: #55595c; margin: 0 0 10px; } .articlewave-author-topics { display: flex; flex-wrap: wrap; align-items: center; gap: 8px; } .articlewave-author-topics-label { width: 100%; font-size: 13px; font-weight: 700; } /* * Deliberately no background/border/padding overrides on .post-cat-item or * its here — these reuse the theme's own .articlewave-post-cats-list * pill styling (white text, per-category background color from dynamic-styles.php) * unchanged, so they look identical to category tags anywhere else on the site. * The only addition is a "selected" contour, derived from each pill's own * color via the --cat-color custom property set inline per
. */ .articlewave-author-topics-list .post-cat-item a { display: inline-block; cursor: pointer; /* The parent theme's global `a { transition: all 0.3s ease-in-out; }` (style.css:811) would otherwise also apply to outline, making the selected-state contour feel sluggish. Override with just the properties this pill actually needs, faster. */ transition: outline-color 0.12s ease-out, outline-offset 0.12s ease-out; } .articlewave-author-topics-list .post-cat-item.is-selected a { outline: 3px solid color-mix( in srgb, var( --cat-color, #3b2d1b ) 65%, black 25% ); outline-offset: 2px; } .articlewave-author-topics-clear { font-size: 13px; text-decoration: underline; } /* * Dark mode: darken the whole card instead of forcing its text back to * light-mode colors. * * Background history: this card's #eff2f7 was originally left unchanged in * both modes, on the reasoning that a light card is not itself a contrast * bug. That was wrong in practice — the parent theme's dark-mode CSS * forcibly whitens `body`, every heading (h1-h6) and every link (a) * sitewide (parent style.css:3998-4056), and most of this card's text has * no color of its own, so it all went white while the card stayed light * grey. A first fix pinned that text back to its light-mode colors; that * was replaced with darkening the card instead, since a light-grey slab on * a #000 page reads as a leftover from the light theme no matter how * legible its text is — first attempt used #1c1c1c, the parent's own * standard "raised surface" color for dark mode (post cards, #respond, the * nav dropdown; same selector list at parent style.css:4056-4092). * * #1c1c1c wasn't distinct enough against the page in practice and reads to * the eye as no different from the surrounding black. Worth understanding * why rather than just picking a bigger number: light mode's card * (#eff2f7 against a #fff page) sits at a WCAG contrast ratio of only * ~1.12 — genuinely very subtle in the abstract too — but human contrast * perception compresses hard near black (the same numeric gap reads as * far less distinct close to 0 than close to 255, on top of typical * monitor black-level crush), so a mathematically "equivalent" dark grey * would actually look *less* distinct than #eff2f7 does, not equally * subtle. #1c1c1c already sits at ~1.23 against pure black — nominally * *more* separation than light mode's own card — and still wasn't enough. * * Settled on #2a2a2a instead: not a new value invented for this — it's * already this child theme's own dark-mode fill for the search input * (style.css section 14), reused here rather than adding a third dark * surface tone to the file. ~1.46 contrast against pure black, clearly * closer to how #eff2f7-on-white actually *reads*, even though it's * numerically a bigger gap than the light-mode pairing. * * With a dark background, all the inherited-white text is correct as-is * and needs no rules at all. The two exceptions are below: text this child * theme gives an explicit light-mode grey to, which would otherwise stay * dark-on-dark. The category pills need nothing either way — each carries * its own per-category background from the Customizer, independent of mode. */ .site-mode--dark .articlewave-author-header { background-color: #2a2a2a; } .site-mode--dark .articlewave-author-card-info .author-description { color: #c9cdd1; } .site-mode--dark .articlewave-author-card-info .articlewave-post-count { color: #c9cdd1; } @media (max-width: 767px) { .articlewave-author-card { flex-direction: column; align-items: flex-start; } .articlewave-author-card-avatar .avatar { width: 90px; height: 90px; } } /* ========================================================================= Homepage carousel (template-parts/partials/banner/slider.php) The category pill now sits where the removed "Read More" link used to be (see the docblock in slider.php), alongside the reading-time estimate. ========================================================================= */ .articlewave-read-more-est-time { display: flex; align-items: center; justify-content: space-between; flex-wrap: wrap; gap: 8px; /* A bit more separation from the date/author line above it — this context has no margin between .slider-post-meta-wrap and this row otherwise (unlike the archive grid's version of this same class, which gets a border-top + padding the carousel never inherits). */ margin-top: 10px; } .articlewave-read-more-est-time .articlewave-post-cats-list { margin: 0; } /* * No font-size override here (deliberately) — `.articlewave-post-cats-list * li a` (parent's style.css) sets padding/radius/weight but no size of its * own, so it inherits whatever's ambient, same as the pills in the archive * grid cards. An earlier version of this rule capped it at 13px, smaller * than the grid's pills; removed so this one matches them exactly rather * than needing to track their size as a separate hardcoded number. */ .articlewave-read-more-est-time .post-min-read { float: none; } /* ========================================================================= Homepage "Trend Yazılar" list (template-parts/partials/banner/tab.php) Reuses .tabbed-section-wrapper for the parent's existing 30%-width/float column rules — only the internal layout is new, sized to match the carousel's fixed 662px height (.slider-single-post-wrap in the parent theme) so the two columns line up at desktop widths. ========================================================================= */ .articlewave-trending-wrapper { height: 662px; display: flex; flex-direction: column; } .articlewave-trending-label { flex: 0 0 auto; display: flex; align-items: center; gap: 6px; margin: 0 0 14px; font-size: 12px; font-weight: 700; letter-spacing: 0.04em; text-transform: uppercase; color: #767575; } .articlewave-trending-posts { flex: 1 1 auto; display: flex; flex-direction: column; gap: 14px; min-height: 0; } .articlewave-trending-posts .tabbed-single-post-wrap { flex: 1 1 0; min-height: 0; /* .tabbed-post-content-wrap is a sibling of .tabbed-post-thumb, absolutely positioned against *this* element (not clipped by the thumb's own overflow:hidden) — the parent theme never set overflow:hidden here either, so oversized text could spill past the card's bottom edge into the next one. This is the actual guarantee against that, independent of whatever font size is chosen below. */ overflow: hidden; } .articlewave-trending-posts .tabbed-post-thumb { height: 100%; margin-bottom: 0; } /* * The parent theme's .tabbed-post-content-wrap (padding, category pill size) * and its bare `h3 { font-size: 26px }` (style.css:721, with unreset default * browser margins) were sized for the original 287px-tall cards, which * overflowed once these cards shrank to fit 3-in-662px. The clip above * means text can no longer spill into the next card regardless of size, so * this can size the title generously rather than as small as possible — * the 2-line clamp (the same -webkit-line-clamp technique the theme already * uses for its other compact card titles, e.g. * .articlewave-post-title-prefix-wrapper .related-post-content-wrap h4) * is what actually keeps a long title in check. */ .articlewave-trending-posts .tabbed-post-content-wrap { padding: 14px 18px; } .articlewave-trending-posts .tabbed-post-content-wrap h3 { margin: 4px 0 0; font-size: 16px; line-height: 1.3; display: -webkit-box; -webkit-line-clamp: 2; -webkit-box-orient: vertical; overflow: hidden; } .articlewave-trending-posts .articlewave-post-cats-list li a { padding: 4px 10px; font-size: 12px; } /* Below this width the parent theme already stacks the carousel and this column full-width instead of side by side (see articlewave-responsive.css) — height-matching them no longer applies, so let this list size naturally. `margin-top` is added here too — the parent's own responsive.css switches `.tabbed-section-wrapper` (this block's other class) from `float:right; width:30%` to `width:100%` at this same breakpoint, but never gives it any top spacing once it wraps below the now-full-width carousel, so "Trend Yazılar" landed touching the carousel's bottom edge with no gap at all on every vertical tablet width — not "some": there's no width inside this range where a gap existed to begin with. 40px matches `.banner-tabbed-section-wrapper { margin: 40px 0px }` (parent, style.css) — the section's own established vertical rhythm at desktop — rather than inventing a new spacing value for this one edge. */ @media only screen and (max-width: 1025px) { .articlewave-trending-wrapper { height: auto; margin-top: 40px; } .articlewave-trending-posts { flex-direction: row; flex-wrap: wrap; } .articlewave-trending-posts .tabbed-single-post-wrap { flex: 1 1 calc( 33.333% - 10px ); } .articlewave-trending-posts .tabbed-post-thumb { height: 220px; } } @media (max-width: 600px) { .articlewave-trending-posts { flex-direction: column; } .articlewave-trending-posts .tabbed-single-post-wrap { flex: 1 1 auto; } } /* ========================================================================= Related Posts (template-parts/partials/innerpage/relatedpost.php) Same overlay-card design as the homepage's "Trend Yazılar" widget above — category pill + title floated over the bottom of the image on a dark gradient, rounded corners — reusing .related-post-thumb/.related-post- content-wrap as siblings inside a position:relative wrap exactly the way .tabbed-post-thumb/.tabbed-post-content-wrap already do for trending. Sized to this section's own existing 3-column/275px-tall thumbnail proportions rather than the trending widget's narrower sidebar-column sizing — the two sit in very differently-shaped spaces on the page. ========================================================================= */ /* The "separate" site layout previously wrapped the whole section in one big shared white card (padding, shadow, radius) with the 3 posts as plain unstyled columns inside it. The trending widget has no such outer card — each post is its own self-contained image+overlay sitting directly on the page — so this strips that back to just spacing, matching that minimal container style. */ .articlewave-site-layout--separate .related-posts { padding: 0; background-color: transparent; border-radius: 0; box-shadow: none; } .related-posts h2 { font-size: 20px; margin: 0 0 16px; } .related-post-wrap { position: relative; } .related-post-wrap figure.related-post-image { height: 275px; margin: 0; border-radius: 14px; overflow: hidden; } .related-post-content-wrap { position: absolute; left: 0; bottom: 0; width: 100%; z-index: 1; padding: 14px 18px; border-radius: 0 0 14px 14px; background: linear-gradient( to bottom, rgba( 0, 0, 0, 0 ) 0%, rgba( 0, 0, 0, 0.85 ) 100% ); } .related-post-wrap .related-post-content-wrap h3 { margin: 4px 0 0; font-size: 16px; line-height: 1.3; display: -webkit-box; -webkit-line-clamp: 2; -webkit-box-orient: vertical; overflow: hidden; } .related-post-wrap .related-post-content-wrap h3 a { color: #fff; } .related-post-wrap .articlewave-post-cats-list li a { padding: 4px 10px; font-size: 12px; margin-bottom: 0; } /* A post with no featured image has nothing for the overlay to sit on top of — falls back to a plain, non-overlaid card instead of collapsing. None of this site's posts currently lack a thumbnail, but the parent theme's own trending/tabbed cards have this same gap, so this is cheap insurance rather than a fix for something actually hit today. */ .related-post-wrap.no-img-post { background-color: #f4f4f4; border-radius: 14px; min-height: 100px; } .related-post-wrap.no-img-post .related-post-content-wrap { position: static; background: none; padding: 14px 18px; } .related-post-wrap.no-img-post .related-post-content-wrap h3 a { color: #000; } /* ========================================================================= MOBILE-ONLY LAYOUT PASS (sections 1-9) Every rule in sections 1 through 9 is inside a max-width media query and must stay that way — the desktop layout is unchanged by those sections. Sections 10 and 11 are deliberately NOT mobile-scoped; each says why. Cascade note that applies to this whole section: the parent theme's assets/css/articlewave-responsive.css is enqueued AFTER this stylesheet (inc/template-functions.php), and it is where nearly all of the rules being corrected here live. So a selector that merely *ties* on specificity loses. Every override below therefore either out-specifies the parent's selector or uses !important, and says which in a comment where it isn't obvious. Worth knowing: this child style.css is actually enqueued twice — once as 'articlewave-child-style' by this theme's functions.php, and again as 'articlewave-style' by the parent, because the parent registers get_stylesheet_uri() which resolves to the *child's* stylesheet when a child theme is active. Both copies still land before responsive.css, so the rule above holds either way. ========================================================================= */ /* ------------------------------------------------------------------------- 0. Header/top-bar: hamburger nav extended through tablet-portrait widths Root cause of "top-bar displaying problems" reported on several tablet- portrait resolutions (confirmed broken at 800x1280, 800x1180, 834x1210; confirmed fine at 713x1138): the parent theme's own switch from the inline desktop nav row to the "Menü" hamburger dropdown happens at a single breakpoint, `max-width:768px` (assets/css/articlewave- responsive.css). 713px falls at/below that cutoff, so it already got the compact layout — 800px and 834px don't, so they got the *desktop* row forced into a container far too narrow for it. That desktop row has more in it than the breakpoint was sized for: 4 top-level nav items (Kategoriler, Manifestomuz, İletişim, and the notably long "Bize Destek Olmak İçin" — confirmed via the actual rendered menu markup), plus the social icons and search icon sharing the same row. Nothing in the parent theme addresses this gap either — its next breakpoints above 768px are `min-width:1000px/max-width:1019px` and `min-width:1026px/max-width:1100px`, and both only tweak minor spacing (nav item gap, padding), never switch layouts. So every width from 769px up to just under 1000px — which covers most tablets held vertically, since a device's CSS width in portrait is its *shorter* physical dimension — got zero help from either theme and just rendered whatever the unconstrained desktop row computed to. Fix: extend the exact same hamburger-dropdown pattern up through 1024px — the width of the largest mainstream tablet in portrait (iPad Pro 12.9"), and the same general "tablet and below" cutoff already established elsewhere in this file (section 17). Two parts: - This block mirrors the specific subset of the parent's own `max-width:768px` rules that actually implement the pattern (menu- toggle visibility, primary-menu-wrap positioning, list display mode, sub-menu behaviour, and the header row's own spacing) into the newly covered 769-1024px range. It's a mirror, not a rewrite, because the switch itself is defined in a parent-theme file this project doesn't edit (see "Deployment workflow" in CLAUDE.md) — only the rules actually needed to reproduce the pattern are included here, not the parent's entire breakpoint (which also touches unrelated things — footer widget columns, the homepage carousel arrows, main-content width — none of which were part of the reported problem). - Sections 1, 3, 4 and 9 below, which already style *this exact* pattern for phone widths, have their own `max-width:768px` widened to `max-width:1024px` to match — otherwise the pattern would newly activate at these tablet widths but look unstyled (square corners, off-centre label, wrong icon size) rather than matching 713px exactly, as asked. ------------------------------------------------------------------------- */ @media (min-width: 769px) and (max-width: 1024px) { .articlewave-menu-toogle { display: block; cursor: pointer; background: none; border-color: #fff; color: #000; padding: 10px; width: 100%; position: relative; font-size: 17px; } .site-mode--dark .articlewave-menu-toogle { color: #fff; border: none; } #site-navigation .primary-menu-wrap { position: absolute; top: 100%; background: #fff; left: 0; display: none; } .site-mode--dark #site-navigation .primary-menu-wrap { background: #1c1c1c; } .site-mode--dark #site-navigation ul li a { border-radius: 0; } #site-navigation ul, #site-navigation #primary-menu { display: block; } #site-navigation ul li { margin: 0; } #site-navigation ul li.menu-item-has-children > a::before, #site-navigation ul li.page_item_has_children > a::before { display: none; } #site-navigation ul li:hover > a, #site-navigation ul li.current-menu-item > a, #site-navigation ul li.current_page_item > a, #site-navigation ul li.current-menu-ancestor > a, #site-navigation ul li.focus > a { border-radius: 0; } #site-navigation ul li a { padding: 0 15px !important; border-bottom: 1px solid #e1e1e1; border-radius: 0px; } #site-navigation ul li a.articlewave-sub-toggle, #site-navigation ul.sub-menu li a.articlewave-sub-toggle, #site-navigation ul.children li a.articlewave-sub-toggle { display: block; position: absolute; right: 15px; top: 7px; background: #212121; color: #fff; width: 28px; height: 28px; text-align: center; line-height: 28px; padding: 0 !important; } #site-navigation ul.sub-menu, #site-navigation ul.children { position: static; float: none; opacity: 1; visibility: visible; transform: none; line-height: 42px; box-shadow: none; display: none; width: 100%; } #site-navigation ul.sub-menu li a, #site-navigation ul.children li a { line-height: 42px; width: auto; } #site-navigation .sub-menu li > a::after { display: none; } /* Header row spacing/positioning — same source breakpoint in the parent, needed alongside the nav-switching rules above so the row actually has room for the now-block-level "Menü" button and doesn't keep the taller desktop row height around it. */ .header-layout-one { background-color: #fff; position: relative; height: 100%; } .site-mode--dark .header-layout-one { background-color: #1c1c1c; } .is-sticky .site-header { height: inherit !important; } .site-header .sticky-wrapper .articlewave-container { padding: 0px 20px; } .has-site-info .site-branding { padding: 0px; } .site-branding { position: static; transform: translate( 0 ); } .site-header { height: 100% !important; } .header-layout-wrapper { padding: 10px 0px 10px; } #sticky-wrapper { height: auto !important; } } /* ------------------------------------------------------------------------- 1. Top-bar social icons (mobile, and now tablet-portrait — see section 0) Smaller and tighter than the same icons elsewhere on the site. The existing rules further up this file size *every* instance of .articlewave-social-icons-wrapper together (top bar, footer, and the single-post nav card) at 18px/14px on mobile; scoping to .site-header here — 3 classes vs. their 2, both !important — peels the top-bar copy away from that without touching the footer or post-nav ones. ------------------------------------------------------------------------- */ @media (max-width: 1024px) { .site-header .articlewave-social-icons-wrapper .single-icon-wrap { font-size: 15px !important; margin-left: 8px !important; } /* The row reads as one tight group rather than being nudged in from whatever sits to its left. */ .site-header .articlewave-social-icons-wrapper .single-icon-wrap:first-child { margin-left: 0 !important; } /* Both the shared child rule (2px) and responsive.css (4px at this breakpoint) pad each glyph; at this size that padding is most of the perceived gap, so it goes. */ .site-header .articlewave-social-icons-wrapper .single-icon-wrap i { padding: 0 !important; } } @media (max-width: 400px) { .site-header .articlewave-social-icons-wrapper .single-icon-wrap { font-size: 14px !important; margin-left: 6px !important; } } /* ------------------------------------------------------------------------- 2. Floating bottom-right controls (mobile, and now tablet-portrait — see section 0): scroll-to-top, and the dark/light switcher moved out of the top bar to sit beneath it. The switcher's markup (template-parts/partials/header/sitemode-search.php) stays where it is in the header — position:fixed just lifts it out of that flow on small screens, so no template override is needed and the desktop header is untouched. The header row simply closes up around it. Stacking order, measured from the bottom edge: the switcher occupies 20-64px and the scroll-up button 76-120px, so the switcher sits under the scroll-up button with a 12px gap, as asked. Widened from max-width:768px to max-width:1024px alongside section 0: without this, the switcher would stay in-flow at 769-1024px with no `order` assigned in section 9's flex-wrap row, landing it before the social icons instead of being pulled out of the row entirely — visibly different from how 713px (and every other phone width) renders it. ------------------------------------------------------------------------- */ @media (max-width: 1024px) { .articlewave-scrollup { right: 16px; bottom: 76px; width: 44px; height: 44px; line-height: 50px; font-size: 26px; /* The parent sets no z-index at all on this fixed element, leaving it to win only by document order. Made explicit so neither the sticky header (z-index 999) nor anything a plugin injects can bury it. */ z-index: 9990; } #articlewave-site-mode-wrap { position: fixed; right: 16px; bottom: 20px; z-index: 9990; margin: 0; } /* Matches the scroll-up button's footprint so the two read as one stack. responsive.css shrinks this to 30px at =<600px, hence !important. */ #articlewave-site-mode-wrap a { width: 44px !important; height: 44px !important; /* The parent's default shadow is a soft 35px bloom meant for a button sitting on the white header bar; over arbitrary page content it disappears. Tightened so the circle keeps an edge against text and images alike. */ box-shadow: 0 2px 10px rgba( 0, 0, 0, 0.25 ); } } /* * Why the scroll-to-top button was missing on posts but present on the * homepage. * * It is not conditional markup and not a CSS gap: the rendered HTML for the * button is byte-identical on both, it sits outside #page as a direct child * of in both, and both pages load exactly the same stylesheets and * scripts. What differs is that single posts overflow horizontally on mobile * — the three bugs fixed in sections 5, 6 and 7 below (the "Sonraki" card, * the author box, and the related-posts grid) each push content past the * right edge of the viewport, and the homepage has none of them. * * Horizontal overflow widens the *layout* viewport beyond the visual one on * mobile browsers, and position:fixed resolves against the layout viewport. * So `right: 20px` positioned the button 20px from the right edge of the * widened layout viewport — off-screen, past where the user can see — while * on the non-overflowing homepage it landed where expected. * * Fixing those three overflows is the actual repair. This is the guard that * keeps a *future* overflow from silently doing the same thing again. * * It goes on #content specifically, not and not #page. All three * overflow sources live inside #content, while neither fixed button does: * .articlewave-scrollup is a sibling of #page entirely (footer.php prints it * after the closing
), and #articlewave-site-mode-wrap sits in the * header, inside #page but before #content opens. Keeping both of them * outside the clipping element sidesteps the question of whether * `overflow: clip` clips fixed-position descendants — browsers agree that * `hidden` does not, but `clip` is newer and less uniformly implemented, and * a guard that could hide the very button it exists to protect would be * worse than no guard. `clip` rather than `hidden` so no scroll container is * created and position:sticky elsewhere keeps working. * * #content is printed exactly once per page by every template that renders * one (single, archive, category, author, search, 404, index), so this * covers the whole front end. */ @media (max-width: 768px) { #content { overflow-x: clip; } } /* ------------------------------------------------------------------------- 3. "Menü" button (mobile) The icon beside the label is dropped, and the label is brought in line with post titles. The font mismatch was real and had a specific cause: the Customizer's generated typography CSS sets `body { font-family: Raleway }` and `h1,h2,h3,h4,h5,h6 { font-family: Raleway }`, but the parent's base rule `body, button, input, select, textarea { font-family: "Roboto", sans-serif }` also names `button` — which the Customizer rule does not — so this one control kept rendering in Roboto 400 while the rest of the site was Raleway. `font-family: inherit` hands it back the inherited Raleway. Sizes track the responsive post-title scale defined further up this file (22/20/18px) so the two genuinely match at every breakpoint. Selector is id-scoped because responsive.css sets font-size: 17px on the bare class. ------------------------------------------------------------------------- */ @media (max-width: 1024px) { /* The icon beside the label was hidden outright at first; it's back at a smaller size now — see section 9, which owns its styling. */ #site-navigation .articlewave-menu-toogle { font-family: inherit; font-weight: 700; font-size: 22px; line-height: 1.35; } } @media (max-width: 600px) { #site-navigation .articlewave-menu-toogle { font-size: 20px; } } @media (max-width: 400px) { #site-navigation .articlewave-menu-toogle { font-size: 18px; } } /* ------------------------------------------------------------------------- 4. Menu dropdown panel (mobile) Rounder corners; the accent-blue submenu expander is emitted from functions.php instead (articlewave_child_accent_color_css) so it follows the Customizer color, and the animation speed-up lives in assets/js/mobile-nav.js since both durations are hardcoded in the parent's JS, not in CSS. ------------------------------------------------------------------------- */ @media (max-width: 1024px) { #site-navigation .primary-menu-wrap { border-radius: 14px; /* Clips the square-cornered backgrounds and the last item's border to the rounded shape. Safe alongside slideToggle: jQuery sets overflow:hidden inline for the duration of the animation and restores the *inline* value afterwards, which leaves this stylesheet declaration in force throughout. */ overflow: hidden; box-shadow: 0 8px 24px rgba( 0, 0, 0, 0.12 ); } /* (The last menu item's divider is cleared in section 9, alongside the equivalent rules for submenu items.) */ /* Rounds the expander square to match the panel. Colour comes from functions.php — keep the two in sync if either moves. */ #site-navigation ul li a.articlewave-sub-toggle { border-radius: 8px; } } /* ------------------------------------------------------------------------- 5. Post body: everything that isn't a
(mobile) The existing mobile rule near the top of this file only shrinks `.entry-content p`, because at the time that was the only thing carrying an editor-set inline font-size. It isn't: a scan of every published post and page turns up inline font-size on `li` (19px/18px), `ul`, `ol`, `figure` and `h2` as well, and the "Notlar" footnotes block renders as `
` — the size comes from the block's own typography attribute, so it lands inline on the
and every
inherits it. That is why those sections stayed at desktop size while the body copy shrank. Inline styles beat ordinary selectors, so !important is unavoidable here, and the media query keeps the editor-chosen desktop sizes untouched — same reasoning as the original `.entry-content p` rule. Sizes are set per role rather than all flattened to one number: running text (lists) matches body copy at 16px, while genuinely secondary material — footnotes, image captions — sits a step below it, and headings a step above. ------------------------------------------------------------------------- */ @media (max-width: 600px) { /* Running text in lists: same size as body paragraphs. */ .entry-content ul, .entry-content ol, .entry-content li, .entry-content dd, .entry-content dt { font-size: 16px !important; line-height: 1.7 !important; } /* * "Notlar". Two classes beats the `.entry-content ol` / `.entry-content li` * rules above (one class + one element each), so the footnote list keeps * its smaller size instead of being flattened to 16px with everything * else. The
selector is required as well as the
one: without * it the generic `.entry-content li` rule would set the items directly * and inheritance from the
would never come into play. */ .entry-content .wp-block-footnotes, .entry-content .wp-block-footnotes li { font-size: 14px !important; line-height: 1.6 !important; } .entry-content figcaption, .entry-content .wp-element-caption { font-size: 13px !important; line-height: 1.5 !important; } /* responsive.css puts .wp-block-heading at 25px here, which towered over 16px body copy. .widget-title shares that parent rule and is deliberately left alone — this is scoped to post content only. */ .entry-content h2, .entry-content .wp-block-heading { font-size: 20px !important; line-height: 1.35 !important; } .entry-content h3 { font-size: 18px !important; line-height: 1.4 !important; } .entry-content blockquote, .entry-content blockquote p { font-size: 16px !important; line-height: 1.6 !important; } } @media (max-width: 400px) { .entry-content ul, .entry-content ol, .entry-content li, .entry-content dd, .entry-content dt { font-size: 15px !important; } .entry-content .wp-block-footnotes, .entry-content .wp-block-footnotes li { font-size: 13px !important; } .entry-content h2, .entry-content .wp-block-heading { font-size: 18px !important; } } /* ------------------------------------------------------------------------- 6. Post navigation — the "Sonraki: {title}" card (mobile) The parent sizes this card for exactly one line of text: height 46px with overflow:hidden, and `white-space: nowrap` + ellipsis on the link inside (style.css 1177 / 3574). A Turkish post title is almost never one line at phone width, so the second line was being clipped off by the fixed height — the box rendered, its contents didn't. Fixed by letting the card grow instead: auto height with a 46px floor (so short titles keep the original proportions), wrapping re-enabled, and the two cards stacked rather than floated side by side. float/width/max-width/margin need !important because responsive.css re-declares them at =<600px with equal or greater specificity; the flex container needs the extra .post-navigation class to out-specify its `display: inline-block` on .nav-links. ------------------------------------------------------------------------- */ @media (max-width: 768px) { .articlewave-content-wrapper .post-navigation .nav-links { display: flex; flex-direction: column; gap: 10px; } .articlewave-content-wrapper .nav-links .nav-previous, .articlewave-content-wrapper .nav-links .nav-next { float: none !important; width: 100% !important; max-width: 100% !important; margin: 0 !important; height: auto; min-height: 46px; line-height: 1.45; /* The parent's `line-break: anywhere` was there to make a nowrap line break at the clip edge; with real wrapping it just produces ugly mid-word breaks. */ line-break: auto; overflow: visible; box-sizing: border-box; } .articlewave-content-wrapper .nav-links .nav-next a { white-space: normal; overflow: visible; text-overflow: clip; /* Only kicks in for a single unbroken token longer than the card — normal words still break at spaces. */ overflow-wrap: anywhere; } } /* ------------------------------------------------------------------------- 7. Post-bottom author box (mobile) responsive.css includes `.articlewave-author-image` in a grouped `width: 100% !important` rule at =<600px. That was written for the parent's own stacked author layout, but this child theme lays the box out as a flex row (avatar + text side by side, see the section further up this file), so a 100%-wide avatar column consumed the entire row and squeezed .articlewave-author-info to zero width — its text then spilled out of the card. Restoring the intended width is the whole fix; the row layout is otherwise fine on mobile. ------------------------------------------------------------------------- */ @media (max-width: 600px) { /* !important purely to cancel the parent's !important above. */ .articlewave-author-container .articlewave-author-image { width: auto !important; } .articlewave-author-container .articlewave-author-info { width: auto !important; /* Without this a flex item refuses to shrink below its longest word, which is the other half of how text escaped this box. */ min-width: 0; /* responsive.css sets a flat 28px line-height, far too airy for the 13.5px description this child theme uses. */ line-height: 1.55; overflow-wrap: anywhere; } } /* ------------------------------------------------------------------------- 8. Related posts — "İlginizi çekebilir" (mobile) Three separate parent rules combined to break this at =<600px: - responsive.css forces .related-post-wrap to `width: 100% !important`, but the cards keep their desktop `display: inline-block`, `margin-left: 3%` and `margin-right: -4px` (style.css 3680), so each card was 103% of the row and overflowed it — the single biggest contributor to the horizontal overflow described in section 2. - `.articlewave-site-layout--separate .related-post-wrap` zeroes margin-bottom, so once stacked the cards touched with no gap at all, and since each card's caption is absolutely positioned over the bottom of its own image, consecutive cards read as overlapping. - responsive.css switches .articlewave-post-cats-list to `display: block` at =<1025px, stacking the category pills vertically and inflating that bottom-anchored caption upward over the image. Replaced with a plain one-column grid, which makes the widths, gaps and stray negative margins all moot at once. ------------------------------------------------------------------------- */ @media (max-width: 600px) { .articlewave-related-posts-wrapper { display: grid; grid-template-columns: 1fr; gap: 16px; /* Cancels the desktop gutter hack that pairs with each card's 3% left margin. */ margin-left: 0; } .articlewave-site-layout--separate .related-post-wrap, .related-post-wrap { display: block; width: 100% !important; /* Covers margin-left: 3%, margin-right: -4px and the zeroed margin-bottom in one go; the grid owns spacing now. */ margin: 0 !important; } /* Full-bleed at phone width, so the desktop column's 275px would be nearly square. */ .related-post-wrap figure.related-post-image { height: 200px; } /* Puts the pills back on one wrapping row (2 classes beats the parent's 1-class display:block), keeping the caption overlay short. */ .related-post-wrap .articlewave-post-cats-list { display: flex; flex-wrap: wrap; gap: 6px; } .related-post-wrap .post-cat-item { padding-top: 0; } } /* ------------------------------------------------------------------------- 9. Mobile header row + "Menü" dropdown: centering, rounding, continuity 9a. WHY THE MENU WENT OFF-CENTRE The header's second row is a flex row: [social icons][#site-navigation] [site-mode switcher][search]. #site-navigation carries width:100% but is a shrinkable flex item, so in practice it just occupies whatever is left between the two side groups — and the "Menü" button (width:100%, label centred by the browser's default button text-align) is therefore centred within *that leftover box*, not within the viewport. As long as the two side groups have different widths the label sits off-centre, and section 2 widened that mismatch by pulling the site-mode switcher out of the row entirely, leaving ~110px of social icons on the left against a lone ~30px search icon on the right. Rather than chase a balance between the two side groups, the nav is given its own full-width row below them. That centres the label against the viewport for good, and — because the button now spans the same width as the panel beneath it — is also what makes 9c's continuous look possible. `order` is required: without it the nav's 100% flex-basis would push the search icon onto a third line, since flex fills lines in document order. 9b. WHY THE DROPDOWN ITEMS WERE LEFT-ALIGNED Pre-existing parent behaviour rather than a regression, though it reads as one next to the newly centred button. The base rule `#site-navigation ul, #site-navigation #primary-menu` centres items with `justify-content: center`, but responsive.css switches those same elements to `display: block` at =<768px, which makes justify-content inert (and section 0 above now switches them the same way again at 769-1024px, for the same reason). The links themselves are still `display: flex` (base style.css), so they fall back to flex-start. Re-centring is a matter of giving the link — not the list — its own justify-content. 9d. This entire block now also covers 769-1024px, not just phones — see section 0 for why the hamburger pattern itself needed extending to that range before any of the styling below had a "Menü" button/dropdown to apply to in the first place. ------------------------------------------------------------------------- */ @media (max-width: 1024px) { .header-layout-wrapper .articlewave-container.articlewave-flex { flex-wrap: wrap; /* Social icons stay left, search stays right, as they are today. */ justify-content: space-between; row-gap: 8px; } .header-layout-wrapper .articlewave-social-icons-wrapper { order: 1; } .header-layout-wrapper .header-search-wrapper { order: 2; } #site-navigation { order: 3; flex: 1 1 100%; width: 100%; /* * Makes this the containing block for .primary-menu-wrap, which * responsive.css positions with `position:absolute; top:100%; left:0`. * Without it the nearest positioned ancestor is .site-header, so the * panel spanned the whole header (wider than, and offset from, the * button) — fine when the two were unrelated boxes, but 9c needs them * to share an edge exactly. */ position: relative; } /* Centre the label; the icon rides along with it. */ #site-navigation .articlewave-menu-toogle { display: flex; align-items: center; justify-content: center; gap: 6px; } /* * 9c. Small icon beside "Menü". * Section 3 hid this outright; it's back, at roughly half the parent's * 22px so it reads as a marker next to the label rather than competing * with it. It's the parent's own from header.php — * restyled, not re-added, so no template override is needed. */ #site-navigation .articlewave-menu-toogle i { display: inline-block; font-size: 15px; line-height: 1; vertical-align: middle; } /* -------- rounding + continuity: Menü button <-> dropdown panel -------- */ /* Closed: a self-contained rounded control. */ #site-navigation .articlewave-menu-toogle { border-radius: 14px; transition: border-radius 0.12s ease-out; } /* * Open: the button's bottom corners square off and the panel's top * corners do the same, so button + panel render as one continuous * rounded rectangle instead of two stacked boxes with a seam between * them. Driven by aria-expanded, which assets/js/mobile-nav.js keeps in * sync (the parent theme declares the attribute but never updates it) — * no extra state class needed for this one. */ #site-navigation .articlewave-menu-toogle[aria-expanded="true"] { border-radius: 14px 14px 0 0; /* Matches the panel so the join is invisible; the panel is #fff here and #1c1c1c in dark mode (responsive.css). */ background-color: #fff; } .site-mode--dark #site-navigation .articlewave-menu-toogle[aria-expanded="true"] { background-color: #1c1c1c; } #site-navigation .primary-menu-wrap { /* Section 4 rounded all four corners; only the bottom pair should be round now that the button caps the top. */ border-radius: 0 0 14px 14px; } /* -------- centring + continuity: menu items -------- */ #site-navigation ul li a { justify-content: center; text-align: center; } /* * The submenu expander is absolutely positioned at right:15px, so it sits * clear of the centred label and doesn't need to be accounted for in the * centring above. Left here as a reminder that widening it would. */ /* * "Kategoriler" joined to its own submenu. The divider below the parent * item is what made the two look like separate stacked blocks; dropping * it while the submenu is open lets them read as one run. The state class * comes from mobile-nav.js — see the comment there for why a pure * selector can't express this. */ #site-navigation ul li.is-submenu-open > a { border-bottom-color: transparent; } /* * Nested items sit on a slightly inset surface so the hierarchy is still * legible without a hard rule between parent and child. rgba rather than * a flat colour so the same declaration works over both the light and * dark panel backgrounds. */ #site-navigation ul.sub-menu, #site-navigation ul.children { background-color: rgba( 0, 0, 0, 0.035 ); border-radius: 0; } .site-mode--dark #site-navigation ul.sub-menu, .site-mode--dark #site-navigation ul.children { background-color: rgba( 255, 255, 255, 0.05 ); } /* The panel's own rounded bottom edge is the last thing on screen; a square-cornered divider on the final item would cut across it. */ #site-navigation .primary-menu-wrap > ul > li:last-child > a, #site-navigation ul.sub-menu li:last-child > a, #site-navigation ul.children li:last-child > a { border-bottom: none; } #site-navigation ul.sub-menu li:last-child, #site-navigation ul.children li:last-child { border-bottom: none; } } /* ------------------------------------------------------------------------- 10. Desktop "Kategoriler" submenu: rounder, and joined to its parent item NOT inside a media query, by request — the rounding was asked for on both PC and mobile. In practice the rules below only take effect at desktop widths anyway: responsive.css re-declares this submenu at =<768px as a static, full-width, inline block (no absolute positioning, no shadow), and section 9 above owns its mobile appearance. The parent theme gives the hovered top-level item a fully round 30px pill (`#site-navigation ul li:hover>a`) and drops a square-cornered white panel directly beneath it at `top:100%`. The two touch but share no geometry, so they read as a pill with an unrelated box stuck to it. Squaring just the pill's bottom corners while the submenu is open, and rounding only the panel's corners that don't sit under the pill, makes the pair a single rounded envelope — the colour split between the black parent and the white list stays, which is the theme's own design. Only the panel's TOP-LEFT corner is square, not both top corners. The panel (`ul.sub-menu`, width: 200px, style.css:2224 in the parent) is positioned with `left: auto` — its static position, which for a block child of a `position: relative`
(style.css:2186) is flush with that
's own left edge, same as the pill above it. But the pill's width is only as wide as its label ("Kategoriler" renders well under 200px), so the panel extends further right than the pill does. Squaring *both* top corners — the first version of this fix — left the panel's actual top-right corner sitting in empty space with nothing above it, looking like a plain rendering bug (reported against the first item, "Bilim ve Bilim Felsefesi", since it's whatever sits at that top-right position). Only the left corner, which is genuinely flush against the pill's own square bottom-left corner, should stay square; the right corner is a normal exposed corner and rounds like the other three. ------------------------------------------------------------------------- */ #site-navigation ul li.menu-item-has-children:hover > a, #site-navigation ul li.page_item_has_children:hover > a, #site-navigation ul li.menu-item-has-children.focus > a, #site-navigation ul li.page_item_has_children.focus > a { border-radius: 16px 16px 0 0; } #site-navigation ul.sub-menu, #site-navigation ul.children { border-radius: 0 16px 16px 16px; /* Clips each row's own square corners — and the last item's divider — to the rounded shape. Safe here: this submenu has no descendant that escapes its box (the third-level flyout the parent theme supports opens at `right:-100%`, and this menu is only two levels deep). */ overflow: hidden; } #site-navigation ul.sub-menu li:last-child, #site-navigation ul.children li:last-child { border-bottom: none; } /* ------------------------------------------------------------------------- 11. Dark mode: "İlginizi çekebilir" background NOT mobile-scoped, deliberately. The related-posts section already renders with no container card in light mode — see the .related-posts rule further up this file, which strips the parent's padding/shadow/background at every width. Dark mode was the one case still showing one, because `.site-mode--dark.articlewave-site-layout--separate .related-posts` and `.site-mode--dark .related-post-wrap` both repaint it #1c1c1c while the page itself is #000 — a visibly lighter grey slab. Scoping the fix to phones would leave desktop dark mode contradicting the light-mode rule it sits next to, so this matches the existing rule's scope instead. Both selectors restate the parent's own specificity exactly and win on source order: this stylesheet is enqueued after the parent's style.css, where both of those rules live. ------------------------------------------------------------------------- */ .site-mode--dark.articlewave-site-layout--separate .related-posts { background-color: transparent; } .site-mode--dark .related-post-wrap { background-color: transparent; } /* ------------------------------------------------------------------------- 12. Dark mode: comment-form notes and author-box bio text Also not mobile-scoped — same reasoning as section 11, this is a contrast bug that exists at every width. Both pieces of text were set with a plain, mode-agnostic grey earlier in this file (#767575 for .comment-notes/.logged-in-as, #55595c for .author-description) because at the time neither had a dark-mode counterpart to worry about. They do: the comment form's own container (#respond) and the post-bottom author box's container (.articlewave-author-container, inside .articlewave-site-layout--separate) both repaint to #1c1c1c in dark mode via the parent's big `.site-mode--dark ... { background-color: #1c1c1c }` selector list — and dark grey on near-black is low-contrast enough to be hard to read. #fff rather than a softer off-white, to match the parent theme's own established dark-mode convention for equivalent secondary text — its own `body.site-mode--dark, ... { color: #fff }` selector list (style.css:3998) already whitens comparable elements (widget links, meta text, etc.) the same way; picking a different shade here would be one more inconsistent grey among several already-white ones. Only re-declares `color`, not the surrounding rules that set font-size/ line-height/margin earlier in this file — those stay identical in both modes, only the color changes. `.required-field-message` ("Gerekli alanlar * ile işaretlenmişlerdir") needs no rule of its own: it's a plain inline `` inside `.comment-notes`/`.logged-in-as` with no color set anywhere, so it already inherits whichever of the two colors below applies to its parent paragraph. ------------------------------------------------------------------------- */ .site-mode--dark .logged-in-as, .site-mode--dark .comment-notes, .site-mode--dark .articlewave-author-container .author-description { color: #fff; } /* ------------------------------------------------------------------------- 13. Header logo: 50% smaller, with a gap above it Applies at every width (not scoped to mobile) — this request had no viewport qualifier, unlike the mobile-only work above. WHY `zoom` INSTEAD OF A FIXED PIXEL WIDTH: The logo's actual on-screen size isn't pinned down anywhere in the parent theme. The WordPress prints carries real width/height HTML attributes from the uploaded file (currently 184x175 — Appearance > Customize > Site Identity), but the parent's own global `img { width:100%; height:100% }` (style.css:774) applies to it too, and its containing block — .custom-logo-link, `display:inline-block` with no width of its own — is exactly the shrink-to-fit case where a percentage width can't be resolved (the box's own width would depend on the percentage, which depends on the box's width). Per the CSS2.1 spec (10.3.9) browsers treat that percentage as 'auto' when it's unresolvable, so in practice the logo already falls back to rendering at its uploaded file's own intrinsic size — but that fallback isn't something this stylesheet can safely assume holds in every browser or after some future markup change nearby. `zoom: 0.5` sidesteps needing to know or predict that base size at all: it scales whatever the browser has *already* computed the box to be, by exactly half, and — unlike `transform: scale()` — it resizes the actual layout box rather than just repainting it visually smaller, so no leftover empty space is left where the full-size logo used to be. This guarantees "50% smaller than however it currently renders" is true regardless of which sizing rule ends up winning that box. `zoom` was a legacy Chrome/Safari-only property for years; Firefox shipped support in Firefox 126 (May 2024), so as of this pass it's safe to rely on across current evergreen browsers. WHY THE MOBILE 70% RULE IS NEUTRALISED, NOT LEFT ALONE: The parent's assets/css/articlewave-responsive.css separately sets `.site-branding img { width: 70% }` at <=600px. Left in place, that width and this zoom would both apply and compound — the mobile logo would end up at roughly 70% x 50% of baseline (~35%), noticeably smaller than the 50% asked for and inconsistent with every other breakpoint. Reset back to `auto` there so `zoom: 0.5` is the single source of truth for logo size everywhere. `.site-branding .custom-logo` (two classes) is used rather than repeating the parent's own `.site-branding img` selector so this wins on specificity alone — two classes beats one class + one type selector — without needing `!important` or depending on this stylesheet's position relative to the parent's in the cascade. ------------------------------------------------------------------------- */ .site-branding { padding-top: 24px; } .custom-logo { zoom: 0.5; } @media (max-width: 600px) { .site-branding .custom-logo { width: auto; } } /* ------------------------------------------------------------------------- 14. Search box redesign Applies at every width, like section 13 — no viewport qualifier was given for this one either. Blue used throughout below is hardcoded to #0092cb, matching articlewave_primary_theme_color's current Customizer default (functions.php) — the same choice already made for .kaynak-kutusu further up this file, for the same reason: this is a self-contained visual redesign, easier to read as one block of color + geometry together than split against a second, theme_mod-aware copy living in functions.php's articlewave_child_accent_color_css(). If that Customizer color is ever changed, update it here too. WHY :has() INSTEAD OF JS FOR THE OPEN/CLOSED COLOR SWAP: `.search-icon` (the button) and `.search-form-wrap` (the panel, carrying the `.active-search` class the parent's own JS already toggles on every click — see below) are siblings, with the button appearing FIRST in the markup. A sibling combinator can only select elements AFTER the reference selector, so plain CSS has no way to style the earlier button based on the later panel's state. `:has()` reaches back up instead: the whole `.header-search-wrapper` is matched first, conditioned on whether it *contains* an active panel anywhere inside it, and the button is then selected relative to that match. Support has been safe to rely on since this project's zoom-based logo fix (section 13) established the bar — :has() shipped in every evergreen browser earlier than zoom did (Chrome/Edge/Safari since 2023, Firefox since 121, Nov 2023). WHY NO JS FILE FOR THIS SECTION AT ALL: Removing the X button (template-parts/partials/header/sitemode-search.php, overridden in this child theme purely to drop that one ) doesn't break anything to begin with. The parent's assets/js/custom-scripts.js already does `$('.search-icon').click(function(){ $('.search-form-wrap') .toggleClass('active-search') ... })` — a TOGGLE, not just an "open" — so the button already closed the panel again on a second click, same as the X button did via a separate `removeClass`. The X was always a second way to do something the icon already did; jQuery's `.click()` on the now- absent `.search-icon-close` selector is simply a no-op, not an error. THE 2x2 COLOR MATRIX: The button's own light/dark colors are themselves inverses of each other, and each mode's open/closed colors are also inverses of each other — so the four states are just two pairs of swapped values, not four unrelated rules: light, closed: white circle, blue icon (base parent style, recolored) light, open: blue circle, white icon (light's own inverse) dark, closed: blue circle, white icon (light-open's colors, reused) dark, open: white circle, blue icon (light-closed's colors, reused) ------------------------------------------------------------------------- */ /* Circle geometry + light/closed colors (the base, unqualified state). */ .header-search-wrapper .search-icon a { display: flex; align-items: center; justify-content: center; width: 36px; height: 36px; padding: 0; margin: 0; border-radius: 50%; box-shadow: 0 0 35px rgba( 0, 0, 0, 0.13 ); background-color: #fff; color: #0092cb; font-size: 18px; /* Kept in step with the panel's own open/close speed above (0.15s), so the button's color inversion and the panel appearing read as one action rather than two staggered ones. Originally 0.25s, matching the mode-switcher; the panel is the thing being waited on here, so it's the better reference of the two. */ transition: background-color 0.15s ease-out, color 0.15s ease-out; } /* Light, open. */ .header-search-wrapper:has( .search-form-wrap.active-search ) .search-icon a { background-color: #0092cb; color: #fff; } /* Dark, closed. Two separate declarations because the parent's own `.site-mode--dark .header-search-wrapper i { color: #fff }` sets the glyph's color directly, and a direct rule always wins over inheriting from an ancestor's `color` no matter the specificity — recoloring the anchor alone wouldn't reach the icon here the way it does in the light-mode rule above, where no such competing rule exists. `.search-icon i` alone already out-specifies that parent rule (3 classes vs. 2), no !important needed. */ .site-mode--dark .header-search-wrapper .search-icon a { background-color: #0092cb; } .site-mode--dark .header-search-wrapper .search-icon i { color: #fff; } /* Dark, open — the most specific pair, correctly winning over both rules above. */ .site-mode--dark .header-search-wrapper:has( .search-form-wrap.active-search ) .search-icon a { background-color: #fff; } .site-mode--dark .header-search-wrapper:has( .search-form-wrap.active-search ) .search-icon i { color: #0092cb; } /* ---- The dropdown panel: rounder corners, black accents replaced with blue ---- Only the accent details below (the little arrow, the top border, the submit button) are recolored; the panel's own light/dark background stays the site's general page-background convention, not part of the blue/white scheme. In dark mode the one exception is the panel surface itself: the parent paints it pure #000, which made it invisible against the #000 page behind it — swapped for #1c1c1c, the same raised-surface color the parent already uses for every other floating panel in dark mode (post cards, the nav dropdown, #respond). */ .header-search-wrapper .search-form-wrap { border-radius: 16px; /* The parent's border-top was the panel's only accent tying it visually to the triangle above it; recolored together with the triangle below so the two still read as one shape pointing down from the button. */ border-top-color: #0092cb; /* Parent animates this open/closed with `all 0.4s ease-in-out`, which reads as sluggish for a control you tap and immediately type into. Scoped to the two properties that actually change (opacity + the scaleY transform), so `all` isn't also animating incidental things. */ transition: opacity 0.15s ease-out, transform 0.15s ease-out; } .header-search-wrapper .search-form-wrap::before { border-bottom-color: #0092cb; } /* * Lay the form out as a flex row so the input and the "Ara" button can have * a real gap between them. The parent floats both (`float: left`, submit at * a fixed `width: 20%`) with nothing separating them. Note the input is * wrapped in a (with a screen-reader-only beside it), so the * flex children here are that label and the submit button — the label is * what has to flex, not the field directly. */ .header-search-wrapper .search-form-wrap .search-form { display: flex; align-items: stretch; gap: 8px; } .header-search-wrapper .search-form-wrap .search-form label { flex: 1 1 auto; /* Without this a flex item won't shrink below its content's intrinsic width, which would push the button out of the 300px panel. */ min-width: 0; margin: 0; } .header-search-wrapper .search-form-wrap .search-field { border-radius: 10px; width: 100%; float: none; } .header-search-wrapper .search-form-wrap .search-submit { border-radius: 10px; background: #0092cb; /* Replaces the parent's `width: 20%` + `float: left` — sized to its own label instead, so the gap above is real space rather than something taken out of the input's width. */ float: none; width: auto; flex: 0 0 auto; padding: 0 16px; } /* ---- dark mode ---- */ .site-mode--dark .header-search-wrapper .search-form-wrap { /* See the note above: #000 on #000 left the panel with no visible edge. */ background: #1c1c1c; /* Blue rather than the white this used to be — white gave the panel a hard, bright top edge and a white submit button that dominated a dark panel. Matching light mode's accent keeps one consistent scheme and lets the blue read as the accent it is against the dark surface. */ border-top-color: #0092cb; } .site-mode--dark .header-search-wrapper .search-form-wrap::before { border-bottom-color: #0092cb; } .site-mode--dark .header-search-wrapper .search-form-wrap .search-submit { background: #0092cb; color: #fff; } /* * The input itself had no dark-mode treatment at all — it stayed a white * box with dark text, the brightest thing in the panel. Given a dark fill * and a light border so it still reads as an editable field rather than * dissolving into the panel behind it. */ .site-mode--dark .header-search-wrapper .search-form-wrap .search-field { background-color: #2a2a2a; border: 1px solid #3d3d3d; color: #fff; } .site-mode--dark .header-search-wrapper .search-form-wrap .search-field::placeholder { color: #9aa0a6; } /* * The browser's own default focus ring (never overridden until now — the * parent's `input[type="search"]:focus` rule only sets `color`, no * `outline`) rendered as a mixed white/green halo on top of this dark * field: the native ring itself plus the accent-green `outline-color` * several browsers derive from the page's own link/accent colors once a * field's background is dark. An explicit outline replaces it outright * with a single, intentional color instead of that blend — the site's own * green (`articlewave_link_hover_color`'s default, #349a45; already * hardcoded elsewhere in this file at this same scope, e.g. the search * icon's states, so matching it here rather than pulling the theme_mod is * consistent with how the rest of this section already does it). * Light mode is untouched — only reported as a problem in dark mode, and * the native ring there wasn't described as broken. */ .site-mode--dark .header-search-wrapper .search-form-wrap .search-field:focus { outline: 2px solid #349a45; outline-offset: -1px; border-color: #349a45; } /* * Live-search suggestion dropdown (.articlewave-search-results-wrap, built * by the parent's AJAX live-search JS, assets/js/custom-scripts.js — * unrelated to the redesigned button/panel above other than sharing the * same parent .search-form-wrap). * * Post titles inside it stayed unreadable in dark mode: the panel itself * already goes dark (.site-mode--dark .header-search-wrapper * .search-form-wrap, above), and the wrapper's own text correctly goes * white via the parent's sitewide dark-mode rule (.site-mode--dark * .search-form-wrap .articlewave-search-posts-wrap, in that same big * color:#fff selector list) — but each title's own link * (.articlewave-post-title a) carries an explicit, unconditional * `color: #212121` (near-black) that, being a direct rule rather than * inherited, wins over the wrapper's white regardless of mode. Matched to * the sitewide dark-mode white-text convention rather than inheriting, * since the parent's own rule would otherwise keep winning on directness. */ .site-mode--dark .articlewave-search-results-wrap .articlewave-item .articlewave-post-element .articlewave-post-title a { color: #fff; } /* * Rounded corners on each suggestion's thumbnail — unscoped by mode, the * parent never rounds these at all (plain `display:block; height:auto; * max-width:100%`). Matches this file's smaller-card radius elsewhere * (e.g. the comment avatars, the mobile submenu expander) rather than the * larger 14-16px used for full-size cards, since these thumbnails are * similarly small (flex: 0 1 20% of a compact list row). */ .articlewave-search-results-wrap .articlewave-item .articlewave-post-thumb-wrap img { border-radius: 8px; } /* ------------------------------------------------------------------------- 15. Post image: no hover effect, not clickable (single posts only) Global/unscoped, like sections 13 and 14. This is a markup change, not a CSS one — see single.php, where the featured image's `` wrapper and its Customizer-driven `hover-effect--one` class (the zoom-on-hover the parent theme applies via .post-image.hover-effect--one:hover img, style.css:2062) are both dropped. Every OTHER template that renders this same `.post-image` figure — archive/grid cards, related posts, the carousel, the trending widget — links the thumbnail to that post's OWN permalink, where hovering/clicking it is genuinely useful navigation. On a single post's own page, that same link only ever points at the page already being viewed, so it was never doing anything for a visitor except look clickable. No CSS override was used to just visually suppress the hover (e.g. re-neutralizing `.hover-effect--one:hover img`'s transform) because that would leave the dead link and its pointer cursor in place — removing the anchor is what actually removes the "clickable" affordance, not just the animation that used to accompany it. ------------------------------------------------------------------------- */ /* ------------------------------------------------------------------------- 16. Reading-progress bar (single posts only) Markup: the bar (#articlewave-reading-progress, wrapping #articlewave-reading-progress-bar) is printed once, directly in single.php right after get_header() — a top-level sibling of #page, same placement reasoning as the scroll-to-top/dark-mode-switcher buttons in section 2, so it's never at risk of being clipped by that section's `#content { overflow-x: clip }` guard. Behavior: assets/js/reading-progress.js, enqueued only on is_single() in functions.php. It measures progress between the top of .single-post-content-wrap and the top of the comments heading ("{post title} içeriği için {N} yorum", #comments .comments-title from comments.php), so the bar reaches exactly 100% at the scroll position where that heading reaches the top of the viewport — not somewhere under the related-posts/author-box sections above it or the comment list below it, and not stalled below 100% by them. Falls back to the full document height on posts with no comments yet (or comments disabled entirely), where that heading never renders at all — see the JS file for the exact condition. z-index deliberately higher than everything else on the page, including the sticky header (.site-header, z-index:999) — a reading-progress bar is conventionally the topmost thing on screen, a thin strip sitting above the header rather than tucked under it. ------------------------------------------------------------------------- */ #articlewave-reading-progress { position: fixed; top: 0; left: 0; width: 100%; height: 4px; z-index: 100000; /* Click-through: this sits directly over the sticky header, which does have its own interactive controls (menu, search, mode switcher). */ pointer-events: none; } #articlewave-reading-progress-bar { width: 0; height: 100%; background-color: #0092cb; /* Smooths out the width jumps between individual scroll events without visibly lagging behind the page — matches the mobile menu's own "fast, not sluggish" tuning (assets/js/mobile-nav.js) rather than the parent theme's much slower global default. */ transition: width 0.1s linear; } /* ------------------------------------------------------------------------- 17. Homepage grid: 2 columns on tablet-portrait widths, not 3 The homepage's masonry grid (body classes: front-page-post-style--grid, front-grid--masonry, sidebar-layout--no-sidebar-center) is NOT laid out with CSS Grid despite the naming — cards are `display:inline-block` with an explicit `width` + `margin-left`, absolutely positioned into place by Masonry.js reading those computed box sizes (parent's .front-page-post-style--grid .articlewave-content-wrapper article, style.css:3105 — width:30.33%, i.e. 3 per row). Changing the column count at any width is a matter of changing that `width`, not adding/removing a grid-template-columns rule. The gap: none of the parent's own responsive breakpoints ever touch that width for the plain, no-sidebar case this site actually uses. The responsive.css breakpoints that DO adjust this rule (max-width:1300px, min-width:1026px/max-width:1100px) only target the `.sidebar-layout--both-sidebar` / `.sidebar-layout--right-sidebar` variants, which don't match this page's own `sidebar-layout--no-sidebar- center` class — so the 30.33%/3-column width rode unchanged from full desktop width all the way down to the theme's own `max-width:600px` breakpoint, where it falls straight to `width:100% !important` (1 column, also parent, responsive.css) — no 2-column step in between at all. Every width in between, which covers essentially the entire tablet-portrait range (iPad mini/Air/Pro all fall between 768-1024px), rendered the same cramped 3-column grid as desktop. 601-1025px chosen as the range rather than picking new numbers: it's exactly the gap between the theme's own existing 600px (1-column) and 1025px (the theme's own general "tablet and below" cutoff, already used unconditionally elsewhere in responsive.css — e.g. the homepage's carousel/"Trend Yazılar" pair stacking, footer widget column count) — 601, not 600, so this range and the 1-column rule below 600px never both match at the same width. 47% (not exactly (100% - 3%)/2 = 48.5%) leaves a bit of slack alongside the existing `margin-right: -4px` fudge already on this rule at every width, rather than tuning a second number to match a third. Originally scoped to just the homepage (.front-page-post-style--grid) — flagged at the time as leaving the identical gap on category/tag/author archive pages, which reuse the *other half* of the very same parent selector for this width (style.css:3105): `.archive.archive-style--grid .articlewave-content-wrapper article, .front-page-post-style--grid .articlewave-content-wrapper article { width: 30.33% }`. Confirmed present at the exact same 3-column-on- tablet bug via a category page's own rendered body classes (`archive category archive-style--grid sidebar-layout--no-sidebar-center`) — same no-sidebar layout as the homepage, same untouched-by-any-breakpoint width. The identical fix reaches every archive-style--grid page this theme has (category, tag, and author archives — this child theme's own author.php included, which shares the same body classes) in one rule, since they all render through this one shared selector. Search results (search.php) are NOT included here on purpose, despite also carrying an `archive-style--grid` body class — checked and ruled out, not assumed: that page's body lacks the parent's own `archive` class (`search search-results archive-style--grid ...`), and the rule this section targets requires *both* classes together (`.archive.archive-style--grid`, not `.archive-style--grid` alone) to match at all. Search results fall through to the plain, unscoped `.articlewave-content-wrapper article { width: 100% }` base rule instead (style.css:3088) — already a single column at every width, nothing to fix here. Selector specificity matters for this rule to actually win: the archive half must repeat the parent's own `.archive.archive-style--grid` prefix in full (3 classes + 1 type — same as the parent's, tied, won only by this stylesheet loading after the parent's), not just the bare `.archive-style--grid` class alone (2 classes + 1 type) — a lower- specificity version of this selector would lose outright to the parent's own, more specific, always-on 30.33% rule at every width, doing nothing. ------------------------------------------------------------------------- */ @media (min-width: 601px) and (max-width: 1025px) { .front-page-post-style--grid .articlewave-content-wrapper article, .archive.archive-style--grid .articlewave-content-wrapper article, .search.archive-style--grid .articlewave-content-wrapper article { width: 47%; } } /* ------------------------------------------------------------------------- 18. Grid post cards: description capped at 6 lines, with an ellipsis Every width, every device — not part of the mobile-only pass above, deliberately unscoped by any media query. Targets `.article-post-content-wrap .entry-content` — the card excerpt markup content.php (parent) renders via `the_excerpt()` — the same selector this file already touches a few lines up ("Post özetleri artık kesilmiyor") to fix mid-word breaking. Nothing about the excerpt *text* changes: `the_excerpt()` still runs exactly as before (still capped by WordPress's own default 55-word `excerpt_length`, or a manually-written excerpt if a post has one — either way, whatever text it produces is untouched). Only how much of that text is *visible* is capped, the same `display:-webkit-box; -webkit-line-clamp; -webkit-box-orient:vertical; overflow:hidden` technique this file already uses for the trending/ related-post title clamps above — clamping the block itself rather than inserting a manual "…" means the ellipsis only appears when a card actually needed truncating, never tacked onto short excerpts that already fit. Scoped to grid-mode cards specifically (`.front-page-post-style--grid` / `.archive.archive-style--grid` — the same compound selector and the same specificity reasoning as section 17 immediately above, including why it needs the full `.archive.archive-style--grid` prefix rather than the bare class alone), matching "grid posts" precisely: content.php's `.article-post-content-wrap .entry-content` markup is shared with `archive-style--list`/`front-page-post-style--list` (a different Customizer post-display option, more horizontal room per row, where a 6-line cap wasn't asked for and would just discard text list cards have the width to show in full) and with search results (`content-search.php`, a near-identical but separate template — see section 17's note on why `.archive.archive-style--grid` doesn't match search results' body classes at all). None of those are touched here. ------------------------------------------------------------------------- */ .front-page-post-style--grid .article-post-content-wrap .entry-content, .archive.archive-style--grid .article-post-content-wrap .entry-content, .search.archive-style--grid .article-post-content-wrap .entry-content { display: -webkit-box; -webkit-line-clamp: 6; -webkit-box-orient: vertical; overflow: hidden; } /* ------------------------------------------------------------------------- 19. Grid post cards: a real vertical gap between rows Every width, every device — the grid (homepage and category/tag/author archives, same `.front-page-post-style--grid` / `.archive.archive-style-- grid` scope as sections 17 and 18) is positioned by Masonry.js (assets/js/custom-scripts.js, `new Masonry(grid, {itemSelector:'article'})` — no `gutter` option passed). Masonry reads each item's full computed outerHeight, margin included, to decide the next item's position in that column — margin-bottom on the item IS the mechanism Masonry expects for row spacing, there's no separate "row gap" setting to reach for. The parent theme never sets one: neither style.css's base `.articlewave- content-wrapper article` rule nor either grid selector sets any margin- bottom at all, at any width — searched specifically, not assumed. Rows were stacking with zero space between them, cards touching edge to edge. 24px, not a percentage: the existing horizontal gutter is `margin-left:3%` (of the container's width — resolves to roughly 40px at the desktop 1320px container, proportionally less at narrower widths since it's a percentage), but a percentage vertical margin *also* resolves against the container's width, not its own element's height, per the CSS spec — so reusing 3% here wouldn't track row height at all, and would shrink to a cramped ~10px at single-column mobile widths where a percentage-based horizontal gutter no longer even applies (it's reset to 0 there — see the parent's `.articlewave-content-wrapper article { width:100% !important }` at <=600px). A fixed value keeps the vertical rhythm identical at every breakpoint instead, including the already-established mobile/tablet 1-and-2-column layouts from sections 17 and earlier. 24px matches this file's own existing "comfortable, not sparse or tight" spacing scale used for comparably-sized elements elsewhere (e.g. the author-topics pill row, the mobile menu's rounded-corner radius). ------------------------------------------------------------------------- */ .front-page-post-style--grid .articlewave-content-wrapper article, .archive.archive-style--grid .articlewave-content-wrapper article, .search.archive-style--grid .articlewave-content-wrapper article { margin-bottom: 24px; } /* ------------------------------------------------------------------------- 20. Search results: the same card grid as the homepage Search results carry an `archive-style--grid` body class but NOT the parent's `archive` class (`search search-results archive-style--grid sidebar-layout--no-sidebar-center`) — and the parent's grid rule requires both together (`.archive.archive-style--grid`, style.css:3105). So search results never matched it and fell through to the plain base rule (`.articlewave-content-wrapper article { width: 100% }`, style.css:3088): one full-width card per row, nothing like the homepage. Earlier sections noted this and deliberately left it alone as out of scope; this is the part that opts search in. This rule is the parent's own 3-column grid definition mirrored onto `.search.archive-style--grid`, values unchanged, so desktop search results are laid out identically to the homepage. Sections 17, 18 and 19 have each had `.search.archive-style--grid` added to their selector lists alongside it, which is what carries over the rest of the treatment: 2 columns at tablet-portrait widths, the 6-line description clamp, and the 24px row gap. Masonry needs no extra work — search.php already wraps its loop in `.articlewave-archive-posts-wrapper`, and the body already carries `archive-grid--masonry`, which is exactly what the parent's JS initializes against (assets/js/custom-scripts.js). It simply had no multi-column widths to lay out until now. The excerpt those cards display comes from this child theme's template-parts/content-search.php override — the parent's version of that template renders no description at all. See its docblock for why it's an override rather than repointing search.php at content.php. ------------------------------------------------------------------------- */ .search.archive-style--grid .articlewave-content-wrapper article { width: 30.33%; display: inline-block; margin-left: 3%; margin-right: -4px; vertical-align: top; position: relative; } /* * Single column on phones, matching what responsive.css already forces for * the homepage/archive grids at this width (its grouped * `width: 100% !important` rule lists several selectors but, consistent with * everything else here, none that match a search page). */ @media (max-width: 600px) { .search.archive-style--grid .articlewave-content-wrapper article { width: 100%; margin-left: 0; } } /* ------------------------------------------------------------------------- 21. Dark mode: page/post body text set to the editor's "Black" swatch goes invisible Not mobile-scoped — a contrast bug present at every width, same category as sections 11-12 above. Root cause: any block whose text color was set to the Gutenberg default "Black" swatch (Manifestomuz's paragraphs and its "Neler yapıyoruz?" heading, for instance) renders with class `has-black-color`. WordPress core generates that class's CSS at runtime from its own default theme.json (wp-includes/theme.json) via wp_enqueue_global_styles(), and core emits it as `color: #000000 !important` (class-wp-theme-json.php) — not a plain declaration. Neither this theme nor its parent registers its own editor color palette (no theme.json in either), so every "Black" swatch pick site-wide resolves through this same core rule. That !important beats the parent's own dark-mode text-whitening rules regardless of specificity — including both `.site-mode--dark .entry-content p` and the plain `.site-mode--dark h1/h2/h3...` element rules (style.css:3998, parent) — so any paragraph *or* heading using this swatch stays pinned to black against the page's near-black dark-mode background. Beating an !important rule requires both higher specificity and !important of our own; not scoped to `p`/heading tags specifically since the "Black" swatch can land on any block type, and `.entry-content` is what every content-bearing template (page, single, content-page.php) already wraps its blocks in. ------------------------------------------------------------------------- */ .site-mode--dark .entry-content .has-black-color { color: #fff !important; } /* ------------------------------------------------------------------------- 22. Palatino everywhere except the top bar Chosen after comparing eight faces side by side on this site's own posts (Garamond/EB Garamond, Sabon/Crimson Pro, Miller Text/Newsreader, Literata, Source Serif 4, Palatino, Georgia, against the existing Raleway). Palatino is a SYSTEM font — 'Palatino Linotype' (Windows), 'Palatino' (macOS), 'URW Palladio L' (most Linux), 'Book Antiqua' (older Office) — falling back to Georgia and then the platform serif. Nothing is downloaded, so this costs zero bytes and cannot delay first paint. Worth defending if anyone later proposes swapping it for a Google-hosted serif: that would undo part of the font-payload work (31 KB -> 3.7 KB) done just before this. The header ("top bar" — logo row, nav, social icons, search) deliberately stays on Raleway, so the masthead keeps its existing sans identity while everything below it — posts, pages, archives, the grid, sidebars, footer — reads as serif. THE SPECIFICITY LADDER HERE IS LOAD-BEARING. Four tiers, each of which must beat the one above it and nothing else: 1. Sitewide Palatino. Needs `!important` and ELEMENT-ONLY selectors. The Customizer emits `body{font-family:Raleway}` and `h1,h2,h3,h4,h5,h6{font-family:Raleway}` *inline in , after this stylesheet* — same (0,0,1) specificity, later source order, so it would win without `!important`. Element-only keeps this at (0,0,1) so tier 3 can still outrank it. 2. Header back to Raleway, at (0,1,1) — one class beats tier 1's bare elements. `i` is deliberately NOT in this list: including it would make this rule (0,1,1) against Boxicons' own `.bx` at (0,1,0) and turn every social/menu/search icon in the header into a letter. 3. Icon font re-asserted. Boxicons ships `.bx { font-family:'boxicons' !important }` at (0,1,0), which already beats tier 1 on its own; the `.site-header` variants here are (0,2,1) so they also beat tier 2 inside the header. This tier is belt-and-braces, not strictly required, but it makes the intent explicit for whoever edits this next. 4. Admin bar, at (1,0,0) — never restyled, so wp-admin's bar keeps its own system sans while logged in. ------------------------------------------------------------------------- */ /* 1. Palatino everywhere */ body, button, input, select, textarea, optgroup, h1, h2, h3, h4, h5, h6, p, a, li, span, div, blockquote, cite, q, td, th, dd, dt, figcaption, label, legend, caption, em, strong, b, small, sub, sup { font-family: 'Palatino Linotype', Palatino, 'URW Palladio L', 'Book Antiqua', Georgia, serif !important; } /* 2. ...except the top bar, which stays Raleway. No `i` here — see tier 3. */ .site-header, .site-header button, .site-header input, .site-header select, .site-header textarea, .site-header h1, .site-header h2, .site-header h3, .site-header h4, .site-header h5, .site-header h6, .site-header p, .site-header a, .site-header li, .site-header span, .site-header div, .site-header label, .site-header em, .site-header strong { font-family: 'Raleway', sans-serif !important; } /* 3. The icon font must survive both rules above. */ .bx, i[class*="bx"], [class*="bx-"], .site-header .bx, .site-header i[class*="bx"], .site-header [class*="bx-"] { font-family: 'boxicons' !important; } /* 4. Leave the logged-in admin bar alone. */ #wpadminbar, #wpadminbar * { font-family: -apple-system, BlinkMacSystemFont, 'Segoe UI', Roboto, sans-serif !important; }