Fix text direction for URL and email fields in block editor for RTL languages #68188

im3dabasia · 2024-12-20T11:38:10Z

Closes : #65893

What?

Adds direction: ltr for URL and email input fields in the block editor to ensure correct text alignment, especially for RTL languages.

Why?

Screenshots or screencast

Here are a few samples which I tested out.

Embed Block

Before	After

RSS Block

Before	After

Audio Block which uses url-popover component

Before	After

github-actions · 2024-12-20T11:38:25Z

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: im3dabasia <[email protected]>
Co-authored-by: t-hamano <[email protected]>
Co-authored-by: mirka <[email protected]>
Co-authored-by: tyxla <[email protected]>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

im3dabasia · 2024-12-25T16:11:45Z

Hey @t-hamano ,

Thank you for pointing out this #65893. When you have a moment, could you please check this PR and provide your feedback?

t-hamano

Thanks for the PR!

I think the purpose of this PR is reasonable, but it is not desirable to write styles for input elements in the stylesheet of a specific block (Form Input block).

In my opinion, it might be better to solve this problem at the component level.

That is, add direction:ltr here in the InputControl component if the type is email or url.

Also, if we want to solve a similar problem with the Textcontrol component, I think we would need to add CSS here.

im3dabasia · 2024-12-26T13:51:25Z

Also, if we want to solve a similar problem with the Textcontrol component, I think we would need to add CSS here.

Hi @t-hamano,

For the TextControl component, we’ll need to add the type prop wherever the input type is set to url or email. Currently, the type prop isn't passed, which is why the CSS is not being applied. I’ve compiled a list of places where this prop can be added. Could you please review it and let me know if I've missed any?

form

gutenberg/packages/block-library/src/form/edit.js

Lines 109 to 126 in 48b8624

    
           <TextControl 
        
           	__nextHasNoMarginBottom 
        
           	__next40pxDefaultSize 
        
           	autoComplete="off" 
        
           	label={ __( 'Email for form submissions' ) } 
        
           	value={ email } 
        
           	required 
        
           	onChange={ ( value ) => { 
        
           		setAttributes( { email: value } ); 
        
           		setAttributes( { 
        
           			action: `mailto:${ value }`, 
        
           		} ); 
        
           		setAttributes( { method: 'post' } ); 
        
           	} } 
        
           	help={ __( 
        
           		'The email address where form submissions will be sent. Separate multiple email addresses with a comma.' 
        
           	) } 
        
           />

gutenberg/packages/block-library/src/form/edit.js

Lines 148 to 162 in 48b8624

    
           <TextControl 
        
           	__next40pxDefaultSize 
        
           	__nextHasNoMarginBottom 
        
           	autoComplete="off" 
        
           	label={ __( 'Form action' ) } 
        
           	value={ action } 
        
           	onChange={ ( newVal ) => { 
        
           		setAttributes( { 
        
           			action: newVal, 
        
           		} ); 
        
           	} } 
        
           	help={ __( 
        
           		'The URL where the form should be submitted.' 
        
           	) } 
        
           />

navigation-link

gutenberg/packages/block-library/src/navigation-link/edit.js

Lines 192 to 205 in 48b8624

    
           <TextControl 
        
           	__nextHasNoMarginBottom 
        
           	__next40pxDefaultSize 
        
           	label={ __( 'Link' ) } 
        
           	value={ url ? safeDecodeURI( url ) : '' } 
        
           	onChange={ ( urlValue ) => { 
        
           		updateAttributes( 
        
           			{ url: urlValue }, 
        
           			setAttributes, 
        
           			attributes 
        
           		); 
        
           	} } 
        
           	autoComplete="off" 
        
           />

navigation-submenu

gutenberg/packages/block-library/src/navigation-submenu/edit.js

Lines 422 to 431 in 48b8624

    
           <TextControl 
        
           	__nextHasNoMarginBottom 
        
           	__next40pxDefaultSize 
        
           	value={ url || '' } 
        
           	onChange={ ( urlValue ) => { 
        
           		setAttributes( { url: urlValue } ); 
        
           	} } 
        
           	label={ __( 'Link' ) } 
        
           	autoComplete="off" 
        
           />

There are several places where the rel attribute is used for links. I'm not entirely sure if the type prop is necessary in these cases. Could you please clarify if adding type="url" is required here?

Sample Link rel

gutenberg/packages/block-library/src/post-title/edit.js

Lines 164 to 172 in 48b8624

    
           <TextControl 
        
           	__next40pxDefaultSize 
        
           	__nextHasNoMarginBottom 
        
           	label={ __( 'Link rel' ) } 
        
           	value={ rel } 
        
           	onChange={ ( newRel ) => 
        
           		setAttributes( { rel: newRel } ) 
        
           	} 
        
           />

Screenshots for navigation-link

Before	After

t-hamano

Thanks for the update!

Sorry, I'm starting to think that since the TextControl component is so widely used, it might be better to address it in a separate PR. Can this PR address just the InputControl component?

t-hamano · 2024-12-27T09:23:47Z

packages/components/src/input-control/styles/input-control-styles.tsx

+		&[type='email'],
+		&[type='url'] {
+			/* rtl:ignore */
+			direction: ltr;
+		}


If you reference the props directly, you should be able to output CSS conditionally. A possible approach would be something like this:

Details

diff --git a/packages/components/src/input-control/styles/input-control-styles.tsx b/packages/components/src/input-control/styles/input-control-styles.tsx index 39eea8fdb0..ece01451db 100644 --- a/packages/components/src/input-control/styles/input-control-styles.tsx +++ b/packages/components/src/input-control/styles/input-control-styles.tsx @@ -4,7 +4,7 @@ import type { SerializedStyles } from '@emotion/react'; import { css } from '@emotion/react'; import styled from '@emotion/styled'; -import type { CSSProperties, ReactNode } from 'react'; +import type { CSSProperties, ReactNode, HTMLInputTypeAttribute } from 'react'; /** * Internal dependencies @@ -141,6 +141,7 @@ type InputProps = { dragCursor?: CSSProperties[ 'cursor' ]; paddingInlineStart?: CSSProperties[ 'paddingInlineStart' ]; paddingInlineEnd?: CSSProperties[ 'paddingInlineEnd' ]; + type?: HTMLInputTypeAttribute; }; const disabledStyles = ( { disabled }: InputProps ) => { @@ -262,6 +263,15 @@ const dragStyles = ( { isDragging, dragCursor }: InputProps ) => { `; }; +const directionStyles = ( { type }: InputProps ) => { + if ( type !== 'url' && type !== 'email' ) { + return ''; + } + return css` + direction: ltr; + `; +}; + // TODO: Resolve need to use &&& to increase specificity // https://github.com/WordPress/gutenberg/issues/18483 @@ -283,6 +293,7 @@ export const Input = styled.input< InputProps >` ${ fontSizeStyles } ${ sizeStyles } ${ customPaddings } + ${ directionStyles } &::-webkit-input-placeholder { line-height: normal;

Any reason why we would prefer this over plain CSS selectors? I think in general we should use plain CSS instead of JS when possible, since it will be simpler both in terms of lines of code and runtime work. Another reason is that we are actually planning to move off of CSS-in-JS (#66806).

Any reason why we would prefer this over plain CSS selectors?

I did it for consistency with existing approaches (sizeStyles, customPaddings, etc.). But if we are planning to move off of CSS-in-JS, I think the plain CSS is better.

Hey @t-hamano , I have reverted back to using CSS. Please review my work once again.

im3dabasia · 2024-12-27T15:58:38Z

Hey @t-hamano ,

Thank you for your insightful suggestions on conditionally implementing the CSS. I truly appreciate the feedback, and I’m learning a lot from it.

I have made the changes you requested and have created this PR specifically to incorporate the updates to the <InputControl> component. However, there are two instances where I’m unsure if type="url" is strictly necessary. The code suggests it’s for handling URL-related input, but I would appreciate your input on whether it's needed in these cases.

Looking forward to your thoughts!

InputControl component

gutenberg/packages/fields/src/fields/slug/slug-edit.tsx

Lines 88 to 119 in d517683

    
           <InputControl 
        
           	__next40pxDefaultSize 
        
           	prefix={ 
        
           		<InputControlPrefixWrapper> 
        
           			/ 
        
           		</InputControlPrefixWrapper> 
        
           	} 
        
           	suffix={ 
        
           		<Button 
        
           			__next40pxDefaultSize 
        
           			icon={ copySmall } 
        
           			ref={ copyButtonRef } 
        
           			label={ __( 'Copy' ) } 
        
           		/> 
        
           	} 
        
           	label={ __( 'Link' ) } 
        
           	hideLabelFromVision 
        
           	value={ slug } 
        
           	autoComplete="off" 
        
           	spellCheck="false" 
        
           	type="text" 
        
           	className="fields-controls__slug-input" 
        
           	onChange={ ( newValue?: string ) => { 
        
           		onChangeControl( newValue ); 
        
           	} } 
        
           	onBlur={ () => { 
        
           		if ( slug === '' ) { 
        
           			onChangeControl( originalSlugRef.current ); 
        
           		} 
        
           	} } 
        
           	aria-describedby={ postUrlSlugDescriptionId } 
        
           />

gutenberg/packages/editor/src/components/post-url/index.js

Lines 111 to 162 in d517683

    
           <InputControl 
        
           	__next40pxDefaultSize 
        
           	prefix={ 
        
           		<InputControlPrefixWrapper> 
        
           			/ 
        
           		</InputControlPrefixWrapper> 
        
           	} 
        
           	suffix={ 
        
           		<InputControlSuffixWrapper variant="control"> 
        
           			<Button 
        
           				icon={ copySmall } 
        
           				ref={ copyButtonRef } 
        
           				size="small" 
        
           				label="Copy" 
        
           			/> 
        
           		</InputControlSuffixWrapper> 
        
           	} 
        
           	label={ __( 'Slug' ) } 
        
           	hideLabelFromVision 
        
           	value={ forceEmptyField ? '' : postSlug } 
        
           	autoComplete="off" 
        
           	spellCheck="false" 
        
           	type="text" 
        
           	className="editor-post-url__input" 
        
           	onChange={ ( newValue ) => { 
        
           		editPost( { slug: newValue } ); 
        
           		// When we delete the field the permalink gets 
        
           		// reverted to the original value. 
        
           		// The forceEmptyField logic allows the user to have 
        
           		// the field temporarily empty while typing. 
        
           		if ( ! newValue ) { 
        
           			if ( ! forceEmptyField ) { 
        
           				setForceEmptyField( true ); 
        
           			} 
        
           			return; 
        
           		} 
        
           		if ( forceEmptyField ) { 
        
           			setForceEmptyField( false ); 
        
           		} 
        
           	} } 
        
           	onBlur={ ( event ) => { 
        
           		editPost( { 
        
           			slug: cleanForSlug( 
        
           				event.target.value 
        
           			), 
        
           		} ); 
        
           		if ( forceEmptyField ) { 
        
           			setForceEmptyField( false ); 
        
           		} 
        
           	} } 
        
           	aria-describedby={ postUrlSlugDescriptionId } 
        
           />

im3dabasia · 2024-12-28T09:06:56Z

@t-hamano, I’ll be opening a new PR with the changes to the component shortly and will link it here once it's ready.

t-hamano

@im3dabasia Thanks for the update. Finally, it would be nice to add a CHANGELOG entry. In my opinion, this is a bug fix.

@WordPress/gutenberg-components

I think this PR is OK to ship, but please note that it will make a visual change to the placeholder. The text will be left-aligned regardless of whether it is an LTR or RTL language:

Ideally maybe only the placeholder should be right-aligned, but for some reason the code below didn't work for me:

diff --git a/packages/components/src/input-control/styles/input-control-styles.tsx b/packages/components/src/input-control/styles/input-control-styles.tsx
index db24a5e60f..3fc293e9c3 100644
--- a/packages/components/src/input-control/styles/input-control-styles.tsx
+++ b/packages/components/src/input-control/styles/input-control-styles.tsx
@@ -292,6 +292,11 @@ export const Input = styled.input< InputProps >`
                &[type='url'] {
                        /* rtl:ignore */
                        direction: ltr;
+
+                       &::-webkit-input-placeholder {
+                               // For RTL languages, the value changes to "rtl".
+                               direction: ltr !important;
+                       }
                }
        }
 `;

Furthermore, we cannot know in advance whether the text that goes into the placeholder is for an RTL language or whether it is something that is meant to be displayed in LTR, such as a URL.

In any case, since the text doesn't become unreadable, I think it's fine to always left-aligned the placeholder.

im3dabasia · 2024-12-28T10:06:42Z

@im3dabasia Thanks for the update. Finally, it would be nice to add a CHANGELOG entry. In my opinion, this is a bug fix.

@t-hamano , I'm not quite sure how to create a CHANGELOG entry or which CHANGELOG I should add an entry to. I'd really appreciate it if you could guide me here.

t-hamano · 2024-12-30T07:05:49Z

@im3dabasia No need to create a new file, just access this file and add the new line here.

Essentially, if any changes are made to the @wordpress/components package, those changes must be added to a changelog file. Otherwise, CI will fail (although this CI is not required check).

tyxla · 2024-12-30T09:39:13Z

@im3dabasia Thanks for the update. Finally, it would be nice to add a CHANGELOG entry. In my opinion, this is a bug fix.

@WordPress/gutenberg-components

I think this PR is OK to ship, but please note that it will make a visual change to the placeholder. The text will be left-aligned regardless of whether it is an LTR or RTL language:

Ideally maybe only the placeholder should be right-aligned, but for some reason the code below didn't work for me:
diff --git a/packages/components/src/input-control/styles/input-control-styles.tsx b/packages/components/src/input-control/styles/input-control-styles.tsx
index db24a5e60f..3fc293e9c3 100644
--- a/packages/components/src/input-control/styles/input-control-styles.tsx
+++ b/packages/components/src/input-control/styles/input-control-styles.tsx
@@ -292,6 +292,11 @@ export const Input = styled.input< InputProps >`
                &[type='url'] {
                        /* rtl:ignore */
                        direction: ltr;
+
+                       &::-webkit-input-placeholder {
+                               // For RTL languages, the value changes to "rtl".
+                               direction: ltr !important;
+                       }
                }
        }
 `;
Furthermore, we cannot know in advance whether the text that goes into the placeholder is for an RTL language or whether it is something that is meant to be displayed in LTR, such as a URL.

In any case, since the text doesn't become unreadable, I think it's fine to always left-aligned the placeholder.

According to the spec, when the placeholder needs to be with a different directionality than the content, we wrap contents with ‫ and ‮, so that might be a better alternative, see spec here.

im3dabasia · 2024-12-30T12:07:15Z

Hey @t-hamano and @tyxla, I’ve made the requested changes. Please take a look when you have a moment.

tyxla · 2024-12-30T12:19:50Z

@im3dabasia thanks for working on it!

However, @t-hamano mentioned that the &::-webkit-input-placeholder approach didn't work for him. Also, this could only work for webkit browsers, so it wouldn't work for Firefox for example.

Furthermore, as I mentioned above, the spec recommends a different approach, have you tried that?

im3dabasia · 2024-12-30T13:56:08Z

I tried a combination of approaches.. sharing with you the results

trunk

The entire placeholder text is right-aligned, and the ellipsis is placed first, followed by the text itself.

Current branch

The placeholder is left-aligned, with the text displayed first, followed by the ellipsis.

These are the 3 approaches I tried:

1. placeholder={ "‫ " + __( 'Enter URL here…' ) + " ‮" }

The entire placeholder is left-aligned, and the ellipsis appears after the text.

placeholder={ `‫ ${ __( 'Enter URL here…' ) } ‮` }

The entire placeholder is left-aligned, and the ellipsis appears after the text.

placeholder="‫ Enter URL here… ‮"

The placeholder is left-aligned, but the ellipsis appears before the text.

Based on my understanding, the goal is for the placeholder text to be in RTL (right-to-left), just like plain text would be, and for the placeholder to be right-aligned within the input box. This means the placeholder text should be displayed in RTL, but the input box itself should remain rendered in LTR, with only the placeholder text aligned and displayed in RTL.

During my experimentation, I was able to achieve the RTL text alignment as shown in Case 3 with what @tyxla suggested. However, I found that when I removed the __() translation function and used plain text, the text direction switched to RTL. The resulted text was RTL but was left aligned, which is not the desired behavior. The alignment still remains incorrect. Also removing the translation function isn't a suitable solution.

EDIT:

It's also worth mentioning that after adding the HTML entities in the placeholder (as shown in Case 3), the output for an LTR language is as follows:

Hardcoding the entities will cause an override for all languages, both LTR and RTL. While adding them will fix the alignment in RTL languages, it will disrupt the alignment in LTR languages.

I believe the approach of using ‫ and ‮ may not be ideal for this scenario, as the placeholder text will vary based on the user's language, and the entire text will switch between LTR and RTL. This method seems more appropriate when the website is primarily in a base language (e.g., English), with occasional RTL words embedded. In such cases, the entities approach ensures correct directionality for those specific words. However, it may not be suitable when the entire placeholder text changes based on the language.

Please let me know your thoughts on this.

tyxla · 2024-12-30T15:18:30Z

Thanks for trying it out 👍 If that approach doesn't work, we might want to resort to the placeholder one.

I know we've historically used all (&::-webkit-input-placeholder, &::-moz-placeholder, &:-ms-input-placeholder) or used ::placeholder which should have browser-wide support at this time. Perhaps that might be something to try out.

im3dabasia · 2025-01-01T16:30:20Z

I know we've historically used all (&::-webkit-input-placeholder, &::-moz-placeholder, &:-ms-input-placeholder) or used ::placeholder which should have browser-wide support at this time. Perhaps that might be something to try out.

I tried the approaches you mentioned (using &::-webkit-input-placeholder, &::-moz-placeholder, &:-ms-input-placeholder, or ::placeholder), but none of them worked. They do not allow us to explicitly set the placeholder and the input box to have different directions.

As an alternative, I used text-align: right. This works, but I’m not sure whether it is the most correct approach.

trunk	with text-align:right

I have added screenshots comparing the text with direction: rtl and text-align: right, specifically in Arabic. The difference lies in how the punctuation (the full stop) is placed.

Though the text is rendered correctly, the placement of the final punctuation (.) differs.

Text align right	direction: rtl

Here is a screen recording showing the result after I applied this CSS:

Final Code

&[type='email'],
&[type='url'] {
	/* rtl:ignore */
	direction: ltr;

	[dir='rtl'] &::placeholder {
		text-align: right;
	}
}

Screen.Recording.2025-01-01.at.9.34.14.PM.mov

I would love to hear your thoughts on this approach. Would setting the text-align of the placeholder to right when dir=rtl work as expected, or do you see any potential issues?

cc: @tyxla and @t-hamano

t-hamano · 2025-01-02T04:14:22Z

@im3dabasia Thank you for testing various things.

Based on my understanding, the goal is for the placeholder text to be in RTL (right-to-left), just like plain text would be, and for the placeholder to be right-aligned within the input box. This means the placeholder text should be displayed in RTL, but the input box itself should remain rendered in LTR, with only the placeholder text aligned and displayed in RTL.

Perhaps we should first discuss whether this is an ideal behavior.

If the placeholder text is normal RTL text, it is expected to be RTL and right-aligned:

But the placeholder can be changed. Some developers may want to display a sample URL as the placeholder text. In this case, the right alignment may feel a bit unnatural:

Probably the ideal solution would be to parse the placeholder property and make it left-aligned and LTR if it's a url/email, and right-aligned and RTL otherwise, but that would be a bit more complicated to implement.

Personally, I'd prefer to always left-align regardless of what the placeholder text is. What do you think?

im3dabasia · 2025-01-02T08:31:40Z

Personally, I'd prefer to always left-align regardless of what the placeholder text is. What do you think?

I agree that keeping it left-aligned would be a good option, as having different alignments for the placeholder and the input box can make things unnecessarily complicated.

Out of curiosity, I checked how other sites handle RTL languages for email input fields specifically. Here's what I found—I’ll attach some screenshots for reference. Interestingly, I noticed that they align the Arabic text to the left.

Screenshots

As @t-hamano rightly pointed out, the end developer might use a URL or email as a placeholder. In such cases, aligning the text to the right would indeed be incorrect.

mirka · 2025-01-02T09:54:57Z

Personally, I'd prefer to always left-align regardless of what the placeholder text is. What do you think?

Agreed. Let's go with this for now, especially because it is simpler 😄

tyxla · 2025-01-02T10:01:21Z

Happy to go with the simplest way 👍

t-hamano

LGTM! I think this is the best approach for now.

Audio block and Embed block:

LTR language	RTL language

Storybook:

f4c8ecd8af00e5b9cfc3c0ebe5a088b1.mp4

@WordPress/gutenberg-components I would be grateful for any additional feedback on whether it's OK to ship this PR.

t-hamano · 2025-01-03T12:07:11Z

packages/components/CHANGELOG.md

@@ -25,6 +25,7 @@
 -   `BoxControl`: Better respect for the `min` prop in the Range Slider ([#67819](https://github.com/WordPress/gutenberg/pull/67819)).
 -   `FontSizePicker`: Add `display:contents` rule to fix overflowing text in the custom size select. ([#68280](https://github.com/WordPress/gutenberg/pull/68280)).
 -   `BoxControl`: Fix aria-valuetext value ([#68362](https://github.com/WordPress/gutenberg/pull/68362)).
+-   `InputControl`: Ensures email and url inputs have consistent LTR alignment in RTL languages ([#65893](https://github.com/WordPress/gutenberg/issues/65893)).


Suggested change

- `InputControl`: Ensures email and url inputs have consistent LTR alignment in RTL languages ([#65893](https://github.com/WordPress/gutenberg/issues/65893)).

- `InputControl`: Ensures email and url inputs have consistent LTR alignment in RTL languages ([#68188](https://github.com/WordPress/gutenberg/pull/68188)).

This must be the pull request number, not the issue number.

In addition to that, it needs to be put under the "Unreleased" section, instead of under an already released one.

@im3dabasia

It would be a good idea to add a Bug Fixes section under the Unreleased section and add an entry there. Like this:

 ## Unreleased ### Bug Fixes - `InputControl`: Ensures email and url inputs have consistent LTR alignment in RTL languages ([#68188](https://github.com/WordPress/gutenberg/pull/68188)). ## 29.1.0 (2025-01-02)

@tyxla and @t-hamano ,
Thank you for the guidance; I appreciate it!

tyxla

LGTM 👍

Should be good to go once the CHANGELOG issues are addressed.

tyxla · 2025-01-03T12:45:10Z

packages/components/CHANGELOG.md

@@ -25,6 +29,7 @@
 -   `BoxControl`: Better respect for the `min` prop in the Range Slider ([#67819](https://github.com/WordPress/gutenberg/pull/67819)).
 -   `FontSizePicker`: Add `display:contents` rule to fix overflowing text in the custom size select. ([#68280](https://github.com/WordPress/gutenberg/pull/68280)).
 -   `BoxControl`: Fix aria-valuetext value ([#68362](https://github.com/WordPress/gutenberg/pull/68362)).
+-   `InputControl`: Ensures email and url inputs have consistent LTR alignment in RTL languages ([#68188](https://github.com/WordPress/gutenberg/pull/68188)).


Sorry for the trouble, but we can now remove this one now that it's included in the "Unreleased" section.

Suggested change

- `InputControl`: Ensures email and url inputs have consistent LTR alignment in RTL languages ([#68188](https://github.com/WordPress/gutenberg/pull/68188)).

@tyxla , Fixed it . Thank you for the quick review!

tyxla

LGTM 👍

Thanks again @im3dabasia 🙌

im3dabasia requested review from ellatrix, ajitbohra and fabiankaegy as code owners December 20, 2024 11:38

im3dabasia marked this pull request as draft December 20, 2024 11:40

im3dabasia marked this pull request as ready for review December 25, 2024 10:20

t-hamano reviewed Dec 26, 2024

View reviewed changes

t-hamano added [Type] Bug An existing feature does not function as intended l10n Localization and translations best practices labels Dec 26, 2024

t-hamano requested a review from a team December 26, 2024 02:47

im3dabasia requested a review from t-hamano December 26, 2024 14:24

t-hamano reviewed Dec 27, 2024

View reviewed changes

im3dabasia requested a review from t-hamano December 27, 2024 15:59

t-hamano reviewed Dec 28, 2024

View reviewed changes

im3dabasia force-pushed the fix/add-ltr-for-url-email-65893 branch from 4ec51ae to 8606e29 Compare December 30, 2024 12:05

im3dabasia requested a review from t-hamano December 30, 2024 12:07

im3dabasia requested a review from mirka January 3, 2025 10:32

im3dabasia added 10 commits January 3, 2025 16:04

fix: Add ltr for email and url

854ceca

style: Add CSS for email/url in component

c8cc7de

fix: Revert extra file change

8fedafe

fix: add ltr for email and url in the textcontrol component

f79f6e9

revert: Changes for textcontrol reverted

a5f99f5

fix: Add directionStyles for input-control-styles

e1b2203

style: Add direction ltr for email and url for rtl languages

136e669

style: Add ltr for placeholder

c1f30f9

doc: Add log for InputControl ltr alignment change

ddc78cd

fix: Remove ltr CSS for placeholder

7056c85

im3dabasia force-pushed the fix/add-ltr-for-url-email-65893 branch from 12552e1 to 7056c85 Compare January 3, 2025 10:37

t-hamano approved these changes Jan 3, 2025

View reviewed changes

tyxla reviewed Jan 3, 2025

View reviewed changes

doc: Add Log in unreleased section and updated log to refer to PR

a53b66c

tyxla reviewed Jan 3, 2025

View reviewed changes

doc: Remove log in the Bug Fixes header

26ab442

tyxla approved these changes Jan 3, 2025

View reviewed changes

tyxla enabled auto-merge (squash) January 3, 2025 12:52

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Fix text direction for URL and email fields in block editor for RTL languages #68188

Fix text direction for URL and email fields in block editor for RTL languages #68188

im3dabasia commented Dec 20, 2024

github-actions bot commented Dec 20, 2024 •

edited

Loading

im3dabasia commented Dec 25, 2024

t-hamano left a comment

im3dabasia commented Dec 26, 2024 •

edited

Loading

t-hamano left a comment

t-hamano Dec 27, 2024

mirka Dec 27, 2024

t-hamano Dec 28, 2024

im3dabasia Dec 28, 2024

im3dabasia commented Dec 27, 2024 •

edited

Loading

im3dabasia commented Dec 28, 2024

t-hamano left a comment

im3dabasia commented Dec 28, 2024

t-hamano commented Dec 30, 2024

tyxla commented Dec 30, 2024

im3dabasia commented Dec 30, 2024

tyxla commented Dec 30, 2024

im3dabasia commented Dec 30, 2024 •

edited

Loading

tyxla commented Dec 30, 2024

im3dabasia commented Jan 1, 2025

t-hamano commented Jan 2, 2025

im3dabasia commented Jan 2, 2025

mirka commented Jan 2, 2025

tyxla commented Jan 2, 2025

t-hamano left a comment

t-hamano Jan 3, 2025

tyxla Jan 3, 2025

t-hamano Jan 3, 2025

im3dabasia Jan 3, 2025

tyxla left a comment

tyxla Jan 3, 2025

im3dabasia Jan 3, 2025

tyxla left a comment

	- `InputControl`: Ensures email and url inputs have consistent LTR alignment in RTL languages ([#65893](https://github.com/WordPress/gutenberg/issues/65893)).
	- `InputControl`: Ensures email and url inputs have consistent LTR alignment in RTL languages ([#68188](https://github.com/WordPress/gutenberg/pull/68188)).

Fix text direction for URL and email fields in block editor for RTL languages #68188

Are you sure you want to change the base?

Fix text direction for URL and email fields in block editor for RTL languages #68188

Conversation

im3dabasia commented Dec 20, 2024

What?

Why?

Screenshots or screencast

Embed Block

RSS Block

Audio Block which uses url-popover component

github-actions bot commented Dec 20, 2024 • edited Loading

im3dabasia commented Dec 25, 2024

t-hamano left a comment

Choose a reason for hiding this comment

im3dabasia commented Dec 26, 2024 • edited Loading

Screenshots for navigation-link

t-hamano left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

im3dabasia commented Dec 27, 2024 • edited Loading

im3dabasia commented Dec 28, 2024

t-hamano left a comment

Choose a reason for hiding this comment

im3dabasia commented Dec 28, 2024

t-hamano commented Dec 30, 2024

tyxla commented Dec 30, 2024

im3dabasia commented Dec 30, 2024

tyxla commented Dec 30, 2024

im3dabasia commented Dec 30, 2024 • edited Loading

trunk

Current branch

EDIT:

tyxla commented Dec 30, 2024

im3dabasia commented Jan 1, 2025

t-hamano commented Jan 2, 2025

im3dabasia commented Jan 2, 2025

mirka commented Jan 2, 2025

tyxla commented Jan 2, 2025

t-hamano left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

tyxla left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

tyxla left a comment

Choose a reason for hiding this comment

github-actions bot commented Dec 20, 2024 •

edited

Loading

im3dabasia commented Dec 26, 2024 •

edited

Loading

im3dabasia commented Dec 27, 2024 •

edited

Loading

im3dabasia commented Dec 30, 2024 •

edited

Loading