Here for the community? On May 9th, we'll be in New Orleans. Don’t miss out!
there is a secondary tabs conflict with views.. see screenshot
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
@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.
@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.
Can you post a link to the related issue in the Views queue so we can track it here?
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. :-)
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.
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
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?
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.
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.
yes, i edited my post, sorry about that.
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.
Drupal is a registered trademark of Dries Buytaert.