W3C home > Mailing lists > Public > public-respimg@w3.org > October 2016

Re: Revisiting aspect ratios in sizes

From: Paul Deschamps <pdescham49@gmail.com>
Date: Tue, 4 Oct 2016 14:26:42 -0400
Message-ID: <CACPLTHgMpFSJs+FUWz+DwC2krng3tj8yoNQ__vf6npwTPtbFVw@mail.gmail.com>
To: steve@steveclaflin.com
Cc: Simon Miles-Taylor <smilestaylor@gmail.com>, Jonathan Kingston <jonathan@jooped.co.uk>, Greg Whitworth <gwhit@microsoft.com>, Yoav Weiss <yoav@yoav.ws>, Jason Grigsby <jason@cloudfour.com>, "public-respimg@w3.org" <public-respimg@w3.org>
IMHO, Stretching a raster to accommodate some "hack" - for example turning
a one pixel dot into a line should not be a part of any edge case.

Vectors should be treated as vectors and Rasters should be treated as
Rasters. There is no "quality" in allowing a raster to be scaled in a way
so that there is a loss of anti-aliasing or the image quality becomes
skewed.

Rasters should have two simple strict rules:

   - With / Height: should *never* exceed the "source" file's width ||
   height
   - The raster should *not* scale in any way that doesn't adhere to the
   source aspect ratio.

If you want imagery the scales outside of the aspect ratio then you to use
a "vector" image format.

Just my two cents

Paul.





On Tue, Oct 4, 2016 at 2:08 PM, <steve@steveclaflin.com> wrote:

> I can think of several situations where an image would be stretched from
> it's natural aspect ratio.  One is the simple color dot stretched into a
> line, which admittedly isn't necessary any more given advances in CSS.
> Another would be an image initially created for a device with non-square
> pixels.
>
> For what it's worth, and although it's not a use case, here is an example
> of "another methodology" instead of the padding hack.  While it's a little
> cumbersome, it might serve as a starting point for a polyfill.
> http://www.steveclaflin.com/blog-stuff/html/scalable-video.html
>
> Regards,
>
> Steve
>
>
> On 2016-10-04 12:40, Simon Miles-Taylor wrote:
>
>> Hi,
>>
>> I have difficulty understanding why height and width can ever
>> uncoupled. The resizing or aspect should be proportional to avoid
>> distortion of the image.  Works of art have a defined dimension or
>> else you could end up giving the Mona Lisa a grimace. Whichever way
>> you render images, some long and others tall vs square images this is
>> going to be iniquitous as the area of a square is proportionally
>> larger that any rectangle of a similar size.  Trying to represent a 3
>> metre wide painting onto a phome format gives a poor result so there
>> are some limitations.  Neither is very efficient to reduce a large
>> images 1000px to 100px and picture element is a great solution.
>>
>> What I really like to see is margin auto being applied to both the
>> horizontal and vertical.  I have dealt with 25,000 image of all shapes
>> and sizes and as all these images are in a parent container, next to a
>> spacer, both with a vertical alignment there is no issues with
>> rendering because the parent container has "reserved" space for the
>> image.  All that is required is aligning the image within the parent
>> container.
>>
>> The work on responsive images has been really appreciated.  It is a
>> vast improvement of having no img src whatsoever and using java to
>> define what image to use depending on the screen resolution.  The
>> issue I have with artists is to provide stillness and it does not
>> matter what aspect or screen resolution, in each environment there is
>> no flickering.  More to the point as a web designers we do not have
>> the right to distort a work of art, the artist meant the image size to
>> reflect the dimensional aspect of their work.  To change just one
>> aspect is disrespectful to an artist's intentions.
>>
>> There is an asthetic dimension as well as a technical consideration.
>>
>> Kind regards
>>
>> Simon
>>
>> On 4 October 2016 at 17:15, Jonathan Kingston <jonathan@jooped.co.uk>
>> wrote:
>>
>> I haven't forgotten, I shall be working with a designer to hammer
>>> out use cases hopefully on Friday :).
>>>
>>> On Tue, Oct 4, 2016 at 4:51 PM Greg Whitworth <gwhit@microsoft.com>
>>> wrote:
>>>
>>> I also created a repo with issues that were actioned at the meeting:
>>>
>>>
>>> https://github.com/WICG/aspect-ratio [1]
>>>
>>> If anyone wants to provide use cases where they utilize the padding
>>> hack or other methodology to achieve aspect-ratio, feel free to add
>>> them to the readme via PR.
>>>
>>> ~Greg
>>>
>>> FROM: Yoav Weiss [mailto:yoav@yoav.ws]
>>> SENT: Tuesday, October 4, 2016 7:52 AM
>>> TO: Jason Grigsby <jason@cloudfour.com>
>>> CC: public-respimg@w3.org
>>> SUBJECT: Re: Revisiting aspect ratios in sizes
>>>
>>> My notes from the meeting (among others) are at
>>> https://blog.yoav.ws/tpac_2016/ [2]
>>>
>>> On Tue, Oct 4, 2016 at 1:19 PM, Jason Grigsby <jason@cloudfour.com>
>>> wrote:
>>>
>>> Hi Yoav,
>>>
>>> What was the outcome of the discussion at TPAC? Is it shipping in
>>> browsers next month? ;)
>>>
>>> -Jason
>>>
>>> On Wed, Sep 21, 2016 at 2:35 AM, Yoav Weiss <yoav@yoav.ws> wrote:
>>>
>>> Thanks all!
>>>
>>> A bunch of us are currently at TPAC, so we're running a session
>>> about this problem and related proposals. We'll try to keep minutes
>>> and publish conclusions (if there are any)
>>>
>>> On Wed, Sep 21, 2016 at 11:08 AM, Jonathan Kingston
>>> <jonathan@jooped.co.uk> wrote:
>>>
>>> Hi All,
>>>
>>> I drafted a similar demo for creating a new size property in CSS and
>>> expanded from Tab Atkins aspect ratio work here in this demo (this
>>> links to a draft spec also):
>>>
>>> https://jonathankingston.github.io/logical-sizing-properties
>> /demo/index.html
>>
>>> [3]
>>>
>>> The discussion was started here:
>>>
>>> https://discourse.wicg.io/t/shorthand-for-width-height-css-
>> longhands/1160/26
>>
>>> [4]
>>>
>>> Also CSSWG thread:
>>> https://lists.w3.org/Archives/Public/www-style/2016Sep/0046.html [5]
>>>
>>>
>>> I would love your input on this as ideally if this is going to be a
>>> property of HTML it would make sense to have some form of syntax
>>> interop.
>>>
>>> Thanks
>>>
>>> On Wed, Sep 21, 2016 at 8:22 AM Tommy Hodgins <tomhodgins@gmail.com>
>>> wrote:
>>>
>>> Hey Jason & everybody!
>>>
>>> I have two code demos to contribute toward this discussion. I often
>>> have to implement responsive video embeds and instead of trying the
>>> “_wrapper + padding hack”_ technique for every video I have to
>>> embed — and then find some other way to calculate the aspect ratio
>>> based on its dimensions — I’ve taken to just copy/pasting the
>>> embed code directly from Youtube or Vimeo with the width="" and
>>> height="" attributes intact, and using JS to calculate the correct
>>> height for the element as the width adapts to fill its container
>>> responsively:
>>>
>>> http://codepen.io/tomhodgins/pen/PZqaLm [6]
>>>
>>> The other example demonstrates how responsive aspect ratio might
>>> work in CSS. The desired aspect ratio is stored in a custom data
>>> attribute called data-ratio="" and read by (JS and) CSS and the
>>> correct height is calculated based on the same formula:
>>>
>>> http://codepen.io/tomhodgins/pen/XKJpYr [7]
>>>
>>> So I hope these two demos can serve as a springboard for further
>>> brainstorms & exploration! Me and my buddies have often discussed
>>> that it would be cool if there was a $nativeWidth or $nativeHeight
>>> unit in CSS that was aware of the native resolution of any
>>> image/video content that you could use in your calculations - but
>>> haven’t mocked up support for that yet.
>>>
>>> Also, on the element queries front: this week I had a fun
>>> implementing of an element query solution in ~40-lines of
>>> JavaScript. It’s a non container-query style element query demo
>>> that uses custom data attributes and applies classes, so the
>>> features are quite limited. But hopefully this demo will help
>>> simplify the concept for people wondering how to implement element
>>> queries, or use them: http://codepen.io/tomhodgins/pen/bwwNRr [8]
>>>
>>>
>>> Happy hacking,
>>>
>>> Tommy
>>>
>>> On Sep 21, 2016, at 1:44 AM, Jason Grigsby <jason@cloudfour.com>
>>> wrote:
>>>
>>> Back in 2014, Steve Caflin started an interesting thread on finding
>>> some way to tell the browser the size of the image in the page for
>>> the purposes of assisting with layout.[^1]
>>>
>>> The conversation led to two tickets in Github about intrinsic
>>> dimensions[^2] and how sizes only works with width-constrained
>>> images.[^3] Conversations on both tickets have subsided and issue
>>> #86 was explicitly tabled.
>>>
>>> I would like to reopen this conversation. In particular, we've seen
>>> an increased emphasis on providing old school width and height
>>> attributes to avoid the page jumping around.
>>>
>>> AMP Pages explicitly require height and width declarations for this
>>> reason.[^4] Owen Cambell-Moore's UI recommendations for Progressive
>>> Web Apps also state you should avoid pages jumping around by
>>> declaring height and width.[^5]
>>>
>>> The problem was also recently raised on the www-style list[^6] where
>>> Rachel Nabors[^7] among others described how this is a generalized
>>> problem for more than simply images.
>>>
>>> I believe we need to strongly consider two actions:
>>>
>>> 1. Prioritize adding aspect ratio information to sizes (or adding a
>>> aspect attribute).
>>>
>>> 2. Considering extending the sizes (and an aspect attribute if one
>>> exists) to be available to other elements that provide similar
>>> layout problems in responsive designs.
>>>
>>> With sizes, we've provided half of what the browser needs to reserve
>>> the size of the image in the page. If the browser knew the aspect
>>> ratio, it could calculate the other half. Let's find a way to make
>>> this happen.
>>>
>>> -Jason
>>>
>>> [^1]:
>>>
>>> https://lists.w3.org/Archives/Public/public-respimg/2014Oct/0043.html
>>
>>> [9]
>>>
>>> [^2]:
>>> https://github.com/ResponsiveImagesCG/picture-element/issues/85 [10]
>>>
>>>
>>> [^3]:
>>> https://github.com/ResponsiveImagesCG/picture-element/issues/86 [11]
>>>
>>>
>>> [^4]: https://www.ampproject.org/docs/guides/amp_replacements.html
>>> [12]
>>>
>>> [^5]:
>>>
>>> https://medium.com/@owencm/designing-great-uis-for-progressi
>> ve-web-apps-dd38c1d20f7#.hzxdz4z7d
>>
>>> [13]
>>>
>>> [^6]:
>>> https://lists.w3.org/Archives/Public/www-style/2016Jun/0072.html
>>> [14]
>>>
>>> [^7]:
>>> https://lists.w3.org/Archives/Public/www-style/2016Jun/0091.html
>>> [15]
>>>
>>> --
>>>
>>> +1 (503) 290-1090 [16] o | +1 (503) 502-7211 [17] m |
>>> http://cloudfour.com [18] | @grigs
>>>
>>
>> --
>>
>> +1 (503) 290-1090 [16] o | +1 (503) 502-7211 [17] m |
>> http://cloudfour.com [19] | @grigs
>>
>>
>>
>> Links:
>> ------
>> [1] https://github.com/WICG/aspect-ratio
>> [2] https://blog.yoav.ws/tpac_2016/
>> [3] https://jonathankingston.github.io/logical-sizing-properties
>> /demo/index.html
>> [4] https://discourse.wicg.io/t/shorthand-for-width-height-css-
>> longhands/1160/26
>> [5] https://lists.w3.org/Archives/Public/www-style/2016Sep/0046.html
>> [6] http://codepen.io/tomhodgins/pen/PZqaLm
>> [7] http://codepen.io/tomhodgins/pen/XKJpYr
>> [8] http://codepen.io/tomhodgins/pen/bwwNRr
>> [9] https://lists.w3.org/Archives/Public/public-respimg/2014Oct/0043.html
>> [10] https://github.com/ResponsiveImagesCG/picture-element/issues/85
>> [11] https://github.com/ResponsiveImagesCG/picture-element/issues/86
>> [12] https://www.ampproject.org/docs/guides/amp_replacements.html
>> [13]
>> https://medium.com/@owencm/designing-great-uis-for-progressi
>> ve-web-apps-dd38c1d20f7#.hzxdz4z7d
>> [14] https://lists.w3.org/Archives/Public/www-style/2016Jun/0072.html
>> [15] https://lists.w3.org/Archives/Public/www-style/2016Jun/0091.html
>> [16] tel:%2B1%20%28503%29%20290-1090
>> [17] tel:%2B1%20%28503%29%20502-7211
>> [18] http://cloudfour.com/
>> [19] http://cloudfour.com
>>
>
>
>
Received on Tuesday, 4 October 2016 18:27:14 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:06:19 UTC