- From: Cathleen McGuire <CathleenM@msn.com>
- Date: Sat, 3 Aug 96 18:47:34 UT
- To: www-html@w3.org
unsubscribe www-html-d
----------
From: www-html-d-request@w3.org
Sent: Friday, August 02, 1996 6:43 PM
To: www-html-d@w3.org
Subject: www-html-d Digest V96 #243
------------------------------
Content-Type: text/plain
www-html-d Digest Volume 96 : Issue 243
Today's Topics:
Re: Render EM as underline [was: deprecated tags in Wilbur & Cougar] (fwd)
Re: Proposal: Definition Popup Tag
Re: What about ?
Re: deprecated tags in Wilbur & Cougar -Reply
Re: deprecated tags in Wilbur & Cougar -Reply
Re: deprecated tags in Wilbur & Cougar -Reply
NDN: www-html-d Digest V96 #242
Re: What about ?
Re: deprecated tags in Wilbur & Cougar -Reply
i know this is absolutely the wrong forum for this but...
Netscape and SGML
Re: Netscape and SGML
Re: What about ?
Re: What about ?
Tastes great! Less filling!
Re: Tastes great! Less filling!
Re: What about ?
------------------------------
Date: Thu, 01 Aug 1996 20:31:34 +0200
From: galactus@stack.urc.tue.nl (Arnoud "Galactus" Engelfriet)
To: www-html@w3.org
Subject: Re: Render EM as underline [was: deprecated tags in Wilbur & Cougar]
(fwd)
Message-ID: <GgPAy4uYONrK089yn@stack.urc.tue.nl>
In article <ae26722601021004d0e7@[199.106.6.97]>,
Terje@in-Progress.com (Terje Norderhaug) wrote:
> At 6:26 PM 7/30/96, MegaZone wrote:
> >Never happen. People expect EM to be italics in all major browsers, I
> >know I would not be alone it screaming my objections if that were even
> >considered. Besides, people would just start using <I> if that change
> >happened.
>
> I assume you refer to HTML authors when you say "people". Those that would
> be using <EM> with requirements about how it will be rendered is probably
> using <I> anyway. A main feature of an element for describing what is
> emphasized is that you can change the rendering as appropriate.
Well, one possible reason for using EM when you want I is what I
have often heard: People use <I>, get flamed by someone who says
he should use <EM> and <STRONG>, so he replaces all his <I> tags
by <EM>. It shows up the same in Netscape and keeps the purists
quiet, so he gets the best of both worlds.
Galactus
--
To find out more about PGP, send mail with HELP PGP in the SUBJECT line to me.
E-mail: galactus@stack.urc.tue.nl - Please PGP encrypt your mail if you can.
Finger galactus@turtle.stack.urc.tue.nl for public key (key ID 0x416A1A35).
Anonymity and privacy site: <http://www.stack.urc.tue.nl/~galactus/remailers/>
------------------------------
Date: Thu, 01 Aug 1996 16:40:15 -0500 (EST)
From: Foteos Macrides <MACRIDES@SCI.WFBR.EDU>
To: marcush@crc.ricoh.com
Cc: www-html@w3.org
Subject: Re: Proposal: Definition Popup Tag
Message-id: <01I7RNWBXES6000D3R@SCI.WFBR.EDU>
Content-type: TEXT/PLAIN; CHARSET=US-ASCII
Content-transfer-encoding: 7BIT
"Marcus E. Hennecke" <marcush@crc.ricoh.com> wrote:
>On Thu, 1 Aug 1996 15:23:09 -0400 (EDT),
> Carsten Whimster <bcrwhims@undergrad.math.uwaterloo.ca> wrote:
>> Proposal for a Definition Popup Tag:
>
>Something similar has been proposed previously:
>
>On Wed, 26 Jun 1996 08:58:26 -0400,
> Melt van Schoor <Hermanus@iafrica.com> wrote:
>> This is probably not new, but has anyone ever thought about glossarry-style
>> hyperlinks, where a certain term might be explained in, say a pop-up box?
>
>Yes, something like this has been discussed on the HTML working group
>mailing list. Check out
>
>http://www.acl.lanl.gov/HTML_WG/html-wg-96q1.messages/0168.html
>http://www.acl.lanl.gov/HTML_WG/html-wg-96q1.messages/0558.html
>http://www.acl.lanl.gov/HTML_WG/html-wg-96q1.messages/0760.html
>
>Apparently, there is even a browser that handles this glossary markup.
This would be ideal for that:
<!--======================== Footnotes ====================================-->
<!--
Typically rendered as popup note. These elements are referenced
by hypertext links specified with the anchor element.
-->
<!ELEMENT FN - - %body.content;>
<!ATTLIST FN %attrs; -- id, class, style, lang, dir -->
Footnotes
Permitted Context: %body.content, %flow, %block
Content Model: %body.content
The FN element is designed for footnotes, and when practical, rendered
as pop-up notes.
Example:
<DL>
<DT>Hamlet: <DD>You should not have believed me, for virtue cannot so
<a href="#fn1">inoculate</a> our old stock but we shall <a
href="#fn2">relish of it</a>. I loved you not.
<DT>Ophelia: <DD> I was the more deceived.
<DT>Hamlet: <DD>Get thee to a nunnery. Why wouldst thou be a breeder
of sinners? I am myself <a href="#fn2">indifferent honest</a> ...
</DL>
<fn id=fn1><i>inoculate</i> - graft</fn>
<fn id=fn2><i>relish of it</i> - smack of it (our old sinful
nature)</fn>
<fn id=fn3><i>indifferent honest</i> - moderately virtuous</fn>
Note: If %html.recommended is active, the HTML 3.0 DTD expects you to
enclose plain text in a block element such as <P> e.g.
<FN ID=fn23><P>A simple footnote</FN>
Permitted Attributes
ID
An SGML identifier used as the target for hypertext links or
for naming particular elements in associated style sheets.
Identifiers are NAME tokens and must be unique within the scope
of the current document.
LANG
This is one of the ISO standard language abbreviations, e.g.
"en.uk" for the variation of English spoken in the United
Kingdom. It can be used by parsers to select language specific
choices for quotation marks, ligatures and hypenation rules
etc. The language attribute is composed from the two letter
language code from ISO 639, optionally followed by a period and
a two letter country code from ISO 3166.
CLASS
This a space separated list of SGML NAME tokens and is used to
subclass tag names. By convention, the class names are
interpreted hierarchically, with the most general class on the
left and the most specific on the right, where classes are
separated by a period. The CLASS attribute is most commonly
used to attach a different style to some element, but it is
recommended that where practical class names should be picked
on the basis of the element's semantics, as this will permit
other uses, such as restricting search through documents by
matching on element class names. The conventions for choosing
class names are outside the scope of this specification.
STYLE
For fine tuning the style to achieve maximum sex appeal.
DIR
For internationalization.
<NOTE CLASS="joyful"> that since the Content-Model is %body.content,
and presentational features can be fine tuned via style sheets and/or
the STYLE attribute, all of the special-purpose popup proposals
are encompassed by this, i.e., you make the content whatever
markup is ideal for your purpose. Think of it as a popup TABLE
cell which can be positioned anywhere in the document, with
the popup appearing there for clients which fully support it,
and the <FN ID="wow">...</FN> itself placed at the bottom of
the document, serving as a NAMEd anchor (via it's ID) for
clients which do not fully support the fancier presentational
features.</NOTE>
Fote
=========================================================================
Foteos Macrides Worcester Foundation for Biomedical Research
MACRIDES@SCI.WFBR.EDU 222 Maple Avenue, Shrewsbury, MA 01545
=========================================================================
------------------------------
Date: Thu, 01 Aug 1996 20:37:11 +0200
From: galactus@stack.urc.tue.nl (Arnoud "Galactus" Engelfriet)
To: www-html@w3.org
Subject: Re: What about ?
Message-ID: <XlPAy4uYOxuc089yn@stack.urc.tue.nl>
In article <960801103128_100320.1303_JHF60-1@CompuServe.COM>,
Jonathan Rosenne <100320.1303@CompuServe.COM> wrote:
> Arnoud "Galactus" Engelfriet wrote:
> >Then how do we define ™? I don't see anything wrong with thinking
> >up new entities, as long as you unambigously define which entity it
> >should be.
>
> ™ is the UCS-4 character ™ or a reasonable representation of
> it.
Ok, bad example. What I was trying to say is that the definition of the
entity is what matters. If the HTML specs were to say that &emspace;
would correspond to ⃒ that would be perfectly valid. It would just
be a bad name for this character.
IOW, if the specs say should (not) collapse, then that's what
should happen.
> >Yes, but is there a *reason* for not to get collapsed, like the
> >normal space?
>
> There are reasons, and this is why so many implementations - HTML and others
- treat
> NBSP the way they do. The main reason is the logic that NBSP is treated just
like
> any other graphic character -- it does not make much sense to invest in
special
> logic for a feature that was included for compatibility and the use of which
is
> discouraged. Another reason is that this is what many authors expect.
I have never understood the reason as to why HTML 2 says that use of
the non-breaking space is discouraged. Perhaps it was a valid concern
at the time of writing, when few browsers supported it. But now almost
every browser does.
In any case, the logic of parsing in a collapsing way doesn't seem
too hard to me. Basically you regard the words before and after it as one
word, AFTER having collapsed multiple spaces between the words. If it
occurs at the beginning of a paragraph, just kill it.
I would say that cases like " " are implementation dependant
and should be avoided.
> >In my opinion, (as well as the HTML 3 draft's), the
> >non-breaking space is simply a space where the line should not be
> >broken. If it occurs at a location away from the line end, it should
> >be treated as a normal space, including the collapsing.
>
> This is a valid view when one ignores the installed base and common
practice.
The common practice is only because that's what the current browsers
(incorrectly, IMO) do with it. I don't see why this would mean what
the browsers do is right: Try feeding the following comment to any
current browser.
<!-- I'm a comment -- --> foozlebib -->
The "installed base" and "current practice" demand that the '> foozlebib'
text should be displayed, even though this is technically part of the
comment.
Galactus
--
To find out more about PGP, send mail with HELP PGP in the SUBJECT line to me.
E-mail: galactus@stack.urc.tue.nl - Please PGP encrypt your mail if you can.
Finger galactus@turtle.stack.urc.tue.nl for public key (key ID 0x416A1A35).
Anonymity and privacy site: <http://www.stack.urc.tue.nl/~galactus/remailers/>
------------------------------
Date: Thu, 01 Aug 1996 14:28:08 -0700
From: Matt Heffron <heffron@falstaff.css.beckman.com>
To: www-html@w3.org
Subject: Re: deprecated tags in Wilbur & Cougar -Reply
Message-Id: <199608012128.AA109504888@inet.dp.beckman.com>
>In article <1.5.4.32.19960801134613.00748d04@csclub.uwaterloo.ca>,
>Paul Prescod <papresco@calum.csclub.uwaterloo.ca> wrote:
>> At 12:32 PM 8/1/96 +0200, Arnoud "Galactus" Engelfriet wrote:
>> >It's similar to using <SPAN CLASS=phonenumber> and then specifying how
>> >it should be displayed in the style sheet, rather than having a standard
>> ><PHONE> element, which the browser can display/render/dial/stuff-in-a-
>> >phone-book any way it likes.
>>
>> It doesn't really matter whether you do it in CLASS or with an element. The
>> important thing is that it be _standardized_. We should standardize CLASS
>> sets just as we standardize entity and elemenet sets.
>
>That would only partially solve the problem. By putting information
>about the *contents* of marked-up text in a style sheet, you're
>actually lessening the power HTML can offer.
>
>Style sheets are for layout.
>HTML elements are for contents.
>
I agree that HTML elements are for STRUCTURE of the document contents.
I hope it is clear that we don't need/want a new tag for each new ROLE
that some part of a document plays in the document as a whole.
(Heaven forbid that lawyers create new tags for every type of information
in a legal document! <PLAINTIFF>, <CASENUMBER>, <UNDERPAID_PUBLIC_DEFENDER>,
<CELEBRITY_$$_DEFENDANT>, ... :-)
The tags would explode exponentially as EVERY field that has it's own
types of information in a document would be creating new tags.
There are SOME relatively universal document structures, and significant
roles that need their own tags. Some, like <B>, <I>, (and perhaps <U> which
started this whole thread) must continue for a long time for backward
compability.
Using tags such as DIV and SPAN with CLASS attributes does not preclude
indexers from using the CLASS info to build smart indices. There
could/should be some "standard" CLASSes that are defined a-priori (e.g. your
"phonenumber" class from above). Otherwise, let each field define their own
standard classes for their documents and define a standard style sheet for
the "default" rendering of those documents. The proliferation of tags will
slow to a crawl (hopefully) and the "my browser has the <FOO> tag and yours
doesn't" wars (akin to the playground "my dad can beat-up your dad"
arguments) will be silenced.
Matt
--
Matt Heffron heffron@falstaff.css.beckman.com
Beckman Instruments, Inc. voice: (714) 961-3128
2500 N. Harbor Blvd. MS X-10, Fullerton, CA 92634-3100
I don't speak for Beckman Instruments (or CRFG) unless they say so.
------------------------------
Date: Thu, 01 Aug 1996 17:27:14 -0400
From: Paul Prescod <papresco@calum.csclub.uwaterloo.ca>
To: galactus@stack.urc.tue.nl (Arnoud "Galactus" Engelfriet), www-html@w3.org
Subject: Re: deprecated tags in Wilbur & Cougar -Reply
Message-Id: <1.5.4.32.19960801212714.0075ed10@csclub.uwaterloo.ca>
Content-Type: text/plain; charset="us-ascii"
At 08:28 PM 8/1/96 +0200, Arnoud "Galactus" Engelfriet wrote:
>In article <1.5.4.32.19960801134613.00748d04@csclub.uwaterloo.ca>,
>That would only partially solve the problem. By putting information
>about the *contents* of marked-up text in a style sheet, you're
>actually lessening the power HTML can offer.
>
>Style sheets are for layout.
>HTML elements are for contents.
CLASS is for content, just as elements are for content. Therefore the debate
about whether to make something an element or a class need not involve
stylesheets at all. The questions we should ask are:
"Does this data class have content model implications?" If so, an element is
more appropriate. Classes cannot have specialized content models or occur in
different content models than their elements.
"Is this class specific to a small vertical market?" If so, a class is more
appropriate. Elements must be supported by all tools, everywhere (until all
tools support generic SGML).
"Is this class important enough to change the DTD and incur these costs?"
"How soon is the new DTD going to be available?" Since classes can be
deployed more quickly, a class may be more appropriate.
"Is this concept experimental?" Classes can be dropped more easily than
elements, so a class may be more appropriate.
"Are we unsure?" Classes can be turned into elements more easily than vice
versa, so when in doubt, a class may be better.
Note that none of these questions involve style sheets. Style sheets are a
way of attaching visual representations to particular elements _or_ classes.
Paul Prescod
------------------------------
Date: Thu, 1 Aug 1996 22:33:08 GMT
From: "Christopher R. Maden" <crm@ebt.com>
To: www-html@w3.org
Subject: Re: deprecated tags in Wilbur & Cougar -Reply
Message-Id: <199608012233.WAA08376@phaser.EBT.COM>
Matt Heffron:
> (Heaven forbid that lawyers create new tags for every type of
> information in a legal document! <PLAINTIFF>, <CASENUMBER>,
> <UNDERPAID_PUBLIC_DEFENDER>, <CELEBRITY_$$_DEFENDANT>, ... :-)
>
> The tags would explode exponentially as EVERY field that has it's
> own types of information in a document would be creating new tags.
This is already happening - it's called SGML. Lawyers could have
their own DTD! Imagine that!!!!!!!!
SP is out there. It's free. IMPLEMENT IT ALREADY! An SGML-based
browser's only limitation would be that it wouldn't handle some of the
crap that some current browsers do, and users would complain.
Preemptory response: Yes, I should do it myself. I will. But give me
a few more years to finish working through K&R in my copious free
time.
> There are SOME relatively universal document structures, and
> significant roles that need their own tags. Some, like <B>, <I>,
> (and perhaps <U> which started this whole thread) must continue for
> a long time for backward compability.
There is need for these, sometimes, but far FAR less than you might
think. EBT has products called, among other things, DynaText and
DynaTag. "Dyna" is italicized. Not for any good reason, really, it
just is, so I use <i> for it in HTML. I *never* use it otherwise.
There's always a reason I think it should be italicized. Title? Use
<cite>. Foreign word? Use <em>. Variable? Use <var>. Ditto
boldface or underlining.
The <u> element, I think is more damaging than <i>, because it's only
shorthand for italics in the first place. However, just as I found a
use for pure <i> in <i>Dyna</i>Web, someone else might have a use for
pure <u>, so I won't stand in its way.
If someone finds that the presentation of the document is critical
enough that the important words *must* be italicized, etc., their
documents are probably better suited for PDF. I don't mean that in
any derogatory sense; if presentation is the primary focus, than a
page description language is what is wanted, not generic markup.
> Using tags such as DIV and SPAN with CLASS attributes does not
> preclude indexers from using the CLASS info to build smart indices.
> There could/should be some "standard" CLASSes that are defined
> a-priori (e.g. your "phonenumber" class from above). Otherwise, let
> each field define their own standard classes for their documents and
> define a standard style sheet for the "default" rendering of those
> documents. The proliferation of tags will slow to a crawl
> (hopefully) and the "my browser has the <FOO> tag and yours doesn't"
> wars (akin to the playground "my dad can beat-up your dad"
> arguments) will be silenced.
Oh please oh please cat fud. Maybe some day this dream will come
true. AND IF SGML WERE USED INSTEAD OF TAG-SOUP PROCESSING, IT WOULD!
If someone needed a new tag, they could just add it!
... I'm done ranting now.
-Chris
--
<!NOTATION SGML.Geek PUBLIC "-//GCA//NOTATION SGML Geek//EN">
<!ENTITY crism PUBLIC "-//EBT//NONSGML Christopher R. Maden//EN" SYSTEM
"<URL>http://www.ebt.com <TEL>+1.401.421.9550 <FAX>+1.401.521.2030
<USMAIL>One Richmond Square, Providence, RI 02906 USA" NDATA SGML.Geek>
------------------------------
Date: 01 Aug 1996 23:31:26 GMT
From: Gateway@magnet.at (Gateway)
To: www-html@w3.org
Subject: NDN: www-html-d Digest V96 #242
Message-Id: <71434173.3569170@magnet.at>
Sorry. Your message could not be delivered to:
Heinz Tuppinger,magnet (The name was not found at the remote site. Check that
the name has been entered correctly.)
------------------------------
Date: Sun, 1 Aug 1976 17:13:59 -0700
From: Walter Ian Kaye <boo@best.com>
To: www-html@w3.org
Subject: Re: What about ?
Message-Id: <v03007804888858bf5790@[205.149.180.135]>
Content-Type: text/plain; charset="us-ascii"
At 8:33p +0200 08/01/96, Arnoud "Galactus" Engelfriet wrote:
>Eh? I thought it was defined as "connects two non-whitespace sequences
>in such a way the line will not be broken between the two."
And this behavior just happens to be fulfilled by simply treating the
nonbreaking-space as non-whitespace. And since non-whitespace does not
collapse, is "protected" from collapsing. No special treatment
was necessary, no special treatment was specified, and so no special
treatment was ever applied to . Why start now?
>This doesn't
>say anything about collapsing in either way, but as it's a _space_
>it should be collapsed, IMO.
No, it only *looks* like a space. (Why does this remind me of Dan Rather?;)
-Walter
__________________________________________________________________________
Walter Ian Kaye <boo@best.com> Programmer - Excel, AppleScript,
Mountain View, CA ProTERM, FoxPro, HTML
http://www.natural-innovations.com/ Musician - Guitarist, Songwriter
------------------------------
Date: Fri, 02 Aug 1996 11:56:45 +0100
From: Abigail <abigail@uk.fnx.com>
To: www-html@w3.org
Subject: Re: deprecated tags in Wilbur & Cougar -Reply
Message-ID: <3201DEED.167EB0E7@uk.fnx.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Matt Heffron wrote:
>
> >In article <1.5.4.32.19960801134613.00748d04@csclub.uwaterloo.ca>,
> >Paul Prescod <papresco@calum.csclub.uwaterloo.ca> wrote:
> >
> >Style sheets are for layout.
> >HTML elements are for contents.
> >
> I agree that HTML elements are for STRUCTURE of the document contents.
> I hope it is clear that we don't need/want a new tag for each new ROLE
> that some part of a document plays in the document as a whole.
>
> (Heaven forbid that lawyers create new tags for every type of information
> in a legal document! <PLAINTIFF>, <CASENUMBER>,
<UNDERPAID_PUBLIC_DEFENDER>,
> <CELEBRITY_$$_DEFENDANT>, ... :-)
I don't understand all this talk about `legal' documents; that they must
have underline, small print and strawberry flavoured letters. *If* the
appearance of a document is important for it to be considered legal,
than surely HTML is _not_ the proper way to publish it? Why not distribute
it in a language which is much more suitable for that, like TeX or
PostScript? Granted, you will lose some platform independance, but you
will anyhow if appearance is vital.
HTML is well suited for the task it is supposed to do. And so are TeX and
PostScript. People should pick a method best suited for their purposes,
and not try to blend HTML into a `do-it-all-but-nothing-well' thingy.
Abigail
------------------------------
------------------------------
Date: Fri, 2 Aug 1996 07:14:47 -0700
From: Erik Aronesty <earonesty@montgomery.com>
To: "'www-html@w3.org'" <www-html@w3.org>
Subject: i know this is absolutely the wrong forum for this but...
Message-ID:
<c=US%a=_%p=Montgomery%l=EXCHANGE_SERVE-960802141447Z-398@sf-exch-2.montgomery
.com>
looking for a specification of a standardized data format which
is suitable for transferring datasets over HTTP
anyone know if there is an RFC...a working-group....a file
spec....etc...for this sort of thing?
the only formats i know of are "quote-delimited" or
"delimited-and-escaped"....which are only good for a single data
stream...and don't give you the opportunity to define the data within
------------------------------
Date: Fri, 2 Aug 1996 11:47:27 -0400 ()
From: Michael Seaton <mseaton@pobox.com>
To: www-html@w3.org
Subject: Netscape and SGML
Message-ID: <Pine.WNT.3.95.960802112835.-488887B-100000@mseaton.nbnet.nb.ca>
Content-Type: TEXT/PLAIN; charset=US-ASCII
I discovered the following statement in Netscape's documentation for
Naviagtor 3.0:
http://home.netscape.com/comprod/products/navigator/version_3.0/multicolumns.h
tml
> Font styles - The MULTICOL tag recognizes current font status. So if you
> begin a bold section before the multicolumn, the text in the columns
> will start bold, and if you close the bold in the middle of the
> multicolumn, this nonbold status will continue once you leave the
> multicolumn.
i.e.
<B> bold text <MULTICOL> bold text </B> plain text </MULTICOL> plain text
It was my understanding that SGML elements were not permitted to overlap;
is it even possible for a DTD to specify this behaviour?
--
Michael Seaton (mseaton@pobox.com)
------------------------------
Date: Fri, 2 Aug 1996 11:32:49 -0400 (EDT)
From: Sunil Mishra <smishra@cc.gatech.edu>
To: www-html@w3.org
Subject: Re: Netscape and SGML
Message-Id: <199608021532.LAA06064@cleon.cc.gatech.edu>
\\ I discovered the following statement in Netscape's documentation for
\\ Naviagtor 3.0:
\\
\\
http://home.netscape.com/comprod/products/navigator/version_3.0/multicolumns.h
tml
\\ > Font styles - The MULTICOL tag recognizes current font status. So if you
\\ > begin a bold section before the multicolumn, the text in the columns
\\ > will start bold, and if you close the bold in the middle of the
\\ > multicolumn, this nonbold status will continue once you leave the
\\ > multicolumn.
\\
\\ i.e.
\\
\\ <B> bold text <MULTICOL> bold text </B> plain text </MULTICOL> plain text
\\
\\ It was my understanding that SGML elements were not permitted to overlap;
\\ is it even possible for a DTD to specify this behaviour?
\\
\\ --
\\ Michael Seaton (mseaton@pobox.com)
Netscape has never cared about SGML, and probably never will. As far as I
know, that is completely broken SGML. Although Netscape never did specify
this, the <font> tag could cross paragraph boundaries, such that if you put
a <font ...> in paragraph 1, and put in </font> in paragraph3, you would
end up with parts of paragraph 1 and 3 and all of paragraph 2 modified.
I would love to see them try and write a DTD fragment for that.
Sunil
------------------------------
------------------------------
Date: Fri, 02 Aug 1996 20:01:15 +0200
From: galactus@stack.urc.tue.nl (Arnoud "Galactus" Engelfriet)
To: www-html@w3.org
Subject: Re: What about ?
Message-ID: <rJkAy4uYOBBU089yn@stack.urc.tue.nl>
In article <v03007804888858bf5790@[205.149.180.135]>,
Walter Ian Kaye <boo@best.com> wrote:
> At 8:33p +0200 08/01/96, Arnoud "Galactus" Engelfriet wrote:
> >Eh? I thought it was defined as "connects two non-whitespace sequences
> >in such a way the line will not be broken between the two."
>
> And this behavior just happens to be fulfilled by simply treating the
> nonbreaking-space as non-whitespace. And since non-whitespace does not
> collapse, is "protected" from collapsing. No special treatment
> was necessary, no special treatment was specified, and so no special
> treatment was ever applied to . Why start now?
Because is a _space_ and as such should be collapsed. That's
my main argument here. I do not see a *reason* that should
be treated any different from " ".
> No, it only *looks* like a space. (Why does this remind me of Dan Rather?;)
The name *says* it's a space. :-)
Who's Dan Rather?
Galactus
--
To find out more about PGP, send mail with HELP PGP in the SUBJECT line to me.
E-mail: galactus@stack.urc.tue.nl - Please PGP encrypt your mail if you can.
Finger galactus@turtle.stack.urc.tue.nl for public key (key ID 0x416A1A35).
Anonymity and privacy site: <http://www.stack.urc.tue.nl/~galactus/remailers/>
------------------------------
Date: Fri, 02 Aug 1996 20:02:51 +0200
From: galactus@stack.urc.tue.nl (Arnoud "Galactus" Engelfriet)
To: www-html@w3.org
Subject: Re: What about ?
Message-ID: <LLkAy4uYOZgX089yn@stack.urc.tue.nl>
In article <v01540b01ae2792d291d3@[194.150.2.68]>,
jbaagoe@planete.net (Johannes Baagoe) wrote:
> In a message dated 20:37 1/08/96, Arnoud "Galactus" Engelfriet wrote:
> >I have never understood the reason as to why HTML 2 says that use of
> >the non-breaking space is discouraged. Perhaps it was a valid concern
> >at the time of writing, when few browsers supported it. But now almost
> >every browser does.
>
> Non-breaking spaces are necessary, e.g., to write good French. French
Well, they'r also quite useful in other languages, even in English.
For example, to protect initials and last names getting separated, or
to keep "Chapter" and "5" together.
And since HTML is now trying to be more international, doesn't this
indicate that should become MORE important?
Galactus
--
To find out more about PGP, send mail with HELP PGP in the SUBJECT line to me.
E-mail: galactus@stack.urc.tue.nl - Please PGP encrypt your mail if you can.
Finger galactus@turtle.stack.urc.tue.nl for public key (key ID 0x416A1A35).
Anonymity and privacy site: <http://www.stack.urc.tue.nl/~galactus/remailers/>
------------------------------
Date: Fri, 2 Aug 1996 14:05:40 -0700 (PDT)
From: "Lee Daniel Crocker" <lcrocker@calweb.com>
To: www-html@w3.org
Subject: Tastes great! Less filling!
Message-Id: <199608022105.OAA07873@web1.calweb.com>
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Let's sum up and see if we can end this interminable thread
with a decision from the big guys.
To sum up, there are two ways to look at
1. It's just like the letter "G", but using no ink.
2. It's just like a space, except you can't break a line there.
There are many arguments on both sides:
#1 is simple to explain and trivial to implement
#1 is closer to current practice in a particular piece
of shi^H^Hoftware that shall remain nameless.
#2 better fits advanced typological practice: e.g. justified
text will pad or squeeze them like other spaces.
#2 it's _called_ a space, so it should act like one (a pretty
silly argument if you ask me, but it was brought up).
So, can the W3C just agree to pick one for the next version
of whatever they release, document it, and be done with it?
--
Lee Daniel Crocker <lee@piclab.com>
------------------------------
Date: Fri, 2 Aug 1996 21:57:39 GMT
From: amc@cs.wustl.edu (Adam M. Costello)
To: www-html@w3.org
Subject: Re: Tastes great! Less filling!
Message-Id: <9608022157.AA28933@siesta.cs.wustl.edu>
"Lee Daniel Crocker" <lcrocker@calweb.com> says:
> To sum up, there are two ways to look at
>
> 1. It's just like the letter "G", but using no ink.
> 2. It's just like a space, except you can't break a line there.
All the things fitting description 1 that I've ever heard of have been
called "quad space", "em space", "en space", "thick space", or "thin
space".
If authors use "non-breaking space" in the manner it was intended to be
used--to suppress line breaks--then they won't care whether description
1 or 2 applies. If I type 2 Aug 1996 do I really care whether
there is a fixed predefined width for those spaces? Not likely. So
it's no tragedy if browsers don't all agree. Description 2 should
probably be acknowledged as better, but the simpler implementation
allowed by description 1 should be considered sufficient.
When authors want to space things out, they should use something else,
like   or   (as soon as such things are supported).
AMC
------------------------------
Date: Fri, 2 Aug 1996 15:40:53 -0700
From: "David Perrell" <davidp@earthlink.net>
To: <www-html@w3.org>
Subject: Re: What about ?
Message-Id: <199608022237.SAA01938@norway.it.earthlink.net>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Arnoud "Galactus" Engelfriet wrote:
> The name *says* it's a space. :-)
Likewise emspace and enspace and thinspace, all of which are
typically non-breaking, and (I hope) won't collapse when they're
implemented.
David Perrell
--------------------------------
End of www-html-d Digest V96 Issue #243
***************************************
Received on Monday, 5 August 1996 16:14:52 UTC