Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Breakpoints do not match the one in @angular/flex-layout #8928

Closed
probert94 opened this issue Dec 11, 2017 · 6 comments · Fixed by #9284
Closed

Breakpoints do not match the one in @angular/flex-layout #8928

probert94 opened this issue Dec 11, 2017 · 6 comments · Fixed by #9284
Assignees
Labels
needs: discussion Further discussion with the team is needed before proceeding P4 A relatively minor issue that is not relevant to core functions

Comments

@probert94
Copy link

Bug, feature request, or proposal:

Proposal, probably

What is the expected behavior?

The @angular/material2 README-file contains a link to @angular/flex-layout, so I expect, that the two libraries collaborate somehow and therefore share the same breakpoints.

What is the current behavior?

@angular/flex-layout defines xs as max-width: 599px (see Breakpoints), while @angular/material defines it as max-width: 600px (see Variables).
Same goes for sm (959px vs 960px).

What is the use-case or motivation for changing an existing behavior?

I would like to replace hardcoded max-width-statements in my code with scss-variables, however I am not sure, which breakpoints to use, since they differ (even if it's just 1px).

@josephperrott
Copy link
Member

@ThomasBurleson What are your thoughts for this? I interpretted it as the size begins at a breakpoint value, so the previous size would max out at breakpoint value - 1. Thoughts on which way we should go with it?

@josephperrott josephperrott added P4 A relatively minor issue that is not relevant to core functions responsive labels Dec 15, 2017
@ThomasBurleson
Copy link

ThomasBurleson commented Dec 19, 2017

@josephperrott - So I interpreted the breakpoint start as inclusive of the start value:

  • xs < 600 px , max-width = 599px
  • lt-sm < 600 px, max-width = 599px
  • sm >= 600px

If we consider the BreakPoint Diagram on Material Design, it does not clearly indicate which. Yet the authors do talk about amounts “under” a certain breakpoint; which implies the breakpoint includes the value.

@josephperrott
Copy link
Member

After speaking with the material design team, the breakpoints are inclusive of the start value as @ThomasBurleson noted.

This however is only an issue in the variables we have defined in scss, but is not an issue within the preferred BreakpointObserver.

@probert94
Copy link
Author

@josephperrott thanks for your effort.
For the BreakpointObserver, I am currently using ObservableMedia from @angular/flex-layout, so those breakpoints should be fine too.
The problem is only with some properties in SCSS (like toolbar-height), but it's not a big issue.
Btw.: Is it possible to access the _variables.scss inside my *.scss-files? At the moment I am defining my own variables, but it would be much better to reuse the one in @angular/material2.

Thanks :)

@alsami
Copy link

alsami commented Jan 8, 2018

I am having the same problem in an application. The toolbar resizes its height based on the width. When the width is greater than 600px the height equals 64px otherwise 56px. With the breakpoints from angular-flex-layout you cannot make changes to the given layout. Of course you can make your own media-queries to make this work but it'd be really awesome if the breakpoints were aligned according to the specs. Anyway thanks for the great work!

@angular-automatic-lock-bot
Copy link

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

This action has been performed automatically by a bot.

@angular-automatic-lock-bot angular-automatic-lock-bot bot locked and limited conversation to collaborators Sep 8, 2019
@mmalerba mmalerba added the needs: discussion Further discussion with the team is needed before proceeding label Mar 3, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
needs: discussion Further discussion with the team is needed before proceeding P4 A relatively minor issue that is not relevant to core functions
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants