Re: Proposal: ALT text for IMG does not allow carriage returns

"Daniel W. Connolly" <connolly@hal.com>
Date: Tue, 2 Aug 94 13:07:03 EDT
Message-id: <9408021706.AA02064@ulua.hal.com>
Reply-To: connolly@hal.com
Originator: html-wg@oclc.org
Sender: html-wg@oclc.org
Precedence: bulk
From: "Daniel W. Connolly" <connolly@hal.com>
To: Multiple recipients of list <html-wg@oclc.org>
Subject: Re: Proposal: ALT text for IMG does not allow carriage returns 
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
X-Comment: HTML Working Group (Private)
In message <9408021651.AA24024@hook.spyglass.com>, Eric W. Sink writes:
>
>I suggest we edit the document to specifically prohibit carriage returns
>within the ALT attribute for the IMG tag.  I don't know what browser
>supports this, but there must be at least one in the world, since
>there are web sites making use of the "feature".  Nonetheless, I
>don't think there's enough reason to call this Bad Idea (IMHO)
>current practice.
>
>Comments?

Why is this a bad idea? What's wrong with:

	<img alt="some text
	some more text" src="xxx.gif">

Seems like perfectly reasonable SGML to me. Are there HTML parsers
that act strangely when they see newlines inside attribute values?

[By the way... the SGML standard states that to determine the
value of an attribute from an attribute value literal, e.g
to compute
		abc<def>"
from
		"abc&lt;def&gt;&#34;"
you're supposed to change RE characters to SPACE characters.
In many SGML document files, the \n character represents
the sgml RE character. This is not so in HTML. There is no
RE character in HTML, so none of this hocus-pocus newline
processing occurs.

I have enhanced SGML.c from libWWW to support numeric character
references inside attribute value literals, e.g.
	"abc &#34; def &#62;"
but entity references are still not supported, e.g.
	"abc &dquot; def &lt;"
]




Dan