IMG SRC and FULLSRC

[skitch]

If an IMG tag had an optional attribute, FULLSRC, filled with the URL of a larger/higher-res version of the same image, the browser could do interesting things with it and it could improve accessibility. Further, applications like http://piclens.com could do a lot with it.

To be totally clear, an IMG tag would have the following attributes:
- SRC (required): URI of the image object to display in the page
- FULLSRC (optional): URI of (likely the same but higher-res) image object to NOT display in the page by default; the browser is free to do with it what it likes (slideshow, show high res version on hover, etc.)

[anne]

Netscape 4 or so supported the lowsrc="" attribute. There src="" would be for the hires image and lowsrc="" for the smaller image using less bandwidth. This wasn't really a success. Why would fullsrc="" be a success?

[skitch]

I agree that lowsrc was a fallure. I don't think any features that help a page degrade gracefully in lesser environments have really caught on, except maybe <noscript> and usually that is just a go-away message.

FULLSRC is a totally different kind of attribute; it doesn't change the rendering of the page in any way, and it's not intended to make low-bandwidth/power situations better. It's there for features in browsers to take advantage of in new ways if they like. piclens.com is one such possibility, but I'm sure every browser vendor would love to offer some sort of enhanced image viewing capacity.

[zcorpan]

I think there are two ways to solve this problem today.

1) <img src="foo-800x600.jpg" width="400" height="300">

2) <img src="foo.svg">

[Le Sage]

Solution 1) will result as a long downloading type + bad closest-neighbour (or at most linear) interpolation on most current browsers (I'd say only FF 3 & Opera 9 don't do closets-neighbour, & IE7 if you specify it in the CSS something like:

Code: Select all

img {
  -ms-interpolation-mode : bicubic;
}

).
Solution 2) doesn't work for pictures (e.g. JPEG) or images you're not the author of (i.e. high resolution images (e.g. JPEG or PNG) grabbed on the web, e.g. from Google images).

[anne]

Solution 1) will result as a long downloading type + bad closest-neighbour (or at most linear) interpolation on most current browsers

In comparison, all current browsers don't do fullsrc.

[zcorpan]

Solution 1) will result as a long downloading type

Hmm, I recall some attribute called lowsrc=''?

+ bad closest-neighbour (or at most linear) interpolation on most current browsers

Scaled down to 50% looks good even with closest-neighbour interpolation.

Solution 2) doesn't work for pictures (e.g. JPEG) or images you're not the author of (i.e. high resolution images (e.g. JPEG or PNG) grabbed on the web, e.g. from Google images).

Right. Solution 1 works for these cases though.

[Le Sage]

@ anne & zcorpan: I didn't say I was supporting lowsrc (nor fullsrc). I was just pointing out that there were some problems in zcorpan's Solution 1) & 2).

Scaled down to 50% looks good even with closest-neighbour interpolation.

hum... Maybe to you. Maybe to most Internet users. But I can personally tell if a 80x80 picture is in a <img style="width: 79px; height: 79px" ... /> element. (I think, don't have an exemple close although).
ADD: try
<img style="width: 800px; height: 600px;" alt="" src="http://download.qj.net/uploads/files_module/screenshots/253_PSP-background-thor64.jpg" />, do you notice something around the lines? (not the best example ever, though)
I guess the difference of lowsrc & fullsrc usage would be (although I'm not in skitch's mind):

original:
<img style="width: 320px; height: 240px;" src="320x240.png" ... />
with lowsrc:
<img style="width: 320px; height: 240px;" src="320x240.png" lowsrc="80x60.png" ... />
let's say 320x240.png's weight is x KB; 80x60.png's weight could be approximately 16 times less (I'm writing PNG, but we could also use JPEG). So we end up in having a downloading time of 106% the original one (again approximately, as you have to download 2 different files, treat 2 files, ...). The browser would first display 80x60.png, & then 320x240. Mobile user agents that want to minimize the downloading data could ignore lowsrc attribute, or even hardcorly only use lowsrc where available. Though today, usage of progressive JPEGs or interlacing ADAM7 PNG makes me personally think that lowsrc is not necessary for computer browsers.



original case:
<img style="width: 320px; height: 240px;" src="1280x960.png" ... />
with fullsrc:
<img style="width: 320px; height: 240px;" src="320x240.png" fullsrc="1280x960.png" ... />
Here, the size of 1280x960 is roughly 16 times the size of 320x240 (which is obviously not exactly true for PNG nor JPEG files because of each one compression algorithm). In this case, you don't multiply your downloading time by 16 (friendly for mobile user agents as cellphones), you don't have closest neighbor horrible interpolation, the user agent can allow to download the fullsrc image on onmouseover for example.
I guess I could make a real test case, but sorry I don't really have time. If you find it necessary though, please tell me, & I'll try to do all I can.
Also, fullsrc could replace the usage of poping the full resolution image opening a new custom window in JavaScript, or using a (widely spread) script call ThickBox.

Thanks for reading!

[zcorpan]

@ anne & zcorpan: I didn't say I was supporting lowsrc (nor fullsrc). I was just pointing out that there were some problems in zcorpan's Solution 1) & 2).

The proposal in this thread suffers from the same problems as solution 1.

Scaled down to 50% looks good even with closest-neighbour interpolation.

hum... Maybe to you. Maybe to most Internet users. But I can personally tell if a 80x80 picture is in a <img style="width: 79px; height: 79px" ... /> element.

I said 50% and meant 50% specifically -- not 98.75%.

<img style="width: 320px; height: 240px;" src="320x240.png" ... />
with lowsrc:
<img style="width: 320px; height: 240px;" src="320x240.png" lowsrc="80x60.png" ... />

I had something like this in mind:

Code: Select all

<img width=320 height=240 src=640x480.png lowsrc=320x240.png>

Mobile user agents that want to minimize the downloading data could ignore lowsrc attribute, or even hardcorly only use lowsrc where available.

lowsrc is so rarely used that it's pretty useless to anyone to support. If a mobile user agent wants to minimize the downloading data then it is way more effective to preprocess the data in a proxy and send compressed data to the mobile.

Though today, usage of progressive JPEGs or interlacing ADAM7 PNG makes me personally think that lowsrc is not necessary for computer browsers.

Right.

[Le Sage]

Code: Select all

<img style="width: 118px; height: 74px;" alt="" src="http://blog.neovov.com/images/2007-03/w3c.gif" />

(real picture: 236x147, displayed at 50%)
don't you find it really ugly? I do.
bonus:

left: Firefox 2; right: cubic downscaling with Gimp

The proposal in this thread suffers from the same problems as solution 1.

I don't agree, & I thought my long answer was self explanatory (apparently not). Let's say you want to display 320x240, & if the user wants extra quality, 640x320 (triggered on some user action like right click on the image + "show full resolution" or rollover the image + wait a few seconds).
fullsrc: 320x240 downloaded (quick), & if necessary 640x320, no aliasing due to crappy image reduction
solution 1): 640x320 downloaded (more data, longer to display if not progressive image (I'd say that not so many images on the web are optimized this way)), crappy downscaling, but at the end you've downloaded less if you want to show full resolution
Personally, I think this thread's idea is good, if the browsers had "thickbox"-like behavior built-in (or some full resolution displayed on roll-over after a delay of a few seconds), I would use this feature on my pages.

[zcorpan]

left: Firefox 2; right: cubic downscaling with Gimp

Fair enough.

[skitch]

Le Sage has the right idea. Mobile is not really the use case here; extended browser functionality is. Scripts that currently lightbox a full-size image could be made simpler. Browser extensions that display media in interesting ways would benefit.

[urbanjost]

Although not perfect, I find I have sufficient control of pixmap sizes
by using a mix of JavaScript/ECMAScript and HTML already. The
examples at

http://home.comcast.net/~urbanjost/resize/resize.html

work in iexplore(1), opera(1), safari(1), and firefox(1). It's not perfect
(as mentioned, the browsers do not have many options for controlling
resizing artifacts).

If you weren't familar with that, I'm glad I shared :>. Otherwise, I'm
missing something. Why duplicate the functionality?
Is it that JavaScript has to be supported and
active? Other elements depend on JavaScript to process events and so on
(<CANVAS> elements, for example) once you go past the basics, too.

I tried to make an example for each feature request as I understood them.
You can view a high-res image at other resolutions, you can make a click go get another higher-res. image (or an unrelated image). ..

And I think the page at

http://www.netzgesta.de/lab

which goes way beyond the basics shows what a combination of images and HTML5 can do. I used their scripts and an IFRAME to make a photo
album viewer that I like better than a commercial one I have in
a few hours. That page convinced me anything I wanted to do with static
images was probably possible.

[Le Sage]

example of usage of what I suggest (here done in JavaScript):
http://java.sun.com/javafx/

[zcorpan]

example of usage of what I suggest (here done in JavaScript):
http://java.sun.com/javafx/

So how do you suggest that browsers implement this? Where should the large image be shown? What if the author wants it to appear somewhere else? How does the author specify that there should be a semitransparent border on the large image, like on that page? What if you want text along with the large image? And so forth.

It seems to me that this is an area where authors want to innovate (with e.g. javascript and CSS), not browsers. No?