Re: Revisiting aspect ratios in sizes

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
>>
>>
>>
>> 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/
>>
>>
>>
>> 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
>>
>> The discussion was started here: https://discourse.wicg.io/t/
>> shorthand-for-width-height-css-longhands/1160/26
>>
>> Also CSSWG thread: https://lists.w3.org/Archives/
>> Public/www-style/2016Sep/0046.html
>>
>> 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
>>
>>
>>
>> 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
>>
>>
>>
>> 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
>>
>>
>>
>> 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
>>
>> [^2]: https://github.com/ResponsiveImagesCG/picture-element/issues/85
>>
>> [^3]: https://github.com/ResponsiveImagesCG/picture-element/issues/86
>>
>> [^4]: https://www.ampproject.org/docs/guides/amp_replacements.html
>>
>> [^5]: https://medium.com/@owencm/designing-great-uis-
>> for-progressive-web-apps-dd38c1d20f7#.hzxdz4z7d
>>
>> [^6]: https://lists.w3.org/Archives/Public/www-style/2016Jun/0072.html
>>
>> [^7]: https://lists.w3.org/Archives/Public/www-style/2016Jun/0091.html
>>
>>
>>
>>
>>
>> --
>>
>> +1 (503) 290-1090 o | +1 (503) 502-7211 m | http://cloudfour.com | @grigs
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> --
>>
>> +1 (503) 290-1090 o | +1 (503) 502-7211 m | http://cloudfour.com | @grigs
>>
>>
>>
>