Indents

[Cedar Falls Public Library Acct #1]

I liked Thom Dowling's comments and agree 
whole-heartedly with his point about the 
problem of Kludges having to be fixed next 
year or whenever.  After 3 years,
I'm still learning about things that don't
work in lynx and fixing things.

*I* would like to see more recognition by those who
are verbally/printed word-oriented of the fact that
visual design _also_ is involved in the process of
communication of information.  They are sometimes
inseparable.

I'm not "anti-word" which would be ridiculous, but 
it's ocurred to me that one important reason that there's 
any discussion at all of quick fixes that are "dirty" 
is the fact that at it's inception, the model the Web
creators were following was that of the codex or the 
scroll.  I'm not _blaming_ them or anything --
in the West at least, visual elements were always 
considered pretty much secondary to the print.  
Illustration means to augment understanding of the 
words, not stand in place of them.  It's been proven 
however, especially in children's books and in Medieval
stained glass, that printed words are not always necessary. 
It depends on the nature of what you want to convey.

There is also the issue of plain white space.  Every 
artist knows that leaving space open makes what's 
left much more important and meaningful.  The relationship
of images on the page, whatever it's proportion, is 
meaningful in itself.  Indenting sends a different
message from bulleted lists and so sometimes lists are
inappropriate formatting for the information.  I find
non-indented paragraphs less easy to read. (Although of 
course, I'm not bothering to do it here!)  There is a
rhythm to them, a better sense of beginning and end, 
which also makes them seem more reasoned, logical and 
less hasty.

I think that this search for a way to indent or 
tab is additionally reflective of the fact that 
we need visual formatting for simple ease of reading.  
We all know it's not a trivial thing when you're
trying to read something with no line breaks.  

My point is that, for people who are able to 
see and who don't have to use braille, the visual 
aspects of communication are every bit as meaningful 
as the meaning behind only the printed, verbal 
aspect.  This is often very subtle which I think 
is why we don't acknowledge it properly.

For the record, I'm not down on content standards,
-- far from it! -- I'm just surprised that anything 
visual _tends_ to be considered so unimportant.

Thanks,
--Barb Dunn


On Thu, 1 Aug 1996, Thomas Dowling wrote:

> I'm a little disappointed at the seeming willingness on this list to
> recommend deliberately broken HTML structures to kludge together a solution
> to a formatting problem.  IMO this is akin to squeezing awkward cataloging
> data into the wrong MARC field on the presumption that it will come out
> looking right on most OPACs.  <UL> defines an unordered list.  <DL> defines
> a definition list, like a glossary.  <BLOCKQUOTE> defines, umm, a block of
> quoted material.
> 
> Dirty solutions like multiple <UL> or <DL> tags with no <LI> or <DT> do in
> fact work on a certain percentage of browsers, possibly a very high
> percentage.  But you are left with absolutely no guarantee that the next
> hot browser will choose to display these structural elements the way the
> current hot browsers do; in fact it's quite likely that a browser will come
> along that will allow the *user* to determine how an unordered list will be
> presented (indented with bullets? change of font? change of background
> color?).  If you're satisfied with serving users with Netscape 1.2, 2.0,
> 3.0, and don't mind the possibility of having to rewrite all your documents
> next year, and don't envision ever indexing your site, I guess you can go
> ahead.
> 
> In cases where formatting elements like indentation are really necessary
> for the document, there are lots of options, with varying degrees of
> support and elegance:
> 
> 
> Present the document as .txt rather than .html.  Pros: universal support. 
> Cons: monospaced font, lack of hypertext links, no pretty logo.
> 
> Slap <PRE>...</PRE> around the text of the document.  Pros: universal
> support, pretty logo at the top, hypertext links.  Cons: monospaced font.
> 
> PDF.  Pros: you're using a page description language, which is what you
> really need.  Cons: requires commercial software to create the file, less
> than universal support, possible charges from some quarters of being
> elitist and a pawn in Adobe's attempt to take over the world. :-)
> 
> Distribute in a word processor format (most likely Word).  Pros: layout
> control similar to PDF, many users can edit the document once they have it.
>  Cons: requires a compatible word processor or Word viewer, possible
> charges of being elitist and a pawn in Microsoft's attempt to take over the
> world.
> 
> Style sheets.  Pros: in line with a standard that is both supported by the
> web community and gaining favor among some browser manufacturers, lets you
> define or redefine a style (e.g. P.indent1) once for your entire site and
> reference it from any document with a <P class="indent1"> tag.  Cons: very
> limited support as of 8/1/96.
> 
> <SPACER> tag.  Pros: will probably be supported by 40%-50% of your users
> within a couple months.  Cons: another kludge from the gang at Tags-R-Us.
> 
> <TABLE> tag e.g.
> <tr><td colspan=4>Top level paragraph.
>   <tr><td> <td colspan=3>Second level paragraph
> Pros: fairly wide support.  Cons: less than universal support, memory
> problems on some platforms if the document gets too long.
> 
> Preface each line with <PRE>[spaces]</PRE> and end each line with <BR>. 
> Pros: fairly wide support.  Cons: looks really ugly if the previous line
> wraps in a window narrower than you expected, some browsers mistakenly slap
> a line feed after the </PRE> tag.
> 
> Preface each line with &nbsp;&nbsp;... Pros: fairly wide support.  Cons:
> same line wrap problems as above, no rule that multiple nbsp entities
> shouldn't be collapsed into a single space (the rule only says no line
> break there).
> 
> Preface each line with one or more tab-sized, completely transparent GIFs. 
> Pros: fairly wide support.  Cons: line wraps, *really* ugly for people
> using graphical browsers with the graphics turned off.
> 
> <UL>/<DL>/<BLOCKQUOTE> kludge described in previous posts.  Pros: will
> "look right" to many users.  Cons: violates the spirit and sometimes the
> letter of the HTML law, may get mild grumblings from some validation
> services, HTML editors, grumpy old Web4Libbers, etc.
> 
> 
> Thomas Dowling
> tdowling at ohiolink.edu
> (This is a dream.  I'm going to wake up, it will be the summer of 1995, and
> all known browser manufacturers will be presenting beta versions supporting
> all of the newly formalized HTML 3.0, including style sheets and the <TAB>
> tag.  Also, I will have won the lottery the night before.)
> 
>