/* Theme Name: smeweb.site Theme URI: https://www.smeweb.site Author: smeweb.site Author URI: https://www.smeweb.site Description: Block themes for smeweb.site Version: 3.82.1 Requires at least: 6.6 Tested up to: 6.8 Requires PHP: 7.4 License: GNU General Public License License URI: license.txt Text Domain: smeweb Tags: full-site-editing, block-patterns, block-styles, custom-colors, custom-logo, custom-menu, editor-style, translation-ready, blog, portfolio, business */ /* * Global design tokens (color, typography, spacing, layout) live in theme.json. * This file carries only what theme.json cannot express: interaction states, * a few composite components, and the Fluent Forms bridge. * * Contents * 1. Base * 2. Header / navigation * 3. Buttons * 4. Cards * 5. Feature checklists * 6. Marquee * 7. Pricing page — hero and packages * 7b. Pricing hero — floating elements * 7c. Website templates page * 8. FAQ accordion (details/summary) * 9. Posts * 10. Footer * 11. Fluent Forms * 12. Utilities & decorations * 13. Accessibility & motion */ /* ------------------------------------------------------------------ * * 0. Type: Jost for Latin and figures, LINE Seed Sans TH for Thai * ------------------------------------------------------------------ */ /* * One stack, two scripts. A browser resolves font-family per character, not per * element: Jost carries no Thai glyphs, so Thai falls through to LINE Seed Sans TH, * while Latin and digits are served by Jost because it comes first. Nothing has to know * which language a string is in. * * Jost is self-hosted here. It was named in theme.json all along but never arrived — * the Google Fonts request is off (see smeweb_load_google_fonts), so every stack that * started with Jost was silently falling through to Anuphan, then Noto Sans Thai, then * the platform UI font. What looked like Jost on a Windows machine was Segoe UI. * * Two subsets of the variable font, 300-700 on one axis: latin at 26 KB and latin-ext * at 17 KB. unicode-range means a page only fetches the file it needs, and latin covers * U+0000-00FF, so the figures come from it. Cyrillic is not shipped — nothing on this * site is written in it. * * Self-hosted rather than switching the Google request back on: one origin, no third * party in the render path, and the same arrangement LINE Seed already has through the * font library. */ @font-face { font-family: "Jost"; font-style: normal; font-weight: 300 700; font-display: swap; src: url("assets/fonts/jost-latin-ext.woff2") format("woff2"); unicode-range: U+0100-02BA, U+02BD-02C5, U+02C7-02CC, U+02CE-02D7, U+02DD-02FF, U+0304, U+0308, U+0329, U+1D00-1DBF, U+1E00-1E9F, U+1EF2-1EFF, U+2020, U+20A0-20AB, U+20AD-20C0, U+2113, U+2C60-2C7F, U+A720-A7FF; } @font-face { font-family: "Jost"; font-style: normal; font-weight: 300 700; font-display: swap; src: url("assets/fonts/jost-latin.woff2") format("woff2"); unicode-range: U+0000-00FF, U+0131, U+0152-0153, U+02BB-02BC, U+02C6, U+02DA, U+02DC, U+0304, U+0308, U+0329, U+2000-206F, U+20AC, U+2122, U+2191, U+2193, U+2212, U+2215, U+FEFF, U+FFFD; } /* * Applied by redefining the presets rather than by restating font-family on each * selector that sets it. * * Global Styles — which lives in the database and outranks theme.json — declares a * family on body, on a, on h1 through h6, on buttons and on post titles, and every one * of those resolves through one of these three variables. Redefining the variables * reaches all of them at once, and reaches whatever the next Global Styles rule turns * out to be, where a list of selectors would have to be found and extended. * * html:root rather than :root, so this wins on specificity rather than on being later * in the cascade. It is later today; that is a fact about enqueue order, not something * to build on. * * The line-seed variable now leads with Jost, which reads oddly against its name. It is * the trade for reaching every rule from one place, and there is no case on this site * for Latin set in LINE Seed while Thai is not. */ html:root { --smeweb-type: "Jost", "LINE Seed Sans TH", -apple-system, BlinkMacSystemFont, "Segoe UI", sans-serif; --wp--preset--font-family--body: var(--smeweb-type); --wp--preset--font-family--display: var(--smeweb-type); --wp--preset--font-family--line-seed-sans-th: var(--smeweb-type); } /* * The small preset, brought to the body size. * * Body copy came down from 17.6 to 16 on 28 ก.ย. 2569 (see html body, html p below), and the * preset that had been the body size stayed where it was: clamp(0.9375rem … 1.1rem), 17.6 on a * desktop. Everything still sized through it — blog card titles, the prev/next links, the search * box, the cookie table, the sign-in buttons, the docs list — read one step larger than the text * around it. On 1 ต.ค. 2569 the team asked for all of it at 16. * * Redefined here, once, for the same reason the families above are: Global Styles in the database * names this variable in .has-small-font-size, in :where(.wp-block-search), in the table block * and in the button element, and this stylesheet names it twenty-odd times more. Changing the * variable reaches all of them, including the ones a scan of today's pages cannot see — an open * dropdown, the OTP step, a filter that is only shown once something is filtered. * * The same clamp as body text, so a phone keeps the 15 it already had and only the desktop end * moves. Fields that need 16 at every width, so iOS does not zoom on focus, say 1rem themselves. */ html:root { --wp--preset--font-size--small: clamp(0.9375rem, 0.88rem + 0.18vw, 1rem); } /* ------------------------------------------------------------------ * * 1. Base * ------------------------------------------------------------------ */ html { scroll-behavior: smooth; } body { -webkit-font-smoothing: antialiased; -moz-osx-font-smoothing: grayscale; overflow-x: hidden; } /* * Top level sections butt against one another. * * WordPress gives every child of .wp-site-blocks a block gap: * * :where(.wp-site-blocks) > * { margin-block-start: 1.5rem; } * * Header, main and footer are all full-bleed bands carrying their own padding, * so those 24px never separated anything — they only exposed a strip of page * background: white under the navbar, and again above the footer. Zeroed for * every gap rather than just the one that was noticed, because it is the same * seam each time. * * This is the outer half of the problem fixed inside the footer in 1.1.4; that * one was the same core rule applied to .smeweb-footer's own two children. * * The core selector is `:where(…) > *` — specificity (0,0,0) — so one class * clears it. */ .wp-site-blocks > * { margin-block-start: 0; } /* * And the same again one level in, between the sections themselves. * * `
` is a constrained container, so core gives each of its children * * :root :where(.is-layout-constrained) > * { margin-block-start: 1.5rem; } * * Every top-level child of main in this theme is a full-bleed band carrying its * own vertical padding, so those 24px separated nothing and only showed the page * behind. Invisible between the bands that have no background, obvious between * the lavender features band and the blue clients band. * * Scoped to `main`, not to `.is-layout-constrained` at large: the same rule is * what spaces content *inside* a card or a section, and that spacing is wanted. * Element plus class is (0,1,1), against core's `:root :where(…)` at (0,1,0). */ main.wp-block-group > * { margin-block-start: 0; } img, video, svg { max-width: 100%; height: auto; } /* * Form controls take the page font. * * Browsers do not let inputs inherit font-family — they use the operating system UI * font instead — so a field renders in whatever the OS reaches for. In Latin that * passes for a while; in Thai it does not, because the fallback is a looped face and * the site is set in a loopless one, so the placeholder in a search box was visibly * a different alphabet from the label above it. * * Written for every control rather than for the field that showed it. This is a * default browsers get wrong, not a property of one input, and the next field added * anywhere would have arrived with the same fault. * * Only the family is inherited. Size stays with each control, because a plugin that * sizes its own fields has usually done so for a reason. */ input, textarea, select, button { font-family: inherit; } /* * Running text gets room between its lines. * * Global Styles sets body to 1.3 and everything inherits it, so a paragraph at * 17.6px was getting 22.9px of leading. theme.json asks for 1.7 and has been * overruled by the database since before this stylesheet existed — this restores * the number the theme already wanted rather than inventing one. * * 1.3 is tight for any language and tighter for this one: Thai stacks vowels above * and tone marks above those, so the ascender zone is two storeys deep and the * descenders of the line above meet it. Latin at 1.3 looks dense; Thai at 1.3 has * marks nearly touching the line above. * * Applied to paragraphs and content lists, not to body. Raising body would take the * navigation row, the marquee band and every single-line label with it, growing the * header and the bands by the difference — none of which is running text and none of * which was asked about. * * Left alone deliberately, because each already carries its own and each is right: * buttons at 1.2, the step chips at 1.5, post excerpts at 1.7 from theme.json. * Headings stay at 1.3 as well — at 44px that is 57px of leading, which is generous * in absolute terms, and loosening display type would change the shape of every * hero on the site. */ p, .smeweb-checklist li, .smeweb-entry-content li { line-height: 1.7; } /* * The text styles from the new design, node 5833:1830. * * Figma names six: H1 44/60 at -1, H3 Jost 24, text 18/30, text 16px 16/28, tag 14/22 and * button 18. Three of them were already what the site does — H3 is 24 and Jost, the tag sizes * match x-small, and body copy already runs at letter-spacing normal. What is left is this. * * H1 drops from 56 to 44. Pointing it at the xx-large preset rather than a literal 44px keeps * the theme's own fluid curve, so the phone end stays at 28px where huge used to put 34. * * H2 is 36, a style added to the file after this work started — there was nowhere using an H2 * in the frames when the first set was drawn, so it was not needed until now. 36 has no preset * on this site, so it is a clamp built on the same shape as the theme's: the desktop end is the * number from the frame, and the phone end keeps the 0.64 ratio every other preset here uses, * which puts it at 23px. Leading and tracking are carried over from H1 as ratios rather than as * pixels, because the frame gives H2 a size and nothing else. * * The tracking is the part that shows. -1px at 44 is -0.023em, twice the -0.01em the site * uses everywhere, and it is written in em so the phone size is tightened by the same * proportion rather than by the same pixel. * * Figma reports lineHeight 100 for H3 and for button, which is 100% — its way of writing AUTO, * not a request for line-height: 1. Setting 1 on Thai clips the tone mark off a stacked vowel, * measured on this site before now, so those two keep the leading they have. */ html h1 { font-size: var(--wp--preset--font-size--xx-large); line-height: 1.364; letter-spacing: -0.023em; font-weight: 700; } /* * The size class is named as well as the element, because every section heading on this site * carries one. The editor wrote fontSize xx-large into fifteen patterns and into the templates in * the database when 44 was the section size, and a class beats a bare element selector, so the * rule above reached none of them. Naming it here moves all of them at once and leaves alone the * h2s set to something else on purpose — blog card titles and the footer column heads at medium, * which are not section headings and are not 36. The bare selector is fenced off the same way, * so an h2 the editor sized deliberately keeps that size instead of being pulled to 36 by accident. * * important, because WordPress prints its preset size classes with it — .has-xx-large-font-size * carries font-size: … !important in the global stylesheet, so specificity alone loses however far * the selector is stretched. This is answering that one declaration, not overriding a choice. * * Not on an h2 that is part of a component — a class with __ in it, the BEM element the theme * names its own pieces by. Those are sized by the component: the account dashboard's section * headings and the checkout's แพ็กเกจที่เลือก are 24 off their frames, and with nothing in the * bare selector to stop it this pulled all nine to 32.64 — larger than the 30px page title above * them, so on every account tab the second heading out-ranked the first. Section headings carry * wp-block-heading and no __, so every one of them is still reached. */ html h2:not([class*="font-size"]):not([class*="__"]), html h2.has-xx-large-font-size { font-size: clamp(1.4375rem, 1.05rem + 1.1vw, 2.25rem) !important; line-height: 1.364; letter-spacing: -0.023em; font-weight: 700; } /* * H3 is Jost Regular in the frames, and the site has been setting it at 600 — the one place the * new styles ask for lighter type rather than smaller. Tracking goes to 0 with it; the -0.01em * the rest of the headings carry is not on this one. * * Size and family are already right, so this rule is only the two properties that are not. */ html h3 { font-weight: 400; letter-spacing: 0; } /* * Except the three pillar cards on the front page, which the team wants at semi-bold. * * The new H3 style is Regular and that is right for a subhead sitting under a paragraph, where * the weight of the text around it does the separating. These three are the only thing in their * card — a screenshot above, a checklist below — so the name has to hold the card together by * itself, and at 400 it stopped doing that. * * Keyed on the shot rather than on .smeweb-card, because that class is also the service grid, * which takes a weight of its own below. */ html .smeweb-card:has( .smeweb-feature-shot ) h3 { font-weight: 600; } /* * And the six service cards, at 500. * * They are already 24px, the same as a package name, and were the only 24px card title on the * site still at Regular — set beside the packages the two read as different kinds of heading * when they are the same kind. One step, not two: these titles do sit above a paragraph, so 600 * would be heavier than the pillar cards need and heavier than the packages carry. */ html .smeweb-card-grid:has(.smeweb-service-icon) h3 { font-weight: 500; } /* * 16/28 for body copy. * * The style file's text token is 18/30 and this was set to it. 16 is the team's call after seeing * it on the page: it is the browser default, it is what most of the web sets body copy at, and at * 18 a paragraph of Thai on a laptop reads slightly oversized next to the same page on a phone. * * 28 rather than 30 of leading, which is the pairing the file itself gives 16px — the two sizes * are both in there, and this is now using the smaller one whole rather than borrowing half of * the larger. * * The clamp keeps the theme's own small preset at the phone end (0.9375rem), so a narrow screen * barely moves; it is the desktop end that comes down. */ html body, html p { font-size: clamp(0.9375rem, 0.88rem + 0.18vw, 1rem); } p, .smeweb-checklist li, .smeweb-entry-content li { line-height: 1.75; } /* * The paragraphs and lists the editor marked small come down with the rest. * * WordPress writes its size presets as .has-small-font-size { font-size: … !important }, so the * rule above reaches every paragraph except the ones somebody deliberately sized — which on this * site is most of the section ledes and the four footer link columns. They were left at the * preset's 17.6 while body copy moved to 16, which put the supporting line under a heading at a * larger size than the article text below it. * * Named with html and the element so it is 0-1-2 against the preset class, and important because * the preset is. Buttons and the navigation carry the same class and are not included: the frame * puts both at 18 on purpose. * * a is in the list for the Read More link at the foot of a blog card, which is the only anchor on * the site the editor sized. Post titles were left out — headings that happen to be small, allowed * to be larger than the body under them — until 1 ต.ค. 2569, when the small preset itself came down * to the body size and took them with it. See html:root at the top of this file. * * ul and ol are named as well as li. A list written in the editor carries the size class on the * list and not on each item, which is why the footer columns stayed at 17.6 when everything * around them came down — the rule was looking at the wrong element. */ /* * And the plain lists, which is the four columns of links in the footer. * * They carry no size class at all, so neither the paragraph rule nor the one below reached them, * and they sat at the 18 that body copy used to be while everything around them came down. The * navigation is a list too and stays where it is — its items are in wp-block-navigation, not in * wp-block-list, so this selector does not see them. * * :not on the list and not on the item, because a checklist inside a card puts its size on the ul * — has-x-small-font-size at 14 — and a rule aimed at the li would overrule the parent it is * meant to respect. */ html .wp-block-list:not([class*="font-size"]) > li { font-size: clamp(0.9375rem, 0.88rem + 0.18vw, 1rem); line-height: 1.75; } html a.has-small-font-size, html p.has-small-font-size, html li.has-small-font-size, html ul.has-small-font-size, html ol.has-small-font-size { font-size: clamp(0.9375rem, 0.88rem + 0.18vw, 1rem) !important; line-height: 1.75; } /* * 18 on the button, Regular, and no tracking on it. * * The style file names the button Bold and it was set that way at first. The team looked at it on * the page and asked for Regular — every button on this site sits on a solid fill, and a bold * label inside a filled pill is a second thing shouting where the fill already is the emphasis. */ html .wp-element-button, html .wp-block-button__link { font-weight: 400; letter-spacing: 0; } /* * The exceptions are the paragraphs that are not prose: a single-line label inside a * component sized around it. Left at the inherited value so the component keeps its * height. */ p.smeweb-tpl-count, p.wp-block-site-title, .smeweb-marquee p { line-height: 1.3; } /* * Centred standalone paragraphs get a measure. * * A section's own width is set by its widest element — a three-card grid, a * table — and a lone sentence centred in that space inherits it. Measured on the * home page, the intro under "Our Clients" ran 1200px at 17.6px type: 68em, * against the 30-40em a line wants. The features sub-head and closing line came * in at 62em, the hero's supporting sentence at 55em. * * 42em is chosen over a pixel value so the measure tracks the type: fluid sizes * mean the same paragraph is 14px on a phone and 19px on a desktop, and a fixed * max-width would be two different measures. * * Card and column copy is unaffected — those parents are already narrower than * 42em, so the cap never binds. Eyebrows are caught but are a few words long. */ .wp-block-group > p.has-text-align-center, .wp-block-cover__inner-container > p.has-text-align-center { max-width: 42em; margin-inline: auto; } /* * Even lines, so a paragraph does not end in two words on a line of its own. * * Measured across the site before touching it, taking line widths from * Range.getClientRects() so these are the boxes the browser actually made. The pricing lead * ran 711px then 82px; the sentence under the template grid 739px then 22px; a service card * 292/270/52; the footer blurb 364/362/62. Thirty-four paragraphs on five pages ended on a line * under 55% of their longest, and a dozen under 20%. * * balance, not pretty. Both were measured on the same paragraphs and pretty moved almost * nothing here — 711/82 stayed 711/82, and its best result was 292/250/73 against balance's * 215/200/205. Chromium implements pretty as a light touch on the last lines; balance rewrites * the whole block, which is what a two-line lead needs. * * Safe in the way that matters: balance redistributes lines without changing how many there * are, so every height measured before and after was identical — no card resized, nothing * reflowed. Where it cannot help it does nothing: a six-line excerpt came back untouched, * because browsers cap balancing at a handful of lines. * * Unsupported in an older browser means the paragraph wraps exactly as it does today, so there * is nothing to fall back to. */ h1, h2, h3, h4, .wp-block-heading, p, .wp-block-post-excerpt__excerpt { text-wrap: balance; } /* * Except the body of an article, where it would be wrong rather than merely useless. * * Balancing is for a heading or a lead — a block short enough to read as one shape. Long-form * copy wants an even left edge and a normal rag; balancing paragraph after paragraph gives a * column of narrow blocks that drift away from the measure. Headings inside the article are * deliberately left balanced. * * wrap, not normal. text-wrap takes wrap | nowrap | balance | pretty | stable, so normal is not * a value it has: the first attempt was dropped as invalid and the article body stayed balanced, * which a computed-style check caught rather than an eye. */ .smeweb-entry-content p, .smeweb-entry-content li { text-wrap: wrap; } /* * And except every card that clamps its text, which is the other half of the same idea. * * Balancing evens out all the lines a block has, including the ones a clamp then hides. On a * card that is exactly wrong: the hidden line still gets a share of the words, so the visible * ones come up short and the right side of the card empties out. Measured across the four-wide * grid, the first line of a title filled 64% of its column under balance and 96% without — * 211px and 251px of a 357px card against 350px and 343px. * * The cost is a last line that can land at about a third, and in a clamped card that reads as * normal: a title whose first line runs the full width reads as filling the card, where two * lines that both stop short read as the card being half empty. It is the opposite call to the * one above for the same reason — what the reader sees is not the whole block. * * pretty was measured here too and came out identical to wrap on every card, so there is no * third option to reach for. */ .smeweb-post-scroll .wp-block-post-excerpt__excerpt, .smeweb-trending .wp-block-post-excerpt__excerpt, :is(.smeweb-blog-grid, .smeweb-related) .wp-block-post-excerpt__excerpt, :is(.smeweb-blog-grid, .smeweb-related) .wp-block-post-title a, .smeweb-picks .wp-block-post-excerpt__excerpt, .smeweb-picks .wp-block-post-title a { text-wrap: wrap; } /* Anchor targets clear the sticky header. */ :target { scroll-margin-top: 6rem; } :where(a):focus-visible, :where(button):focus-visible, :where(input, textarea, select):focus-visible, :where(summary):focus-visible { outline: 2px solid var(--wp--preset--color--primary); outline-offset: 2px; border-radius: 4px; } /* ------------------------------------------------------------------ * * 2. Header / navigation * ------------------------------------------------------------------ */ /* * Sticky belongs on the template part wrapper, not on the group inside it. * * A sticky box only travels inside its own parent's box, and *
is exactly as tall as the header it * contains — so `position: sticky` on .smeweb-header had nowhere to travel and * never engaged, at any scroll position. The wrapper's parent is * .wp-site-blocks, the whole page, which is the room the header actually needs. * * All eleven templates render this part with `tagName: header`, so one selector * covers every page. The footer part is a