there's lots of good stuff here:

http://www.alistapart.com/topics/design/typography/

How about The Elements of Typographic Style Applied to the Web? http://www.webtypography.net/

Sounds precisely like what you're after.

"i" was once widely used for italics. Now "em" is favored, because, in the effort to separate aesthetics from content, "emphasis" does not refer to any particular visual style. Emphasis is more semantically appropriate.

If you're really hopeless, message me privately and I'll give you a rundown on whatever you need help in.

Originally, HTML, and SGML on which it was based, was highly unfriendly to typographers. Initially you didn't have access to leading, paragraph indents, or paragraph spacing. We still are hampered with lack of hyphenation, making justified text ugly, although possible. It was all originally built by a committee of programmers, with little or no typographic input.

When CSS came out, it did get some input from typographers, and you can now do many more things. (Although I am still baffled how you can use em as a dimension without it being based on some other element).

Slowly the ugly is being squeezed out of HTML, but it is a slow process.

I suggest that the hardest step for a print designer is to learn that on the Web, you never know what size of 'paper' you are designing for. Get past that, and you are more than half way towards being a web designer.

Oh yeah, you did ask a question ... I use http://www.w3schools.com as an excellent learning resource on HTML and CSS.

You’re talking to the wrong “Web people.” Talk to Jason Santa Maria, Clagnut, Andy Clarke, Mark Boulton. (Buy Mark’s book.)

Don McCahill, em is “the font-size of the relevant font,” namely the font in use for the text to which the declaration applies. HTML has no “ugly”; it is unstyled by default, save for rare presentational elements that are not used by the pros.

—
Joe Clark
http://joeclark.org/

Regarding your examples:

• I don’t know how to style the numerals in an ordered list (beyond specifying the kind of enumeration). I believe it’s impossible.
• You get the indention you have shown for free by default in all browsers. You can change it if desired.
• Type size and leading are readily specified. Space after paragraphs is readily specified.
• <sup>®</sup> is not horrifically wrong for the registered-trademark symbol you are using and can be styled.

—
Joe Clark
http://joeclark.org/

Thank you all for your useful comments, and I will check all the resources you've so kindly provided.

You’re at risk here of falling prey to bad advice and producing tag soup. You need to learn correct standards-compliant HTML, which is legitimately easy. (It’s tag soup that’s hard.)

You would want Designing with Web Standards by Zeldman, a new edition of which just came out. The CSS Zen Garden book by Dave Shea could be useful to look at.

If you told us what city you were in, chances are there are standardistas already there whom you could get to know.

—
Joe Clark
http://joeclark.org/

HTML is not for typesetting per se. That's really what CSS is for.

A poor analogy, perhaps, but consider HTML the structured Word Document and CSS your InDesign tweaking.

Thank you, Joe; I'm in New York City; I'll be looking into all of this! I'll get all of these books ASAP, and I'll beware of producing tag soup.

But to clarify, are you saying I can't get hanging bold numerals in an ordered list with plain HTML, or can it be done with CSS? Or is it better to stick with standards-compliant HTML, and redesign the page?

I can live with bullets and no numerals, in any case.

I don’t know of a way to style the numbers of an ordered list, beyond specifying the form of enumeration.

Perhaps you should take Jason out for a burger, as he is into that sort of thing, I think. He’ll set you straight.

Aluminum is not really accurate. HTML is your semantically-marked-up text, which has little or no implied presentation. CSS determines presentation, except of course for the fact it can be and is overridden.

—
Joe Clark
http://joeclark.org/

Yes, stick with standards compliant HTML. Again, you don't style text with HTML (though browsers do have default styles for the HTML).

Use CSS to style the typefaces to the extent that you can.

Beyond that, you can do things with CSS to fudge what you want. For instance, you could create your own numerals as GIF files, then via CSS, cover the default numbers created with your custom image based numbers. You end up with standards compliant HTML, but with the look you want. You could look into using @font-face as well.

"Aluminum is not really accurate."

Like I said, not a great analogy. It was the best I could think aimed at someone that is primarily coming from a print-centric mindset.

Joe's literal definition is the better way to describe it. HTML is semantic markup. CSS makes it pretty.

As the enumeration belongs to the list item (LI), it is not possible to specify, for example, different colors for the number and the list item itself – without extra markup. One could wrap the list item's content into a new element (both block and inline elements are allowed within LI). But that’d be a real bloat.

@ Cameron

Understanding the difference between the logical structure and the style is important, because many people with handicaps are also using computers. Blind people are using screenreaders. If the markup is misused for the style, the access to the content is harder for them. Cascading Style Sheets are not limited to the visual style by the way. But how should a screenreader interpret the expression "italic"? The expression indicates a visual style, while "emphasis" indicates "importance". Additionally it would be absurd to style the italic element upright bold with the help of CSS, while there are cases in which it makes sense to style the em element upright bold.

For the same reason you should make use of attributes like "title" or elements like "acronym". In case of the acronym-element the handicap is the limited knowledge of the user. The biggest handicap is stupidity. This does not mean, that you always should design for the most stupid user, but in case of websites, that are intended to be used by a wide range of users, that don’t belong to a group with special interests, the Amazon website or a government website for example, you should keep in mind, that many people are more stupid than you or that many people are less competent than you.

There are cases, in which blinds are not in your target group. I think, this website is one example – although even on this website you probably find discussions about braille.

Do not do what Aluminum says with the images of numbers and whatnot.

—
Joe Clark
http://joeclark.org/

Do not do what Aluminum says with the images of numbers

Why not?

Because it messes with the flexibility of the text. Somebody trying to view the page on a monitor set to a different resolution (e.g. someone with sight problems, or someone with a small screen handheld device) may not see the list quite as you see it on your own equipment.

I used to be a stubborn as Joe in terms of full on obedience to web accessibility guidelines but have become more pragmatic over the years. Partly because I'm not a pundit and have to adhere to demands of others and partly because the more you learn about web accessibility, the more gray area you find within it. It's getting better (really looking forward to ARIA standards).

In the end, it all depends. Apply and/or ignore the rules of thumb based on the context of the site you are building.

ricadus is sort-of correct. If the numeral is an image, and a user changes their font size, it may not scale in relation to the type. You could get around that by sizing the image in ems. The other issue if a person is using page-zoom (via the OS or the browser itself) the image will scale, but quickly become much more pixelated than the text. That may be an issue. But that's but one way to skin the cat.

You can do a lot with HTML + CSS but there are limitations when comparing it to traditional typesetting. It's up to you to decide when over-rides are warranted and when they are not. Both from an end-user usability/accessibility standpoint as well as production-side sanity.

Looking at your specific example, try this:

[ol style="font-weight: bold; font-family: verdana; color: red;"]
[li][div style="font-weight: normal; font-family: georgia; padding-left: 2em; color: black;"]content[/div][/li]
[/ol]

That's about as close as you can get to using pure HTML/CSS to separate the styles of the numerals and the style of the list contents itself.

Alas, the period is part of the browser's rendering of ordered lists so there'd be no way to omit that via this method.

Inline styles? Seriously? You might as well use the <sup>®</sup> tags.

One thing that I have learned for a certainty, is that the more bloat you add to your content, the more problems you will eventually have with content re-use (The golden goose of XML) AND usability.

The markup exists for a reason. The UA is supposed to adjust its own display of the content to fit the locale and the technical requirements of the page.

Now, given the original problem, a <dl> could also do the trick fairly robustly, although the counter would have to be added manually.


<style type="text/css" media="screen">
dl{position:relative;}
dt{font-weight:bold;}
dd{position:relative;top:-1em;}
</style>


<p>Here's what we've done to help:</p>
<dl>
<dt>1</dt>
<dd>We eliminated traditional film and plate processing, along with the associated toxic chemicals</dd>
<dt>2</dt>
<dd>We acquired a chemical free <abbr title="computer-to-plate">CTP</abbr> (computer-to-plate) setter.</dd>
</dl>


Some definite clean up of the CSS would be required, but I hope you get the drift.

"Inline styles? Seriously?"

For a simple concise demo in a forum post to communicate the overall concept rather than act as a literal production file? Yes.

The definition list is OK, but technically you aren't defining the numbers. But definition lists always have that issue...no one seems to agree on proper uses for them and accessibility software tends to ignore them outright.

I hate that about definition lists. Actually, I hate that about a lot of HTML.

To be fair, re: DLs, that's more the fault of browser rendering engines and their ambivalence to the tag.

It'd be a pretty useful set of markup otherwise.