- From: Adam Barth <w3c@adambarth.com>
- Date: Sun, 10 Nov 2013 00:20:33 -0800
- To: Ian Hickson <ian@hixie.ch>
- Cc: WHATWG <whatwg@whatwg.org>, Yoav Weiss <yoav@yoav.ws>
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. Adam
Received on Sunday, 10 November 2013 08:21:32 UTC