search box style is wrong
DominatorMaster - March 11, 2008 - 13:36
| Project: | Localization client |
| Version: | 6.x-1.1 |
| Component: | User interface |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed |
Description
Hi, just tryed this module, is awesome but it have saw some bugs like the one i'll try to explain here (sorry my abd english, isn't my mothertongue).
When you type the name of a string in the searchbox of the AJAX textfield all works good, but if you have to cancel a letter or the entire word, then you have to hit the delete key and/or the backspace one, the AJAX interface mess up. I've atatched a screenshoot to help you to understand this bug.
Good Work,
Mat.
| Attachment | Size |
|---|---|
| bug.jpg | 40.06 KB |
#1
Same here
#2
Experienced similar (and sometimes even worse) issues myself in Safari too. Looking forward to any fix someone might work out!
#3
I also once had this problem after I checked out a newer version from CVS but without completely refreshing (Ctrl-F5) the browser. Things went OK after I accidentally cleared all private data.
#4
Ok. It seems to me that the problem is caused by the SIZE parameter of the textbox, which is set in l10n_client.module.
The size is set to 60 (way too much for a non-1600 wide screen). Set it to 40 and the screen gets better.
In fact, there is a button under the box (you can go to it tabbing out from the buggy textbox). It is hided by the fixed height form, but it's there, under the lower border of the page. AFAIK it's completely useless, so I simply disabled it (but be warned, I'm not really sure of this). Resulting function on my l10n_client.module is:
/*** Search form for string list
*/
function l10n_client_search_form() {
global $language;
// Selector and editing form.
$form = array();
$form['search'] = array(
'#type' => 'textfield',
'#size' => '40'
);
//$form['clear-button'] = array(
// '#value' => "<input id='search-filter-clear' class='form-submit' type='button' value='". t('X') ."'/>",
//);
return $form;
}
Last note: I use fckeditor and captcha and the submit button on the right side was going out of sight very often. So I resized edit-form also. To do this simply change the css height from the default value to a more suitable one (in my case, 6em):
#l10n-client-form .form-textarea {//height:13em;
height:6em;
font-size:1em; line-height:1.25em;
width:95%;}
Probably every styling should be done via css, but localization client is just working well enough.
#5
gremlinc5: that X button is useful to clear the search input field with one click. That resembles X buttons browser use in their search fields for example.
#6
Yep. But you can simply delete the content of the search textbox.
"Useless" is not the right term, maybe better "redundant".
Anyway, the problem with that button is: with Firefox (and Explorer BTW), it goes under the lower border of the screen, so if you tab out of the search box, you mess up the viewport. When I inspected the generated HTML with Firebug, I saw that the textbox is surrounded by a div tag with css display property set to block instead of inline.
Since I don't know how to fix that, for my personal site, I prefered renounce the commodity and simplify the interface.
Mine is not a patch (I am in no way a drupal developer), it's just a quick-and-dirty way to accomodate the interface with Firefox (and Explorer) and some additional plugins.
Just a thought: wouldn't be better if the interface was made as a popup? I think I'll be posting about this in another thread.
Anyway, this tool is invaluable for fast translation. Great work!
#7
This whole thing can be fixed without changing the code as in #4, but simply patching the CSS, per the attached patch.
#8
Please do not add
+ direction:ltr;in modules. This should be a global style on body or html element...#9
@hass - it is added since it does not work correctly on RTL themes otherwise. The l10n_client form should stay "ltr" no matter what the active language is.
True, I should have mentioned that the patch fixes this as well.. sorry.
#10
If this does not work in RTL themes, why are you not adding it to the RTL file? That's cleaner... on the other side you break "direction" inheritance now... Is this again a RTL bug that is fixed in FF3?
OT: Do you have some good links about RTL CSS bugs? I'm really searching for this, but i cannot find any "reference" site. I only found "one" bug in the IE7 blog... aside i'm shocked about IE8 and RTL - to say short - really *nothing* works here - damn buggy beta :-(((. Hopefully your links are in Hebrew/Arabic what i cannot read/write...
#11
If this does not work in RTL themes, why are you not adding it to the RTL file? That's cleaner... on the other side you break "direction" inheritance now... Is this again a RTL bug that is fixed in FF3?
I am not sure I understand what you mean here. This is unrelated to FF. It is related to the fact that RTL CSS assumes the whole site should become RTL, while this specific component should always be LTR, so I think it should be mentioned specifically.
I did something similar in #127295: Module numbers display incorrectly if direction is set to RTL and it was accepted. Feel free to edit the patch as you see fit, I'd like to see it committed with or without the direction fix.
OT: Do you have some good links about RTL CSS bugs?
I might have some info. Will PM you.
#12
I wonder... i thought it was a consense that we only add required styles... and if LTR does not required this definition, why are we adding it!? If the RTL layout requires this declaration we can add it there. We could better distinguish between bugfixes made only for RTL if they are in a RTL file. Nobody will understand why you add this in a LTR theme/core if the html or body element already have a direction to LTR. This is double declaration in a LTR layout that makes no big sense as the LTR page is correctly rendered without this declaration...
I'm only arguing not to mix LTR styles with RTL bugfixes.
#13
If I read that right, hass would like to see an l10n_client-rtl.css file with that LTR definition.
#15
Yep, that's all.
#16
I've just fixed the form styling in another commit independently. Now I've added an l10n_client-rtl.css file with the suggested rule, and committed it. Hope it fixes the RTL issues as well :) Thanks for the suggestions.
#17
Automatically closed -- issue fixed for two weeks with no activity.