--- name: hebrew-web-typography description: Hebrew web typography rules, RTL conventions, and design principles for building high-quality Hebrew websites. Use this skill whenever working on Hebrew/RTL typography — setting font sizes, line-height, spacing, emphasis, bidirectional text, type scale, structuring/chunking Hebrew running text, or auditing typography in Hebrew web projects. Also trigger when the user asks about Hebrew fonts, RTL layout rules, optical balance, fixing dense "wall of text" Hebrew paragraphs, or typographic hierarchy for Hebrew sites. This skill is a reference companion to hebrew-site-builder and design-taste-frontend — always consult it when those skills are active on Hebrew projects. --- # Hebrew Web Typography A reference skill for making correct, high-quality typographic decisions on Hebrew RTL websites. Covers rules that differ from Latin/English typography, structure and chunking of running text, font recommendations, type scale systems, emphasis conventions, bidirectional text handling, spacing, and optical balance principles. --- ## 1. HEBREW-SPECIFIC TYPOGRAPHY RULES These rules override standard Latin typography conventions. Hebrew script has fundamentally different structural properties that demand different treatment. ### Font Size - **Minimum body font size: 18px.** Hebrew glyphs are visually smaller than Latin at the same pixel size due to different x-height proportions. - **Navigation items: 16–18px** (larger than English's typical 14–16px). - Use `clamp()` for all font sizes — never hardcode px or rem values. - **Mixed Hebrew/Latin slots — share the leading, not the size.** When Hebrew and Latin share a role (bilingual templates, EN/HE twins, an English term inside a Hebrew line), set the Hebrew **+5–10% larger** (up to +14% on display, as little as +3% on small meta) and hold the *pixel leading* constant on body blocks so the baseline rhythm doesn't shift between languages. Hebrew has no ascenders/descenders or caps, so it reads optically smaller than Latin at equal px — size it up to match. **Calibrate the exact % on the REAL fonts, by eye** — a stand-in face mis-states it (e.g. RecStudio's Heebo-beside-Metropolis lands at Latin 0.95em = Hebrew +5%, tuned on real Metropolis, not the calculator's guess). ### Line Height - **Running/long-form body text: 1.7–1.8** (English typically uses 1.4–1.5). 1.7 is the floor for any Hebrew text a reader moves *through* — guides, articles, multi-paragraph sections; push toward 1.8 for marketing/landing pages where air matters more than density. Hebrew needs more vertical breathing room than Latin. - **Short editorial bursts (1–3 rendered lines, ≥22px): 1.25–1.4 is legitimate.** A single statement or project-blurb is display-adjacent, not reading text — solid-ish leading makes it a typographic object. The moment text runs past ~3 lines, or the reader must *read on*, the 1.7 floor applies. (Field: Dov Abramson ships running Hebrew at 1.23–1.3, but only on single-blurb / short-paragraph pages — bursts, never long-form.) - **Headings: 1.2–1.3** for tight, impactful display. - **Display/decorative text — by size band:** ~40–70px → 1.1–1.2 · 70–95px section-head display → 1.15–1.25 · **≥95px-class statement/hero → 1.0–1.1 (solid-set is shippable, even multi-line Hebrew).** Below ~70px, never 1.0. - Base vertical rhythm on Hebrew body line-height (e.g., 18px × 1.7 ≈ 30.6px, round to 32px on the 8px grid). All margins, paddings, and component spacing should derive from this unit or its multiples. ### Letter-Spacing (Tracking) - **Body text: NEVER add letter-spacing.** Hebrew letterforms are calibrated by the type designer at their native spacing. Tracking disrupts reading rhythm. - **Emphasis exception:** The W3C Hebrew Layout Requirements states that Hebrew uses letter-spacing to emphasize or highlight text — names, concepts, terms. This is a legitimate Hebrew convention (analogous to German Blackletter *sperren*). Single terms only — never a phrase, never a paragraph. - **Large display headings — negative tracking scales with size.** -0.01…-0.02em from ~50px; up to **-0.03…-0.05em at 100px-class** display. Hebrew display tolerates *tighter* tracking than Latin at the same size — but the tolerance is font-specific: calibrate by eye per family (a value tuned on one face does not transfer). Visible Hebrew display is always tracked negative or zero — **never positive**. - **List-row air:** short link / list / index rows (nav-like rows, credit lists, chips — one line, not prose) may take slight POSITIVE tracking, ~+0.03…+0.04em, to air out a dense stack of short Hebrew items. Never on paragraphs, never on display. ### Word-Spacing (the legitimate "air" axis) - **Word-spacing — not letter-spacing — is how Hebrew gets air.** Hebrew justification stretches word spaces only (never letter spaces), and the same logic applies to manual adjustments: a slight positive `word-spacing` (up to ~0.05em) can relieve dense display or marketing text. - Use it sparingly, on short display/marketing blocks — not as a default on body text. - **If a block needs more relief than word-spacing gives, the problem is structural, not spacing** — see §2 Structure & Chunking. ### Emphasis Hebrew's emphasis hierarchy (documented by Michal Sahar, Typotheque): 1. **Bold weight** (primary — always use this first) 2. **Ink-value step** (demote the surrounding text to a muted/faint token, then snap ONE word back to full ink + bold — the gray→black+700 beat; in Hebrew, *value* does the job italic does in Latin. One beat per paragraph.) 3. **Different typeface** (a brand-level move — body↔heading font; master practice runs one family per script and switches only per-language, not per-paragraph) 4. **Letter-spacing** (for highlighting specific terms) 5. **Underlining** 6. **Color change** (hue — last resort; *value* is #2) **NEVER use italic for Hebrew text.** Hebrew typography considers slanted/italic fonts controversial. Bold replaces italic entirely. > **The ink-value step is one rung of the 3-level ladder → full rule in [§1.5 Text Hierarchy](#15--text-hierarchy--the-three-axes-size--weight--ink-value).** Short version: a light ramp does NOT survive a hex-inversion to dark — pure `#fff` halates, so the dark lane uses an off-white anchor (`#e6edf3`) on a not-quite-black bg (`#1a1b1d`). §1.5 has both presets, the halation rule, and the live ink-ramps widget. ### Case & Capitalization - **Hebrew is unicameral** — no uppercase or lowercase letters. - This eliminates: small-caps, ALL CAPS transformations, text-transform: uppercase, and case-based hierarchy. - Visual hierarchy must come entirely from: size, weight, typeface contrast, and color. - Hierarchy must therefore come from size, weight, and **ink value** first. Typeface switching is a *brand-level* tool (display face vs body face), not a paragraph-level one — a single Hebrew family with two well-chosen weights can carry an entire site's hierarchy. ### Paragraph Treatment - **Space-between, not indentation.** Hebrew web convention uses vertical space between paragraphs rather than first-line indentation. - Never use both spacing and indentation together (Bringhurst/Butterick rule). - For running text longer than a few lines, structure beats styling — see §2 Structure & Chunking. ### Text Alignment - **Use `text-align: start`** (resolves to right-alignment in RTL) with ragged-left edges. - **Avoid justified text on the web.** Hebrew justification adjusts only word-spacing (never letter-spacing), but browser support remains inconsistent. ### Content Width - **Max-width ~40rem is the ceiling for Hebrew body text containers** — marketing/landing text reads best narrower, around 30–38rem. - Hebrew line length guidance: roughly 45–75 characters per line, same principle as Latin but Hebrew words tend to be shorter, so the character count may differ. --- ## 1.5 · TEXT HIERARCHY — the three axes (size · weight · ink-value) Hebrew is unicameral (no caps) and bans italic, so hierarchy **can't** lean on case or slant the way Latin does. It runs on **three axes — size, weight, ink-value** (typeface-switch is a brand-level fourth, per-language, never per-paragraph). Get these three right and one Hebrew family carries a whole site. This is the consolidated rule; §1 Emphasis, §5 Type Scale, and §7 Visual Weight hold the per-axis detail. **The three axes** 1. **Size** — the loudest signal. Content systems → the §5 scale (1.25 ratio). Brand / cover / poster surfaces → the **two-scale page law** (one giant + one tiny, **4–6× apart, nothing mid-scale**). Hebrew needs *more* size contrast than Latin — there's no case to help. 2. **Weight** — 400 body / 700 emphasis. The primary emphasis tool (it replaces italic). Two weights of one family can carry a whole hierarchy. 3. **Ink-value (tone)** — the **3-level ladder: anchor → mid → faint**. This layers a body *without* changing size. (Lineage: Material 87/60/38% white · Apple label/secondary/tertiary · GitHub Primer.) **The 3-level ink ladder** | Level | Role | Emphasis move | |---|---|---| | **anchor** | loudest text — headline, the one emphasized word | body sits at mid → snap ONE word here + weight 700 (the gray→black+700 beat — *value does italic's job*). One beat per paragraph. | | **mid** | body / running text lives here | — | | **faint** | meta, captions, source / footnote lines | — | **Light vs dark — RE-TUNE, never hex-invert** (the load-bearing rule) A dark ramp is **not** the light ramp flipped. Pure white `#fff` on dark **halates** — it glows/bleeds and blurs the glyph edges; and a naive inversion sinks the faint level into the background. So on dark: **not-quite-black background + not-quite-white anchor.** | Lane | bg | anchor | mid | faint | |---|---|---|---|---| | **Light** | `#ffffff` | `#1a1b1d` | `#7f7f7f` | `#c1c1c1` | | **Dark (Bots)** | `#1a1b1d` | `#e6edf3` | `#8b949e` | `#6e7681` | Dark-lane values are GitHub Primer. **Anchor is off-white (`#e6edf3`), never `#fff`.** WCAG-on-dark: anchor ≈ AAA, mid ≈ AA, faint often dips below AA — **fine for meta, never for body.** **Tune & verify live:** the interactive **ink-ramps widget** (in recstudio-content: `lab/design-widgets/ink-ramps/`) ships both presets, a live WCAG ratio per level, and a **halation flag** that fires when the anchor gets too close to pure white on dark. "Copy CSS" emits the three vars — use it to pick or sanity-check a ramp instead of guessing hexes. ### Deriving a ramp for ANY background (not just the two presets) The presets cover white and the Bots near-black. For **any other surface** — a colored lane, a photo panel, a client's brand color — *derive* the ramp; don't guess hexes. The method (verified against the field's tooling): 1. **Hierarchy is stepped LUMINANCE CONTRAST, not hue.** The three levels are three *contrast targets* against the bg. Hue only makes the text feel like it belongs to the surface — it never carries the hierarchy. So you solve for three tones, then tint them. 2. **The three contrast targets, in APCA** (font-size/weight-aware — the right tool; WCAG is the legal floor, *not* the design target): anchor **Lc ≈ 90** · mid/body **Lc ≈ 75** · faint/meta **Lc ≈ 45–60** (below body is fine for meta, **never** for body). 3. **Solve in a PERCEPTUAL space — OKLCH or CAM02 — never HSL.** Step the three levels along OKLCH's **L** axis: it's perceptually even, so equal L steps read as equal tonal steps (HSL's "lightness" lies — equal HSL steps look uneven). Don't eyeball hexes; let the space do the spacing. As a starting point the presets sit at roughly OKLCH L: dark-lane anchor ≈ 0.93 · mid ≈ 0.65 · faint ≈ 0.52; light-lane anchor ≈ 0.20 · mid ≈ 0.56 · faint ≈ 0.80. 4. **Tint the neutrals toward the bg's hue, at LOW chroma (~0.01–0.02 — a hint, not saturation).** Pure grey looks dead on a colored surface; a faint tint of the surface hue makes the text feel *part of* the panel (Refactoring UI "tinted greys", Radix "tinted palettes"). On a blue bg → cool, blue-tinted off-whites and slates. On neutral bg, chroma → ~0 (plain grey). 5. **Halation cap — the load-bearing rule.** On any dark **or colored** surface, never push the anchor to pure `#fff` — back it off to an off-white (cap OKLCH L ≈ 0.93). Pure white halates: it glows, bleeds, and blurs the glyph edges. `#e6edf3` on `#1a1b1d` is exactly this rule already applied. 6. **Verify each level's contrast against the bg** (APCA, with WCAG as the floor) and nudge L until anchor / mid / faint each clear their target. **Tools that do this for you — feed bg + contrasts, get hexes:** - **Adobe Leonardo** — open source `@adobe/leonardo-contrast-colors`; `generateContrastColors({ colorKeys, base, ratios })` takes a background + target contrast ratios and returns the hexes. ([github.com/adobe/leonardo](https://github.com/adobe/leonardo)) - **APCA** — the contrast model the targets above are stated in ([apcacontrast.com](https://apcacontrast.com)). - **OKLCH + APCA generators** — pick/step tones perceptually and read APCA live ([inclusivecolors.com](https://inclusivecolors.com)). - Background reading: Refactoring UI *"Building your color palette"* (tinted greys) · Radix *"Composing a palette."* **Why it's non-negotiable in Hebrew:** with no uppercase, no small-caps, and no italic, *value* and *size* are most of what you've got. A flat-tone Hebrew block reads as a wall even at perfect line-height — the fix is hierarchy (size + the ink ladder) plus structure (§2), not more leading. --- ## 2. STRUCTURE & CHUNKING — THE MONOLITH FIX The single highest-leverage rule on Hebrew marketing and content pages. Hebrew is unicameral and has no italic: in Latin text, italics and case variation create relief *inside* a paragraph, but a Hebrew paragraph is one uniform texture. A long block reads as a wall — even with perfect line-height — and readers feel it before they can name it. **Relief in Hebrew must come from structure, not styling.** ### The failure mode: the monolith A paragraph of 4+ rendered lines, often justified, often tight leading. The font is fine, the colors are fine — the text just feels dense, tiring, unprofessional. Adjusting line-height alone will NOT fix it. ### The rules 1. **Lead-in line.** Open a text block with a short lead-in (one idea, ideally one rendered line) set one step up: one type-scale step larger and/or weight 600. It gives the eye an entry point before the running text. 2. **Beats of 2–4 lines.** Split running text into chunks ("beats") of 2–4 rendered lines, one idea per beat, separated by clear vertical space (0.75–1em minimum). No beat runs past ~4 lines without relief — a break, a subhead, or a pull-line. 3. **Hierarchy from blocks.** Subheads + whitespace do for Hebrew what italics and caps do for Latin. When a section feels flat, add structure — don't reach for styling. 4. **One emphasis per beat.** At most one bold term per chunk (or one letter-spaced term, per the W3C-documented Hebrew highlight convention). Two emphases in one beat cancel each other out. 5. **Narrow the measure.** Chunked Hebrew text reads best at ~30–38rem. A wide measure undoes the chunking. 6. **Air = word-space + line-space.** Never letter-spacing on running text (see §1). ### Before/after recipe — fixing a monolith 1. Extract the first sentence → make it the lead-in (size/weight one step up). 2. Split the rest at idea boundaries into 2–4-line beats with whitespace between them. 3. Set line-height 1.7–1.8; `text-align: start`, ragged — never justified. 4. Narrow the measure to ~30–38rem. 5. Bold the single load-bearing term — max one per beat. Kill any italic. ### CSS sketch ```css .block { max-inline-size: 36rem; } .lead { font-size: 1.2em; font-weight: 600; line-height: 1.5; margin-block-end: .75em; } .beat { line-height: 1.75; margin-block-end: 1em; } .beat b { font-weight: 700; } /* one per beat, maximum */ ``` ### Exemplars The Israeli cultural-institution sites in §10 (Tel Aviv Museum of Art especially) are built almost entirely from this pattern: short modular text blocks, generous whitespace, hierarchy from structure rather than styling. --- ## 3. NAVIGATION TYPOGRAPHY (Hebrew Without Nikud) Comprehensive decision guide for Hebrew navigation bars. Modern Hebrew web uses כתיב מלא (full spelling without nikud) — this affects word length, spacing, and layout decisions. ### Font Choice for Nav Links - **Use the heading font** (e.g., Alef) when: the site is brand-heavy, the nav has ≤5 items, the heading font is clean and geometric, and you want the nav to feel like part of the brand identity. - **Use the body font** (e.g., Heebo) when: the site is content-heavy, the nav has 6+ items, readability at small sizes matters more than brand expression, or the heading font is decorative/serif. - **Never use the display/decorative font** for navigation text (like Ellinia CLM, Suez One) — it's for hero headlines only. - **Decision rule:** Can you read the font comfortably at 16px with just a quick glance? If yes → use it for nav. If you need to "study" the letterforms → too decorative for nav. - **Hebrew-specific reason:** Without nikud, Hebrew letters are visually denser — fewer internal white spaces than Latin. A clean sans-serif keeps nav items scannable; serif or decorative Hebrew fonts at nav sizes (16–18px) lose clarity fast. ### Font Size - **Desktop nav links: 16–18px.** Hebrew glyphs are visually smaller than Latin at the same pixel height — English nav at 14px feels equivalent to Hebrew at 16–17px. Start at 16px; if it feels tight or hard to scan, go to 17–18px. - **Sticky/scrolled nav:** Reduce by 1–2px maximum (e.g., 17px → 15–16px). Never go below 15px for Hebrew nav text. The shrink should feel subtle — if users notice the text got smaller, you've shrunk too much. - **Mobile drawer/hamburger menu links: 18–22px.** Larger than desktop because the drawer is a full interaction context, not a persistent bar. Secondary drawer items (social links, language toggle, legal): 14–16px. - **Sub-nav / dropdown items: 14–16px.** One step smaller than primary nav, creating clear hierarchy. Maintain consistent weight. - **All sizes must use `clamp()` or your type scale tokens** — never hardcode px. ### Font Weight & States Hebrew has no italic, so all state differentiation must use weight, color, or indicators: | State | Weight | Styling | |-------|--------|---------| | **Inactive** | 400 (regular) | Base text color | | **Hover** | 400 — **no weight change** | Accent color, underline, or background shift | | **Active (current page)** | 600–700 (bold) | Accent color + indicator (underline, dot, or background) | | **Focused (keyboard)** | Same as hover | Visible focus ring (accessibility requirement) | - **Never change weight on hover** — it causes layout shift as Hebrew characters change width. Hebrew without nikud has no ascender/descender variety like Latin; all letters sit in a more uniform rectangle, so the width-shift is more noticeable and jarring than in English. - **Recommended hover effects for Hebrew:** 1. Underline with offset — clean, universal. Use `text-underline-offset: 4px–6px` to prevent collision with Hebrew descenders (ק, ן, ף, ך, ץ). 2. Background highlight (subtle, e.g., 8% opacity of accent color) 3. Color change (to accent color) 4. Bottom border / animated underline 5. Opacity change (100% → 80%, subtle) - **Use at least 2 differentiators for the active state** — weight alone isn't always enough. Combine bold + accent color, or bold + underline. - **NEVER use italic** for any nav state. Not hover, not active, not disabled. - **Width-shift prevention** for the active item's bold weight: ```css /* Reserve the bold width so the active state doesn't shift siblings */ nav a::before { content: attr(data-text); font-weight: 700; height: 0; overflow: hidden; visibility: hidden; display: block; } ``` Or with variable fonts, animate `font-variation-settings` instead of `font-weight` for smoother transitions. ### Spacing Between Nav Links Use the 8px grid system. All spacing values must be multiples of 8: - **Gap between nav links: 24px–40px (3–5 grid units).** Start with 32px (`gap-8` in Tailwind). Increase to 40px if items are short, decrease to 24px if items are long. - **Internal padding on each link: 8px–16px vertical, 12px–16px horizontal.** This creates a comfortable hit area (minimum 44×44px touch target per WCAG). - **Use `gap` on the flex container**, not margins on individual items — cleaner and easier to maintain. - **Test with your actual Hebrew labels — don't estimate from English.** "צור קשר" is wider than "Contact"; "אודות" is narrower than "About Us". Compound terms with spaces take significantly more horizontal space than single-word English equivalents. ``` Label widths to plan around: Short: בית | בלוג | אודות | שירותים Medium: תיק עבודות | השירותים שלנו | מי אנחנו Long: צור קשר | שאלות נפוצות | תנאי שימוש | המלצות לקוחות ``` Plan your spacing around your longest label. If one item is significantly longer, consider abbreviating it or restructuring the information architecture. ```css /* Hebrew nav spacing — 8px grid */ nav { display: flex; align-items: center; gap: 32px; /* 4 grid units between links */ } nav a { padding: 8px 16px; /* comfortable hit area */ font-size: clamp(0.9rem, 0.85rem + 0.25vw, 1.063rem); /* ~15–17px */ font-weight: 400; line-height: 1.3; text-decoration: none; transition: color 0.2s; } nav a:hover { color: var(--accent); } nav a[aria-current="page"] { font-weight: 700; color: var(--accent); } ``` ### How Many Nav Items? - **Desktop: 5–7 items maximum** in the horizontal bar. Hebrew words tend to be wider, so you'll hit the space limit sooner than with English. With a CTA button: 4–6 text links + 1 CTA. - **If you have 7+ items:** Move less critical items into a dropdown (labeled "עוד" — "More"), use a mega-menu pattern, or split into primary/secondary nav tiers. - **Calculating if items fit** — for a 1200px max-width container with logo (150px) and CTA button (120px): - Available space for links: ~930px - Average Hebrew nav item (word + padding): ~120–150px - Maximum items that fit comfortably: 6–7 - Test at 1024px viewport too — that's where items start to crowd. | Hebrew Label | Characters | English Equivalent | |-------------|-----------|-------------------| | בית | 3 | Home | | אודות | 5 | About | | שירותים | 7 | Services | | תיק עבודות | 9 (with space) | Portfolio | | צור קשר | 7 (with space) | Contact | | המלצות | 6 | Testimonials | | שאלות נפוצות | 11 (with space) | FAQ | | הזמינו פגישה | 11 (with space) | Book a Meeting | ### Label Abbreviation - **Never abbreviate Hebrew days/months in navigation.** Unlike English where "Mon" or "Jan" are standard, Hebrew abbreviation conventions are less universal and can feel awkward or unclear to readers. - **Prefer single-word labels when possible.** "אודותינו" (About Us) can become "אודות" (About). "צרו קשר" (Contact Us) can become "קשר" (Contact) — but only if the context is obvious. - **If a label is too long, rewrite it** — don't truncate with "..." in navigation. Ellipsis in nav is a UX failure. ### Active State Indicators Since Hebrew has no uppercase/lowercase, and italic is banned, the active-state toolkit is: 1. **Weight change** (400 → 700) — most common; reserve the width (see above) to avoid shift 2. **Color change** — accent color for active item 3. **Bottom border/underline** — 2–3px solid, accent color, with 4–8px offset from text 4. **Background pill** — subtle rounded background behind active item 5. **Combination** — weight + underline or color + underline **Best practice for Hebrew:** Use **color + bottom border** rather than weight alone — it avoids the width-shift problem entirely (there's no case variation to absorb the visual change). ### Sticky/Scrolled Nav Behavior ``` INITIAL STATE (top of page): ├── Nav height: 72–88px (Hebrew needs slightly more vertical space) ├── Logo: full size ├── Link font-size: 17px ├── Link padding: 8px 16px └── Gap between links: 32px SCROLLED STATE (after ~100px scroll): ├── Nav height: 56–64px ├── Logo: scaled to ~70–80% ├── Link font-size: 15–16px ├── Link padding: 6px 12px └── Gap between links: 24px ``` - **Transition duration: 200–400ms** with `ease-out` or a custom cubic-bezier. Add subtle shadow or backdrop-blur to separate from content. - **Animate padding and gap, not font-size directly** — font-size transitions cause text reflow jank. Instead, use CSS `transform: scale()` on the nav container for smoother resizing. - **What NOT to do when sticky:** don't hide nav items on scroll (unless mobile) · don't change the font family · don't reduce link size below 15px · don't add letter-spacing to compensate for smaller size. ### Mobile Navigation - **Hamburger icon: top-left** (in RTL the logo takes the top-right corner; the menu/action side is the left). - **Drawer opens from the left** — the same physical side as the hamburger. - **Drawer background: solid color** (not transparent). Hebrew text needs contrast. - **Mobile nav link size: 18–22px**, weight 500 (medium) — slightly bolder than desktop to compensate for touch context. Full-width tap targets, 48–56px per link minimum. - **Active state indicator: inline-start border** (appears on the right side in RTL, which is the leading edge). - **Sub-items:** indent 16–24px from parent, reduce size by 2px. - **Include a visible close button** (×) — top-left corner, minimum 48×48px tap target. Don't rely only on overlay tap to close. - **Stack nav links vertically with `text-align: start`** (resolves to right-aligned in RTL). **Mobile drawer structure for Hebrew sites:** ``` [× close] ראשי ← Primary nav, 20px, weight 700 if active אודות שירותים → ייעוץ אישי ← Sub-items, 18px, indented → סדנאות תיק עבודות בלוג ───────────────────── ← Divider צור קשר ← Secondary items, 16px תנאי שימוש נגישות 🌐 English ← Language toggle, 14–16px ``` ### Breadcrumbs - Align to the right (start) in RTL. - Separator: use `‹` not `›` (mirrors the LTR chevron direction). - Font size: 13–14px (smaller than body — fine for breadcrumbs since they're short reference text). - Use the body font, weight 400. - Current page in breadcrumb: weight 600, no link. ### Language Toggle For bilingual Hebrew/English sites: - Place the toggle at the inline-end of the nav (leftmost position in RTL). - Label: "English" or "EN" (not a flag icon — flags represent countries, not languages). - In Hebrew nav: use "עב" or "עברית" for the Hebrew side. - Font size: same as nav links or slightly smaller (14–16px). ### CTA Button in Nav If your nav includes a call-to-action button (like "הזמינו פגישה" or "התחילו עכשיו"): - **Place it at the inline-end of the nav** (left side in RTL — the terminal position where the eye lands last, before the language toggle if present). - **Visually separate it** from nav links with a filled background + border-radius (pill for friendly, 8px for professional). - **Text: short** — 2–3 Hebrew words max. - **Font size: same as nav links or 1px smaller.** Never larger — it shouldn't overpower the navigation. - **Font weight: 500 (medium).** The filled background already draws attention; the text doesn't need to be bold. - **Min-width: 120px** to prevent the button from looking cramped with short Hebrew text. - **Padding: generous horizontal (20–28px)** — Hebrew CTA text tends to be wider than English equivalents. ### Nav with Mixed Hebrew-English Common in Israeli sites (brand names, English terms): - **Don't abbreviate the English.** "Portfolio" stays "Portfolio," not "Port." - **Wrap English nav labels in ``** if they sit among Hebrew links, though single-word English items usually render fine without explicit direction. - **Match font rendering:** If your Hebrew font has a Latin companion (Heebo includes Latin), use the same font for both. Mixing fonts between Hebrew and English nav items creates visual inconsistency. - **Font size stays the same** for English labels — don't upsize or downsize relative to Hebrew items. ### Accessibility Checklist for Hebrew Nav ``` 1. ☐