Re: HTML 3.2: PRE should not exclude IMG

On Fri, 31 May 1996, Abigail wrote:

> Gerald Oskoboiny wrote:
> > 
> > I guess that would be "undefined", but, if you have:
> > 
> >   <pre>
> >   a b <img src = "foo.gif" alt = "xxx"> d
> >   1 2 <img src = "bar.gif" alt = "yyy"> 4
> >   </pre>
> > 
> > and "foo.gif" is exactly as wide as "bar.gif", the behavior is well-defined,
> > and extremely useful. (as in, for instance, <URL:http://sunsite.unc.edu/>.)
> 
> 
> I remember replying to this argument... but perhaps it got lost
> somewhere. I don't think this behaviour is well defined because
> it's just an exception. In general, images are not the same size.
> And if you allow <img> just because it can happen they are the same
> size, what's the point of excluding <font>, <sub>, <sup>, <small>,
> <big>? Just like in your example,
> <pre>
> a b <big>c</big> d
> 1 2 <big>3</big> 4
> </pre>
> will work. Similar examples can be made with <small>, <sub>, etc.

Sure. There does not appear to be any real reason to exclude font markup.
As long as the 'monospaced font' rule is observed for every size I
see no harm in allowing the page author to say 'bigger' and 'smaller'.

Also the 'exception' you claim here is one that has precisely defined
behaviour in all the browsers I know of and your objection that 'in
general images are not the same size' is irrelevant because page designers
who are exploiting this behavior don't have images that 'just happen' to
be the exact same size: They done it on purpose.

The whole issue is rapidly becoming irrelevant anyway since the use of
images in PRE is a hack to work around the lack of deployed tables - a
situation that has all but disappeared now as even AOL is rolling out a
table capable browser - leaving Lynx as the only browser with any
significant share that _cannot_ do tables. Tables are *much* superior
in achieving page layout control in general.

I use <PRE> now only to achieve vertical whitespace and for large tables.
Some popular browsers are absolute memory hogs for large tables - I have
had a browser with 16 Meg of memory allocated simply run out of memory
rendering a table that took less than 100K to build. Not anything
sophisticated - just a table with 5 colmuns and several thousand rows
containing tabular text. 

Basically - at this point a browser that *doesn't* support tables is going
to have to take its chances. I make some effort to make tabled stuff
readable in a non-tabled browser. But if I cannot achieve the effect I
want without doing something that will freak out the display in a
non-tabled browser: Oh well. Thats life. 


> I really like to know if there's more reasoning behind the allowing
> the <img> tag inside <pre> except that "it can happen it will work".
> And if not, why will the font changing markup be excluded?

It doesn't really matter anymore anyway. The WG dragged its feet on this
so long on this one so long that any change would be irrelevant anyway. It
was a real issue while table supporting browsers were not nearly
universally used. Dan's 'Graceful Transition' paper was utterly useless
in the real world as it pre-supposed deployment of effective content
negotiaion (something that ironically still hasn't happened - table
deployment was completed well before content negotiation deployment). 

Which reminds me, I need to hack the Apache content negotiation module
into something useful. The current implementation is useless for real
world use because it fails to leave control of ambiguous cases in the
control of the document author. Thus if I have a PNG, a JPG and a GIF
available in decreasing order of quality, but the browser requests only
'*/*' or 'image/*' - they get the PNG dumped on them. But as a document
author I would prefer to send them the GIF in the case where I have no
idea what they accept because while of the lowest quality - it is the most
universal readable format while PNG is the least likely to actually be
viewable under those circumstances. Highest quality almost always
corresponds to the least likely to be viewable by random person X and so
should not be the default for cases where no information is known about
the viewer's capabilities.

-- 
Benjamin Franz

Received on Friday, 31 May 1996 10:55:26 UTC