/* * printman-rtl-exceptions.css * ----------------------------------------------------------------------------- * Loaded AFTER style-rtl.css. Everything here is a thing rtlcss got wrong, or a * thing CSS mirroring cannot express at all. * * Rule for this file: every block cites the evidence that put it here. If a rule * has no observed defect behind it, it does not belong in this file — speculative * RTL overrides are how a 1,170-declaration stylesheet becomes 1,400. * * Project constraint: anything WE author uses logical properties * (margin-inline-start, padding-inline-end, text-align: start). Never margin-left. * The theme's 1,170 physical declarations are its debt, not a licence to add more. * ----------------------------------------------------------------------------- */ /* ============================================================================= * 1. ICON-FONT ARROW GLYPHS — CSS cannot mirror a character * ----------------------------------------------------------------------------- * rtlcss correctly moves the arrow BUTTONS to the other side. It cannot touch the * glyph inside them, because the arrow is a codepoint in the `haruicons` font, not * a border or a background. Result without this block: a "next" control sitting on * the left of an RTL carousel still drawing a right-pointing chevron. * * Evidence — glyphs extracted from the theme stylesheet and grouped by direction: * \e915 prev \e916 next \e918 pagination prev \e919 pagination next * \e902 \e903 \e904 \e914 \e921 submenu indicators * \e90f view-all \e91d post-prev \e91e post-next * \e908 \e927 \e931 nav / filter arrows * \e917 back-to-top <-- VERTICAL. Deliberately absent below: mirroring a * vertical arrow is a no-op that costs a repaint, and if * the glyph is ever changed to a diagonal it would break. * ============================================================================= */ .haru-slick .slick-prev:before, .haru-slick .slick-next:before, .haru-testimonial--slick-4 .slick-prev:before, .haru-testimonial--slick-4 .slick-next:before, .single-product-top .slick-arrow.slick-prev:before, .single-product-top .slick-arrow.slick-next:before, .haru-carousel .owl-nav .owl-prev:before, .haru-carousel .owl-nav .owl-next:before, .haru-product-nav .product-prev > a:before, .haru-product-nav .product-next > a:before, .haru-product-nav .product-back-btn:before, .woocommerce-pagination .page-numbers li span.prev:before, .woocommerce-pagination .page-numbers li a.prev:before, .woocommerce-pagination .page-numbers li span.next:before, .woocommerce-pagination .page-numbers li a.next:before, .archive-pagination a.prev:before, .archive-pagination a.next:after, .single-content .single-post-navigation .post-nav .post-prev a:before, .single-content .single-post-navigation .post-nav .post-next a:after, .haru-romeo-slideshow .view-all-btn:after, .haru-layla-slideshow .view-all-btn:after, .haru-nav-menu--indicator-classic .haru-nav-menu .sub-arrow i:before, .haru-nav-menu--indicator-angle .haru-nav-menu .sub-arrow i:before, .haru-nav-menu--indicator-chevron .haru-nav-menu .sub-arrow i:before, .haru-nav-menu-sidebar .sub-arrow i:before, .haru-nav-menu-popup .sub-arrow i:before, .haru-nav-menu-template .sub-arrow i:before, .widget_shopping_cart_content .woocommerce-mini-cart-item .continue-shopping:before { display: inline-block; /* transform does not apply to non-replaced inline boxes */ transform: scaleX(-1); } /* The `+` / `-` plus-indicator submenu variant is direction-neutral. Listing it * here as an explicit exclusion so a later pass does not "complete the set". */ /* ----------------------------------------------------------------------------- * 1b. NAMED DIRECTIONAL ICON CLASSES (phosphor / pricons / haruicons) * ----------------------------------------------------------------------------- * Found in browser QA, not by reading CSS: the hero's "Get Started Now" button moved * its icon to the correct side under RTL and kept pointing RIGHT. The icon is * `` inside `span.haru-button-icon` — an icon * chosen BY NAME in the Elementor editor, so there is no declaration for rtlcss to flip. * Nothing in section 1 covers it: that section targets the theme's own pseudo-element * arrows, and this is an author-selected icon class. * * The class list below is the complete horizontal set actually shipped by the three icon * fonts on this site, read from their stylesheets rather than guessed. * * DELIBERATELY EXCLUDED, and this is the point of enumerating instead of wildcarding: * .phosphor-text-align-left / .phosphor-text-align-right * These depict a TOOL ("align text left"), not a direction of travel. Mirroring them * turns the align-left button into a picture of align-right — the icon would then lie * about what it does. A `[class*="-left"]` wildcard would have swept them in. * .phosphor-arrows-left-right * Double-headed and symmetric; mirroring is a no-op that costs a compositing layer. * Vertical and diagonal-free icons generally — nothing named -up-* / -down-* alone. * --------------------------------------------------------------------------------- */ .phosphor-arrow-left, .phosphor-arrow-right, .phosphor-arrow-down-left, .phosphor-arrow-down-right, .phosphor-arrow-up-left, .phosphor-arrow-up-right, .phosphor-caret-left, .phosphor-caret-right, .phosphor-caret-double-left, .phosphor-caret-double-right, .phosphor-paper-plane-right, .pricon-right-arrow, .hicon-arrow-left, .hicon-arrow-right, .hicon-arrow-left-b, .hicon-arrow-right-b, .hicon-arrow-left-l, .hicon-arrow-right-l, .hicon-arrow-thin-left, .hicon-arrow-thin-right, .hicon-chevron-left, .hicon-chevron-right { display: inline-block; transform: scaleX(-1); } /* ============================================================================= * 2. LATIN-SCRIPT RUNS INSIDE ARABIC TEXT — bidi, not layout * ----------------------------------------------------------------------------- * The UBA reorders a Latin/numeric run according to the surrounding paragraph * direction. In an RTL paragraph, "+962 78 8655568" renders with the leading "+" * on the wrong end, and "35 JD" can surface as "JD 35". Neither is a CSS-mirroring * bug — the stylesheet is correct and the text is still wrong. * * Verified present on the live homepage: tel:+962788655568, https://wa.me/962788655568, * and the bilingual site name "Printman | مطبعة برنت مان" (already mixed-script today). * * `isolate` over `embed`: isolate also stops the run from disturbing the ordering * of the text AROUND it, which `embed` does not. * ============================================================================= */ [href^="tel:"], [href^="mailto:"], [href*="wa.me"], [href*="api.whatsapp.com"] { direction: ltr; unicode-bidi: isolate; } /* Prices: the amount + currency must not be split or reordered by surrounding * Arabic prose. Direction is deliberately NOT forced — WooCommerce's own RTL * stylesheet owns currency-symbol placement and we must not fight it. * * The `wc-block-components-*` selectors were added 2026-08-13. /cart/ and /checkout/ * are WooCommerce BLOCKS, which render client-side from the Store API and use an * entirely different class set, so the two classic selectors above matched nothing on * the two pages where prices matter most. * * ⚠️ MEASURED EFFECT ON THOSE PAGES: NONE. The isolation was applied to the Blocks * classes and the VISUAL GLYPH ORDER of every checkout price was re-measured with * Range rects: 0 of 8 changed. Isolation only matters when a price sits inside * surrounding prose; at checkout each price is a standalone element with nothing * around it to reorder. This is added for correctness and for the day a price is * rendered inline in Arabic copy — NOT because it fixes a defect. */ .woocommerce-Price-amount, .woocommerce-Price-currencySymbol, .wc-block-components-formatted-money-amount, .wc-block-components-totals-item__value, .wc-block-components-product-price, .wc-block-components-order-summary-item__total-price { unicode-bidi: isolate; } /* Phone country-code prefixes rendered as literal text rather than as a tel: link. * WooCommerce Blocks' phone field prints "+962" beside the input; being a number it * will never be translated, so unlike the English UI strings around it this artifact * does NOT disappear once the site is in Arabic. Under RTL the bidi algorithm renders * it "962+" — which reads correctly right-to-left, so this is a presentation * preference rather than a bug. Isolating it keeps it reading left-to-right, which is * how a phone number is normally written in Jordan even in Arabic copy. */ .wc-block-components-phone-number-input__country-code, .iti__selected-dial-code, .pm-dial-code { direction: ltr; unicode-bidi: isolate; } /* Utility for authored content: wrap brand Latin ("Printman", "inkredible") when * it sits inside an Arabic sentence. Prefer in markup where you control it; * this exists for the cases where you only control a class. */ .pm-ltr { direction: ltr; unicode-bidi: isolate; } /* ============================================================================= * 3. rtlcss FALSE POSITIVE — decorative dot lattice * ----------------------------------------------------------------------------- * `background-position: -5px -5px` on a 28x28 repeating pattern is a PHASE offset, * not a left-edge anchor. rtlcss rewrote it to `right -5px top -5px`, which * re-anchors the tile to the opposite edge and shifts the lattice. * * On a symmetric dot grid the visible difference is a few pixels, so this is * cosmetic — it is listed because it is the ONLY background-position rtlcss got * wrong out of 5, and a future theme update that turns this into a real sprite * would turn a cosmetic shift into a broken image. * ============================================================================= */ .haru-decor--style-4 .haru-decor__dotted { background-position: -5px -5px; } /* ============================================================================= * 4. WHAT IS DELIBERATELY NOT IN THIS FILE * ----------------------------------------------------------------------------- * - Logo: `.haru-logo img` carries no directional declaration in either * stylesheet. No override needed; adding a defensive `transform: none` would be * dead CSS that hides a real regression if one ever appears. * - `transform: translate(-50%, -50%)` centering: rtlcss DID flip these (545 * transform declarations rewritten), so `left:50%`→`right:50%` and * `translate(-50%)`→`translate(50%)` stay consistent. Verified by diff, not * assumed — this was the failure mode most likely to sink route A and it did not. * - Carousel SLIDE direction: slick's ordering is a JS option (`rtl: true`), not * CSS. It cannot be fixed here. See RTL-REPORT.md — it is the one genuine * route-A gap and it needs a JS shim, not a stylesheet rule. * ============================================================================= */ /* ============================================================================= * 5. rtlcss INVERTED THE THEME'S OWN RTL HELPER — the highest-impact bug found * ----------------------------------------------------------------------------- * The source stylesheet already contained exactly one RTL-scoped rule: * * .rtl { direction: rtl; } * * rtlcss mirrored it, faithfully and catastrophically, into `.rtl { direction: ltr }`. * * WordPress adds the `rtl` class to whenever is_rtl() is true. So on every * Arabic page that flipped rule matched the body and overrode the inherited * dir="rtl" — computed direction on came out **ltr** while * document.documentElement.dir still read "rtl". * * That combination is nastier than an obviously broken page: the html attribute is * right, hreflang is right, the mirrored stylesheet is loaded, the layout boxes flip * — and the TEXT still flows left-to-right. Nothing errors. curl cannot see it; * `getAttribute('dir')` cannot see it. It was found by reading COMPUTED style in a * real browser, which is the only place the two disagree. * * Generalises: a stylesheet that already contains RTL-specific rules must have them * EXCLUDED from the flip, not flipped. Auto-mirroring assumes its input is * exclusively LTR. Re-check this after any theme-options change regenerates * style-custom.min.css — measured 2026-08-12: exactly 1 such block exists. * ============================================================================= */ .rtl { direction: rtl; } /* ============================================================================= * 5. THE ARTWORK UPLOADER — was here, deliberately REMOVED. Read this before * re-adding anything like it. * ----------------------------------------------------------------------------- * A hand-written block of 11 rules lived here on 2026-08-13, fixing a real defect: * `dnd-upload-wc.css` pins the file list's Remove control with `right:0`, so under * RTL it rendered ON TOP of the file thumbnail — measured at 681.5-697.5 against a * thumbnail occupying 657.5-697.5. * * It was removed the same day because the RIGHT fix turned out to be more general. * `scripts/rtl-coverage-audit.py` showed the uploader was not a special case: TWELVE * stylesheets on this site are covered by none of the three things that make a sheet * RTL-safe (a vendor -rtl.css sibling, self-scoped RTL rules, or no directional CSS * at all). So the uploader now goes through the same mechanism as the other eleven — * an rtlcss mirror served by `swap_vendor_css()` from `vendor-rtl/`. * * PROVEN EQUIVALENT, not assumed. The mirror was tested ALONE, with this block * deleted, and produced the identical corrected geometry: * * details padding 0 left / 10px right (was 10px left / 0 right) * Remove control at the list's far edge, clear of the thumbnail * progress bar stops 10px short of the thumbnail * * The mirror is also strictly better: rtlcss flips 26 declarations in that file, * including the `.codedropz--preview` tile states and the max-767px media query, * where the hand-written block covered 11 rules and had to reason about specificity * against the plugin's own overrides. * * THE RULE: if a THIRD-PARTY stylesheet is wrong under RTL, add it to * `scripts/regen-vendor-rtl.sh` and let rtlcss flip it. Hand-write an exception here * only for things rtlcss cannot express — which is what blocks 1-4 above are. * ============================================================================= */