Become a fan of Slashdot on Facebook

 


Forgot your password?
Close
typodupeerror
×
The Internet Technology

New HTML Picture Element To Make Future Web Faster 161

Posted by Soulskill from the until-it's-used-for-ads dept.
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?
This discussion has been archived. No new comments can be posted.

New HTML Picture Element To Make Future Web Faster More

New HTML Picture Element To Make Future Web Faster

Comments Filter:

  • Dupe (Score:5, Interesting)

    by Hsien-Ko ( 1090623 ) on Tuesday September 02, 2014 @02:39PM (#47810041)
    of the HTML 5.1 story [slashdot.org]?

  • GUI technology has regressed since the 90s (Score:4, Insightful)

    by thebeastofbaystreet ( 3805781 ) on Tuesday September 02, 2014 @02:48PM (#47810109)
    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.

    • Bah (Score:2)

      by Anonymous Coward

      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? S

    • Re: (Score:2)

      by znrt ( 2424692 )

      gui technology? it's the whole software industry. you need aprox the same amount of "experts" to print a fkucing report from persisted data nowadays. not to mention a herd of managers, several whiteboards and a shitload of postits.

    • Things are a bit more complicated than they used to be...

  • 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.

    • 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.

  • Responsive Web Design (Score:5, Insightful)

    by vux984 ( 928602 ) on Tuesday September 02, 2014 @02:52PM (#47810153)

    " 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".

    • 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?

      • Re:Which site "collapses"? (Score:5, Insightful)

        by vux984 ( 928602 ) on Tuesday September 02, 2014 @03:47PM (#47810677)

        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.

        • 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

          • Re: (Score:2)

            by vux984 ( 928602 )

            " But those are fixable problems if only Mashable management had the sense to correct the design."

            Yes.

            "You're not claiming that the very opportunity to do width transitions wrong justifies removing the media queries feature entirely, are you?"

            I'm claiming that proposing a responsive design using media queries as a solution to designing a site for desktop and mobile users is generally more work and harder to get right than just building two separate sites.

            To make a (flying) car analogy:

            "Responsive design" is

    • Re: (Score:2)

      by znrt ( 2424692 )

      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

      current users aren't supposed to be able to do that without extra help or risking injury. didn't you notice the window managers / desktops most of them are using? split the screen? are you nuts???

      by they way, *their* fix for your problem would be eradicating desktop design versions completely. "develop once, works in every device". why should we go through the hassle of developing a desktop version for elitists like you if we're anyway served well enough with a single tap mobile interface, which is what ou

      • Re: (Score:2)

        by vux984 ( 928602 )

        by they way, *their* fix for your problem would be eradicating desktop design versions completely.

        As bad as that is, that would actually be an improvement over the mess that "responsive web design" has made.

        At least then the design would be relatively simple, and it would be easier to maintain. The problem with responsive web designs is that they are inherently complicated and things break or go missing or become inaccessible between the mobile and desktop transitions. Maintenance cycles tend to make them w

        • Re: (Score:2)

          by znrt ( 2424692 )

          a possible mitigation is designing "mobile first" (an industry meme that actually makes sense for a change). this forces to focus on providing core functionality in limited space (i.e.: clarifying what the core functionality is in the first place), from there expand to desktop version. it's not a silver bullet but IF you want to go the "responsive" route it can help and is the way to go. ofc also in maintenance. if that extra column (whatever) doesn't fit well int the mobile version then it might be woth re

    • This one works pretty well: http://www.feedprojects.com/FE... [feedprojects.com]
      It uses gridiculous.

  • It's the 1990s all over again. (Score:5, Insightful)

    by oneiros27 ( 46144 ) on Tuesday September 02, 2014 @02:53PM (#47810171) Homepage

    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?

    • 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?

      That's the wonderful thing about standards. there are so many to choose from!

    • Re: (Score:3)

      by tepples ( 727027 )

      <img lowsrc='...' src='...' ...>

      That was never standardized, and its implementation was removed for reasons described in bug 92453 [mozilla.org].

      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.

      Do media queries allow changing the effective src of an img element, or do they work only with background images?

      • <img lowsrc='...' src='...' ...>

        That was never standardized, and its implementation was removed for reasons described in bug 92453 [mozilla.org].

        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.

        Do media queries allow changing the effective src of an img element, or do they work only with background images?

        You could combine it with the CSS 'content' property if supported, or just pretend the background is the foreground, which it tends to be unless you put something in front of it.

        Seriously. This would be better solved by going back to trying to standardize CSS 'content' that way IMG could be implemented using CSS.

        • This is not supported by Firefox because it violates the CSS spec Basically, replaced elements (img, video, iframe, etc) cannot be modified via the content property because they eliminate any ability to replace them with accessible content. For example, an image cannot be replaced by its alt text.
      • Only the background image. Media queries don't modify HTML, they modify CSS.

    • Re: (Score:2)

      by PRMan ( 959735 )
      Lowsrc didn't take high-DPI screens into account, which is what they are trying to solve with Picture.

  • Kodak had the right idea decades ago (Score:5, Interesting)

    by Solandri ( 704621 ) on Tuesday September 02, 2014 @02:56PM (#47810213)
    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 [wikipedia.org] 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.

    • There's also progressive JPEG - pretty much the same effect, you'd end up displaying a low-res/blurry version of the image first that gradually refines to a higher resolution version, building off of the earlier lower resolutions.

      • 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 d
        • Comment removed based on user account deletion

    • Re: (Score:2)

      by alexhs ( 877055 )

      AFAIK, PhotoCD uses JPEG. It's just that it's JPEG's hierarchical mode, that nobody else uses. (See my other post [slashdot.org])

    • And [Kodak's] engineers put a lot of time and thought into the Photo CD format and future-proofing it.

      And after the patent restrictions expire, this format may possibly become useful. As it is, this format is completely useless because of the patent threat.

      Software Patents: killing innovation since 1998.

    • Re: (Score:2)

      by Tablizer ( 95088 )

      Agreed. It would be easier on many levels to promote and support the browser use of a progressive-resolution image-file format rather than overhaul markup standards and load & store multiple image versions on servers.

      Let's hope sanity and logic prevail, and this tag idea is dumped.

      And I hope patent issues don't derail it also.

      Further, we don't have to have an entirely new tag. Just add something like a LOWRES or LOWRESSRC attribute to the existing IMG tag. Old browsers would still use the regular image

      • A progressive resolution image format wouldn't help art directors show the image with a tighter crop on devices with lower pixel density.

  • Let's see (Score:5, Funny)

    by Aaron H ( 2820425 ) on Tuesday September 02, 2014 @02:56PM (#47810215)
    Let's see how Internet Explorer can manage to munge THIS tag up.

  • 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.

    • Fantastic.

      Except I have never seen a web client that handles JPG this way. Not a single one will stop at target resolution, and will continue to load until they have all the bytes of the image. Furthermore, there's plenty of reasons to download the full image size. Perhaps the image needs to resize dynamically after being loaded. Perhaps I rotated my device from portrait to landscape and now I need a larger image to fill the space. There's no pause/resume mechanism in the format to handle this, and the resu

  • Designer (Score:4, Informative)

    by CanadianMacFan ( 1900244 ) on Tuesday September 02, 2014 @03:11PM (#47810343)
    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.
    • 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.

    • Re: (Score:2)

      by AmiMoJo ( 196126 ) *

      The issue is more to do with widely varying pixel densities of screens, rather than simple size. A standard desktop monitor is about around 100 PPI, but 4k monitors are usually twice that. Some phones and tablets are over 500 PPI. Designers want to provide full resolution images where possible, but even if the phone has a 500 PPI screen it might be on a slow mobile connection. The best thing to do is let the device decide which version it wants.

    • So they are supposed to prioritise those with poor slow computers at the expense of owners of devices pushing 3+ megapixels of desktop resolution?

      Tell me again why you think optimising for a different device solves the problem rather than making the entire system suitable for all devices?

  • 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 s
  • 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 bee

    • Re: (Score:2)

      by pspahn ( 1175617 )

      I don't know, what is the rationale in asking such a long-winded question when you could have made it clearer by saying it in about seven words?

      Why trust industry standards when they are so fleeting?

      Maybe you'd rather have standards that last forever? Or possibly no standards at all? What exactly are you getting at?

  • 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?

  • 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...).

  • Because you couldn't do this without yet another tag, right? Oh yeah.. I guess you could have done it with IMG.. oh well.

  • 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 horiz

Slashdot Top Deals

news: gotcha

Close