HTML (webhelp)/HTML5 output differences for drop-downs
HTML (webhelp)/HTML5 output differences for drop-downs
I've started using drop-downs heavily, and I'm finding differences in the output for WebHelp and HTML5. I'm using the same stylesheet. Can someone explain what I'm missing?
I've been using WebHelp output up until now, as we had to be compatible with older versions of Internet Explorer. This is about to change (I hope) so I thought I'd generate HTML5 outputs for some content to get a feel for what I could do with it. I'm still using Flare 9.
The figure shows HTML5 (left) and WebHelp (right) output for the same topic, with nested drop-downs. The HTML5 automatically indents nested drop-downs, and also adds extra spacing before the first nested drop-down. The WebHelp has no nesting and even spacing throughout. When I first set up the nested drop-downs, I was expecting to wrap a div around a cluster on nested drop-downs and apply an indent style to it, or use specific indented styles for different nesting levels. It appears that this indenting happens outside of my control for HTML5 and not for WebHelp. I don't want to have a different stylesheet for HTML5 (or a different medium in my web stylesheet) if I can help it.
Here's an extract from my topic XML. [The divs that are there come from my standard template snippet that I use to insert a new drop-down, and they're there to avoid a drop-down bug where you can't apply styles properly, not to apply styles. Even if I remove them from the topic, I still get the same inconsistent behaviour]
Style MadCap|dropDown.ProgressiveFirst is present in my stylesheet but doesn't have any specific settings.
Style dropDownHead.h4 just sets the font and colour - I've not set anything else there yet.
MadCap|dropDownHotspot.h4 is present in my stylesheet but doesn't have any specific settings.
I've been using WebHelp output up until now, as we had to be compatible with older versions of Internet Explorer. This is about to change (I hope) so I thought I'd generate HTML5 outputs for some content to get a feel for what I could do with it. I'm still using Flare 9.
The figure shows HTML5 (left) and WebHelp (right) output for the same topic, with nested drop-downs. The HTML5 automatically indents nested drop-downs, and also adds extra spacing before the first nested drop-down. The WebHelp has no nesting and even spacing throughout. When I first set up the nested drop-downs, I was expecting to wrap a div around a cluster on nested drop-downs and apply an indent style to it, or use specific indented styles for different nesting levels. It appears that this indenting happens outside of my control for HTML5 and not for WebHelp. I don't want to have a different stylesheet for HTML5 (or a different medium in my web stylesheet) if I can help it.
Here's an extract from my topic XML. [The divs that are there come from my standard template snippet that I use to insert a new drop-down, and they're there to avoid a drop-down bug where you can't apply styles properly, not to apply styles. Even if I remove them from the topic, I still get the same inconsistent behaviour]
Style MadCap|dropDown.ProgressiveFirst is present in my stylesheet but doesn't have any specific settings.
Style dropDownHead.h4 just sets the font and colour - I've not set anything else there yet.
MadCap|dropDownHotspot.h4 is present in my stylesheet but doesn't have any specific settings.
You do not have the required permissions to view the files attached to this post.
Marjorie
My goal in life is to be as good a person as my dogs already think I am.
My goal in life is to be as good a person as my dogs already think I am.
Re: HTML (webhelp)/HTML5 output differences for drop-downs
In MadCap|dropDownBody, set margin-left to 0 if you don't want an indent, or set it to a value if you do want an indent.
Re: HTML (webhelp)/HTML5 output differences for drop-downs
Thanks Dave.
That's the thing. I was expecting to have to set an indent where I wanted it. And the WebHelp output exhibits that behaviour - I have set no indent in my stylesheet (yet) and there isn't one.
But the HTML5 output, which uses the same stylesheet and medium, has an indent, and also different vertical spacing above the nested drop-downs. So my questions are:
That's the thing. I was expecting to have to set an indent where I wanted it. And the WebHelp output exhibits that behaviour - I have set no indent in my stylesheet (yet) and there isn't one.
But the HTML5 output, which uses the same stylesheet and medium, has an indent, and also different vertical spacing above the nested drop-downs. So my questions are:
- Where are the indents in the HTML5 output coming from, given that I didn't explicitly set them (the nested drop-down heads are indented, and the body text below a drop-down head is also indented)?
- How should I set my indents so that a single stylesheet works for HTML5 and WebHelp?
Marjorie
My goal in life is to be as good a person as my dogs already think I am.
My goal in life is to be as good a person as my dogs already think I am.
Re: HTML (webhelp)/HTML5 output differences for drop-downs
They'll be Flare's own default styles - these aren't in any stylesheet, and are just added by Flare in outputs.Msquared wrote:
- Where are the indents in the HTML5 output coming from, given that I didn't explicitly set them (the nested drop-down heads are indented, and the body text below a drop-down head is also indented)?
So if you don't want the defaults, you have to explicitly set them in your own stylesheet.
Other examples of default styles are things like the breadcrumbs and miniTOC proxies; they'll automatically have some formatting, before you set any.
As mentioned in my last post.Msquared wrote:[*]How should I set my indents so that a single stylesheet works for HTML5 and WebHelp?[/list]
Re: HTML (webhelp)/HTML5 output differences for drop-downs
So what you're saying is that Flare is setting different defaults for HTML5 and WebHelp, so if I just go ahead and set them all as I was planning to, I'll get the results I expect?
Makes sense now I think about it. I was looking for some more subtle HTML5-related issue.
Makes sense now I think about it. I was looking for some more subtle HTML5-related issue.
Marjorie
My goal in life is to be as good a person as my dogs already think I am.
My goal in life is to be as good a person as my dogs already think I am.
Re: HTML (webhelp)/HTML5 output differences for drop-downs
Hi, I've changed image for dropdown text, and now there is a big gap between the image and the dropdown header. What do I need to change in the CSS style sheet to align with the dropdown body?
You do not have the required permissions to view the files attached to this post.
Re: HTML (webhelp)/HTML5 output differences for drop-downs
Firstly I'd check the margin-right setting on MadCap|dropDownHead. I'd definitely make sure it is the same as the margin-right setting used for your body text. If it wasn't, making it the same should fix it.
If it is already the same, but the text is still to far to the right, you could try reducing it until you get the spacing you want. But in that case, I'd rather work out why the different image had pushed the drop-down heading text over to the right. I assume that's what has happened? Did it previously line up with the body, when you used the default image?
Is it possible that the image has more white space to the right of it? If that's not it, perhaps someone else may be able to suggest what has occurred.
The problem with bodging the spacing (assuming it solves your problem) is that, rather than solving the real problem, if the image is changed again, you'll have to adjust the spacing again.
If it is already the same, but the text is still to far to the right, you could try reducing it until you get the spacing you want. But in that case, I'd rather work out why the different image had pushed the drop-down heading text over to the right. I assume that's what has happened? Did it previously line up with the body, when you used the default image?
Is it possible that the image has more white space to the right of it? If that's not it, perhaps someone else may be able to suggest what has occurred.
The problem with bodging the spacing (assuming it solves your problem) is that, rather than solving the real problem, if the image is changed again, you'll have to adjust the spacing again.
Marjorie
My goal in life is to be as good a person as my dogs already think I am.
My goal in life is to be as good a person as my dogs already think I am.
Re: HTML (webhelp)/HTML5 output differences for drop-downs
Thanks Msquared for your reply. Unfortunately this did not work, I've tried to reduce the space for margin-right as well as padding-left for dropDown, dropDownHead, dropDownHotspot but with no result.
The images are 9 x 9 px with no space around them.
So the dropdown text still looks terrible
The images are 9 x 9 px with no space around them.
So the dropdown text still looks terrible
Re: HTML (webhelp)/HTML5 output differences for drop-downs
There are plenty of people here who know more that me about HTML5 and CSS, and can probably help you. I would have been delighted if this post answered your problem too, but I suspect some of the CSS/HTML5 experts on this forum may be more likely to spot your cry for help if you start a new post with a title that reflects your specific problem.
Might be worth a try. I shall watch your post keenly, as I expect it's something that I may be interesting in doing too at some point.
Might be worth a try. I shall watch your post keenly, as I expect it's something that I may be interesting in doing too at some point.
Marjorie
My goal in life is to be as good a person as my dogs already think I am.
My goal in life is to be as good a person as my dogs already think I am.
Re: HTML (webhelp)/HTML5 output differences for drop-downs
I was able to resolve this issue by setting padding-left: 0px; on the MadCap|dropDownHotspot.
It looks much better now.
Re: HTML (webhelp)/HTML5 output differences for drop-downs
Awesome! Setting padding-left: 0px on MadCap:toggler fixes a similar spacing issue (too much indent between the icon and text of a toggler heading) when compiling HTML5 using Flare 10.1