there is a secondary tabs conflict with views.. see screenshot

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

JohnAlbin’s picture

:-(

KrisBulman’s picture

there are some pretty specific overrides from Views going on.. i wish Views were more pared down with less specificity, it would certainly make things easier to override.

one solution might be to drop the ul from .primary & .secondary, and set the .secondary li li to float:none

barraponto’s picture

@KrisBulman another would be cleaning up Views and CTools CSS. It is awfully haunted by the past. Seriously, a few weeks ago I removed Garland-specific cruft from CTools. And I believe it was D5 cruft.
Let's clean it up.

KrisBulman’s picture

@barraponto I agree, it's massive and really rough around the edges. I'm game for cleaning it up instead of hacking zen tabs to work around it. Mind you, if it's not cleaned up by 7.x-5.x release, we will have to do something here so we better get cracking.

JohnAlbin’s picture

:-)

Can you post a link to the related issue in the Views queue so we can track it here?

JohnAlbin’s picture

Priority: Normal » Major
Issue tags: +7.x-5.0 blocker

Mind you, if it's not cleaned up by 7.x-5.x release, we will have to do something here so we better get cracking.

Cough. Cough. I'm itching to tag a release. :-)

KrisBulman’s picture

I'm going to fess up here, I never created a views issue for it, and I don't think a bug fix release of views is going to be released in the time frame we want even if we do get it committed.. yesterday.

I'll start working on a zen patch now.

KrisBulman’s picture

Status: Active » Needs review
FileSize
1011 bytes
11.49 KB
11.54 KB

OK, this at least makes the tabs dropdown usable and I don't think it's an issue blocker. The problem is now purely cosmetic, leaving the active hover links white, on a light grey background.

hovering on an active secondary tab

There are a couple future problems here up for discussion..

* Views depends on system.menus.css, Zen does not
* Views adds an extra layer of specificity by prepending the class .views-displays to all menu overrides, which as a result overrides zen tabs css

JohnAlbin’s picture

Assigned: Unassigned » KrisBulman
FileSize
2.46 KB

I decided to tackle this from the previously empty views-styles.scss file.

I don't really like the idea of tweaking our tabs styling by adding a little specificity to match what Views expects. Instead we can apply the minimal amount of code to override our tabs styling from bleeding into the Views admin. That leaves our tab styling at a lower specificity and allows people to yank the entire Views tabs styling out if their sub-theme isn't handling admin pages. (Which is why I never noticed this issue, btw.)

Kris, can you review? Or Capi?

KrisBulman’s picture

Status: Needs review » Reviewed & tested by the community

your patch has whitespace on line 89.

I applied it manually, and it looks good, even in IE. I know it's not something you are overriding in this patch, and probably has no place, but a 1pixel drop on the '+' icon (and icon in hover state) would do wonders. :P

*EDIT* removed line about not providing compiled starterkit css, it's there. what's not there is the views-styles css for zen-internals.

JohnAlbin’s picture

Title: tabs css conflict with views » Tabs css conflict with views
Status: Reviewed & tested by the community » Fixed

Ok. Fixed the whitespace. http://drupalcode.org/project/zen.git/commitdiff/9a87590

I notice your patch doesn't include compiled starterkit css

Actually the patch did include a compiled CSS version of the Sass.

KrisBulman’s picture

yes, i edited my post, sorry about that.

JohnAlbin’s picture

Ah, yes. zen-internals.

There's actually a little script in there. zen-internals/css/generate.sh that I run occasionally to make sure the CSS of Zen stays in sync with the STARTERKIT. You can include or not include the changes to zen-internals/css in your patches; it doesn't really matter. :-)

Automatically closed -- issue fixed for 2 weeks with no activity.