RE: Revisiting aspect ratios in sizes

Since the thread is here & github, I’ll reply here as well:

Thanks for the video, cleared things up for me in what you were actually wanting because I was going to suggest max-content but you're actually wanting the computedWidth. It's worth noting, that this won't allow any usage of %s or autos because you won't know this at cascade time, the only reason you can do this sufficiently in JS is because it's interacting on the used width.
That is a huge downside to this property. Take flex for example, at computation time, it may be 50px wide but the flexible space after layout may allow it to be 100px yet you're setting your height up to be proportional to 50px rather than that of the 100px. While it would be nice to have in CSS, I actually think this makes more since in JS since Layout has completed at that time, thus all styles are fully resolved and can be trusted as complete.

The nativeWidth and nativeHeight are interesting as well, but there are times that we do layout without all resources available, so we could provide this if known but otherwise, 0? Maybe we should spin up a separate thread regarding this since it’s technically a separate feature to possibly design.

~Greg

From: Tommy Hodgins [mailto:tomhodgins@gmail.com]
Sent: Tuesday, October 4, 2016 1:23 PM
To: Hall, Charles (DET-MRM) <Charles.Hall@mrm-mccann.com>
Cc: steve@steveclaflin.com; Paul Deschamps <pdescham49@gmail.com>; 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
Subject: Re: Revisiting aspect ratios in sizes

Hi all!

While I can appreciate the desire for native aspect ratio to be made available to web designers and developers, I don't think we should lose the freedom to distort an image like we currently can. Not only would this break a lot of existing sites, but not all images are artwork, and it may be desirable to display them larger than their native resolution as well! It would be nice to have an aspect-ratio property though - the three pieces of information CSS would need to be aware of for something like this to work would be the original native width and height, and the current width that the element was displaying at.

Check this out: I made a short video exploring a technique I use to create responsive aspect ratios in CSS https://www.youtube.com/watch?v=FcxCGjMNhcg



On Oct 4, 2016, at 4:00 PM, Hall, Charles (DET-MRM) <Charles.Hall@mrm-mccann.com<mailto:Charles.Hall@mrm-mccann.com>> wrote:

It seems this entire conversation thread assumes that the aspect ratio of
the source will always be equal to the target display aspect ratio.
This to me is a very dangerous assumption.
Of course the use case to distort the aspect ratio of a bit map by
unconstrained scaling is a generally unwanted and unwise edge case. But it
is far from the only one.
Art direction is the reason that the cover and contain values exist for
the background-size CSS property.
It is a contributing factor for why CSS and SVG clipping exist.
Art direction is the reason that Responsive Images evolved to account for
it.
Anyone remember letterbox?
There will always be the case where the aspect ratio needs to be
conditionally modified based on context and not based solely on original
source.

Am I off topic?


Charles Hall
UX Architect, Technology

t / 248.203.8723  m / 248.225.8179
e / charles.hall@mrm-mccann.com<mailto:charles.hall@mrm-mccann.com>
skype / charles.h.all
280 N Old Woodward Suite 300, Birmingham MI 48009
w / www.mrm-mccann.com<http://www.mrm-mccann.com/>


Creativity. Technology. Performance.





On 10/4/16, 3:25 PM, "steve@steveclaflin.com<mailto:steve@steveclaflin.com>" <steve@steveclaflin.com<mailto:steve@steveclaflin.com>>
wrote:


And in my opinion, one of the most fundamental implementation rules is
that the implementation should never prevent you from doing anything the
spec says you can do.  I see too much activity in the web world already
that falls into the "the use cases I know are the only ones that will
ever exist" category.

But, one thing you mentioned is the source aspect ratio.  It would be
nice if whatever CSS spec comes from this exercise allowed for something
to be specified as having an aspect ratio that is defined by the source,
not by the coder. i.e., some sort of "native" aspect ratio. While that
could prevent on-screen sizing until after the item has been received,
it may be necessary in some situations, such as where the image source
is variable at runtime.

On 2016-10-04 13:26, Paul Deschamps wrote:

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<mailto: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 [1]

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<mailto: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<mailto:gwhit@microsoft.com>>
wrote:

I also created a repo with issues that were actioned at the
meeting:

https://github.com/WICG/aspect-ratio [2] [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<mailto:jason@cloudfour.com>>
CC: public-respimg@w3.org<mailto: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/ [3] [2]

On Tue, Oct 4, 2016 at 1:19 PM, Jason Grigsby <jason@cloudfour.com<mailto: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<mailto: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<mailto: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.h

tml

[4]
[3]

The discussion was started here:


https://discourse.wicg.io/t/shorthand-for-width-height-css-longhands/1160

/26

[5]
[4]

Also CSSWG thread:
https://lists.w3.org/Archives/Public/www-style/2016Sep/0046.html

[6] [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<mailto: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 [7] [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 [8] [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 [9]
[8]

Happy hacking,

Tommy

On Sep 21, 2016, at 1:44 AM, Jason Grigsby <jason@cloudfour.com<mailto: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


[10]
[9]

[^2]:
https://github.com/ResponsiveImagesCG/picture-element/issues/85

[11] [10]

[^3]:
https://github.com/ResponsiveImagesCG/picture-element/issues/86

[12] [11]

[^4]: https://www.ampproject.org/docs/guides/amp_replacements.html

[13]
[12]

[^5]:


https://medium.com/@owencm/designing-great-uis-for-progressive-web-apps-d

d38c1d20f7#.hzxdz4z7d

[14]
[13]

[^6]:
https://lists.w3.org/Archives/Public/www-style/2016Jun/0072.html

[15]
[14]

[^7]:
https://lists.w3.org/Archives/Public/www-style/2016Jun/0091.html

[16]
[15]

--

+1 (503) 290-1090 [16] o | +1 (503) 502-7211 [17] m |
http://cloudfour.com [17] [18] | @grigs

--

+1 (503) 290-1090 [16] o | +1 (503) 502-7211 [17] m |
http://cloudfour.com [17] [19] | @grigs

Links:
------
[1] https://github.com/WICG/aspect-ratio [2]
[2] https://blog.yoav.ws/tpac_2016/ [3]
[3]

https://jonathankingston.github.io/logical-sizing-properties/demo/index.h

tml

[4]
[4]

https://discourse.wicg.io/t/shorthand-for-width-height-css-longhands/1160

/26

[5]
[5]
https://lists.w3.org/Archives/Public/www-style/2016Sep/0046.html [6]
[6] http://codepen.io/tomhodgins/pen/PZqaLm [7]
[7] http://codepen.io/tomhodgins/pen/XKJpYr [8]
[8] http://codepen.io/tomhodgins/pen/bwwNRr [9]
[9]
https://lists.w3.org/Archives/Public/public-respimg/2014Oct/0043.html


[10]
[10]
https://github.com/ResponsiveImagesCG/picture-element/issues/85 [11]
[11]
https://github.com/ResponsiveImagesCG/picture-element/issues/86 [12]
[12] https://www.ampproject.org/docs/guides/amp_replacements.html

[13]
[13]

https://medium.com/@owencm/designing-great-uis-for-progressive-web-apps-d

d38c1d20f7#.hzxdz4z7d

[14]
[14]
https://lists.w3.org/Archives/Public/www-style/2016Jun/0072.html

[15]
[15]
https://lists.w3.org/Archives/Public/www-style/2016Jun/0091.html

[16]
[16] tel:%2B1%20%28503%29%20290-1090
[17] tel:%2B1%20%28503%29%20502-7211
[18] http://cloudfour.com/ [18]
[19] http://cloudfour.com [17]



Links:
------
[1] http://www.steveclaflin.com/blog-stuff/html/scalable-video.html

[2] https://github.com/WICG/aspect-ratio

[3] https://blog.yoav.ws/tpac_2016/

[4]

https://jonathankingston.github.io/logical-sizing-properties/demo/index.h

tml
[5]

https://discourse.wicg.io/t/shorthand-for-width-height-css-longhands/1160

/26
[6] https://lists.w3.org/Archives/Public/www-style/2016Sep/0046.html

[7] http://codepen.io/tomhodgins/pen/PZqaLm

[8] http://codepen.io/tomhodgins/pen/XKJpYr

[9] http://codepen.io/tomhodgins/pen/bwwNRr

[10]
https://lists.w3.org/Archives/Public/public-respimg/2014Oct/0043.html

[11] https://github.com/ResponsiveImagesCG/picture-element/issues/85

[12] https://github.com/ResponsiveImagesCG/picture-element/issues/86

[13] https://www.ampproject.org/docs/guides/amp_replacements.html

[14]

https://medium.com/@owencm/designing-great-uis-for-progressive-web-apps-d

d38c1d20f7#.hzxdz4z7d
[15] https://lists.w3.org/Archives/Public/www-style/2016Jun/0072.html

[16] https://lists.w3.org/Archives/Public/www-style/2016Jun/0091.html

[17] http://cloudfour.com

[18] http://cloudfour.com/


This message contains information which may be confidential and privileged. Unless you are the intended recipient (or authorized to receive this message for the intended recipient), you may not use, copy, disseminate or disclose to anyone the message or any information contained in the message.  If you have received the message in error, please advise the sender by reply e-mail, and delete the message.  Thank you very much.