When I view the Display Suite field layout for a display with custom regions, the "remove custom regions" block is made display: none. This is because of the following CSS at line 46 in views-admin-rubik.css
/* Hide 'remove' checkboxes. This might be scoped too widely. */
[class*="form-type-checkbox"][class*="remove"] {
display: none;
}
Prescient comment there: it does indeed seem to be scoped too widely! It's targeting an element with the otherwise innocuous class of:
form-item form-type-checkboxes form-item-additional-settings-region-to-block-remove-block-region
This CSS declaration needs to be more tightly scoped, as it currently breaks pages like the DS admin interface. That [class*="remove"] is the cause for concern - "remove" can mean all sorts of things depending on context! - but it can probably be fixed by just adding some more classes based on what we expect this CSS to apply to.
Does anyone have any examples of what views-admin-rubik.css is trying to do here? If you can volunteer one, and you can transcribe Google Chrome's path to element (right-click to Inspect Element, and read the classes and IDs off the bottom status bar) then that'd help work out what classes to add to this declaration.
| Comment | File | Size | Author |
|---|---|---|---|
| #3 | rubik-views-remove-css-class-1315898-3.patch | 337 bytes | gapple |
Comments
Comment #1
modestmoes commentedI am having problems with this. I have a field named 'Date Removed' that get's hidden in the views admin by this line of CSS.
Comment #2
micnap commentedStill a problem. I was having several rules components which had a machine name with the word "remove" in not being displayed in the VBO actions list. http://drupal.org/node/1696218#comment-6801668
Mickey
Comment #3
gappleI ran into this trying to find a configuration item for the views search filter:
Here's a patch that reduces the scope of the selectors from matching any class declaration that contains both "form-type-checkbox" and "remove" anywhere in it, to just matching on both classes.
Comment #4
vuzzbox commentedThe revised CSS rule in #3 works.
Comment #5
haydeniv commentedCommitted: 9fbea37
Thanks!