Opened 14 years ago
Closed 12 years ago
#16834 closed enhancement (fixed)
UI problem in Permalinks SubPanel (on RTL sites)
Reported by: |
|
Owned by: |
|
---|---|---|---|
Milestone: | 3.6 | Priority: | normal |
Severity: | normal | Version: | 3.1 |
Component: | RTL | Keywords: | rtl-feedback has-patch 3.6-early |
Focuses: | Cc: |
Description
hi,
i want to report a UI problem in RTL sites, on the Settings->Permalinks SubPanel.
See the Attached screenshots.
Attachments (11)
Change History (39)
#3
@
14 years ago
- Keywords 3.2-early added; needs-ui ui-feedback removed
- Milestone changed from Awaiting Review to Future Release
#6
@
14 years ago
@ramiy - I don't think this would work as the table will stretch to the far end.
https://skitch.com/yoavf/rai1h/wordpress
However, we should add some bid-overriding there so that the slashes are in the right place.
16834-override.diff does that.
#12
@
12 years ago
Yoav, i tried to recreate this on WordPress350-Beta3, but it's not working.
Tried both direction: lrt; and unicode-bidi: override;.
Fixed this using:
.options-permalink-php code, #permalink_structure { float:left; }
(on wp-admin-rtl.css:1322)
Here is the result - http://i.imgur.com/cnmNa.png
#14
in reply to:
↑ 13
@
12 years ago
Replying to ocean90:
Does attachment:16834.2.patch fix the issue for you?
#15
@
12 years ago
Mhh, that doesn't look like my screenshot from my patch, are you sure you are using the right one? Which browser?
#16
@
12 years ago
16834.left-edge.patch is an attempt at left edge alignment, as in the original patch. Fixes table stretching mentioned in comment:6.
Screenshot: 16834.left-edge.png.
Perhaps unicode-bidi: embed
should be applied to .code, code
instead, along with direction: ltr
:
http://core.trac.wordpress.org/browser/tags/3.4.2/wp-admin/css/wp-admin-rtl.dev.css#L60
#18
@
12 years ago
16834.left-edge.patch looks good too.
#20
@
12 years ago
-1 for left alignment. At least for me it looks very strange, like I need to stop scanning RTL and move my attention to the left side and find the point in which to start reading again and then adjust to scanning LTR. This is too much mental work.
Keeping alignment to the right like in the image in comment:13 is IMO the better solution. In that case you don't need to scan the whole length of the page to find where does the text starts again.
#21
follow-ups:
↓ 22
↓ 27
@
12 years ago
16834.3.patch refreshes 16834.left-edge.patch.
I also switched the float on #permalink-settings code, #permalink_structure
to float right instead of left to achieve the desired look in 16834.left-edge.png. Otherwise, it looked like this: http://cl.ly/image/0c2b101L3V2n
#22
in reply to:
↑ 21
@
12 years ago
Replying to DrewAPicture:
+1 to 16834.left-edge.png
#23
@
12 years ago
With 16834.3.patch it looks like http://cl.ly/Ojlz, which is IMO the best approach.
@mark-k
In comment:20 you give -1, in comment:22 +1, …?
#24
@
12 years ago
lol, better compromise? going all the way to the left is bad IMO, too hard to read as you have to move your focus a long way on wide screens. having the URL aligned left in the middle of the screen in the same "view frame" is much better.
Right aligning all the way. esthetically just doesn't look very organized. Either of this two options is better then the current situation.
Thinking more of it, the problem with @DrewAPicture's patch is that there will be only limited space for long URLs. Not sure how big this problem is.
#25
@
12 years ago
1+ for http://cl.ly/Ojlz , It's easy to read and looks fine :)
#27
in reply to:
↑ 21
@
12 years ago
- Resolution fixed deleted
- Status changed from closed to reopened
Replying to DrewAPicture:
16834.3.patch refreshes 16834.left-edge.patch.
I also switched the float on
#permalink-settings code, #permalink_structure
to float right instead of left to achieve the desired look in 16834.left-edge.png. Otherwise, it looked like this: http://cl.ly/image/0c2b101L3V2n
Looks like it wasn't properly refreshed :)
In 16834.left-edge.patch, id="permalink-settings"
is applied to the primary table (which would no longer be needed since [22931]).
In 16834.3.patch, id="permalink-settings"
is applied to the secondary table, which doesn't have <code>
tags, and its width is irrelevant. So the patch is actually a refresh of 16834.2.patch (comment:13), mixed with some pieces of 16834.left-edge.patch.
22463.4.patch removes the non-working pieces and also fixes the code suggested when .htaccess
is not writable: 16834.htaccess.png.
The ltr Permalinks SubPanel