Slashdot Mirror
New HTML Picture Element To Make Future Web Faster
nerdyalien writes: At some point, haven't all web developers spent an unjustifiable number of hours trying to optimize a desktop site for mobile devices? Responsive web design provides a solution: "develop once, works in every device." However, still it downloads multi-MB images and re-sizes them based on device screen resolution. Retrieving optimized images from the server, based on device (desktop, tablet, phone) and the device's internet connection (fiber, broadband, mobile), has always been an open problem. Recently, a number of freelance developers are tackling this with a new HTML element, <picture>, which informs the web browser to download optimized images from the server. The tag will be featured in Chrome and Firefox later this year. Will this finally deliver us faster web browsing on mobile devices and an easier web development experience?
does this mean that resizing the browser window will cause it to re-download images? because that sounds annoying.
of the HTML 5.1 story?
This really isn't anything special if you think about it for a second. It's just a lazy way of creating a request handler with a limited scope.
Keep in mind that an <img src="filename"> doesn't require the filename to end in .jpg, .gif, or any other particular format-associated extension. Hell, it doesn't even require a particular MIME type (or one of a group of valid ones) when it gets a response from that source URL as long as the client is happy with it.
Over in ASP.Net land, we've been using src="/imageHandler.axd?name=blah&w=foo&h=bar" in img tags for years. You could certainly do the same thing from any server-side language. All you have to do is have the client substitute its window x and y size values into that request. The server can either serve up the closest appropriate size, or dynamically generate and cache one of the correct size on the fly.
All this new tag is going to do is allow those without the ability to write such a server-side script (read: crayon jockeys) to set up a list of pre-baked images for a set of screen size ranges. It will add to page text bloat and provide little actual utility, since they'll only test on Macs and iPhones anyway. This will reduce this entire feature to nothing more than a waste of time.
Think about just how much work is now needed to display a simple GUI on a number of different devices. Something that a single developer could once have cooked up themselves now takes teams of designers, UX people, UI coders, back end coders and the rest to do. Really, we should chuck it all out and just start again.
my blog of work misery - http://beastofbaystreet.com
I'm not sure how this fixes the problem.
You either need a client side (the browser decides what image to fetch and how to display it) or a server side (the server decides what image to send) solution here. I suppose you could do a combination of both, but the problem here is who's going to get the resizing work?
Personally, I think this would be better done on the server side for the most part. That implies that the GET would somehow define for the server enough information about the display available. You are going to need colors supported, user pointer integration (type, minimum size), screen resolution of the user's view both in pixels and actual size. Then the server can decide what page format and image would best fit. All this has to be *independent* of the browser vendor or host platform.
But hey, good luck getting everybody to sign on to a working interface for this... We cannot get a consistent interface between browser vendors now...
"File to fit, pound to insert, paint to match" - Aircraft Maintenance 101
" Responsive web design provides a solution: "develop once, works in every device."
Name one good responsive web design that isn't shit on at least one of desktop or mobile. (And an awful lot of them are shit on both.)
Anything actually good just builds them separately, and lets you switch between them; and selects as default the right one based on screen size (screen not window) Nothing sucks worse than making a desktop window smaller because you just want to keep one part visible while you work with something else and having the site spontaneously implode into a mobile version -- just one of the countless forms of SUCK thanks to "responsive web design".
Back in the days of HTML, they decided that it was awful that the people using dial-up had to wait so long for images to load ... so they came up with the 'lowsrc' attribute to the IMG element:
<img lowsrc='...' src='...' ...>
Or, you could could go with the 2000s route, and use CSS's media queries so that you don't try to push large images down to small-screen devices.
Wouldn't it make more sense to just use a known attribute or method rather than trying to come up with yet another solution every few years?
Build it, and they will come^Hplain.
For this solution to work, not only do you need to implement a new HTML element and get the servers and browsers to support it, people uploading photos (or their servers) need to generate and store multiple size versions of the same pic.
Kodak pretty much solved this problem in the 1990s with their ill-fated Photo CD format. JPEG encodes pictures in sequential 8x8 pixel blocks. So once you set the image size and encoding quality (which determines files size), everything from that point on is committed to those settings. By contrast, Photo CD encoded a low-res Base version of the picture (512x768). A double-resolution version (1024x1536) called 4 Base is then created by doubling the size of the base and storing the (compressed) delta from that and the resized original photo. The process is repeated for 16 Base (2048x3072).
Essentially, whereas JPEG stores the picture in sequential translated blocks, Photo CD stores the picture in zoomed blocks - kinda like a fractal. If you want the low-res Base version of the picture, you only have to read the first part of the image file. If you want the med-res 4 Base version, you read further along the image file. If you want the high-res 16 Base version, you read the entire image file. (Speaking of which, there was a fractal-based compression algorithm. But the licensing fees were so onerous it never went anywhere.)
Despite Kodak's eventual demise, they were at the forefront of digital imaging (why they held on as long as they did - they owned most of the digital photography patents). And their engineers put a lot of time and thought into the Photo CD format and future-proofing it.
Let's see how Internet Explorer can manage to munge THIS tag up.
Progressive JPEG already does most of that. It breaks up the DCT coefficients into multiple "scans", each of which adds more detail to the image. A slowly loading progressive JPEG starts blurry (suitable for small displays) but fills in with the higher spatial frequencies as it is received. Perhaps what progressive JPEG needs in order to become a best practice for responsive images is a header to tell how big each scan is (in spatial frequency and in bytes) so that the browser can use range requests rather than having to close and reopen a connection once it's seen enough data for a particular pixel density.
Retrieving optimized images from the server, based on device (desktop, tablet, phone) and the device's internet connection (fiber, broadband, mobile), has always been an open problem.
Nope. It was already solved by the JPEG's hierarchical mode, more than twenty years ago. You're limited to scaled sizes that are the inverse of a power of 2 of the full size, but on the other hand the client wouldn't even need to inform the server and just proceed with a partial download, up to the point where it has enough data for the desired resolution.
I have discovered a truly marvelous proof of killer sig, which this margin is too narrow to contain.
Or the graphics designer could just optimize the graphics so that they are the smallest possible size in the first place. Then they are the fastest for everyone. Designers, like programmers, are usually used to having the fastest computers and connections so they forget about people with slower computers and connections.
Actually, it's unnecessary because everything picture does could have been added to img instead. There's no semantic difference between the two, so why add a new one? Extending img would have been more backwards compatible as well (one of WHATWG's stated goals, despite doing lots of stupid crap like this).
Nothing sucks worse than making a desktop window smaller because you just want to keep one part visible while you work with something else and having the site spontaneously implode into a mobile version
On which public web site have you seen this happen, so that I can go see for myself what you're talking about?
It seems to me that there is a far easier and more effective way to solve this problem.
This Solution: Have a list of different resolution images for display, have the browser device which one to pick.
Better Solution: Have an image format based on streaming. As the data is steamed in the resolution increases. Based on my experience with slow internet we already have a format very like this (starts out fussy, but complete, gets more details as the picture finishes loading). The browser just stops the stream when it has an image of the appropriate size. You do not need to have 18 different copies of the same picture lying around and, you do not need to expressly code in every circumstance. The HTML code we already have and have been using for a long time is already capable and it is forward and backwards compatible. Visit a page with your computer hooked up to some some of a kind 40K monitor no problem as long as the original image is of a high quality, visit with a 640X* smartphone screen, no problem. The site designer doe snot have to know every use case, let the browser worry about that.
Troll is not a replacement for I disagree.
I don't think you need JavaScript to accomplish what he said. I vaguely remember something similar being done on a recent project using Wicket and Java.
I run AdBlock like most /.ers, but it doesn't get the chance to do much because I have ~132,000 hostnames mapped to 0.0.0.0 in my hosts file specifically for this reason (in Linux and Win2k anyway... Vista/7/8 can only handle about 3000). Anyone who watches me surf is amazed at how the Internet looks without ads.
In practice, wireless speeds increasing just means you'll burn through your 5 GB per month cap twice as fast.
Actually, it's unnecessary because everything picture does could have been added to img instead. There's no semantic difference between the two, so why add a new one?
The semantic difference, as I understand it, is that the picture element means "images behind all these URIs are semantically equivalent, and here is a formula to determine which is preferred in a particular environment."
Progressive JPEG is almost a solution but still has a practical problem. Some HTTP servers don't support range requests for some reason, such as if the server's administrator has in the past seen abuse of range requests by "download managers" to try to download six ranges simultaneously. Besides, even on a server that supports range requests, the browser doesn't know in advance how many bytes to download for a particular spatial frequency to be filled in. This means a web browser can't just request enough data for a particular size. Instead, it has to wait until it has seen enough data and then close and reopen the HTTP connection and endure another TLS handshake and another TCP slow start before it can download more things.
Everything in the cookies, headers and your filesystem is available to you to make your decisions
Cookies don't exist for a first time visitor. And since when have HTTP request headers included window size and pixel density?
What with desktop screen become wider and wider over the past ten years, what with mobile screens being and staying portrait troughout, what with rationalizations given for each of these trends, these rationalizations being apparently highly selective of their own conclusions -- anybody please, tell me where the rationale is in keeping, in wanting to keep, in wanting to program consciously, to remain within the sapproriate standards, to keep ergnomics in mind, to... well, believe anything that has ever been brought up to justify 'the industry's' decisions in manufacture and marketing?
If you want to regain support for big honkin' APK hosts files on Windows, you could try writing your own DNS server that runs on localhost and enforces your hosts file before passing other queries off to 8.8.4.4 and 8.8.8.8. I've written a few notes on efficient hosts file processing.
The smallest possible size in bytes for a photo in a 100x100 pixel viewport isn't the same as the smallest possible size in bytes for the same photo in an 800x800 pixel viewport, unless you want unacceptable blurring on the larger viewport.
Or, it could can just be ignored it from day one, like I did. All my pages still work fine. I never lost sight of the idea that the content was key, and that the interior-designer fascination with "GUI design" was so much ridiculous overkill.
o Does the page work, and quickly? Yes? Fine.
o Is the writing high quality and cover the subject at hand thoroughly? Yes? Perfect.
o Is it image heavy? Probably want to rethink it, because you're probably just producing pablum for the tl;dr masses.
o Does it need input? Server-side CGI then.
HTML, CSS and CGI can easily and consistently handle 99.99% of everything. And you probably don't really need that last .01%
And guess what? Your pages can work on everything that is even somewhat modern.
I'll grant you that the bloody browser makers could do a better job with consistent support of CSS, but other than that one wart, it's all a doddle. IF you know what you're doing.
I agree that images for the foreground page should be prioritized. But not loading images for background tabs at all would break offline use. Consider someone who loads up on web pages to read on a laptop before boarding a bus: load tabs in the background, close the lid to put it in suspend, board the bus, open the lid, and then view the pages.
Most big, professional websites already look fine. They're responsible, and update, and everything.
But there are a lot of crappy sites I'd still like to able to visit. They won't be using the new tag.
So? Do you really think they'll drop the IMG tag in our lifetime?
Write boring code, not shiny code!
Sending a separate request for each 10,000 byte chunk of the picture will increase latency, as the browser has to look at each downloaded chunk and decode it to see whether it should send another request. It'll also burn through more of the user's data plan as the request headers and response headers are resent for each chunk. How should the browser estimate how big the chunk should be for a given pixel count?
Images themselves have no semantic value
I detect definition disagreement, and this thread can't usefully continue until we clear this up. I'm unfamiliar with the definition of "semantic value" that you're using. Is it from a standard? If so, which?
You wouldn't invent a redundant element for audio files
Except they did just that. The audio element allows specifying multiple otherwise equivalent sources, each in a source element, so that the browser can choose the most technically appropriate one. This allows letting the browser choose, say, an MPEG-family format if it's an Apple or Microsoft browser or a royalty-free format if it's a third-party browser.
A progressive resolution image format wouldn't help art directors show the image with a tighter crop on devices with lower pixel density.
Ouch. That transition from 2 columns to 1 is so close to 1024px it sickens me. Even a browser window snapped to half of a 1920x1080 screen, or a user of a 1024x600px netbook whose scroll bars are set just wider than normal, would get the 1-column layout with a hamburger menu on the front page of NCSA's web site.
Yeah, I see the problems you point out with Mashable's front page in Firefox at 500-1024px, and I agree with you that Mashable is doing it wrong. But those are fixable problems if only Mashable management had the sense to correct the design. You're not claiming that the very opportunity to do width transitions wrong justifies removing the media queries feature entirely, are you?
Anyway, badly done viewport width transitions are consistent with other problems I see on Mashable, such as that damn "infinite scrolling". I think infinite scrolling is a crock of $#!+ on desktop; the scrollbar control just wasn't designed for it. Give me defined pages any day of the week. Literally. Just give me a page for each date so that I can link to the collection of stories that the site ran on a particular day (or week or month for a less busy site).
they want their "we'll be the first to have this tag in our browser" back. Shouldn't all browser have the tag at the same time to save people headaches?
by TheSpoom (715771) Uncaring Linux user here. I have nothing to add to this but please continue. *munches popcorn*
http://www.fathead.com/ is pretty good. http://www.internetretailer.co...
You set up a background image for elements in CSS, with the appropriate media queries. What do we need another new tag for? If you are building responsive sites, you should be managing it in CSS anyway. Embedding CSS type media queries into a document tag is about the same as including embedded styles instead of classes. It makes for ugly and redundant HTML (okay, HTML itself is redundant, but stating that would be redundant... er...).
That, and "hover" menus and windows are the #1 reason why I surf away from web pages.
Tip to "designers": If I didn't CLICK on it, I didn't WANT it, and that means ITS IN MY FUCKING WAY
Perhaps the difference comes from limits in CSS. A menu that opens on mouseover works with CSS turned on and JavaScript turned off; a menu that opens on click requires JavaScript.
Because you couldn't do this without yet another tag, right? Oh yeah.. I guess you could have done it with IMG.. oh well.
They're already putting 2k displays on phones.. it's just a matter of time until they put 4k displays on phones and then there's no way a browser is going to download a lower resolution image for the device. The screen is 4k so just download the big picture....
Never mind that you can't see the difference unless you're extremely nearsighted and don't have your glasses on.
Low res is the new "thin".
Where one can specify a X1Y1+WIDTHHEIGHT region of the image and that, not the full image, becomes what is actually rendered or stretched by the element.
And if either the X and/or Y have a MINUS sign, then the same absolute coordinates are used -- but also the presence of the sign causes the browser to FLIP the image horizontally, vertically or both. This deals with the case of mirror elements.
Modern web pages are full of small design elements such as bits of custom corners, tiles that are stretched horizontally and vertically and small recurring icons and pieces that are common to many pages. There can be dozens of these unique elements all told.
Wouldn't it be nice if only ONE image that has been carefully crafted to contain these rectangular regions, is loaded to the client, thus keeping all these bits and pieces from spamming the world's server logs and keepalive sessions?
Yes one can do something like this active scripting and with layers and canvas, but putting clip'n'flip into a newly designed PICTURE tag would achieve what I've been suggesting since... 1995. It would give me personal closure. It would make me feel needed.
<blink>down the rabbit hole</blink>