Re: [whatwg] The src-N proposal

On Sun, Nov 10, 2013 at 12:20 AM, Adam Barth <w3c@adambarth.com> wrote:
> On Fri, Nov 8, 2013 at 11:46 AM, Ian Hickson <ian@hixie.ch> wrote:
>> On Fri, 8 Nov 2013, Rafael Rinaldi wrote:
>>> It looks complex because it tries to solve something complex. I think
>>> there’s no way to avoid verbosity to solve such thing.
>>
>> The way you avoid complexity in such things is that you don't solve the
>> overall problem, you solve small segments of the problem (e.g. in script
>> or CSS), then pick the solution you want.
>>
>> So for example, we could have a script to handle image grids, another to
>> handle simple cases where as the window gets wider you display more
>> context in the image, etc. If all these scripts have some common features
>> they all need (e.g. the ability to work with pre-parsing to say which
>> image they need first, so it can be fetched early) then we can provide
>> that common core.
>>
>> This is similar to AppCache vs Alex's ServiceWorkers. AppCache addresses a
>> small set of use cases, probably not enough. ServiceWorkers provides the
>> tools to address a lot of use cases, but isn't directly itself a solution;
>> you use it to build solutions. Another example would be the WebForms2
>> repetition model, vs Rafael's <template>. The repetition model idea solved
>> some specific use cases, but trying to make it solve all use cases would
>> be a hugely complicated endeavour and would be really ugly. <template>
>> provides a tool with which you can build specific solutions, but isn't
>> itself a direct solution.
>
> I basically agree with Ian.  Let's address the simple use cases first
> (i.e., device-pixel-ratio switching) and worry about the more complex
> use cases in the future.

Remember that we only *have* two use-cases that require different
results - resolution choosing and art direction based on viewport
breakpoints.  These are well-supported as common and necessary
operations, done commonly on existing websites using the various
responsive image hacks.

The final clause that a few people keep hating on is, as I explain in
<http://www.xanthir.com/b4Su0> solely a mechanism for reducing the
*enormous* verbosity that can arise from the existing solutions in
fairly simple, reasonable cases.  (It's also automatically robust
against gains in resolution, whereas the existing solution requires
increasing the verbosity *even further* to make it robust.)

It's easy to look at something more complex than what you're used to
and dismiss all the excess as unneeded, but it's really, seriously not
in this case.  The things I'm addressing are the things that RICG
research found were common and necessary, no more and no less.

~TJ

Received on Sunday, 10 November 2013 17:00:32 UTC