Re: Using CSS to space lists & paragraphs
- --- In firstname.lastname@example.org, "Christine" <christine@...> wrote:
> Boy do I feel weird posting a question, knowing things will always be
> different. At least, everytime we post, we can't help but have Jody
> flash through our thoughts, right?
> Here goes:
> I'm trying to space my paragraphs and list items similarly to how I
> do it in Word. For example, let's say I have a Justified paragraph.
> Rather than a double carriage return in between paragraphs, I set the
> bottom row (and this would apply to a list item or the last row of
> one if it wrapped), to have 1/2 a row height after it. This creates
> a nice little space that gives the eye a break, but doesn't waste so
> much space.
> All the line height details with CSS apply height to an entire line
> or paragraph, with the space above it. If I'm wrong, do you know how
> I can do this?
> I'm thinking I need to create something for a transparent .gif or
> something that would occupy that space. However, I have issues with
> determining size. I don't understand what an em is, a px, etc. I
> know what it IS, but now how big it is. Or isn't.
> Does anyone have any ideas on this? Sorry it's as clear as mud.
An em is the size of a captial M and determined by the current font
you are using in any particular section, whether it is a heading tag
H1 or standard paragraph.
A px is short for pixel and is simply a dot on your screen. Example, a
468x60 banner is 468 pixels wide and 60 pixels tall. A pixel has a set
size and is not altered by any type of formatting.
Now with that in mind, you can set up various paragraph and list
types, each with its own class and call it whenever you want to use it.
Let's say for example that a standard paragraph is set with a single
line height (1em). To lower that to 1/2 a line height, you would go
into your style sheet and tell it what size to make line spaces in the
BODY section: line-height: .5em;
For adding a space at the bottom of each paragraph that will vary
depending on the font size you are using, add this to your paragraph
(P) section: padding-bottom: 1em;
To have a set size for padding that will not change when the font size
does, use pixels: padding-bottom: 12px;
You can do the same for lists. Another example for this is to have
your lists really stand out, so give them 1.5em padding at the top and
bottom: padding-bottom: 1.5em; padding-top: 1.5em;
Now let's put it all together.
padding-bottom: 12px; /* fixed size */
/* denotes a comment to allow you to make notes to yourself for later */
Hope this helps.
- absalom_nemini wrote:
> I have to admit to being appalled. From LaTeX I had expected theFor better or worse, HTML has become more of a de facto formatting
> following snippet to give visible results:
> And he said:<BR>
> <CITE>There is a word here needing to be <EM>emphasized</EM>
> regardless of context.</CITE><BR>
> <B>A sentiment to which I <STRONG>strongly</STRONG> agree.</B>
language rather than a structure-oriented markup language. The DTD
is lax enough that you can get away with all sorts of illogical
structuring schemes -- for example, the hierarchy of heading tags
(h1, h2, h3, etc.) is not enforced. On the one hand, it's made it
easy for millions of pages to be written by non-coding types,
giving us all sorts of wonderful stuff that probably wouldn't
occur to the aforementioned coding types. On the other hand, it's
created all sorts of issues around browser compatibility, made it
very difficult to programmatically port or integrate markup in
other pages or web-based applications, and has engendered page
design horror shows analogous to the multifont, carny colored
nightmares we saw in the early days of Apple and Mac page layout
programs... the digital equivalents of purple shag carpeting and
cheesy faux-wood basement paneling!
As a telling example, note that converting SGML->HTML is generally
a straightforward process, whereas all bets are off when converting
HTML->SGML. In some ways, we're starting to see the code hit the
fan with the rise of XML, XHTML, PHP coding models, which are
usually more strict (depending on your DTD), and are now learning
how it's often really painful to suck existing HTML pages in to
new content structures.
This said, one reason I generally prefer structural markup to
physical markup is that it makes it potentially easier to
repurpose content for things I haven't even anticipated yet --
and I'm just vain enough to hope that some of my old pages might
find their ways into these new content models!
(Coding sermonette #3746.12)