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?
Nah.
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?
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.
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".
There are already technologies to detect user agents, and pull back the correctly sized images from servers. There are also image servers which resize on the fly. And there's CACHING.
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.
This is unnecessary as wireless broadband speeds will continue to double and make the size of a graphical image insignificant. Audio now is nearly trivial to send even over mediocre wireless connections. It will only get more trivial.
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.
How about making autoplay of videos an opt-in type of thing?
How about stopping all the damn links/like/whatever for social network sites?
And even Amazon, WTF? I do a search and their site just locks up. And I watch the status bar and it's hitting all these other sites for shit....
This image thing is being penny wise and pound foolish. Images are not the problem. All the other shit that every website has to bring in is causing the loading latency.
I mean really, adblock is great for the only reason that it speeds up page loading because advertising servers are shit.
In other words, images aren't the problem. It's the sites feeding into your site.
We have an S.C.A. ongoing. Suspect is swift, slimy, sticky, brown or chrome and spreading like cheap money.
[1] Super Cookie Alert
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.
JQuery Mobile.
Works fine.
All you have to do is have the client substitute its window x and y size values into that request.
Good luck doing that if the browser has JavaScript turned off. A lot of Slashdot users, for instance, leave JavaScript turned off for the majority of web sites out of privacy paranoia, out of a fear of non-free software, or to reduce the amount of CPU time and memory the browser spends processing social recommendation and advertisement widgets.
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.
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.
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?
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.
Using any webserver other than IIS will make it download the super-ultra-hires version everytime, proving IIS is the fatest web server.
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.
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.
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.
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.
What you're suggesting adds more moving parts complexity + room for breakdown & wastes resources. Hosts do what's needed already.
Hosts IS efficient (more than a local dns server is by far, per what I just stated above) WHEN COMBINED with what I put out below, especially...
APK
P.S.=> Especially via APK Hosts File Engine 9.0++ 32/64-bit -> http://start64.com/index.php?o... combined with OpenDNS as an EXTERNAL dns system that's DNSSEC secured between it & its upstream updaters AND patched vs. the Kaminsky redirect security flaw (which 99.999% of ISP DNS' aren't)... apk
Cut the DNS local clientside cache service: It's THAT simple saving resources it's using too (cpu, ram, other forms of I/O) & making up for its indexing is EASY TOO, especially via this program I wrote for that -> APK Hosts File Engine 9.0++ 32/64-bit http://start64.com/index.php?o...
* It has a "speedup favorite sites" tab that takes your FAVORITE websites & places them in hosts, hardcoded, which is FASTER than remote dns lookups (& lightens loads on DNS servers too, bonus), keeps you secure/anonymized by keeping you off dns request logs too... for instance, I keep 24 that way @ the TOP of my custom hosts file (rest are 3,121,350++ blocked adbanner servers or known bad sites/servers etc.) - that equates to 2-3++ MILLION index searches (do the math).
That's MORE THAN ADEQUATE to get you speed that's BETTER than REMOTE DNS by far, since the majority of what's in a "huge hosts file" like mine, are blocked since they're bad (who CARES 'how fast' I "get to those" since I never intended to in the 1st place since they're known bad & blocked).
Windows 8 needs to have its "Windows Defender" disabled too (MS screwed the pooch on hosts with it) for hosts to work right with it, in addition to dnscache being cut also (Windows 8 sux though anyhow, lol).
APK
P.S.=> You CAN "get the best of both worlds" with hosts, especially in combination with remote DNS (OpenDNS especially - they're DNSSEC secured between themselves & upstream updaters they use AND they're patched vs. the Kaminsky redirect poisoning security flaw (99.999% of ISP dns', aren't...))
... apk
Because you couldn't do this without yet another tag, right? Oh yeah.. I guess you could have done it with IMG.. oh well.
Just use SVG for every image!
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>
What shit-show of a place do you work at? Just want to make sure not to get tangled up with that company.