[whatwg] RWD Heaven: if browsers reported device capabilities in a request header

[Matthew Wilcox]

Ahhh, ok. I was not aware that SPDY is intended to suffer from the flaws
inflicted by the dated mechanics of HTTP. Is it really different semantics
though? I don't see how it's harmful to enable resource adaption over SPDY
just because browser vendors have decided that HTTP is too expensive to do
it? To be clear: this is a case of browser vendors deciding it's too
expensive and therefor not allowing it to be implemented, when it should be
authors in the position to know whether it's too expensive given their
specific use case.

I'm sensing the SPDY/HTTP identical-semantics standpoint may be a
philosophical thing rather than technical?

No offense taken btw. Things have to prove themselves. The danger is the
standards process is too slow to react well, and some even more hacky
solution turning into a de-facto standard. Personally, I think the issue of
adapting resources to client capabilities is here to stay. Devices of
significantly varied size and performance are here to stay, and adapting
images to suit is only one example of smart resource adaption - it doesn't
seem like it would become irrelevant until all devices are memory and
processor monsters over high speed connections. Which is going to take
decades, if it ever happens.

I'm glad the discussion is going on though, and there are as always points
to be considered that are not obvious at first.

It just seems like SPDY as a technology is in a great position to do this.
It's the choice of restricting SPDY to HTTP's viable capabilities which is
the cause of a potential veto of this.

:)

On 7 February 2012 13:34, Henri Sivonen <hsivonen at iki.fi> wrote:

> On Mon, Feb 6, 2012 at 5:52 PM, Matthew Wilcox <mail at matthewwilcox.com>
> wrote:
> > Also, as indicated, with SPDY this is much much less of a problem than
> for HTTP.
>
> SPDY transfers the HTTP semantics more efficiently when supported. You
> aren't supposed to communicate different semantics depending on
> whether SPDY is enabled. That would be a layering violation.
>
> That is, SPDY is supposed to work as a drop-in replacement for the old
> way of putting HTTP semantics over IP. You aren't supposed to send
> different headers depending on whether SPDY is there or not.
>
> And the old HTTP is going to be around for a *long* time, so even if a
> bunch of important sites start supporting SPDY, if browsers send the
> same headers in all cases to avoid the layering violation, the long
> tail of plain old HTTP sites would be harmed by request size bloat.
>
> So I think "SPDY will fix it" is not a persuasive argument for
> allowing HTTP request bloat to cater to the bandwagon of the day.
> (Sorry if that seems offensive. You've worked on responsive images, so
> they evidently seem important to you, but in the long-term big
> picture, it's nowhere near proven that they aren't a fad of interest
> to a relative small number of Web developers.)
>
> If there is evidence that responsive images aren't just a fad
> bandwagon and there's a long-term need to support them in the
> platform, I think supporting something like
> <picture>
> <source src=something.jpg media=...>
> <source src=other.jpg media=...>
> <img src=fallback.jpg>
> </picture>
> would make more sense, since the added to transfer this markup would
> affect sites that use this stuff instead of affecting each request to
> all sites that don't use this stuff. This would be more
> intermediary-friendly, too, by not involving the Vary header.
>
> The points Boris made about the device pixel size of the image
> changing after the page load still apply, though.
>
> But still, engineering for sites varying the number of pixels they
> send for photos seems a bit premature when sites haven't yet adopted
> SVG for illustrations, diagrams, logos, icons, etc.
>
> --
> Henri Sivonen
> hsivonen at iki.fi
> http://hsivonen.iki.fi/
>