Dropdown styles in Flare 10

[pouliotmax]

My dropdowns are now becoming blue when i click on them (in Flare 10). Anyone can tell me what attribute i can force them to stay black after i click on them

Thx

[Lydia]

I also see a difference between v9 and v10. My dropdown head text becomes green when hovering over it. That was not the case in v9.

In the output, you can see that there is an <a> tag now involved:
<div data-mc-state="open" class="MCDropDown dropDown MCDropDown_Open"><span class="MCDropDownHead dropDownHead"><a href="javascript:void(0);" class="MCDropDownHotSpot dropDownHotspot MCDropDownHotSpot_"><img class="MCDropDown_Image_Icon" src="../Skins/Default/Stylesheets/Images/transparent.gif" alt="Open" data-mc-alt2="Closed">Delete this text and replace it with your own content</a></span>

I suspect that this accounts for the difference. However, I did not find a note on this in the Flare Help.

Did you contact support about this already?

[pouliotmax]

Yep. here's the response :

New changes to dropdowns for 508 compliance requires they get converted to a tags so they can have the alt text applied properly.
It looks like this issue is isolated to IE only for some reason.
If you add the following 2 items to your stylesheet, they will be black for all browsers.

MadCap|dropDownHotspot:link
{
color: #000000;
}
MadCap|dropDownHotspot:visited
{
color: #000000;
}

It works

[Lydia]

Thank you for sharing the solution! My guess would be that more people run into this.

[asmith]

I ran into this problem when I upgraded from v9 as well. The solution provided works great. Thanks for sharing!

[lindseyrix]

That transparent.gif is getting in the way of the other settings we have used in the stylesheet for dropdowns including the dropdown image we set. Where is this auto generated from and how do we get rid of it? Doesn't sound like any of you removed that image.

We did put an image for the DropDown itself, do we need to put it on the DropDownHead instead?

[NorthEast]

Thanks for posting - this bug caught us out too.

Note that the bug affects togglers too, so you may also need to include fixes for:

MadCap|toggler:link
MadCap|toggler:visited

[ChoccieMuffin]

Really glad I read the forums every day - last thing last night I spotted this problem. I knew I'd read about it recently so came straight to this topic (after a bit of hunting for it) and voila', the solution did the trick.

Thumbs up to MadCap Forums and the lovely people who make my job so much easier.

[MCPBecker]

Thank you, thank you. I was also able to use this information to get rid of the border I am using instead of text decoration on my other links.

[Leon Descoteaux]

Be aware that your new CSS settings will not appear in Preview mode, only in a Build (took me way too long to realize this, duh!).

[Paulie]

Thanks for the suggestion. It definitely sent me in the right direction when trying to find a solution that worked for my team. In our case, our drop down heading styles visually match our regular heading styles (which are multiple colours). This means that our online help can be expanded or collapsed, but the drop-down text is displayed in-line in our printed documents and for all intents and purposes looks and behaves like regular headings.

For our specific use case, we were able to use the CSS color: inherit property to pick up the colour that was set in the MadCap:dropDownHead style (which is the parent tag of the MadCap|dropDownHotspot tag).

Our CSS is below:

Code: Select all

MadCap|dropDownHotspot
{
	cursor: hand;
	text-decoration: none;
	color: inherit;
}

MadCap|dropDownHotspot:link,
MadCap|dropDownHotspot:visited
{
	color: inherit;
}

[Rona Kwestel]

Paulie, I think you're describing something that I was trying to achieve at one time, and then gave up on, but I'm not sure I fully understand your solution. I wanted the dropdown hotspot to be the same size and color as the heading level that it supplants in the online version. So, if what I would have in print form is an h2 tag that online will be a dropdown, I would like the dropdown hotspot to have the same styling as the h2 tag, whereas if it was an <h3> tag, then I want it to mimic the h3 tag style.

But now I have another question that I can't quite sort out. For some reason, in preview mode, the spacing of the dropdown hotspots looks good to me, but when I build and view them in the browser (Chrome, in this case), there is an unpleasantly large gap between them. When I inspect the element, I can see that the space above each hotspot is quite significant, even though the only spacing I explicitly define in the stylesheet is as follows:

Code: Select all

MadCap|dropDownHead
{
	color: #fb8615;
	font-size: 16px;
	line-height: 20px;
}

Here is the Flare Preview output:

Hotspots in previewer.png

And here is the Browser view:

Hotspots in browser.png

Even if I comment out the line-height setting, it makes no difference. I can't figure out where all that space is coming from. Any ideas appreciated.

[Paulie]

At a quick glance at my own project, it looks like it is coming from the MapCap Topic.css style sheet.

As a quick workaround, I was able to override this by defining the margins in my style sheet:

Code: Select all

span.dropDownHead
{
margin-top:6px;
margin-bottom:6px;
}

[Rona Kwestel]

Thanks, Paulie. I'm not sure what "span.dropDownHead" is, but I fiddled with both the margin-top/bottom and padding-top/bottom in the MadCap|dropDownHead selector in my stylesheet, and it made no functional difference, as the Inspect Element viewer indicates that the large blue space is neither the padding nor the margin, but the element itself.

dropDownHeadSpacing.png

So, for example, here's the element with padding set to 10px top and bottom:

dropDownHeadPadding.png

And here's the element with margin set to 6 top and bottom:

dropDownHeadMargin.png

The question is, why is my element 46px tall? I could find nothing in the Topic.css or TextEffects.css that would explain it. The font-size is 16px and I commented out the line-height set to 20px just to make sure that wasn't the problem, but it only shaved off 2px, bringing the height down to 44. I'm stumped.

[NorthEast]

You're inspecting the the dropDownHead style there, which also contains the hotspot - so I'd suggest inspecting the dropDownHotspot too, and also the a hyperlink tag (since it will inherit from that).

[Rona Kwestel]

Thanks, Dave, that pushed me in the right direction, and I found the culprit. It's the img element (the little arrow next to the dropDownHead text) that's causing the problem.

Here is the fully expanded dropDownHead inspection that revealed the img element:

fully expanded drpoDownHead inspection.png

Here is the img element causing the excessive spacing:

img element.png

And here is the image style definition:

img style.png

I have the img selector defined with large top and bottom margins because I like to offset screenshot images from the text, but I see now that I should have created a separate img.screenshot class to apply to only those images, and left the basic img selector with the default margin values. Any advice on how best to handle images would be appreciated - maybe a div.largeImage around screenshot images?

[Rona Kwestel]

And I see from this thread that I'm not the only person who had this problem: viewtopic.php?f=6&t=18281

[NorthEast]

If you don't want to change the base img styles, then a quick fix would be to reset the margins for an img inside the dropdown:

Code: Select all

.dropDownHotspot img
{
  margin: 0;
}

[Rona Kwestel]

Yes, thanks, Dave, I did something similar that worked, setting img.MCDropDown_Image_Icon with 0 margin, but decided in the end that it seemed best to be explicit about the img classes and create a screenshot class. It is a bloody nuisance to go back and fix all the unclassed images, especially since I already have some of them classed as thumbnail, so I can't just do a blanket search and replace. Write and learn.