ALT="<PRE>ascii art</PRE>
Ashley G. Perrien
Has anyone tried putting ascii art as an ALT to a gif? It's not the most
artistic of solutions but for simple graphics, why not?
Possible?
Warren Steel
Ashley G. Perrien wrote:
> Has anyone tried putting ascii art as an ALT to a gif? It's not the most
> artistic of solutions but for simple graphics, why not?
Have you tried it? what did you learn?
HTML markup is allowed in alternative text in the HTML 3.0
<FIG> element, and in the current draft <OBJECT> element, but
neither is widely implemented. An inline image <IMG> may
include an ALT= attribute, but the attribute value may not
include additional markup (other than entities such as ").
What a particular browser may do with such invalid HTML is
completely unpredictable and unreliable.
"ASCII art" may be easily incorporated in a preformatted
block <PRE>, provided that only the ISO-Latin-1 character set
is used (no IBM-PC line-drawing characters, for example), and
that all instances of < > and & are "entified." But this
preformatted block may not be part of the ALT= attribute.
I hope this is clear.
--
Warren Steel mu...@olemiss.edu
Department of Music University of Mississippi
URL: http://www.mcsr.olemiss.edu/~mudws/
Klaus Johannes Rusch
Ashley G. Perrien wrote:
>
> Has anyone tried putting ascii art as an ALT to a gif? It's not the most
> artistic of solutions but for simple graphics, why not?
>
No, the alt attribute takes PCDATA only, no tags allowed. You would need
to detect if the browser accepts images (Accept: image/gif), and if not
send the text instead using a script or SSI.
Klaus Johannes Rusch
--
e872...@student.tuwien.ac.at, Klaus...@atmedia.net
http://www.atmedia.net/KlausRusch/
Alan J. Flavell
On Thu, 19 Sep 1996, Klaus Johannes Rusch wrote:
> No, the alt attribute takes PCDATA only, no tags allowed.
right
> You would need
> to detect if the browser accepts images (Accept: image/gif), and if not
> send the text instead using a script or SSI.
This isn't feasible in practice, for many different reasons. Think it
through.
The answer is (or will be) OBJECT.
--
best regards
"for your safety and convenience, fitted with a UK plug"
Arnoud Galactus Engelfriet
-----BEGIN PGP SIGNED MESSAGE-----
In article <Pine.HPP.3.95.96092...@hpplus09.cern.ch>,
"Alan J. Flavell" <fla...@mail.cern.ch> wrote:
> On Thu, 19 Sep 1996, Klaus Johannes Rusch wrote:
> > to detect if the browser accepts images (Accept: image/gif), and if not
> > send the text instead using a script or SSI.
>
> This isn't feasible in practice, for many different reasons. Think it
> through.
Why wouldn't it be feasible right now? If you set a suitable ALT
text, the worst that can happen is that a Netscape user gets a
rather plain page, or a Lynx user sees [IMAGE] if he hasn't turned
that off.
I use that on my Anonymity and Privacy site - Lynx users get a
text menu bar at the top, and everyone else gets graphical buttons
with acceptable ALT texts. And no, they're not big - the largest
image is 545 *bytes* big.
Galactus
http://www.stack.urc.tue.nl/~galactus/remailers/
- --
E-mail: gala...@htmlhelp.com .................... PGP Key: 512/63B0E665
Maintainer of WDG's HTML reference: <http://www.htmlhelp.com/reference/>
-----END PGP SIGNED MESSAGE-----
Alan J. Flavell
On Fri, 20 Sep 1996, Arnoud Galactus Engelfriet wrote:
> > > to detect if the browser accepts images (Accept: image/gif), and if not
> > > send the text instead using a script or SSI.
> >
> > This isn't feasible in practice, for many different reasons. Think it
> > through.
>
> Why wouldn't it be feasible right now?
I think you are trying to tell me that if a browser lists image/gif
explicitly in its _normal_ accept headers, it proves that it will
display in-line gifs?
I don't see any logical reason why that should be so. The only place
that it would be logical to draw a definite conclusion like that is in
the request when the browser is trying to retrieve the in-line. But a
browser that does not display inlines will never make that request. And
by that time, the HTML has already been sent and can't readily be
revised.
Statistically perhaps you are right. Lynx includes */* in its normal
accept headers since it can potentially display anything (by using an
appropriate helper app), but does not explicitly list image/gif.
Netscape, as it happens, explicitly lists image/gif. The "CERN" (W3C)
linemode browser also explicitly lists image/gif !!! (I tried version
3.0, for the record). Opera, which certainly can display in-lines,
sends */* and nothing more. And (for the record) Cello doesn't send any
accept header at all, although it does display in-line gifs. (OK, a
poor example, since this browser is really obsolete; but I don't have
too many different browsers at my fingertips so I tried the ones I had).
Also there is no indication that a graphical browser has image
auto loading turned off (meaning, presumably, that the reader would
prefer the ascii art instead?).
The next point is of course cache servers. Unless an effort is made
to prevent caching (and you know my views about _that_ ;-) then
whatever version of the document is cached will be sent to whoever
requests it, no matter which browser they use. You say this makes the
accept header useless? Well, so it does, but it's a compromise, and,
at least on the WWW, given a choice between accept headers working
perfectly (which they never have done...) and cache servers working
to relieve the congestion on the WWW, I would have to take the latter.
> If you set a suitable ALT
> text, the worst that can happen is that a Netscape user gets a
> rather plain page, or a Lynx user sees [IMAGE] if he hasn't turned
> that off.
Oh: so you're not claiming that it will work reliably, you're just
saying that it'll do no great harm when it doesn't work. Well, I
can't disagree with that.
Arnoud Galactus Engelfriet
-----BEGIN PGP SIGNED MESSAGE-----
In article <32468fbe...@news.sci.fi>,
myn...@myhome.com (Istvan) wrote:
> It can be done if you put the <IMG SRC=someimage.jpg Alt=your ascii art
> goes here</a> between the <pre></pre> tags. I've seen in done and it does
> exactly what's been asked about.
It works, as long as the ALT text is no longer than 1024 characters
(the limit for attribute values). The only problem is that in HTML
3.2 the IMG tag is not legal inside PRE...
Galactus
Joshua Juran
> On Thu, 19 Sep 1996, Klaus Johannes Rusch wrote:
>
> > No, the alt attribute takes PCDATA only, no tags allowed.
>
> right
You surely mean CDATA, don't you? That's what *my* RFC 1866 says. :-)
(#PCDATA == parsed character data)
> > You would need
> > to detect if the browser accepts images (Accept: image/gif), and if not
> > send the text instead using a script or SSI.
>
> This isn't feasible in practice, for many different reasons. Think it
> through.
Ah, the proxy problem.
> The answer is (or will be) OBJECT.
...and *was* FIG... <sigh>
Josh
--
Joshua Juran Metamage Software
=) and other creative arts
wand...@metamage.com
<http://www.metamage.com/> * Home of TinyMUSH/Mac *
Alan J. Flavell
On Mon, 23 Sep 1996, Arnoud Galactus Engelfriet wrote:
> In article <32468fbe...@news.sci.fi>,
> myn...@myhome.com (Istvan) wrote:
> > It can be done if you put the <IMG SRC=someimage.jpg Alt=your ascii art
> > goes here</a> between the <pre></pre> tags. I've seen in done and it does
> > exactly what's been asked about.
>
> It works,
Really? I just tried it on Netscape 3 and it ignored all the newlines
within the ALT text, making the ASCII art look ludicrous. MS IE 3 _did_
honour the newlines, but it used a proportional font, in spite of the
enclosing <PRE>...</PRE>, so that the ASCII art (a circuit diagram, as
it happens) made no sense. Should I try other graphical browsers with
image loading turned off, or was that enough?
OK, it produced the desired effect on Lynx 2.6 and on WWW-3.0, so I
suppose it's better than nothing.
> The only problem is that in HTML
> 3.2 the IMG tag is not legal inside PRE...
That's right. Nor in HTML2.0, as Webtechs validator confirms:
| sgmls: SGML error at -, line 12 at ">":
| PRE end-tag implied by IMG start-tag; not minimizable
However, thanks for the discussion. I'm not ruling out the possibility
that it might be useful on some special occasion.
--
best regards
"There are two ways to put [counters] on your page: the wrong way, and
the very wrong way. The wrong way merely doesn't work ... the very
wrong way is counter productive". http://www.cranfield.ac.uk/stats/
Alan J. Flavell
On Tue, 24 Sep 1996, Joshua Juran wrote:
> In article <Pine.HPP.3.95.96092...@hpplus09.cern.ch>,
> "Alan J. Flavell" <fla...@mail.cern.ch> wrote:
>
> > On Thu, 19 Sep 1996, Klaus Johannes Rusch wrote:
> >
> > > No, the alt attribute takes PCDATA only, no tags allowed.
> >
> > right
>
> You surely mean CDATA, don't you?
Oh horrors, I said "right" to "no tags allowed", and accidently
said "right" to the wrong content model.
I'm embarassed. Readers should refer frequently to RFC1866 and
in the event of discrepancies, then obviously I'm wrong.
> > This isn't feasible in practice, for many different reasons. Think it
> > through.
>
> Ah, the proxy problem.
Not only the proxy problem. When requesting the initial document,
some browsers that _don't_ display inline images _do_ include explicit
image/gif (they can, after all, use a helper app to display an image/gif
URL); some browsers that _do_ display inline images (Opera for example)
_don't_ send explicit image/gif.
What they send in the accept-headers when they request an in-line
IMG isn't relevant here: AFAIK all browsers that request in-lines can
display GIFs, no matter what their headers say (maybe */*), whereas
those that don't display in-line imgs will never ask for anything, and
by then it's too late to change the HTML. And there is _no_ indication
of a graphics capable browser that happens to have image loading
turned off, and should be sent the ASCII equivalent instead.
So, not, it wasn't only caching. Although caching _is_ an issue too.