p class with background & indentation (CSS question)

[MC Hammer]

I am a bit thick today ...As I am only used to using the Flare Stylesheet Editor for simple and most used properties, I am struggling a bit on this. I have created a p_definition class to which I have applied a background colour. I would like the background colour AND the text to occupy approx. 70% of the screen width, the background to be centered and the text to be aligned to the left (so the text start when the background colour starts). I have tried several combinations of properties and values (box width set to 70%, text align set to left) without success. Which other properties and which values do I have to use to achieve this?

[KevinDAmery]

Try using the Margin attributes (left and right). That should do it.

[lacastle]

Yeah, that's all I did. I have a p.note style that I use for notes in my text. I have the following properties set:

p.Note
{
margin-left: 20pt;
margin-right: 20pt;
background-color: #e1edff;
margin-top: 4pt;
margin-bottom: 4pt;
border-left-style: none;
border-right-style: none;
border-top-style: none;
border-bottom-style: none;
}

you can adjust the margins to make it \"70% of the screen width.\" The background is centered (if the margins are equal on each side) and the text is aligned left if that's what p is set to do.

[Ryan Cerniglia]

I am a bit thick today :roll:...As I am only used to using the Flare Stylesheet Editor for simple and most used properties, I am struggling a bit on this. I have created a p_definition class to which I have applied a background colour. I would like the background colour AND the text to occupy approx. 70% of the screen width, the background to be centered and the text to be aligned to the left (so the text start when the background colour starts). I have tried several combinations of properties and values (box width set to 70%, text align set to left) without success. Which other properties and which values do I have to use to achieve this?

You probably want that to be a div instead of a p.

This is the CSS for what you described:

Code: Select all

div.testing {
background-color:#00FF00;
text-align:left;
margin-left:15%;
margin-right:15%;
}

Then put this in your (X)HTML:

Code: Select all

<div class="testing">some text here</div>

That should work :)

Let me know how it goes!

[KevinDAmery]

That would work--and would have the added advantage that if you wanted two or more paragraphs to appear in the coloured box, they wouldn't have white gaps between them (if you do it in a p tag there will be gaps between them).

Sadly, it doesn't work in print because Word and Frame don't understand what Divs are (I was burned by that a while back) so if print output is also a requirement you may need to take an alternate approach.

[Ryan Cerniglia]

That would work--and would have the added advantage that if you wanted two or more paragraphs to appear in the coloured box, they wouldn't have white gaps between them (if you do it in a p tag there will be gaps between them).

Sadly, it doesn't work in print because Word and Frame don't understand what Divs are (I was burned by that a while back) so if print output is also a requirement you may need to take an alternate approach.

If you really needed print you could do the same CSS style with a p tag, but you'd need to use <br /> tags inside the paragraph so there isn't that unsightly gap between paragraphs...

[MC Hammer]

...and look at all the replies! Thanks, everyone, I will have a look at your suggestions. Otherwise, another question also related to this, and not really to Flare: why should I choose a DIV tag? (I do not really understand DIVs and SPANs)

[LTinker68]

A DIV is a container tag, but it's really flexible. It can contain multiple tags (<p>, <ul>, <blockquote>, etc.), but because they're in the DIV tag then they're in effect grouped. So if you move the DIV, everything inside it is moved, too, instead of having to move each one individually.

In addition, you can position DIVs in multiple ways, so that the DIV always shows in the same position in the page no matter what the user does to their browser window. For instance, you can position it to always be 20px from the right wall so that no matter how wide the browser window, it's always 20px from the right. Or you can have DIVs overlap so that you get cool 3D-ish effects. (To overlap DIVs, look into the z-index.)

Plus, with a bit more programming than what's currently available through the Flare GUI, you can hide and show DIVs depending on user actions. You see this a lot on websites where you mouseover a menu item and its submenu slides out or drops down to show additional choices.


As for SPAN... Think of it as a temporary override to the tag you're using. For instance, if you have a paragraph set up where the text is black and normal weight, then you can create a span with red bolded text. You select a few words inside the paragraph and apply the span class to it, and just those few words in the paragraph are red and bolded -- everything else is black and normal weight.

[Ryan Cerniglia]

To continue on from Lisa's point:

The difference is also semantical - p tags should only be used for paragraph text, while div tags are used for divisions of text.

Ideally, for this you'd use a div tag with a descriptive class name based on what would be expected to be in the tag. For example, a div with a bright yellow background might be a caution class.

Like Lisa said, span tags should be used within a paragraph or div to apply styles to small portions of text, such as creating bold, underlined, or italic text.

The reason you'd want to use spans instead of b, u, and i tags goes further into the push for XML standards: content and style are completely separated. There are entire books on this subject, but the general idea is that you can take the same single content file and only change the style depending on whether you want to view it on a computer, a mobile, or even in print! Flare really alludes to this powerful XML-based technique with its single-sourcing capabilities.

[Andrew]

The reason you'd want to use spans instead of b, u, and i tags goes further into the push for XML standards: content and style are completely separated. There are entire books on this subject, but the general idea is that you can take the same single content file and only change the style depending on whether you want to view it on a computer, a mobile, or even in print! Flare really alludes to this powerful XML-based technique with its single-sourcing capabilities.

To extend this a bit, the reason you want to separate content from markup is that, many times, there is a semantic meaning behind the change you are making to the text. For example, perhaps you want to make every keyboard stroke the user must enter bold face in your help. You could just assign the bold tag (<strong>), and that would work.

However, if you assign it a span class tag (<span class="keystroke">), and then assign the bold face to that span class, you can easily change the way you make keystrokes appear in your help. You could make them all blue with a few clicks, or change the typeface to a courier variant.

The whole point of using style classes is to represent meaningful information (or meaningful "parts") of your document with the markup, so that if you want to, say, reskin the entire thing, you only need to do so in the style sheet. You should try to only use <strong> or <em> tags for ad hoc formatting, where you just want a particular word to have emphasis.

[LTinker68]

You should try to only use <strong> or <em> tags for ad hoc formatting, where you just want a particular word to have emphasis.

Now if only there were a way to change the b and i icons in the Flare toolbar so that they generate strong and em tags, respectively, instead of b and i, which aren't 508-compliant. Not that I have to generate 508-compliant help, but no reason not to set up the help to be that way initially, in case I have to become compliant later.

[KevinDAmery]

True, although it's the same thing you run into with the font, size, colour, etc. buttons in the toolbar. Yes, they work, but in a CSS world they're really bad practice to use.

I'd almost be inclined to request they be removed so that people aren't tempted to use formatting over-rides, but ya just know that if they weren't there, Madcap would have a hard time selling the software because \"it doesn't even have formatting controls.\"

[Andrew]

You know, I can't believe I've never noticed that.

[MC Hammer]

for this comprehensive tutorial. It is all a bit beyond me but I think I am starting to understand your point. Thanks for taking the time to post and explaining things to me.

[MarinaMichaels]

This is way late as a reply, but I was searching to see if someone else had submitted the issue about <i> and <b> versus <em> and <strong>. The WC3 accessibility requirements state that <em> and <strong> should be used for italics and bold instead of <i> and <b>. However, when using the XML editor in Flare, when you press Ctrl-i, the underlying code is <i>text</i>, not <em>text</em>, and likewise for Ctrl-b, the resulting underlying code is <b>text</b>, not <strong>text</strong>.

This seems like it would be such an easy change to make, and I didn't see any indication that someone else has submitted a request to change this (of course, they may have without saying anything on the forums), so I went ahead and submitted an enhancement request.

Also, I do not think a span is a good replacement for <em> and <strong>. Those two elements are well-understood by browsers. The reason why they are recommended for accessibility (over <i> and <b>) is that people can configure how they appear in their browsers. If you instead use a span, then you are forcing your own definition of how that text should appear onto people using your files.

I am not saying all spans should be avoided--Andrew's example of creating a span for a keystroke is a good one--just, spans shouldn't be used for these particular elements if you are simply using these elements for their usual purposes. And in Andrew's example, you don't even need a span; you can assign a class to the <em> and <strong> elements if you want. For example, "Next, press <strong class="keystroke">Enter</strong>."

If you are using spans, make sure that there is semantic markup in addition to color: http://www.w3.org/TR/2008/WD-WCAG20-TECHS-20081103/G138

For more (lots) information on accessibility, see http://www.w3.org/WAI/

[LTinker68]

The WC3 accessibility requirements state that <em> and <strong> should be used for italics and bold instead of <i> and <b>... This seems like it would be such an easy change to make, and I didn't see any indication that someone else has submitted a request to change this (of course, they may have without saying anything on the forums), so I went ahead and submitted an enhancement request.

I submitted a request back in version 1, I think, but the more who request something the more likely it'll get implemented. For now, I keep the Styles pane open and scroll down to the <em> and <strong> tag, although recently I decided to use generic classes that have the effect I want and I've been applying those, since generic classes appear at the top of the Styles pane. Granted, I haven't done much research into accessibility since it's never been a requirement for me, but I don't believe there's a difference between setting bold from the stylesheet instead of the using the <strong> tag. Calling it from the stylesheet does put it in as a <span> tag, but browsers are fully capable of handling that tag.