RTL placeholder text: direction and alignment

A bicycle-parking permit form has an Arabic email label and an LTR email input. Its Arabic placeholder appears at the left edge. Changing the input to RTL moves the hint toward the desired side, but gives the eventual email address the wrong direction policy. The empty form improves while the completed field gets worse.

Separate the hint's language, its alignment and the direction of the value users will enter. A translated placeholder can need different presentation from a machine-format value. CSS can change the input's alignment while it is showing a placeholder; that does not require changing the input's base direction.

There is also a point where a placeholder is the wrong container for the instruction. Long Arabic explanations, mixed-direction examples and information needed during correction belong outside the disappearing hint. This guide uses the permit form to distinguish those choices and test the transition from hint to value.

Identify which part of the placeholder is wrong#

Before changing CSS, describe the failure precisely:

These failures can coexist, but one fix does not establish that the others are solved. Right-aligning an English string does not translate it. Translating a placeholder does not give an email value LTR direction. Increasing width does not make a disappearing instruction available during correction.

Start with the rendered control. A translation file may contain the Arabic hint while the component still uses an English default. A wrapper may be RTL while an inner input has a deliberate LTR direction. Record those facts before deciding which layer to change.

Do not judge a field's entire direction policy from the empty screenshot. Its main job is to accept and edit a value, so the filled state belongs in the diagnosis from the beginning.

Preserve the email value's LTR direction#

This field deliberately keeps the permit contact email LTR:

<div class="permit-panel" lang="ar" dir="rtl">  <label for="permit-email">البريد الإلكتروني لطلب التصريح</label>  <input id="permit-email" class="permit-email" name="email"         type="email" dir="ltr" autocomplete="email"         placeholder="أدخل البريد الإلكتروني"></div>

With start alignment, the LTR control starts its content on the left. That is appropriate for a value such as rider@harborcycle.example, even though the surrounding label and hint are Arabic. text-align controls alignment; dir establishes the field's direction.

Changing this input to dir="rtl" solely for the placeholder is the wrong tradeoff. Setting direction: rtl on the empty input and restoring LTR later also makes the editing context depend on a presentation state that does not describe the expected data.

Keep LTR for this email field. Decide separately whether the Arabic hint should remain left-aligned, move to the right while visible or become help outside the control. A deliberate left-aligned hint is a design choice; an email value inheriting RTL is a different problem.

For an Arabic-only parking-location note, the field itself can use RTL. Do not apply the email solution to every input merely because the same component renders them.

Distinguish the placeholder pseudo-element from the input state#

Two similarly named selectors do different jobs:

::placeholder supports a limited set of styling properties. It is useful for the hint's color and typography, but it is not an independent block that can be positioned and directed like an ordinary paragraph.

This is not a portable way to establish a separate Arabic hint layout:

.permit-email::placeholder {  direction: rtl;  text-align: right;}

The CSS Pseudo-Elements draft ties placeholder styling to the properties applicable to the first-line pseudo-element. Direction is excluded there, and independent placeholder text alignment is not a guaranteed supported property. Do not turn a result observed in one browser into a cross-browser component contract.

For alignment, target the actual control in its placeholder-visible state instead. :placeholder-shown selects that state. The distinction is structural: the pseudo-element styles the hint's text, while the pseudo-class lets you style the input that contains it.

Change empty-state alignment without changing direction#

Use the permit email markup above with this scoped CSS:

.permit-email {  text-align: start;} .permit-panel[dir="rtl"] .permit-email:placeholder-shown {  text-align: right;}

The input remains LTR throughout. While the Arabic panel's input displays its placeholder, the second rule right-aligns its content. Once that state stops matching, the base rule supplies start alignment, which is left for this LTR input.

The physical right is intentional here. It describes the chosen edge for an Arabic hint inside an explicitly LTR control. Using start for that hint would follow the control's LTR direction and return it to the left. The panel's layout direction and the value's direction are different contexts.

The override is scoped to a panel that declares RTL. In an LTR panel, the base rule continues to provide the LTR value's starting edge. Use a translated English placeholder there, then verify that the Arabic-specific rule does not match. If your component inherits RTL without declaring it on this panel, adapt the scope to your actual markup rather than copying a selector that never matches.

This is an alignment solution. It does not give a complex Arabic placeholder its own independent bidi paragraph. If the hint needs a separate reading context to keep its sentence and embedded values understandable, move it into visible help instead.

Test the moment the hint becomes a value#

With state-dependent alignment, the placeholder and the entered value intentionally use different edges. Test that transition, not just the empty control and a fully typed address in separate screenshots.

Focus the empty email field, enter the first character, paste a complete address and delete it again. Inspect the caret and the visible text at each point. Then repeat by selecting all text and replacing it. The empty-state rule should not leave a filled value aligned by a stale class or JavaScript flag.

If the design should stop right-aligning the hint as soon as the control receives focus, add :not(:focus) to the scoped placeholder-state selector. That changes when the alignment transition occurs. It does not eliminate the transition, so test whether the focused hint and caret remain understandable on supported devices.

Do not attach direction changes to these transitions. The email contract remains LTR before, during and after entry. Avoid switching the input's language declaration merely to move the hint too; language and direction are separate from alignment.

If the changing edges distract users during entry, choose a stable arrangement: keep the input LTR with start alignment and put the Arabic instruction outside it. A CSS option is useful only when its resulting interaction suits the field.

Automatic direction does not make an empty Arabic hint RTL#

A bicycle description may accept either Arabic or English. Automatic direction can suit that value, but it has an empty-state behavior the design needs to account for:

<label for="bicycle-description">وصف الدراجة</label><input id="bicycle-description" name="description" dir="auto"       placeholder="اللون ونوع الدراجة">

The browser observations used here were measured in Chromium 151 on September 24, 2026; Firefox and Safari were not measured. An empty automatic-direction input resolved LTR in that setup, with its Arabic placeholder at the left edge. Entered Arabic made the input RTL; Latin letters or digits kept it LTR.

The placeholder is not the entered value that selects the field's automatic direction. Do not replace auto with RTL solely to satisfy an empty-state screenshot when the field intentionally accepts an English description too.

Test an Arabic description, an English description, a digits-only value and a replacement in the other language. Include clearing the control. If the content is specifically required in Arabic, fixed RTL is a different valid policy; make that decision from the field's purpose.

For a detailed account of first-strong behavior, use how automatic direction works. The placeholder decision is what the user should see before that content exists.

Move instructions into help when users need them later#

The permit email's purpose matters after the address is entered. A visible hint can explain that purpose without competing with the LTR value:

<div class="permit-panel" lang="ar" dir="rtl">  <label for="permit-email">البريد الإلكتروني لطلب التصريح</label>  <input id="permit-email" class="permit-email" name="email"         type="email" dir="ltr" autocomplete="email"         aria-describedby="permit-email-help">  <p id="permit-email-help">سنرسل نتيجة الطلب إلى هذا العنوان.</p></div>

This replaces the earlier email fragment; do not mount both with duplicate IDs. It removes the placeholder and associates persistent Arabic help with the input. The Arabic paragraph keeps its own context while the address remains LTR. The placeholder-state alignment rule is unnecessary for this version.

Use help for required formats, exceptions and information needed during correction. W3C's form-instructions guidance describes associating instructions with controls, including through aria-describedby.

Keep a visible label too. A placeholder cannot remain the field's only question once typing removes it from view. W3C's labelling guidance explains the connection between labels and controls. Adding a hidden accessible name alone does not give sighted users a persistent question.

Test the populated field with an error displayed. If the user needs to erase their address to recover the format instruction, that instruction belongs outside the placeholder.

Keep examples short and separate from Arabic instructions#

A placeholder is a plain-text attribute, not a place to nest a directional span. Putting markup-looking text into it does not create an HTML isolation boundary around part of the hint.

For the existing permit reference, the service could show BIKE-V4-783 as a format example in an LTR field. If an Arabic explanation must accompany that example, put it in visible help where the example can receive its own markup boundary. Bidi isolation covers those boundaries.

Do not combine a long Arabic instruction, a code, parentheses and punctuation inside one placeholder merely to avoid a help paragraph. Every extra part makes the hint harder to inspect, and the whole instruction disappears together during entry.

An email-shaped example such as rider@harborcycle.example is not an English instruction that needs literal translation. The surrounding label and explanation should be Arabic; the example illustrates a machine format. Review the purpose of Latin text before classifying every Latin character as untranslated copy.

Do not preload the example through value to imitate a placeholder. An actual value becomes editable form data and can be submitted if left unchanged. Keep an example distinct from the applicant's answer, and verify the request sent by the untouched form.

Translate the live attribute, not just the visible label#

Placeholders can live in a different translation path from labels. A permit field may use an Arabic label supplied by its caller while retaining an English placeholder hard-coded inside the shared component.

Inspect the rendered placeholder attribute after the page finishes loading. Then switch language without leaving the form, if the product supports that. Check the hint after clearing a populated control, because its old translation may have been invisible while the value was present.

The placeholder property exposes the attribute through the input API. Updating that hint is different from replacing the current value. A language switch should not erase the applicant's email or bicycle description to make the new placeholder appear.

Keep the Arabic hint in the same reviewed translation workflow as the label and help. Avoid a fallback that borrows the English prompt whenever the Arabic translation has not loaded. Define the loading state deliberately, then test the final attribute rather than assuming the route language settles it.

Also review component defaults after changing the field's type or purpose. A generic contact component can leave an email hint on a permit-reference field even though both strings were translated. Correct language does not establish correct meaning.

Check whether the control supports a placeholder#

An absent hint is not always a direction bug. Inspect the rendered input type before debugging its alignment. The HTML input reference defines where the placeholder attribute applies; it is not a general hint mechanism for every native control.

For example, a permit form may also collect an expiry date through a date input. Do not assume the same placeholder option used by its email component will replace the native date-entry presentation. Keep the date label and any instructions outside the control, and test the native picker on supported devices.

Changing a date or number control to a text input just to obtain a visible hint changes its behavior and validation contract. Make that a deliberate field-design decision, not a placeholder alignment workaround. If a shared component accepts a placeholder option for every field type, document which types use it and provide a separate help-text option for the others.

Do not make placeholder visibility stand in for form state#

:placeholder-shown describes a rendering state. It does not say that a field is valid, invalid, untouched or intentionally answered. A filled invalid address can stop showing its placeholder; a field with no placeholder attribute does not become valid because the selector fails to match.

This matters when an input style is reused for floating labels or error timing. Do not show a success treatment merely because the hint disappeared. Use validation state for validity and interaction state for when feedback should appear.

For a floating label, test populated, autofilled and restored values. The label must stay readable even when an input arrives with content before the applicant focuses it. A placeholder containing only a space may be used as a styling trigger, but that space supplies no useful instruction and cannot replace a label.

Reset is another path worth testing. Native form reset restores default values, which may be nonempty. Do not assume reset always returns the control to its placeholder-visible state. A form restored after rejection can likewise remain populated while its label and help must still explain the field.

Keep long Arabic explanations out of a narrow hint area#

A single-line email control is not a paragraph layout. Translating a short prompt into a longer Arabic instruction can leave part of the hint unavailable at the widths where people apply for permits on mobile.

The HTML placeholder reference also distinguishes textareas from single-line controls: line feeds and carriage returns are not supported inside input placeholders. Adding a newline is not a way to turn the email hint into wrapped help.

Use a short example or move the instruction outside the input. Do not shrink Arabic text until the entire sentence fits, add letter spacing to compress or decorate it, or make the control arbitrarily wide on small screens.

Test the narrowest supported layout, enlarged text and the actual Arabic font. Include adjacent clear or help actions, because the space available for the hint may be smaller than the control's outer width. Check which end is clipped rather than guessing a universal truncation pattern.

Textarea placeholders need their own test for multiline text and wrapping. Their extra space does not make them a substitute for instructions that must remain during entry. For a layout problem outside the native control, continue with Arabic text overflow.

Make the hint readable without making it look entered#

Placeholder text needs enough contrast to read. W3C's contrast guidance explicitly includes placeholders; for ordinary small text, the minimum contrast ratio is 4.5:1. Default gray styling is not evidence that a particular theme meets that requirement.

Use a tested color for each background and inspect any opacity applied by component or browser styles. ::placeholder is appropriate for that presentation work. Increasing its opacity can change the resulting contrast, so measure the rendered color rather than reviewing the color token alone.

Keep an example recognizable as an example through the label and help. Making it faint is not the only way to distinguish it from entered content. Do not sacrifice readability so that the empty field looks more subtle.

Check light and dark themes, focus styling and the invalid state. A field can have a readable default hint that becomes hard to read when the error background changes. Review the actual Arabic glyphs at the product's font size, without using an English placeholder as the only contrast fixture.

Avoid replacing the native hint with an overlaid instruction#

An absolutely positioned Arabic text layer can appear to offer independent direction and alignment above an LTR input. It also gives the application another object to keep synchronized with value changes, focus, autofill and restored content. Compare that maintenance work with an ordinary help paragraph before building the overlay.

If a design uses one, test tapping directly on the instruction, selecting the input's content and opening the mobile keyboard. Verify that the layer does not obstruct interaction or remain over a populated value. Include values supplied before focus and values cleared through a native clear action, not only changes produced by typing.

Review the accessible label and description separately from the overlay's appearance. A decorative layer should not create a second conflicting question, while instructions needed to complete the field still need an association with it. Do not remove the native label because the layer resembles one in an empty screenshot.

For this permit email, the persistent-help version already allows Arabic instructions and LTR entry without that extra synchronization. Prefer it when the hint requires its own sentence layout.

Inspect hint, value and alignment as separate facts#

For the original email fragment, run this after mounting the control:

const permitEmail = document.getElementById("permit-email");if (!permitEmail) throw new Error("Permit email input is missing");const permitStyle = getComputedStyle(permitEmail); console.table({  placeholder: permitEmail.placeholder,  value: permitEmail.value,  placeholderShown: permitEmail.matches(":placeholder-shown"),  declaredDirection: permitEmail.getAttribute("dir"),  computedDirection: permitStyle.direction,  alignment: permitStyle.textAlign});

Take a new snapshot after each interaction. The output distinguishes a missing translation from an unexpected selector state or CSS override. It does not prove the visible order of a mixed-direction hint, so inspect that presentation directly too.

When the state selector matches but alignment is wrong, inspect the winning text-align declaration on the input. When the direction is wrong, inspect the input's markup and direction styles. Do not add more placeholder pseudo-element rules to compensate for either problem.

Repeat on the LTR route. The alignment change should remain scoped to the intended Arabic panel, while the value's LTR direction remains explicit in both. Record browser, field type, current value and focus state with the result so another engineer can reproduce it.

Verify the empty-to-filled journey before shipping#

Keep the permit email, multilingual bicycle description and reference example in the test set. They exercise different content contracts, so one Arabic prose field cannot stand in for them all.

Include mobile browsers and their real keyboards. A computed-style check can establish the selected alignment rule but cannot establish that the hint is fully visible or that the transition is comfortable to edit. Review those states directly.

A free Ritla scan can report R012: Untranslated attribute text (placeholder, alt, title, aria-label, button value). Placeholder alignment and its transition into a typed value need the tests above; continue with text-align start versus right for edge selection or Arabic text overflow when the hint does not fit.