Re: Revisiting aspect ratios in sizes

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-progressive-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-progressive-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:08:44 UTC