[Webkit-unassigned] [Bug 105741] Make HTTP Accept header for images useful without slowing down page load speeds and without using excessive bandwidth.

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=105741





--- Comment #3 from David Bruant <bruant.d at gmail.com>  2012-12-28 00:59:48 PST ---
(In reply to comment #2)
> If we were to actually enumerate all types we actually support we'd have request headers much, much larger than average and slow down page loads.
> 
> I've retitled the bug to:
> "Make HTTP Accept header for images useful without slowing down page load speeds and without using excessive bandwidth"
> ...to specify what an acceptable resolution to it would be.

I fully agree.
I've discussed the matter on the Firefox side [1] (the bug has changed of summary over there too for the same reason).

A couple of conclusions I've drawn from all this Accept-in-<img> discussion:
* No need to advertise image formats which are known to be widely supported (jpeg, gif, png)
* No need to advertise bad or too exotic image formats even if actually supported
* Accept can be a good idea in transition period when a new good format come along.
* Even when doing server-driven negotiation, a webdev has to test the website, so server-driven negotiation shouldn't be expected to be a magic fully automated thing.
* Web browsers are reluctant to change their Accept, because it may break websites.

In the end, I think it might be good to advertise for image/png, image/svg+xml (debatable) and image/webp (if supported)


I'm also coming to the conclusion that Webdevs could work around the problem of browser-wise Accept by sending themselves HTTP requests via XMLHttpRequest with their own Accept. The matter could be solved in probably about 30-50 lines of client-side JS.
I might just write a library, benchmark and if I'm happy with the result, tell people to do that.

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=824623

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.