W3C home > Mailing lists > Public > www-style@w3.org > July 1996

RE: Introducing NetscapeML

From: David Perrell <davidp@earthlink.net>
Date: Tue, 2 Jul 1996 16:15:01 -0700
Message-ID: <01BB6831.A537BBC0@pool018.max1.montebello.ca.us.dynip.earthlink.net>
To: "'Scott E. Preece'" <preece@predator.urbana.mcd.mot.com>
Cc: "'www-style@w3.org'" <www-style@w3.org>
Scott E. Preece wrote:

If I'm interpreting the intention correctly (I haven't downloaded it yet to try out), the name spacer is appropriate because it just inserts a piece of empty space at a point.  You seem to be interpreting  it as a container that controls spacing within a block of content.

SPACER could be used, for instance, to provide the indentation of lines of prettyprinted source code or to set poetry or other material whose format doesn't fit the simple text model of HTML.

No argument. SPACER would be a more powerful alternative to such standard typographical entities as emspace, enspace, thinspace, etc. (the lack of which in Navigator is difficult for me to understand), so long as it allows the full gamut of fixed and relative spatial descriptors. But given the usage, I would still ask "why 'spacer'?" Why not the shortest possible abbreviation?

Doing this kind of thing in stylesheets would be really, really ugly.
Providing a tab stop capability might be better for some uses, but for
some real uses, direct, local control of spacing is the only reasonable approach.

Would letterspacing with SPACER be attractive?

Rather than expressed inline with style=, why not express CSS inline in standard HTML format:

     <P MARGIN-BOTTOM=0>deep in dark least ourselves remembering<BR>
     love only rides his year.

     <P MARGIN-LEFT="30%" MARGIN-BOTTOM="1em">All lose,whole find


? (I assume here that the arbitrary paragraph spacing added by current browsers equates to the bottom margin of the paragraph block, so a bottom margin of 0 would eliminate that space.)

How would this look with SPACER?

Note that MULTICOLS has three attributes, not just COLS.  Adding GUTTER and WIDTH (meaning column width) to DIV would, to my eye, have been broken.  Interfaces should do one thing.  It's always a bad sign when the value of one argument controls which other arguments are applicable - usually, the interface should have been split into two separate interfaces specific to their separate purposes.  It would be nice to have polymorphism here (so a MULTICOLS icould be a specialized DIV)...

First, GUTTER historically refers to the bound white space between pages (there's a logical analogy here), not between columns on a page. Someone expanded the definition in an Aldus Pagemaker manual and it seems to have become "common knowledge." I would suggest COLSPACE (or COLSPC) as more appropriate.

And once again it's a matter of semantics. If we consider a single column as a default DIV, with multiple columns as an option, what's the problem with <DIV COLS=2 COLWIDTH="48%">? What's broken?

In the single-column case of <DIV COLWIDTH="48%">, the column would, by default, have a 53% right margin, and any COLSPACE would be ignored.

Remember, though, that they're aiming at concepts they can describe to people who aren't software people.  We may not be good judges of what is hard or easy for those users to understand.

Who is? Are "those users" of a single sort? HTML coding is not something anyone will jump into with full-blown expertise simply because the tags are semantically precise (and as you point out, SPACER is not). Authors are building a document. The most important thing is a logically consistent structure with as few elements as possible, each element having a particular scope and attributes. If the understanding of computer-illiterates is of concern, how will a proliferation of overlapping elements promote enlightenment? (Do I <CENTER> or <DIV ALIGN="CENTER">? Arrrg!)

Most computer users are familiar with some word processor, and such applications typically assign columnar specs to a particular section of a document. The analogy in HTML is DIV. And there, in my opinion, is where columnar specifications belong.

David Perrell
Received on Tuesday, 16 July 1996 01:31:25 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:26:40 UTC