- From: Paul Deschamps <pdescham49@gmail.com>
- Date: Tue, 4 Oct 2016 14:26:42 -0400
- 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>
- Message-ID: <CACPLTHgMpFSJs+FUWz+DwC2krng3tj8yoNQ__vf6npwTPtbFVw@mail.gmail.com>
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