numbered list has no hanging indent

[bobmoon]

When I generate my Word output, my numbered lists have no hanging indent. The text lines up at the left margin. I can adjust the margin settings, but I never get a hanging indent in Word. I'm wondering if it is a disconnect between my ol tag and my list tag.

Here's what I've got:

Code: Select all

li.Body-Step1 {
	vertical-align: baseline;
	list-style: decimal;
	font-family: Arial, ' sans-serif';
	font-size: 10pt;
	margin-bottom: 3pt;
	margin-top: 3pt;
}

ol {
	margin: 0;
	margin-bottom: 3pt;
	margin-top: 3pt;
	margin-left: 0.15in;
	font-family: Arial, ' sans-serif';
}

Obviously, I've got some duplication that I can clean up. I had this working when my target used a separate "print only" css file. I'm trying to put all of the print styles into the @media print section of my regular css file.

Thanks!
Bob

[LTinker68]

Nothing jumped out at me as being wrong, except possibly putting the list-type on the ol tag instead of the li tag, but I think it'll work either way. And I'd get rid of the vertical-align to baseline property since you're not using an image for the bullet.

Generally the list lines up by default with the number hanging outside the paragraph. I can't remember the name of the property, but there's something in the list category with values of outside-head and inside-head. Try setting it to outside-head.

Actually, before doing that, get rid of the margin-left of 0.15in on the ol tag. By default, the lists are always indented. Things can get a bit wonky if you set the margin-left value to less than that default value (it's about 40px for web output; don't know for print). Try removing that line first to see if it works.

[bobmoon]

Thanks (again) Lisa. You got me on the right track. I'm combining a web help only CSS and a print-only CSS into one, and I think my problem was caused by confusion between the rules for li.Body-Step1 in both sections.

In the main section, that li.Body-Step1 style has a text-indent rule and margin-left rule. In the @media print section, my li.Body-Step1 style didn't have those rules, so I guess those settings were affecting the default behavior in Word. Flare does not cascade style rules in quite the way I expect when generating Word output. (For example, in my @media print section, I need the font-family rule in the li style, even if it's specified for the ul style. I have a font-family rule specified for the li style in the main section, and I have to override that in the print section.)

The settings below achieve what I want. The numbered list lines up against the left margin with a hanging indent. Actually since the numbers are hanging on the outside and I have to account for double-digit steps, the number is slightly indented from the text margin.

Code: Select all

@media print {
 li.Body-Step1 {
	font-family: Arial, ' sans-serif';
	list-style: decimal;
	font-size: 10pt;
	margin-left: 0in;
	margin-bottom: 3pt;
	margin-top: 3pt;
	text-indent: -0.12in;
 }

 ol {
	margin:0;
	margin-bottom: 3pt;
	margin-top: 3pt;
	margin-left: 0.3in;
	font-family: Verdana, sans-serif;
 }
}

[LTinker68]

... and I think my problem was caused by confusion between the rules for li.Body-Step1 in both sections.

If you specify something in the default medium but don't specify something else in the print medium, then it'll use whatever value was specified in the default medium. So if you change one property in print but leave all the others as defined in the default medium, then you can inadvertently cause conflicts. The default (not specified) value in the print section doesn't mean use the print output's default value -- it means use the value specified in the default medium and if there's nothing specified there, then it'll use the default value for that property as defined in the CSS standards. I think that's how it works. (Unless that default value is specified otherwise by the output medium, as is often the case with browsers.)

Flare does not cascade style rules in quite the way I expect when generating Word output.

How do you mean? I should also mention that Word doesn't implement CSS completely or accurately. There are several properties you can specify in Flare that just don't work in Word because Word doesn't implement them. Images for bullets, for example. Word also doesn't like DIVs. I don't generate Word output anymore for that reason, at least not final, customer-deliverable output. I give them PDF. But I do give the developers Word because they like the track changes option in Word, but the output they get is streamlined and doesn't have the bells-and-whistles that they get in the PDF output.

[bobmoon]

The default (not specified) value in the print section doesn't mean use the print output's default value -- it means use the value specified in the default medium and if there's nothing specified there, then it'll use the default value for that property as defined in the CSS standards.

That's what I thought was happening. I had values specified in the default medium that I hadn't specified for print. I had to go back and plug in those holes to make the print behave the way I wanted it to.

My other point was related. I assumed if I specified the font to be Arial in the ul style rule in the print medium, that I wouldn't need to specify it in the li style for print. But since there is a font declaration for li in the default medium, that was being applied in Word.

Bob

[KevinDAmery]

My other point was related. I assumed if I specified the font to be Arial in the ul style rule in the print medium, that I wouldn't need to specify it in the li style for print. But since there is a font declaration for li in the default medium, that was being applied in Word.

Bob

Yes. Word doesn't have an equivalent of the OL or UL wrapper tag: instead, it embeds everything about the list in the individual list items. As a result, when you export to word it only inherits the style info from the li paragraphs, not from the ol or ul wrapper.

And no, I'm not thrilled with that either...

[papa-mike]

How did you create the Flare project?
If you used a Word document with SEQ field numberinb you'll lose the hanging indent.
Flare is REAL HTML and it is lost. It works in RH because they use a custom format that is NOT real HTML.
I had to move to Word 2007 and use the Word numbering. It is a lot better but sometimes ther is a hiccup.
M