/* =============================================================================
property-rtl.css — the part of right-to-left that logical properties cannot do
=============================================================================
Loaded only when the active locale's direction is rtl, and every rule is
scoped to [dir="rtl"] as well, so it cannot reach the English document by
either route.
Almost all of the mirroring is NOT here. The property stylesheets were
converted to logical properties in place — margin-inline-start,
padding-inline-start, border-inline-start, inset-inline-start/end,
text-align: start/end — which resolve to exactly the physical values they
replaced in a left-to-right document and flip on their own in a
right-to-left one. That is one set of numbers serving both directions rather
than two sets to keep in step, and it is why this file is short.
What is left here is the two things a logical property cannot express:
1. Artwork that points. A logical property moves a box; it cannot turn the
arrow drawn inside it. A "previous" control mirrors to the other end of
the rail on its own, but the chevron in it would still point the way it
was drawn, so the two would disagree.
2. Anything whose direction is baked into a gradient or a shadow offset.
Not here, on purpose:
* the select chevron (property-pages.css). Its mark is drawn from a
border pair turned 45deg, so mirroring the borders would rotate the
glyph rather than move it. Its BOX mirrors via inset-inline-end; the
mark itself points down, which is the same mark in either direction.
* the disclosure chevrons on the filter chips and the account nav. Those
rotate 180deg between closed and open, which is a vertical movement and
means the same thing in both directions.
========================================================================== */
/* ---- pointing artwork ---------------------------------------------------- */
/*
* The carousels' own controls: area cards on the homepage, the listing rail,
* the detail gallery, its thumbnail rail, and the lightbox.
*
* Their boxes have already swapped ends by this point — --prev carries
* inset-inline-start, so it is on the right in Arabic. scaleX turns the glyph
* to match, which is the whole of what is needed: these are single chevrons,
* so a mirror is exactly a reversal.
*/
[dir="rtl"] .hz-areas__nav svg,
[dir="rtl"] .hzpg__nav svg,
[dir="rtl"] .hzpg__railnav svg,
[dir="rtl"] .hzpg-lb__nav svg {
transform: scaleX(-1);
}
/*
* The listing rail's arrows are one glyph used twice, the back one turned
* round in the sheet rather than drawn again. Both need mirroring in Arabic,
* and the back one has to keep its 180 as well — hence the pair, and hence
* the second rule repeating the rotation rather than replacing it. transform
* does not accumulate across rules; the winning declaration is the whole
* value.
*/
[dir="rtl"] .hzp-rail__nav svg {
transform: scaleX(-1);
}
[dir="rtl"] .hzp-rail__nav[data-hzd-scroll="-1"] svg {
transform: rotate(180deg) scaleX(-1);
}
/*
* Breadcrumb separators, where the theme draws one rather than using a
* character. A separator that leans is a directional mark.
*/
[dir="rtl"] .hzp-crumbs__sep svg,
[dir="rtl"] .hzp-breadcrumb svg {
transform: scaleX(-1);
}
/*
* The section heads' "see all" arrow, which was the one member of the family
* above that did not get mirrored. It is an inline SVG -- 'arrow' in the icon
* map, -- so it is drawn
* pointing right and nothing about a right-to-left document turns it round.
*
* A forward affordance points towards the direction of reading, so in Arabic
* it points left. Its box already sits at the inline end without help, because
* the head is a flex row; only the glyph was wrong.
*
* Two call sites, both .hz-seeall: the areas section and every listing row.
*/
[dir="rtl"] .hz-seeall svg {
transform: scaleX(-1);
}
/*
* The hero's projects link had a rule here to turn its forward arrow round.
* The arrow was removed from the control on request, so there is no longer any
* pointing artwork in the tab bar to mirror. Nothing else about that link needs
* this file: the bar is a flex row and reverses on its own, and the hairline
* beside it is a border-inline-start, which flips without help.
*/
/* ---- numbers that must not be reordered ---------------------------------- */
/*
* Prices, areas, telephone numbers and years are left-to-right runs whatever
* surrounds them. Western digits are what this market reads on a property
* portal — Bayut and Property Finder both use them in Arabic — but a bare
* digit run inside Arabic text is at the mercy of the bidi algorithm, which
* is free to reorder the groups around it. "1,250 JOD" can come out with the
* currency on the wrong side of the figure, and a phone number can come out
* with its groups swapped.
*
* isolate is the correct value rather than embed: it also stops the run from
* affecting the ordering of the text on either side of it.
*/
[dir="rtl"] .hz-lcard__price,
[dir="rtl"] .hzp-detail__price,
[dir="rtl"] .hzp-price,
[dir="rtl"] .hz-phone span,
[dir="rtl"] .hzp-fact__value {
unicode-bidi: isolate;
}
/* ---- shadows and gradients with a side ----------------------------------- */
/*
* The header's divider sits at the inline end of the phone block. Its rule
* moved with the logical border, but the sliver of light beside it was drawn
* with a physical offset.
*/
[dir="rtl"] .hz-actions .hz-phone {
box-shadow: none;
}
/* ---- form controls ------------------------------------------------------- */
/*
* Text inputs inherit direction from the document, which is right for a name
* or a district but wrong for the fields that hold a number, an e-mail
* address or a URL — those are left-to-right by nature, and a right-to-left
* input puts the caret and the text on the wrong side of the box.
*/
[dir="rtl"] input[type="email"],
[dir="rtl"] input[type="tel"],
[dir="rtl"] input[type="url"],
[dir="rtl"] input[type="number"],
[dir="rtl"] input[type="password"] {
direction: ltr;
text-align: start;
}
/* ---- the Arabic coverage notice ------------------------------------------ */
/*
* The strip under the header that says what Arabic here covers.
*
* It lives in this sheet rather than property.css because the element it
* styles only ever exists in a right-to-left document -- the partial is inside
* the same direction test that loads this file -- so putting it in the shared
* sheet would ship rules for a node the English page never has.
*
* Quiet on purpose. This is a statement of scope, not a warning: no amber, no
* border, no icon in a coloured circle. It sits between the header and the
* hero at the weight of small print, which is the weight it deserves -- a
* reader who wants it will read it, and a reader who does not is not stopped
* by it. Anything louder would read as an error on a page that has none.
*/
[dir="rtl"] .hz-l10n-note {
border-bottom: 1px solid #e7e9ee;
background: #f7f8fa;
color: #5a6270;
font-size: 12.5px;
line-height: 1.55;
}
[dir="rtl"] .hz-l10n-note .hz-shell {
display: flex;
align-items: flex-start;
gap: 8px;
padding-top: 9px;
padding-bottom: 9px;
}
[dir="rtl"] .hz-l10n-note svg {
flex: none;
width: 15px;
height: 15px;
/* Optical, not geometric: the cap height of the text beside it sits a
little below the line box top, and matching the glyph to the box would
leave it looking high. */
margin-top: 1px;
opacity: 0.75;
}
[dir="rtl"] .hz-l10n-note p {
margin: 0;
}
/* ---- English text inside an Arabic document ------------------------------ */
/*
* The site's own text is Arabic; the listings, the project pages and the
* listing form are not, and will not be for a while. So most Arabic pages here
* carry runs of English inside a right-to-left block, and that is precisely
* the case the bidi algorithm gets visibly wrong.
*
* An English sentence in an RTL paragraph inherits the paragraph's direction,
* which puts its trailing punctuation at the WRONG END: "Homes to rent and buy
* across Jordan." renders as ".Homes to rent and buy across Jordan". The full
* stop, the question mark, the brackets and the quotes all migrate, and it is
* the single most obvious sign of a right-to-left layout done carelessly.
*
* unicode-bidi: plaintext is the property that exists for exactly this: it
* makes each paragraph take its direction from its own first strong character
* rather than from its parent. Arabic text is unaffected -- its first strong
* character is Arabic, so it stays right-to-left. English text becomes
* left-to-right internally and keeps its punctuation where it belongs, while
* still sitting in the right-to-left column, which is what a bilingual page
* should do.
*
* WARNING, AND THE REASON THIS RULE ALONE WAS NOT ENOUGH. The paragraph below
* used to say "it changes ordering only. Alignment still comes from
* text-align, which the stylesheets now state logically, so nothing moves in
* the layout." That is wrong, and it is wrong in a way that is easy to miss.
*
* plaintext changes the element's USED paragraph direction. `text-align: start`
* resolves against that direction. So a card title holding a Latin string got
* paragraph direction ltr, and `start` then meant LEFT -- the title sat hard
* against the left edge of a right-aligned Arabic card, which is exactly what
* the client reported on the featured-properties row.
*
* Note that getComputedStyle still reports direction: rtl for these elements,
* because the `direction` PROPERTY is untouched; only the used bidi paragraph
* direction changes. So this cannot be found by reading computed direction --
* it has to be measured from where the glyphs actually land.
*
* The alignment rule underneath this one is the other half of the fix.
*
* Named on text-bearing elements rather than on * because it establishes a
* bidi paragraph, and doing that on every wrapper as well as every leaf is
* both needless and a way to get surprised.
*/
[dir="rtl"] h1, [dir="rtl"] h2, [dir="rtl"] h3,
[dir="rtl"] h4, [dir="rtl"] h5, [dir="rtl"] h6,
[dir="rtl"] p, [dir="rtl"] li, [dir="rtl"] dt, [dir="rtl"] dd,
[dir="rtl"] th, [dir="rtl"] td,
[dir="rtl"] a, [dir="rtl"] button, [dir="rtl"] label,
[dir="rtl"] figcaption, [dir="rtl"] summary, [dir="rtl"] legend,
[dir="rtl"] option, [dir="rtl"] blockquote {
unicode-bidi: plaintext;
}
/*
* Placeholders too, which are their own text run and get the same treatment
* from the algorithm.
*/
[dir="rtl"] ::placeholder {
unicode-bidi: plaintext;
}
/*
* The other half of the rule above: alignment must follow the DOCUMENT, not
* the direction plaintext just derived from the element's own first character.
*
* match-parent is `inherit`, except that start and end are resolved against the
* PARENT's direction -- and the parent is untouched by plaintext, so it is
* still rtl. Latin and Arabic text therefore both sit at the right edge, while
* plaintext continues to order each run correctly internally and keep its
* punctuation at the right end. Alignment and ordering, decided separately,
* which is the distinction the two properties exist to draw.
*
* It has to be match-parent rather than `text-align: right`. `right` would win
* over the inherited centring in twenty wrapper rules in this theme -- the hero
* content, the band inner, the empty states, the banner rail -- and flatten all
* of them against one edge. match-parent inherits `center` as `center`.
*
* summary is deliberately ABSENT from this list. .hzp-calc__how summary carries
* an explicit text-align: center at the same specificity as [dir="rtl"]
* summary, and this sheet loads last, so including it here would silently
* un-centre that control. It is the only such collision in the theme.
*/
[dir="rtl"] h1, [dir="rtl"] h2, [dir="rtl"] h3,
[dir="rtl"] h4, [dir="rtl"] h5, [dir="rtl"] h6,
[dir="rtl"] p, [dir="rtl"] li, [dir="rtl"] dt, [dir="rtl"] dd,
[dir="rtl"] th, [dir="rtl"] td,
[dir="rtl"] a, [dir="rtl"] button, [dir="rtl"] label,
[dir="rtl"] figcaption, [dir="rtl"] legend,
[dir="rtl"] option, [dir="rtl"] blockquote {
/* THE PREFIX IS LOAD-BEARING, NOT LEGACY HYGIENE.
*
* Chromium 148 does NOT support unprefixed match-parent:
* CSS.supports("text-align", "match-parent") -> false
* CSS.supports("text-align", "-webkit-match-parent") -> true
* An unprefixed declaration is REJECTED at parse time, so the first
* version of this fix was a silent no-op -- the titles stayed flush left
* and computed text-align stayed `start`, exactly as before. Measured, not
* assumed: setting the prefixed form inline moved the title from
* gapRight 19px to gapRight 0 and computed to `right`.
*
* Both spellings, prefixed FIRST. Where only the prefix is understood the
* unprefixed line is dropped and the prefix stands; where both are, the
* later unprefixed line wins and they are equivalent. That covers Blink
* and WebKit by prefix and Gecko by the standard name.
*
* If a browser understands neither, both are dropped and behaviour reverts
* to the defect rather than to something worse. */
text-align: -webkit-match-parent;
text-align: match-parent;
}
/* ==========================================================================
GLYPH DIRECTION -- the arrows and progression chevrons this theme draws
pointing left-to-right. Added 29 August 2026, after the same class of defect
was found on the cars channel's homepage search button.
These are not reachable by any property-based scanner: an arrow is a
of coordinates and declares nothing directional, so the campaign's sweep of
left/right, insets, shorthands and text-align could be complete and still
leave every forward affordance pointing at the wrong edge. Enumerated with
/home/demo/i18n-guard/glyph-recon.py, which reads path geometry instead.
This joins the mirrored-artwork family already in this file (.hz-seeall svg).
Not included, on purpose: the << >> characters in sell-for-me carry Unicode
Bidi_Mirrored=Yes, so the shaper already flips them and a transform here
would flip them back to wrong. Up and down carets are untouched -- a
disclosure caret points down in Arabic too.
========================================================================== */
/* The sell banner's call to action, on the property home banner and again on
the search page. One class, two call sites. */
[dir="rtl"] .hzp-sell__cta svg {
transform: scaleX(-1);
}
/* Back controls: the listing detail bar, and the publish flow's header.
A back affordance points against the reading direction, so it points right
in Arabic. Neither element carries a transform of its own, and the transform
is on the svg rather than the button so that stays true if one is added. */
[dir="rtl"] .hzd-bar__back svg,
[dir="rtl"] .hzpub-head__back svg {
transform: scaleX(-1);
}
/* The "view this" chevron ending each account summary row, at four sites.
.hzac-link svg already has a rule in property-account.css; it sets size and
colour and declares no transform, so there is nothing here to compose with. */
[dir="rtl"] .hzac-link svg {
transform: scaleX(-1);
}