Actual Behavior:
How to reproduce
Iam also facing the same issue in iPad. layout-wrap will not work in safari. even i tried to use flex-wrap css properties still same issue in safari
I am also seeing a similar issue on desktop. While it does not prevent other aspects of Angular Material from working as expected, it would be great for this to be fixed given that this is highly important for making responsive sites and generally laying out websites properly.

(Safari Version 10.1.1 (12603.2.4))
**Edit: After further research I am only seeing this issue when using multiple flex percentage values in one row and when using multiple responsive flex classes/attributes in one row. It does appear to be happening regardless of whether I am using the attributes or the classes.
Example non-working code:
<div class="flex layout-row layout-wrap">
<div class="flex flex-gt-sm-30">
<h1>30%</h1>
</div>
<div class="flex flex-gt-sm-70">
<h1>70%</h1>
</div>
</div>
It appears as though the issue can be circumvented by using only one percentage value, like so:
<div class="flex layout-row layout-wrap">
<div class="flex">
<h1>30%</h1>
</div>
<div class="flex flex-gt-sm-70">
<h1>70%</h1>
</div>
</div>
This will maintain the 30%/70% divide when in a viewport wider than small, and once it reaches the small viewport the view changes appropriately.
+1
Related to #10345 and #10388 ...
Experiencing the same issue, I understand this is caused by a safari bug. I tried solving this by changing the -webkit-flex-basis to match the flex percentage, and it looks like it solved the issue.
This is an example of the bug http://plnkr.co/edit/qhi5xwYF5QRi5C9yGD2e?p=preview
This is the workaround- http://plnkr.co/edit/ebD73Qh5tIK538dWknl2?p=preview
What do you think? Is this a good solution or am I misusing flex-basis?
Not in 1.1.5 馃憥 :(
I can't upgrade material version without break my app on safari...
Any news?
馃憤
had really been hoping 1.1.5 was going to fix this, been stuck on 1.1.1 for a while now due to this, but then we are starting to prepare to upgrade to material 2 now :) still would be nice to update v1 and address some of the bugs recent versions have fixed elsewhere ;)
@andrew-cunliffe - if you prepare a focused Pull-Request fixing this issue, then I will work to get it merged into master.
So I went to look at fixing this (ran into a number of issues running the project and assume they are known - (1) conflicts in master package-lock.json so had to remove this file to perform npm install (2) out of date dependencies which mean running the project with Node 8 fails, when you update it builds and runs the tests but (3) the docs are not building locally due to an issue with parsing the params in the comments for directives etc etc...)
Anyhow that aside I took a different approach and found it was an issue with the layout.scss file... a change implemented to not use a dynamic value but force 100% width... however this change was a PR done by yourself for v1.1.2 - https://github.com/angular/material/pull/9572/files
Now I can see on that PR you have a few other issues (which if I had fully followed the chains here I might have found sooner...)
Based on there being several issues with this past PR I wonder what the best course of action is? I could submit a PR to undo that PR, which will fix Safari but I assume that PR was fixing a problem elsewhere?
What do you do in this situation, revert that change and consider that past PR and alternatives to fix it? Leave Safari broken? Something else?
Still not in this version... ??
Someone tested on safari with 1.1.6? Is it better or not?
@andrew-cunliffe I think that all of the NodeJS, package-log.json, and docs build issues have been fixed in 1.1.6 and master.
There are quite a number of open layout issues that are quite serious. I plan to take some time to review them all and decide upon a course of action.
There is some information on the root of this bug here: https://github.com/angular/material/issues/5345#issuecomment-267838710
This is a duplicate of https://github.com/angular/material/issues/10345 where the bug in Safari is identified and linked.
Most helpful comment
So I went to look at fixing this (ran into a number of issues running the project and assume they are known - (1) conflicts in master package-lock.json so had to remove this file to perform npm install (2) out of date dependencies which mean running the project with Node 8 fails, when you update it builds and runs the tests but (3) the docs are not building locally due to an issue with parsing the params in the comments for directives etc etc...)
Anyhow that aside I took a different approach and found it was an issue with the layout.scss file... a change implemented to not use a dynamic value but force 100% width... however this change was a PR done by yourself for v1.1.2 - https://github.com/angular/material/pull/9572/files
Now I can see on that PR you have a few other issues (which if I had fully followed the chains here I might have found sooner...)
Based on there being several issues with this past PR I wonder what the best course of action is? I could submit a PR to undo that PR, which will fix Safari but I assume that PR was fixing a problem elsewhere?
What do you do in this situation, revert that change and consider that past PR and alternatives to fix it? Leave Safari broken? Something else?