HTML in Backtalk Postings

Mar 5 15:01 UTC 1999

The next version of Backtalk has a new feature that allows users the
options of using HTML in their items and responses.

In an HTML posting you can insert "tags" into the text you type in that
effect the appearance and formatting of items.  So if you type

  This is a <STRONG>great</STRONG> idea!

then when people read the response through Backtalk they will not see
the "<STRONG>" tags, but they will see the word "great" printed in a
bold font.  There are lots of other tags in HTML, some of which will
not work in Backtalk responses (non-functional ones include <BLINK>,
<HR>, <TITLE>, <FRAME>, <INPUT> and such like).  The tags that are
allowed let you do various things with fonts, changing colors, sizes and
styles, some formatting stuff, such as automatic generation of numbered
lists and centered text, inclusion of images into responses, tables, and
the creation of clickable links.

Since Picospan users probably don't want to see all sorts of tags like
<FONT SIZE=+3 COLOR=RED>Hello!</FONT> stuff when reading the
conferences, the new Backtalk automatically generates plain text
versions of all HTML postings, and stores them where Picospan will find
them.  Obviously Picospan users won't see images or font changes, but
the text, at least, will be legible.  Currently the plain-text
conversion isn't amazingly well done.  There is room for improvement
here (but it's a fairly complex thing to do well).

I have installed a test version of this new Backtalk as "bt.new" here
on Grex.  It has been "broken" so that it only works in the "backtalk"
and "backtalk2" conferences.  The following link will run the new
Backtalk in the backtalk conference:

 http://www.grex.org/cgi-bin/pw/bt.new/pistachio/confhome?conf=backtalk

Note that if you want to access any other conference after running this,
you'll need to edit the "bt.new" in the URL to be "bt" instead.

The open question is whether we want to enable HTML postings on Grex.
A couple notes:

  - There is a switch that will allow fairwitnesses to turn HTML posting
    off in their conference.

  - Entering HTML postings is actually fairly finicky work, if you want
    to do it well.  I suspect that they will never become a large
    fraction of all postings.

response 2 of 92:

Mar 5 17:18 UTC 1999

There is a pull-down box above the response box from which you can
select the style of response you are makeing, the options being "plain
text", "lazy HTML" or "pure HTML".  If you select either of the latter,
then two copies of your response are saved, whether there are tags in it
or not.  If you select "plain text" only one copy is saved.

This does waste some disk space.  If we could modify PicoSpan, we could
put the HTML to text conversion into it, and only save one copy, but we
can't (and don't really want to).  However, bbs disk space is really a
tiny fraction of the disk we use, so I think we can afford this.

response 4 of 92:

Mar 5 20:32 UTC 1999

No.  Lynx sucks in too many ways.  For one thing, in the last version I
saw, <TEXTAREA> was implemented very clumsily (no autowrap or scroll),
so that it is kind of a pain to enter responses through lynx.  And there
are basic ways in which a command-line interface is nicer than a point
and click interface (especially a point-and-click interface emulated
with character graphics).

I thought about building HTML->text translation into the pager.  It has
some advantages over what I am doing here, but it requires having
everyone configure the right pager.

response 6 of 92:

Mar 5 22:32 UTC 1999

Note that /bbs has been up past 97% full several times recently.  (I
think it's down to 87% now.)  What's the time-frame for the new backtalk
going live vs. more drive space going live?

response 8 of 92:

Mar 7 03:29 UTC 1999

   The fluctuations in /bbs are me, not the conferences.

   <confessionmode ON> I have spread my corpulance into /bbs since
/a and /c were so full.  I have since (mostly) reformed and have
released that space (burp). <confessinmode OFF>

   On a more serious note--and why I used /bbs--the conference usage
has got to be the most efficient usage of disk that Grex has.  1M of
disk goes a *long* way.  The previous version of Agora is only 4.2M,
for example.  Having responses doubled in size doesn't bother me much.
But would everything double?  I'm confused on that one.

response 10 of 92:

Mar 7 06:56 UTC 1999

   Well, yes.  I think there will be at some point not so far off.
Whenever I feel human again I intend on working with our 'new' 2G
disks again.

response 12 of 92:

Mar 7 19:12 UTC 1999

It's not urgent, just a fantasy.  Unless it tickles other peoples'
imaginations, I would say, don't bother.

response 14 of 92:

Mar 7 21:18 UTC 1999

Getting back to the issue of HTML in conference postings...

I see some benefits to HTML posting in a conferencing environment such 
as Grex's:

(1) More attractive, readable text via the use of such typographical 
devices as proportional fonts, boldface, italics, underlining.

(2) The ability to display special symbols (such as math symbols) and 
characters from non-English alphabets (e.g. German umlauted characters, 
French accented characters, and so forth.

(3) The capability of displaying images to clarify or illustrate a 
point.

But there are some negatives that concern me:

(1) I presume that HTML responses will be shown in proportional font by 
default, and plain-text responses in fixed-pitch font. The effect of 
intermixing these in random order - which will inevitably happen since 
some people will post using Backtalk and others using Picospan - could 
be unattractive and distracting. (I don't really know how bad this will 
be until I see it.)

(2) Some people will inevitably insist on using "glitzy" features of 
HTML in most or all of their responses - larger fonts, colored fonts, 
animated GIF's. Even a little of this would be a perpetual annoyance.

(3) With most browsers, it is very easy to paste a prepared HTML 
document into a text entry form. (I did so in a couple of responses in 
item 8 of the "backtalk" conference. Check it out, using the new 
version of Backtalk.) I worry that this would make Grex an attraction 
to spammers.

A worst-case scenario would be that conferences in which HTML posting 
is turned on become poster children for the "decline of graphics 
standards" (see Larry Kestenbaum's item about this in winter Agora) as 
well as dumping grounds for spam.

Now, that's a worst-case scenario. The reality might not be as bad. But 
these are some issues to think about.

Have you considered HTML subsets as a configuration option, that is,
allowing certain tags to be selectively turned on or off, at the option 
of the fairwitness? Turning off <IMG> would discourage spam, and 
turning off <FONT> would control certain other forms of potential 
obnoxiousness. On the other hand, there are conferences where you'd 
probably want to allow those tags (e.g. "classified").

The negatives I've mentioned might or might not be significant problems 
in practice. It depends on user behavior.

response 16 of 92:

Mar 8 16:40 UTC 1999

Will there be a way for Backtalk users to avoid HTML in user messages?  
I'm looking forward to seeing what happens when people start using the 
new version of Backtalk, but at the same time, I can imagine problems 
with HTML in messages which I or others might want to avoid.

response 18 of 92:

Mar 9 04:57 UTC 1999

I know what you mean.  Coop always causes me eyestrain.

But Backtalk has one basic defect that you have to keep in mind.  Every
new page is a completely new run of the program.  That means
configuration files can't just be loaded once and saved in memory, they
have to be loaded and parsed again on every hit of every page.  The more
configurability I put in, the slower the whole thing gets.  Until I
develop a way to save more state between processes (FastCGI or the moral
equivalent), I'm inclined to keep the number of different configuration
options modest.

So I'm not very enthusiastic about letting fairwitnesses ban individual
HTML constructs.  For one thing, it's confusing for users to have to
remember which HTML tags work in which conferences.

My notion in designing the Pistachio interface was that fairwitnesses
should be able to give their conferences distinctive looks.  I like that
a lot.  Conferences with default color settings actually kind of annoy
me.  It seems wrong for the staff conference and agora to be the same
color.  So, though I find the contrast between text and background too
low in "coop", I do like the fact that I can recognize that it is "coop"
at a glance.

If I let user's override conference background colors, then either all
conferences turn the same colors, which is deathly dull, or I have to
let users configure conference colors on a per conference basis. 
Theoretically, the latter solution is fine.  In practice, I'd have to
figure out how to store not just setting for each user and settings for
each conference, but settings for each user/conference pair.  And I have
to figure out how to find and load those settings fast on every hit by
every user on every conference page.  Glug.

Futhermore, this messes badly with people using
<FONT COLOR=RED>Hello</FONT> stuff in HTML postings, because how can I
be sure that no user has a red background?

So for now my solution is that you either (1) complain to the
fairwitness that his conference colors stink, or (2) use your browser's
preference menu to override the conference color, or (3) highlight the
text with your cursor.  I use option 3 to read coop.

response 20 of 92:

Mar 9 20:10 UTC 1999

I don't get the "deathly dull" bit. I did conferencing for years with a text
interface that always looked exactly the same, and found it continuously
enjoyable. So did you.

Somehow, setting up a system in which one has to worry about what color
someone might be entering their text in seems antithetical to the notion of
conferencing being for good conversation.

response 22 of 92:

Mar 11 02:27 UTC 1999

i suggest a counterpoint.  making the html tools available may well increase
the amount of junk postings, but they will also offer greatly improved
referencing and illustration of discussion points, especially with the
abilility to paste URLs and tabular information with assurance that the
formatting will remain intact.

response 24 of 92:

Mar 11 11:43 UTC 1999

I disagree with rtg's point 3 right above...  I like the Grex "one long
thread" approach much more than the Usenet model of many forks.  I hate having
to navigate all those little forks...