Formatting hints from Mark

Frank asked me about pretty formatting. Well, I can describe how I work and my opinions. Your mileage may vary. I do markup by hand, copy/paste style, in an editor with N clipboards to keep the variations handy. You only need to know 3 things about markup. Forget CSS files, classes, and other fanciness. That's overkill for LtU. The things to know are that:

• The style attribute does everything.
• The value of the style attribute is a single string encoding all parameters. Include or omit as many as you like.
• The style attribute qualifies both paragraph tags and span tags (for inline markup).
That's it. Keep a kitchen-sink style attribute on some clipboard with default values. Paste it as needed, then overtype or delete specific values in context. If you have more clipboards, some can hold preset markup. Here's a kitchen sink, which you may copy with your mouse and customize to your liking:
 style="color: black; background-color: white; font-style: normal; font-weight: normal; font-size: normal; font-variant: normal; text-decoration: none; text-indent: 0%; padding-left: 0%"
DeepX offers a handy cheat sheet (PDF) for these parameters. Note my deliberate omission of font-family.

This paragraph uses the kitchen-sink style. It should look the same as any unadorned paragraph.

For interest's sake we can demonstrate options. The desperately curious may use their browser's "view markup source" function.

A warning paragraph in large-strong-red text with 3% indent and 5% left padding: The old font tag is deprecated, don't use it any more.

Font-size permits many types of settings, but don't use absolute metrics (points, ems, cm, whatever). Use something like xx-small, x-small, small, medium, large, x-large, xx-large, smaller, normal, larger, or a percentage like 65% or 132%.

The only place where you might use absolute metrics is in the border of a highlighted section, if you want a border at all. Note how span tags can nest. Small caps are possible too. There is also something called text-transform for capitalization.

Simple inline markup remains simple. Forget style. First we have the famous "code" tag. You can use font-family: monospace to similar effect. Use the "em" tag for emphasis, the "strong" tag for strength. Don't use older "i" or "b" tags. The style attribute defines italics as font-style: normal, font-style: italic, and font-style: oblique. It defines boldface as font-weight: normal, font-weight: bold, and font-weight: bolder. We also have text-decoration: none, text-decoration: underline, text-decoration: overline, text-decoration: line-through, text-decoration: blink.

Simple "yellow" background color performs inline highlighting. You can also play with hex color codes, but simple color names work, e.g., font-weight: bold; color: yellow; background-color: purple.

This stuff can be overdone. I just wanted to showcase possibilities, since someone (important like Frank) asked me. Use good taste. Colors help a great deal. LtU likes blue, or blue italics, for excerpts, and italics for quoting others from LtU. I would recommend a distinct color as well, more than one if quoting more than one person to compare statements.

Comment viewing options

What would be nice

would be some predefined styles for common content types, so we could use the class attribute and look just like everybody else...

Formatting

What would be nice would be some predefined styles for common content types, so we could use the class attribute and look just like everybody else...

I agree. We'll be doing some of that very soon. I'd advise against a lot of direct use of the CSS style attribute. Ideally, message source should be minimally marked up, and use tags like <blockquote>, which will soon have better default styles associated with them (in the default template). Basic tags like <em>, <strong> etc. are also OK.

Although Drupal is set up to accept arbitrary HTML right now, that's mainly because none of the default options for "cleaning" the HTML were what we wanted. However, there are problems with the current setup, e.g., an unclosed tag can affect subsequent messages. So in future, we'll almost certainly impose some constraints on what HTML can be posted. Since we'll likely be using an off-the-shelf solution (i.e. the kind of thing you find on other blogs and discussion forums), I can't promise that existing use of HTML will be unaffected. I'd recommend being conservative about HTML use in the meantime.

Re: Formatting

What I would like is XHTML compliance.

Don't outlaw too much CSS style attribute usage, particularly colors, for quoting people inline. Don't outlaw span tags. The thing about the style attribute is that it neatly consolidates all text formatting into a single tag. One-stop shopping makes life easy.

The problem with external CSS files is that web pages don't render the same from disk as from the web, unless one tracks all dependencies on the local hard drive. Keep that in mind, too. Simple classes for, say, paper excerpts might insert into each page, individually. Come to that, font-family: sans-serif on each page would help. Firefox renders LtU pages loaded from disk in Times Roman.

Outlawing

Don't outlaw too much CSS style attribute usage, particularly colors, for quoting people inline.

Ideally, things such as quoting would rely on semantic tags, and a standard stylesheet, whether it's in a separate file or embedded in the page. We want the message source to contain semantic content, not presentation markup.

However, I'm not planning to outlaw anything just for the sake of it: I'm saying that we're probably going to use something off-the-shelf, and there's a limit to how much customization we're going to do. Most of the solutions out there are quite draconian, and end up restricting you to a small subset of HTML.

I'll keep the point about local copies in mind with whatever we do.

Re: Outlawing

Yes I understood that. Any solution that permits inline style attributes is fine. There is no semantic marker that means "quote someone inline so as to highlight their remarks." That is, like this, not blockquote. We have to invent such things, and I am saying we should, because they make pages more readable and clear.

There is no semantic marke

There is no semantic marker that means "quote someone inline so as to highlight their remarks."

I thought that's what "quotation marks" were for... ;)

[P.S.: the HTML 4 element "Q" is designed for this purpose.]

BTW, I'd be interested in hearing people's reactions to Textile, which is one of the options easily available to us, since it's available as a Drupal module. Textile provides wiki-style formatting that's more concise than HTML.

Main thing that should be forbidden...

...is the inclusion of any script or object tags within the markup. And given the nature of this forum, I'd probably be against using images as well.

But on a day to day, the validation of the markup probably makes more difference than what specific tricks are used.

Re2: Formatting

It's sound advice to recommend being conservative about HTML use, but there is a flip side. Explaining code can be simpler when pieces are styled. So even a basic code block might want some inline style.

There is also a rule about lists. They are not supposed to live inside paragraphs. I think.

Explaining code can be simp

Explaining code can be simpler when pieces are styled. So even a basic code block might want some inline style.

A prettier style for the <code> element could take care of this, couldn't it? (Assuming the issue of stylesheets for offline copies is dealt with.)

Re: There is no semantic marker

Yes we have good old quotation marks, but that misses the general point. Quotes stand out better with coloring anyway. When you must quote N people, N colors provide clearer presentation. I don't mind Q so long as it permits the style attribute.

No finite set of semantic markers can anticipate all useful applications of markup to convey meaning. I don't pretend that I can, either. The code idea is just that so much narrative text in email lists and LtU posts is wasted verbage, because simple markup would communicate matters more simply. Instead of saying "the code between the inner fifth parens and the end token," you just use markup and say "the purple stuff."

The reason I logged in this last time was that it dawned on me how much I detest wiki markup. Sure enough, there it was posted as an idea. It's hard enough to remember the rules for XHTML 2,3,4,... I don't want to deal with wiki. Just let me keep my inline CSS style, thanks!

By the way - fine work on the new site, and thank you for it.

Accessibility

One of the key arguments in favour of semantic markup over adding lots of style attributes everywhere is accessibility. Not just for people using speech interfaces and other non-graphical means, but also people using such graphically-challenged browsers as Lynx or Netscape 4 :) You can overcome the first by using the voice-* stuff in CSS, but I'm not sure if it covers all the issues (I'm not an accessibility expert).

semantic markup

No finite set of semantic markers can anticipate all
useful applications of markup to convey meaning.

Sure, but we're not talking about creating arbitrarily formatted documents here. Some restrictions are acceptable. I must admit that for me, the ability to e.g. distinguish quotes from different people by color is not high on my list of essentials. I'd rather see the name of the person being quoted, as in "Ehud wrote...", unless we're going to permanently map a unique 24-bit color to each registered member on LtU. ;) And then we need to worry about color-blind readers.

The reason I logged in this last time was that it dawned on me how much I detest wiki markup. Sure enough, there it was posted as an idea. It's hard enough to remember the rules for XHTML 2,3,4,... I don't want to deal with wiki. Just let me keep my inline CSS style, thanks!

Other people like it, since it's more concise than HTML. Even if we install something like Textile, it'll definitely be optional.

I wasn't.

WYSIWYG Tool - Nvu

Nvu will do the heavy lifting for folks who dislike my technique. A tiered context menu offers all the style stuff. Nvu shows the rendering, the HTML code, and other views. It's based on Mozilla code, but is not a browser plug-in, rather a true stand-alone app. Author interview.

FONT Tag Deprecated

This means you, Ehud! I plead guilty, too.

Blue Text

Seeing the problems in the "Wobbly Types" thread, some additional hints might be in order:

• You MUST NOT make text that is not clickable blue, or underlined, or, worst of all, blue and underlined.
• You SHOULD NOT use the style attribute, most of the time it is useless, counterproductive and confusing.

More Nvu

Nvu will happily work directly from LtU's online stylesheets.  For those who have asked about Nvu, the relevant lines to insert in the <HTML> Source tab, within the <header> section, are as follows:

<style type="text/css" media="all"> @import url(http://lambda-the-ultimate.org/misc/drupal.css); </style> <link rel="stylesheet" type="text/css" href="http://lambda-the-ultimate.org/themes/chameleon/common.css" /> <link rel="stylesheet" type="text/css" href="http://lambda-the-ultimate.org/themes/chameleon/ltu/chameleon.css" /> 

This step provides an editing screen with the same visual styles as LtU, so truly WYSIWYG. Posting to LtU is a snap, just go to the <HTML> Source tab and copy everything inside the <body> tags.  Paste that into the LtU post box.  Basically it's everything but the header section and body delimiter tags.

You should create new paragraphs as you edit along, rather than editing at the level of <body> itself.  Nvu doesn't enforce such a discipline.  There is an option under Edit/Preferences/Advanced for "Return in a paragraph always creates a new paragraph."

In fact I have edited this post in Nvu and find it helps the business of escape-quoting markup, as in the code shown above.  Programming languages also use funny characters, so Nvu is useful for code snippets of any kind, not just HTML markup.  In fact I daresay Nvu is far safer than hand-editing for such purposes.

Nvu is cross-platform and open-source, Windows and Linux, with I think Mac coming along too.

You MUST NOT make text that is not clickable blue

LtU has always used blue text for extended quotations, and I like the color difference because it shows who is talking.

You SHOULD NOT use the style attribute, most of the time it is useless, counterproductive

Bulldust.  Use it in good taste, for clarity.  Nvu gives a complete preview.  If you style at all, you are supposed to use styles, not <FONT> any more.

Seeing the problems in the "Wobbly Types" thread

Seeing the problems in the "Wobbly Types" thread, make sure to preview your post (which even LtU allows, online directly, not just Nvu).  We don't want to see your edits in real-time.