-
Notifications
You must be signed in to change notification settings - Fork 3.4k
mdListItem: rendering problem with WebKit (angular-material >= 1.1.0-rc2) #8094
Comments
@devversion - Can you investigate? |
* The height of 100% for the secondary item container was depending on its parent DOM structure. So in some weird cases, the secondary item container was reserving 100% height of the screen. Fixes angular#8094.
* The height of 100% for the secondary item container was depending on its parent DOM structure. So in some weird cases, the secondary item container was reserving 100% height of the screen. Fixes angular#8094.
@igdtl Thanks for the issue, you're right - it's a bug and it's caused by the secondary item container, which expects a height of 100%. The problem is, that those 100% are in some cases not in relative to the actual list-item, which causes the 100% to use the screens 100%. This issue was introduced in a previous commit, which made the secondary items static. The relevance of that feature was really high, because this fixes some huge issues with the overflow on list-items. Also we've removed the behavior of wrapping all content inside of a button, this actually made the list-item usable with Firefox. Before of that, items inside of a list-item were not clickable, because Firefox and IE are blocking pointer events inside of a button (our wrap) So actually there was a lot of improvement in the |
Thanks! @devversion |
* Currently the secondary container was pushed to the end of the list-item by using a flex element with auto. This is causing issues with custom content of developers, because the flex filler has a high priority and reserves space. * This can be fixed, by using a margin auto, which has a lower priority and isn't reserving any space. This allows the user to style the content himself and we won't interfere. * The height of 100% for the secondary item container was depending on its parent DOM structure. So in some weird cases, the secondary item container was reserving 100% height of the screen. This property even became unnecessary, because now the secondary items are expecting its size correctly and will fill the remaining space by the auto margin. Fixes angular#8094. Fixes angular#7976.
* Currently the secondary container was pushed to the end of the list-item by using a flex element with auto. This is causing issues with custom content of developers, because the flex filler has a high priority and reserves space. * This can be fixed, by using a margin auto, which has a lower priority and isn't reserving any space. This allows the user to style the content himself and we won't interfere. * The height of 100% for the secondary item container was depending on its parent DOM structure. So in some weird cases, the secondary item container was reserving 100% height of the screen. This property even became unnecessary, because now the secondary items are expecting its size correctly and will fill the remaining space by the auto margin. Fixes angular#8094. Fixes angular#7976.
* Currently the secondary container was pushed to the end of the list-item by using a flex element with auto. This is causing issues with custom content of developers, because the flex filler has a high priority and reserves space. * This can be fixed, by using a margin auto, which has a lower priority and isn't reserving any space. This allows the user to style the content himself and we won't interfere. * The height of 100% for the secondary item container was depending on its parent DOM structure. So in some weird cases, the secondary item container was reserving 100% height of the screen. This property even became unnecessary, because now the secondary items are expecting its size correctly and will fill the remaining space by the auto margin. Fixes angular#8094. Fixes angular#7976.
It seems that this fix breaks
md-list-item
on WebKit browsers (tested with Chromium 48 and Safari 9.1)angular-material-1.1.0-rc1
angular-material-1.1.0-rc2
Note: not reproducible on Codepen / Fidle
The text was updated successfully, but these errors were encountered: