Re: [whatwg] Features for responsive Web design

Also, srcset does not abstract the control points away from the image
itself. I have already been over why this is a problem and
future-unfriendly. Breakpoints are based on a when a *design* becomes
visually broken, not on the width of a device. So, when a design
changes, so will the response breakpoints, and that would mean having
to revisit and edit every image that's had srcset applied - unless I
am missing something (which given the last day or two, I may well be).

-Matt

On 16 May 2012 13:55, Matthew Wilcox <mail@matthewwilcox.com> wrote:
> Chalk me up as another making that mistake. Properties on elements
> usually describe a property of the element. Not a property of
> something else (like the viewport).
>
> I'm happier than I was about srcset - but why does the spec assume
> pixels? Or does it?
>
> Use case: design breakpoints can and often are based on non-pixel
> units. em's, for example. As far as I can tell, srcset does not work
> with units other than pixels, so how could it work reliably with
> designs done in non-pixel units?
>
> -Matt
>
> On 16 May 2012 13:38, PJ McCormick <pj@mynameispj.com> wrote:
>>>
>>> On Wed, May 16, 2012 at 5:25 AM, Henri Sivonen <hsivonen@iki.fi> wrote:
>>>
>>> On Wed, May 16, 2012 at 2:46 PM, Jeremy Keith <jeremy@adactio.com> wrote:
>>>> > You're right. I was thinking that the values (Nh Nw Nx) described the
>>>> *image* but in fact they describe (in the case of Nh and Nw) the viewport
>>>> and (in the case of Nx) the pixel density of the screen/device.
>>>> >
>>>> > I suspect I won't be the only one to make that mistake.
>>>>
>>>> Indeed. I made the same mistake initially. The what's currently in the
>>>> spec is terribly counter-intuitive in this regard.
>>>
>>>
>> I also made the same mistake, and it took combing through all of
>> yesterday's and this morning's discussions on the topic for me to finally
>> understand it properly. And I consider myself to be a fairly competent
>> developer, not someone just starting out with HTML.
>>
>> Now that I do understand I'm honestly happier with @srcset as a concept,
>> but my problems with the syntax itself still remain. In fact, they might be
>> amplified. Surely we can refine this into a better, more easily understood
>> syntax.
>>
>>
>>
>>
>> On Wed, May 16, 2012 at 5:25 AM, Henri Sivonen <hsivonen@iki.fi> wrote:
>>
>>> On Wed, May 16, 2012 at 2:46 PM, Jeremy Keith <jeremy@adactio.com> wrote:
>>> > You're right. I was thinking that the values (Nh Nw Nx) described the
>>> *image* but in fact they describe (in the case of Nh and Nw) the viewport
>>> and (in the case of Nx) the pixel density of the screen/device.
>>> >
>>> > I suspect I won't be the only one to make that mistake.
>>>
>>> Indeed. I made the same mistake initially. The what's currently in the
>>> spec is terribly counter-intuitive in this regard.
>>>
>>> > I can see now how it does handle the art-direction case as well. I think
>>> it's a shame that it's a different syntax to media queries but on the plus
>>> side, if it maps directly to imgset in CSS, that's good.
>>>
>>> It seems to me that Media Queries are appropriate for the
>>> art-direction case and factors of the pixel dimensions of the image
>>> referred to by src="" are appropriate for the pixel density case.
>>>
>>> I'm not convinced that it's a good idea to solve these two axes in the
>>> same syntax or solution. It seems to me that srcset="" is bad for the
>>> art-direction case and <picture> is bad for the pixel density case.
>>>
>>> (I think the concept of dpi isn't appropriate for either case, FWIW. I
>>> think "the number of horizontal and vertical bitmap samples doubled
>>> relative to the traditional src image" works much better conceptually
>>> for Web authoring than making people do dpi math with an abstract
>>> baseline of 96 dpi. Anecdotal observation of trying to get family
>>> members to do dpi math for print publications suggests that it's hard
>>> to get educated people do dpi math right even when an "inch" is a real
>>> inch an not an abstraction.)
>>>
>>> --
>>> Henri Sivonen
>>> hsivonen@iki.fi
>>> http://hsivonen.iki.fi/
>>>

Received on Wednesday, 16 May 2012 12:58:38 UTC