On Thu, Oct 8, 2020 at 1:28 PM Yoav Weiss <
yo...@yoav.ws> wrote:
>
>
>
> On Wed, Oct 7, 2020 at 6:34 PM Christian Biesinger <
cbies...@chromium.org> wrote:
>>
>> Contact emails
>>
>>
cbies...@chromium.org,
chri...@chromium.org,
ikilp...@chromium.org
>>
>> Explainer
>>
>>
>>
https://docs.google.com/document/d/1VqD0mfkIDyCxQBrrvDw5wEbhXBsmEYIhk6ahiX_fvco/edit#
>>
>> Specification
>>
>>
https://drafts.csswg.org/css-sizing-4/#aspect-ratio
>>
>> Summary
>>
>> Normally, only certain replaced elements have an aspect ratio,
>> particularly images. For them, if only one of width and height is
>> specified, the other can be computed from it using the intrinsic
>> aspect ratio. This property allows explicitly specifying an aspect
>> ratio for any other element to get similar behavior.
>
>
> Will the aspect-ratio property also override the intrinsic aspect ratio in replaced elements?
> The explainer is not very detailed on that front...
The spec is clear on that. You told me that the explainer is more
about use cases and less about being a dumbed down spec :p
(The answer is that it will override it if using the "aspect-ratio:
1/1" syntax, but not if using the "aspect-ratio: auto 1/1" syntax.)
>
>>
>>
>>
>> Blink component
>>
>> Blink>Layout
>>
>> Search tags
>>
>> aspect-ratio, aspect, ratio
>>
>> TAG review
>>
>>
https://github.com/w3ctag/design-reviews/issues/559
>>
>> TAG review status
>>
>> Pending
>>
>> Risks
>>
>>
>>
>> Interoperability and Compatibility
>>
>> The risk (for both compat and interop) is that the layout will be
>> wrong in browsers that do not support this property. This can be
>> mitigated by web developers using polyfills.
>
>
> How polyfillable is this? Is there a known polyfill we can point developers towards?
I have not looked into this. I assume it can be polyfilled using
ResizeObserver. The AMP team has workarounds that work in specific
cases but is not completely general.
Christian