Re: Revisiting aspect ratios in sizes

Hi Guys,

My point was only to be aware of other considerations.  Yes, you can
enlarge image by increasing the dpi but there comes a point where the image
becomes blurred so decisions should be made on quality vs size.  However,
manipulating a colour is rather different than a Jackson Pollock and even
with his paintings there is a structure however obscure to the naked eye.
All I'm asking are just asking that we are not minimalists and recognise
that we are dealing with content as well as a concept.

I spent a considerable amount of effort interrogating images and storing
the dimensions and file sizes for every image large or small.  I suppose I
should miss the height and width in the picture element, but I don't whats
more subjective is determining the break-points.  All I would really like
is both vertical and horizontal alignment of the image with its parent
container.  From an Artist's point of view, they are certainly delighted
with all your efforts.  So thank-you.

Kind regards


Simon

On 4 October 2016 at 21:23, Tommy Hodgins <tomhodgins@gmail.com> wrote:

> 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> 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
> skype / charles.h.all
> 280 N Old Woodward Suite 300, Birmingham MI 48009
> w / www.mrm-mccann.com
>
>
> Creativity. Technology. Performance.
>
>
>
>
>
> On 10/4/16, 3:25 PM, "steve@steveclaflin.com" <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> 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>
> 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 [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 <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/ [3] [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.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>
> 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>
> 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.
>
>
>