New HTML Picture Element To Make Future Web Faster 161
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?
Dupe (Score:5, Interesting)
Re: (Score:2)
Re: (Score:2)
GUI technology has regressed since the 90s (Score:4, Insightful)
Bah (Score:2)
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)
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.
Re: (Score:2)
Things are a bit more complicated than they used to be...
Client or Server side? (Score:2)
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.
Re: (Score:3)
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.
Re: (Score:2)
Yes, (replying to GrandParent, but agreeing with Parent.)
Can you explain why it would be better on the server side? I naturally assumed client side. "Get SmallScreen version of Picture." It would then be scaled by the Browser to fit the size determined by the layout.
I don't think that you'd change the layout based on which images were selected. Everything would look exactly the same, just the byte-size/quality of the image file would be different.
Re: (Score:2)
I don't think that you'd change the layout based on which images were selected. Everything would look exactly the same, just the byte-size/quality of the image file would be different.
You are mistaken. In fact, one of the reasons they decided on this method was so that the image is now from layout constraints. You might want to have the image be 400px square on one layout, while it will be 800x600 in another layout.
On top of that, if you are providing images of varying proportions, you don't really want some computer to auto-crop everything depending on the requesting device since the results will be artistically inferior to a trained human.
Re: (Score:3)
Re: (Score:2)
Re: (Score:3)
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 usi
Re: (Score:2)
I believe that the idea is to provide the different sizes on the server side, but that the browser (and user preferences) determines which version to download.
I get that but it means the server now has multiple URL's to get the picture and these URL's are defined by how the client will format the GET. I'm just pushing the whole page formatting issue to the server so you pull one URL and the server decides which image to give you. Then the server side is free to have the pictures already processed on disk or process them on the fly and is in total control of the formatting on the page. It also frees up network bandwidth and processing and memory requirements fo
Re: (Score:2)
Something akin to using a background image and media queries to pick the right version of the image based on the window size?
Responsive Web Design (Score:5, Insightful)
" 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".
Which site "collapses"? (Score:2)
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)
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.
Mashable sucks in other ways too (Score:2)
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)
" 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)
Re: (Score:2)
Re: (Score:2)
Fiattech.com is a VERY small mobile-centric site, with very little content and some presentation logic to optimize its mobile presentation on desktops.
The articles page for example shows 5 one-line article summaries at a time even on a 1920x1200 desktop. To see all 25 articles I need to page through 5 pages.
Its usable at this tiny content scale, but its hardly a good desktop design; and if there were much more content its usability limitations would become increasingly apparent.
Likewise, the home pa
NCSA is doing it wrong (Score:2)
Re: (Score:2)
Re: (Score:2)
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 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)
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
Re: (Score:2)
It uses gridiculous.
It's the 1990s all over again. (Score:5, Insightful)
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?
Re: (Score:2)
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)
<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?
Re: (Score:2)
<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.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Kodak had the right idea decades ago (Score:5, Interesting)
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.
Re: (Score:2)
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.
But how does a browser know how many bytes? (Score:2)
Re: (Score:2)
Overhead of dozens of requests (Score:2)
Re: (Score:2)
AFAIK, PhotoCD uses JPEG. It's just that it's JPEG's hierarchical mode, that nobody else uses. (See my other post [slashdot.org])
Re: (Score:3)
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)
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
Variable crop (Score:2)
Let's see (Score:5, Funny)
Re: (Score:2)
It will start by downloading the wrong size image first, then repeatedly redownload the image each time the screen refreshes or resizes until you run out of mobile data.
Re: (Score:2)
Let's see how Slashdot can manage to munge THIS tag up.
Good job with the <i> around "real" there, guys. [slashdot.org]
Not an open problem. (Score:2)
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.
Re: (Score:2)
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
Re: (Score:2)
The tag gives a standard way of doing it, and javascript is used already for backporting the functionality to noncompliant browsers.
Designer (Score:4, Informative)
Smallest possible byte size depends on viewport (Score:2)
Re: (Score:2)
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.
Re: (Score:2)
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?
Wrong Way to Solve This Problem (Score:2)
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
Can anybody tell me, please (Score:2)
Re: (Score:2)
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?
Re: (Score:2)
Desktop screens have had two sizes in the past 10 years to my knowledge: 4:3 and 16:9
Display aspect ratios aren't "sizes". A 24" desktop display can show a lot more than a 10" netbook or tablet display, even if they're both close to 16:9.
Re: (Score:2)
That depends on the DPI. My phone, very small indeed, is 1080x1920 (or 1920x1080 if I'm holding it funny.) One of the monitors on my 8-core desktop is 1280x1024.
The DPI difference between them is radical. Even so, any properly designed page will allow the user's browser to resize and reflow the content to fit the window if it's of any sane width (probably only wide enough to render the longest word in the content.) If it can't do that, the browser should hand you scroll bars. Be nice if the browser had a us
Hover menus work with CSS + noscript (Score:2)
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.
Re: (Score:2)
Re: (Score:2)
Desktop screens have had two sizes in the past 10 years to my knowledge: 4:3 and 16:9 (or close to it), so they have not been getting wider and wider.
I you start at 4:3 moving over whatever the hell 1280x1024 was, then back to 4:3 a too short flirt with 3:2 then settling on 16:10 before dumping it for 16:9, and now trying to argue 32:9 is what everybody (should) want. Sounds like the desktop screens are getting wider and wider to me.
Re: (Score:2)
Irrelevant. All you really need to know is that pixels are square. It's been some time since we had to deal with non-square pixels. Everything else should be up to the user's browser window.
The 90's called (Score:2)
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?
Re: (Score:2)
Developers are already using the tag today with javascript libraries to backport to noncompliant browsers. As browsers adopt the standard, the transition will be seamless.
https://github.com/scottjehl/p... [github.com]
Doesn't CSS Already Solve This? (Score:2)
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...).
How useful (Score:2)
While we're at it... CLIP 'n FLIP? (Score:2)
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
Re: (Score:2)
Presumably, they'll scale the one they have and replace it when the new one is available.
Like mipmaps in games.
Re: (Score:2)
How often do you resize your browser?
Re: (Score:2)
You should design an image format in which larger versions can use data from smaller ones. So when you browse the site with a small window, the small version gets downloaded, and when you resize, the larger version gets downloaded, and when you visit with a large browser, both versions get downloaded.
Progressive JPEG (Score:3)
Re:Progressive JPEG (Score:5, Interesting)
What you'd need there is not file support, but server side support. If you're downloading a single file with all those formats, you're going to have to download everything at once. That's inefficient (important on mobile devices) and slow. Stuffing all the sizes into one container isn't the answer.
Instead, what you'd like is one URL to automatically send you the correct file(s) for your size(s). For example, you could put headers in the http request giving the desired resolutions and the response could have each of those sizes, in preference order. Basically have each image request turn into a CGI request for multiple files. More or less what this new tag is trying to do client side. Of course doing it client side, while less convenient all around, does have privacy advantages- you can't guess the device type from the sizes requested.
Re: (Score:2)
you can't guess the device type from the sizes requested.
Sure you can; the security point is that you can't KNOW the device type from the sizes requested. You have to guess.
However, it seems to me that using element fingerprinting, this element would be a pretty strong indicator to narrow down who you were.
Re: (Score:2)
Hmm, decent point. Let me rephrase- its more work to do so when done client side, because it won't be done in 1 chunk, and because those worrying about security can lie and request unneeded sizes as well poisoning the data you're guessing from. Doing it server side makes it trivial.
Re: (Score:3)
I don't think you were paying attention to how a progressive .jpg works. The file has only the full-detail image in the file, but the as you load more and more bits from the file, the quality improves from unrecognisably blurry to sharp and detailed.
Simply request the file from byte 1, load until you get the level of detail you need, then close the connection. If you need more detail later, just resume the download.
Re: (Score:3)
Which is really uncomfortable to look at. My eyes keep trying to focus on the blurry image and can't. Also how do they propose to test client bandwidth, maybe the client is downloading an ISO or five at the same time but wants the higher res images anyway.
Anyway @media does this already with normal image tags and can be refined to any degree of granualarity needed, and yes img srcs can be changed in CSS.
And really the plethora of new tags making an appearance is getting weird. I came across a tag recently
Re: (Score:2)
Slashcode seems to have erased the tag itself, it was figure, the figure tag.
Re: (Score:2)
does this mean that resizing the browser window will cause it to re-download images?
That depends on how often you resize the browser window. Smartphone and tablet operating systems typically implement a window management policy of all maximized all the time, which means the viewport size won't change unless the user is rotating the screen. How often do most desktop and laptop PC users resize a browser window?
Re: (Score:2)
Offline browsing (Score:3)
Re: (Score:3)
If only browsers were smart enough not to play audio in background tabs.
Re: (Score:3)
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?
Re: (Score:3)
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.
Re: (Score:2)
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).
A list of semantically equivalent image URIs (Score:2)
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."
Re: (Score:2)
Images themselves have no semantic value, only the elements that points to them... furthermore, the dimensions of the image are semantically irrelevant. This is a lame, flawed attempt to solve a visual layout problem with misplaced semantics. You wouldn't invent a redundant element for audio files based on varying bitrate because audio similarly has no semantic value and the media type is inherently non-visual.
Layne's Law break: "semantic value" (Score:2)
Images themselves have no semantic value
I detect definition disagreement [c2.com], 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 [mozilla.org] allows specifying multiple otherwise equivalent sources, each in a source element [mozilla.org], 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
Burn through your cap (Score:2)
Re: (Score:2)
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.
Window size and pixel density in what header? (Score:2)
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?
Re: (Score:2)
Pixel density: Since user-agent has been available
A single combination of web browser and operating system can be used on both low DPI displays and high DPI displays. Consider, for example, Safari on a MacBook with a Retina brand high DPI display and Safari on a MacBook with a normal DPI display.
Window size: This is not something you should be using. That's something the browser uses to reflow properly designed content
So if the web page's style sheet specifies that a particular image shall be 50 percent of the width of the viewport, however wide the user might have chosen to make that, how should the server go about determining how many pixels that is in order to serve the corre
Re: (Score:2)
> A single combination of web browser and operating system can be used on both low DPI displays and high DPI displays.
If the image is wider than the window, you get scroll bars; also, browsers can resize. It's not the server's job. We don't have a bandwidth shortage. We have a decently flexible content shortage. If you know it's a mac or a PC, you know it's got a desktop range of pixels. Likewise any particular smartphone. There's no mystery here worth noticing.
Don't resize images with the viewport. That
Re: (Score:3)
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 m
Re: (Score:2)
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.
Re: (Score:2)
Re: (Score:2)
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?
Re: (Score:2)
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".