Re: Suppress scroll bars - an idea

Mike Batchelor said:
 
> Walter Ian Kaye once wrote...
> > You could choose an arbitrary page size, but that would be making many
> > assumptions. At least be sure no graphic is wider than 470 pixels, because
> > that is the standard imaging area width for Netscape and Mosaic browsers
> > when used on screens 640 pixels wide. Anyone with a 512-pixel wide screen
> > or smaller would get the wrong size, although they're probably used to it
> > already. ;)

You should either apply your "no bigger than" argument rigorously - and I bet 
someone could find a platform somewhere with a narrower screen width than 
512 pixels - or apply your "probably used to it" argument to 640 pixels...

Arguing from pixels is a poor choice in any case. Even sticking with computer 
screens there is a wide variation from 60 to 100 or more pixels per inch. Other 
devices such as dye sub printers have higher densities, and your 470 pixel image 
is going to look pretty tiny at 300dpi.

> Or, the browser could scale down images to fit the page it has to work
> with.  This is probably a good idea regardless of whether you scroll or
> page through the document.

That is certainly an option, but should be under user control - the document 
author should indicate that a particular image is to be scaled to full screen 
width, or height. Depending on the aspect ratio of the graphic and the browser, 
either width or height might be the limiting factor.

> Inline images are described as non-essential
> decoration, 

Where? The HTML2.0 specification makes no such value judgement.
  http://www.w3.org/hypertext/WWW/MarkUp/html-spec/html-spec_5.html#SEC62

I suspect you are confusing this with the description of the IMG tag in 
HTML 3.0, which is somewhat different as there is also a FIG tag.

Do not make the assumption that all images are trivial decoration. That 
may be true in some cases - many cases, even - but is not universal. It 
is dangerous to suggest that browsers can play fast and loose with image 
data without warning.

> and the style guides I have read suggest using a link to a
> full-size image if the graphics are really essential. 

That is one way to do it, and with current browsers is likely to result 
in higher image quality when there are inadequate colours. There may be 
cases however where it is required to place the graphic in association 
with text, or to have selectable hotzones on the graphic, and this it must 
be presented inline.

> Therefore I think
> it's perfectly fine for the browser to down-size an image to fit the
> screen. 

Only if the author explicitly requests this. Certainly until browsers start 
offering user preferences on image resampling. Current browsers resize by 
pixel replication which is fast and ugly. 

Other options should include bilinear interpolation, bicubic interpolation, 
and none.

> If I'm not mistaken, the HTML 3 <IMG> tag will let you give
> attributes that define a size relative to the browser page, as well as
> specifying a size in pixels.

No, both IMG and FIG  take optional WIDTH and HEIGHT attributes plus a 
UNITS attribute (pixels or ens). No relation to the browser window.

  http://www.hpl.hp.co.uk/people/dsr/html/img.html
  http://www.hpl.hp.co.uk/people/dsr/html/figures.html
  
However, HTML 3.0 is a draft spec and subject to change.

-- 
Chris Lilley, Technical Author
+-------------------------------------------------------------------+
|       Manchester and North HPC Training & Education Centre        |
+-------------------------------------------------------------------+
| Computer Graphics Unit,             Email: Chris.Lilley@mcc.ac.uk |
| Manchester Computing Centre,        Voice: +44 161 275 6045       |
| Oxford Road, Manchester, UK.          Fax: +44 161 275 6040       |
| M13 9PL                            BioMOO: ChrisL                 |
|     URI: http://info.mcc.ac.uk/CGU/staff/lilley/lilley.html       | 
+-------------------------------------------------------------------+
|     "The first W in WWW will not wait."   François Yergeau        |
+-------------------------------------------------------------------+

Received on Tuesday, 4 July 1995 06:31:36 UTC