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?
of the HTML 5.1 story?
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
" 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.
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.
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.
There are several, but site I was referring to in particular was mashable.com. It came up at work as an example of "good responsive design" to which I argued that it was in fact abysmal.
These were some of my notes taken at the time (I don't know if they all still apply, but a click glance confirms at least most of them still do)
Chunks of the site can't be reached from mobile at all - how do I get to "Jobs" or "Advertising" from a smartphone?
And on the desktop, parts of the site can't be reached depending on the size of the browser window and we're not talking perversely small either: that "more" popup menu on the desktop starts losing sections outright at around 1100px). 1100px is too narrow! Want a job at mashable? They don't have a section for that unless your on a widescreen.
Worse, if you shrink the page below 1000px wide, you start losing content columns off the home page too -- they're just gone. You can't scroll horizontally to get to them, and unlike the mobile version which displays one column at a time with a column selector to switch, that selector doesn't appear on the desktop. If you shrink your window, you just lose columns. No selector, no scrolling, the content is just gone.
Additionally the column selector names are different from the desktop column headers... "What's new" is renamed "New" for space and that's fine as the translation is preserved. But "The Next Big Thing" is renamed "Rising" for space -- that's a navigation cue that got lost in translation. If I were to say, 'Look for the article under "The Next Big Thing", ' nobody is going to make that connection.
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.
I think I may have misunderstood but how the hell does a browser load images before loading the html that tells it what images to load?
-73, de n1ywb
www.n1ywb.com
HTML isn't just one file any more. It's often supplimented by CSS, rewritten on the fly by javascript that pulls additional content from new URLs, and quite dynamic in general. It's quite possible for a browser to start downloading images before it has the HTML fully rendered.
Sounds like a perfect use case of HTTP headers. Why would a new HTTP method be required?
Get the headers? Great! Use them. Don't recognize them? Oh well, ignore them. Don't get them? Use sane defaults.
For large sets, this will be our guide even unto death, for the LORD will work for each type of data it is applied to...
You can't scale it on the client side, because one of the core reasons for doing this is to NOT download large images for areas were a mobile connectivity is a factor. So you can't scale it down unless you've already downloaded the large version. This wouldn't work.
You have to ONLY download the correct size you need.
This could be done manually with tags, which seems to be the chosen route. However I think what "bobbied" suggested above would be a good automated way of doing it. Say you set up a meta tag using the media queries in the HTML to be "mobile conscious". Then anytime it ran across an , the browser would request images as such: "GET image.jpg?max-width=18em" (or however else the developer defined the meta tags). The web server (which would also need to be aware of this type of request), would then return back a certain sized image. This would require the least amount of effort by the developers and would just need support by the browsers and web servers.
If only browsers were smart enough not to play audio in background tabs.
I've fallen off your lawn, and I can't get up.
also, browsers can resize. It's not the server's job
It's the server's job if the user doesn't want to have to download an ultra-high-resolution image over a metered connection. It also used to be the server's job back when web browsers insisted on using nearest neighbor resampling instead of bilinear or bicubic resampling.
We don't have a bandwidth shortage.
You appear not to know what it's like to be stuck on the 10 GB per month cap of wireless (satellite or cellular) home Internet access.
If you know it's a mac or a PC, you know it's got a desktop range of pixels.
But is that 1024 pixels wide with huge distracting white areas on both sides when viewed on a 2560 pixel monitor, or is it 2560 pixels wide with complete inability to see the entire image at once on a 1024 pixel monitor like the one in my laptop?
Likewise any particular smartphone.
A tablet held in landscape orientation runs the same operating system as a smartphone held in portrait orientation, despite the latter having only about one-third the horizontal width.
Don't resize images with the viewport. That's very annoying. They should reflow with the window according to the browser's settings. If you set a constant width, then you're asking for scroll bars if the window can't fit that width.
So what should a designer who doesn't want horizontal scrollbars do?
HTML was intended as the content provider; the browser intended to be the content formatter
And CSS (Cascading Style Sheets) was supposed to be the instructions that the content formatter follows.
using only hints -- lines, paragraphs, font styling, etc. The closer you can get to that in web page design
I imagine that as of 2014, most people would not prefer that most web pages look like Barry T. Smith's MFing Web Site. They would consider the default styling that a browser applies to the MFing Web Site to be unprofessional.
Every time some whackjob decides that menus should drop or windows should open when my mouse pointer crosses some object, I curse.
How would you prefer that a menu be opened while JavaScript is turned off? To the best of my knowledge, CSS supports only hover-to-show, not click-to-show.
Every time I run into some page (like liveaquaria.com's) that won't run its cart or checkout through the usual standard ports and protocols
Could you describe what nonstandard "ports and protocols" liveaquaria.com uses? I tried to buy a coral to test what you describe, but it required me to create a username and password before I could check out. Is the need to register before checking out part of the problem you describe? I do know that some manufacturers, such as Games Workshop, have a policy of forbidding online stores from selling their products through a standard shopping cart.