The CSS selector on drag-and-drop handle needs to be a bit more specific.
Currently, we have just a.tabledrag-handle { .... }, which leaves absolutely no space for themes to define more different styles for links. If the theme have anything more specific than a bare a, it overrides the drag-and-drop definition as well (because theme's CSS come last); then the theme must deal with tabledrag things on its own, which is highly annoying because js-generated code may not be easily observed in a standard browser. Also reuqiring themes to theme standard features independently just to avoid changing them doesn't sound right to me.
My particular use case is as follows: I have underlined links in contents (pretty standard, I believe), but ONLY in contents. The site navigation (and any other links generated outside actual contents) is defined in a different way. To accomplish that, my style.css have simply: .content a { .... }, which I believe to be simple and clean solution. But however, it overrides the drag-and-drop definition now (see screenshot), requiring me to theme d-n-d handle explicitly in my theme, although I have absolutely no intention to change it in any way. Not nice.
The patch makes the selector in system.css one-step-more specific, allowing themes to have different a styles without interference.
| Comment | File | Size | Author |
|---|---|---|---|
| #4 | drupal_tabledrag_rtlfix.patch | 537 bytes | quicksketch |
| drag-underln.png | 40.51 KB | JirkaRybka | |
| d-n-d-css.patch | 462 bytes | JirkaRybka |
Comments
Comment #1
catchWell caught. No way this would break anything but I tested anyway.
Comment #2
gábor hojtsyCommitted this one, thanks.
Comment #3
(not verified) commentedAutomatically closed -- issue fixed for two weeks with no activity.
Comment #4
quicksketchThe more specific classes in the main CSS has caused it to take precedence over the RTL CSS. The handles remain on the left side, leaving the placement in an unhelpful location in RTL languages.
Comment #5
gábor hojtsyIndeed. The /* LTR */ comments are exactly there to alarm to doing such changes in both locations. I am sorry that we overlooked this, and thanks for spotting this. Since the patch is quite trivial, I went ahead and committed it.
Comment #6
quicksketchThanks Gábor!
Comment #7
Anonymous (not verified) commentedAutomatically closed -- issue fixed for two weeks with no activity.