First identified here http://drupal.org/node/732914#comment-3455956
I'm having a very hard time figuring out how to reproduce this - but it just seems that *sometimes* locale.css loads for this path.
Right now in Drupal this has no discernible affect on the exposed filters at admin/content because other CSS overrides locale.css, however if we apply the patch from #732914: Improve the markup/CSS for content and user filter forms those overrides are removed and if locale.css loads it messes up the filters.
From what I can tell locale.css should not be loading on this page so I is this a bug?
I'm attaching a screenshot - this taken before the #732914 patch, you can clearly see locale.css is loading but being overriden by other CSS (node and user css actually).
| Comment | File | Size | Author |
|---|---|---|---|
| #5 | locale.css_.png | 10.53 KB | sun |
| #5 | drupal.locale-css.5.patch | 1.06 KB | sun |
| locale-form-item2.png | 51.44 KB | Jeff Burnz |
Comments
Comment #1
sunsubscribing
Comment #2
jacineFile issue aside, I think this CSS is potentially problematic because the field names are very generic:
This seems safer, and actually more efficient, minus the fact that it's using an ID as opposed to a class:
Comment #3
jacineLooking at the rest of the CSS in that file, it also makes more sense in the context of the existing code to use the ID: http://drupalcode.org/viewvc/drupal/drupal/modules/locale/locale.css?&vi...
Comment #4
mertskeli commented[edit]
I do not have locale.css at admin/content. (I have enabled Locale module but have not touched anything in it since that.)
Comment #5
sunIndeed a problem:
Attached patch fixes the problem.
Usage of a HTML ID is indeed unfortunate, but the other existing styles for the same form are using it too already.
Comment #6
jacineLooks like a fix for this was committed today: #953010: locale.css causes vertical tabs to overlap the language selection drop-down menu in node edit forms.
Comment #7
Jeff Burnz commentedAwesome, at last :)