User login

Navigation

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 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.

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.

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.

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.

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.

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 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.

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.

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!

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).

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.

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.

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.