Re: Netscape's SPACER

  From: "David J. Greenberger" <d.greenberger@cornell.edu>

| On Tue, 16 Jul 1996 10:32:35 -0700, David Perrell wrote:
| 
| >Can anyone explain to me what the TYPE and SIZE attributes add to SPACER
| besides complexity, confusion, and extra characters?
| >
| >Why not just <SPACER HEIGHT=n WIDTH=n>, with default height and width zero?
| 
| Why ask why?  This is Netscape we're talking about, after all, inventors
| of BLINK and CENTER.  What gives you the idea they'll all of a sudden do
| something that makes sense?
---

I don't think snotty, cheap-shot characterizations of other people's
efforts add much to the level of discourse.  State your objections
civilly and propose well-thought-out alternatives; someone who is
creating the future might be able to build on your suggestions (as
opposed to just writing you off as a bozo).

I do agree that this overloading is odd - my own first thought was also
to have just the block mode and use defaulting of the unspecified
direction, though you also need to add a BREAK attribute to control
whether a line-break is implied and I think the defaulting would have
to be to "current line height" or "current line width" rather than to
zero.  If there really are engineering reasons for separating the block
mode from the horizontal and vertical modes, then I would have created
three separate tags, rather than overloading (I probably would have
called them QUAD, LEAD, and HOLE).

My guess would be that they thought that this model (a single tag with
three modes of application) was more attractive pedagogically (easier to
teach and remember one tag than three) and that it was easier to explain
three modes (each of which feels like a simple concept) than to teach a
single model with significant attribute interactions (ALIGN and BREAK
abd defaulting make things complicated).  It's not what I would have
chosen, but it's not stupid, either.  It's' just different.

---
  From: Hakon Lie <howcome@w3.org>

| 
| Holger Struppek writes:
|  > a)
|  > <SPACER TYPE=HORIZONTAL SIZE=width>
|  > (behaves like multiple &nbsp;)
| 
| No, it doesn't. The width of &nbsp; is relative to the font that is
| being used, while the SIZE attribute takes pixel values.
| 
| Compare this with the CSS1 [1] alternative:
| 
|   <BR STYLE="display: inline; width: 10px">  <!-- pixel units -->
---

I have to say I still find the idea of using BR or SPAN as spacers
repugnant.  It's a "programmer's trick" kind of thing (using a funny
collection of attributes to make one construct serve as another - the
programmer's equivalent of sophistry).

The structural meaning of BR is clear in the standard: "The <BR> element
specifies a line break between words" -- using it with "display:inline"
is just plain bad practice.

SPAN is closer to being acceptable, but again this represents a
substantial warping of its intended use (as a carrier for descriptive
attributes on an arbitrary extent of text).  Adjusting the size of a
null string is counter-intuitive.

If we're going to provide a way to insert "meaningful" space (that is,
space whose presence is content), I think there should be a tag that
positively states that presence, whether it's called SPACER or SP or
SPACE or HOLE or whatever.

Note, though, that most of the proposed meaningful uses would be better
handled by a mechanism for specifying meaningful alignment of elements,
rather than by a notion of inserting space.

---
|  > c)
|  > <SPACER TYPE=BLOCK WIDTH=width HEIGHT=height ALIGN=alignment>
|  > (behaves like an invisible image)
| 
| Ditto:
| 
|   <BR STYLE="width: 10px; height: 10pt">
---

I think you'd have to specify more attributes than that to convey all
the semantics of "behaves like an invisible image"; though I suspect all
the needed attributes are available.

scott

--
scott preece
motorola/mcg urbana design center	1101 e. university, urbana, il   61801
phone:	217-384-8589			  fax:	217-384-8550
internet mail:	preece@urbana.mcd.mot.com

Received on Wednesday, 17 July 1996 10:57:38 UTC