Image being squashed on Safari #141
Assignees
Comments
|
Thank you for flagging this, @wayne-shih! |
|
I can confirm the issue the default browser on the other hand I can report that |
juliyvchirkov
added a commit
to juliyvchirkov/doctocat
that referenced
this issue
Feb 28, 2021
Fixes [primer#141](primer/design#141) This styled component imported on pageload by React engine and applied to the images included with tutorials on [primer.style](https://primer.style/) The component includes directive `max-width: 100%`, which prevents images to stretch to their original full width thus avoiding possible `overflow-x` and forcing images to be responsive In general this trick should be enough to achieve the goal, 'cause if image property `height` in css is not declared explicitly, by default it respects the state of property `width` and scales accordingly itself. This behaviour is taken as usual and almost like an axiom, since for a long time all common browsers have been treating this situation in the same way But current actual builds of `Safari` *v14.x.x* (the latest one for this moment is *14.0.3 16610.4.3.1.4*) break this idyll - due to some bug in `Safari` css interpreter, with this browser `height` property on images doesn't rely on `width` as usual This miss like a snowball leads to serious abnormalities fon the whole page render - since `height` is not deriving the proper scale from `width`, the css interpreter inspects the project's css rules for explicit declaration for `height` (or does not inspect indeed; this is only my guess, since this step is mandatory according to `css specifications`), and since there's no matching rule declared, `Safari` applies to `height` the default (initial) value, which for `height` property means the original image height in pixels This results in total mess on pages which utilize large images to illustrate text content. Since directive `max-width: 100%` clearly and undoubtedly by `css specifications` prevents images to stretch in width over main content area, `width` is rendered according to the limits declared by layout. But at the same time `height` is scaled to the original image height The consequences are ugly and disgusting, 'cause every large illustration on the page gets dreadfully stretched, and the page looks totally broken In upcoming `Safari` *14.2* this bug is already fixed and now for this moment it renders the same pages on [primer.style](https://primer.style/) correctly (this beta is available for download at [developer.apple.com](https://developer.apple.com/safari/technology-preview/) as `Safari Technology Preview` Release 120 / v14.2, WebKit 16612.1.2.6) The update in this commit overrides the destructive behaviour of actual builds of `Safari`, forcing image `height` property to follow `width` by explicit declaration of `height` value as `100%`.The value declared thru directive `height: 100%` is relative, so the css interpreter is forced to utilize the exact relative value for final calculations. And since `100%` for `width` property de facto is always bound by `max-width: 100%` to the limits of content area layout, `height` scales accordingly and the goal is achieved Inequality with existing and applied directive (`height` vs `max-width`) is affected by concept of web design per se. The width of pages has always been limited by the screen width, so `max-width` directive is reasonable and acceptable, while the scrollable concept of web pages turns the height attribute into the abstraction. In common cases this always leads `max-height: 100%` directive to be equal to original (full) height of an object and thus makes it useless
|
Is this still an issue? Seems to render fine for me on Safari 15. |
|
I can't replicate it anymore either. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
image on this page https://primer.style/design/tools/figma is being squashed on safari; appears normal on chrome + firefox.
I'm running Safari Version 14.0.3 (16610.4.2) on macOS Big Sur 11.2 Beta (20D5029f)
but also tested on Safari Version 13.1.2 (15609.3.5.1.3) on macOS Catalina Version 10.15.6 (19G2021) and it's the same thing...
The text was updated successfully, but these errors were encountered: