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

Include "Mappy Breakpoints" #132

Closed
marcvangend opened this Issue Mar 26, 2015 · 6 comments

Comments

Projects
None yet
3 participants
@marcvangend

marcvangend commented Mar 26, 2015

Even though I have not extensively used it in production yet, I really like the ideas and logic I saw in the Mappy Breakpoints mixin by @zellwk. Most problems / annoyances he describes in his blog post, I experienced myself.

I think it would be a great idea if you could join forces and include the mappy breakpoints approach in breakpoint. I would rather write @include breakpoint(small large) than @include mappy-bp(small large) :-)

@Snugug

This comment has been minimized.

Show comment
Hide comment
@Snugug

Snugug Mar 26, 2015

Member

We've had the ability to have map based breakpoints for a while now (if I'm going to be specific, 2 years and 5 days) through respond-to. We abstracted out writing them as a map into function calls because we found that, once you started writing queries more advanced than a single number, or wanted to include or queries, it got a little bit weird to do by hand.

We have also had for almost Breakpoint's entire life the ability to output em based media queries. It's true that we don't support rems, but those aren't valid Media Query units and we're not in the base font size game, so we don't support them.

In terms of being able to do less than and greater than, it's something @codingdesigner and I have discussed. The issue we're currently facing with them (and with the rest of Mappy Breakpoints, specifically being able to combine media queries) is that Breakpoint allows for much much more than just min-width queries. How do complex queries get combined? What happens if there are competing definitions? What happens if there are too many definitions to resolve effectively? Or do we just restrict combining to only single number queries only when using a feature that supports min/max? If we can get those questions resolved, we're happy to add this functionality, but we've gotta figure that out first.

Member

Snugug commented Mar 26, 2015

We've had the ability to have map based breakpoints for a while now (if I'm going to be specific, 2 years and 5 days) through respond-to. We abstracted out writing them as a map into function calls because we found that, once you started writing queries more advanced than a single number, or wanted to include or queries, it got a little bit weird to do by hand.

We have also had for almost Breakpoint's entire life the ability to output em based media queries. It's true that we don't support rems, but those aren't valid Media Query units and we're not in the base font size game, so we don't support them.

In terms of being able to do less than and greater than, it's something @codingdesigner and I have discussed. The issue we're currently facing with them (and with the rest of Mappy Breakpoints, specifically being able to combine media queries) is that Breakpoint allows for much much more than just min-width queries. How do complex queries get combined? What happens if there are competing definitions? What happens if there are too many definitions to resolve effectively? Or do we just restrict combining to only single number queries only when using a feature that supports min/max? If we can get those questions resolved, we're happy to add this functionality, but we've gotta figure that out first.

@zellwk

This comment has been minimized.

Show comment
Hide comment
@zellwk

zellwk Mar 26, 2015

@Snugug I didn't realise there was a respond-to mixin. Glad I got to know it now.

By the way, Mappy breakpoints doesn't only work with width queries. It supports height queries and other properties as well. However, how the queries get combined may not be as comprehensive as what breakpoint has to offer.

Quick question: How do you calculate pixel to em based queries if you don't use a base for conversion?

zellwk commented Mar 26, 2015

@Snugug I didn't realise there was a respond-to mixin. Glad I got to know it now.

By the way, Mappy breakpoints doesn't only work with width queries. It supports height queries and other properties as well. However, how the queries get combined may not be as comprehensive as what breakpoint has to offer.

Quick question: How do you calculate pixel to em based queries if you don't use a base for conversion?

@Snugug

This comment has been minimized.

Show comment
Hide comment
@Snugug

Snugug Mar 26, 2015

Member

@zellwk em based media queries are not based on your site's font size, but rather the browser's default 16px === 1em ratio that's used by all browsers. As such, we can use that for our conversion.

Member

Snugug commented Mar 26, 2015

@zellwk em based media queries are not based on your site's font size, but rather the browser's default 16px === 1em ratio that's used by all browsers. As such, we can use that for our conversion.

@zellwk

This comment has been minimized.

Show comment
Hide comment
@zellwk

zellwk Mar 26, 2015

@Snugug what happens if users decide to change their font size such that 16px no longer equals to 1em? Say if they put font-size: 125% in the HTML.

It's been a big question I'm trying to answer when I wrote Mappy Breakpoints with a $base-font-size. Would be great to learn more, and see how to improve that.

zellwk commented Mar 26, 2015

@Snugug what happens if users decide to change their font size such that 16px no longer equals to 1em? Say if they put font-size: 125% in the HTML.

It's been a big question I'm trying to answer when I wrote Mappy Breakpoints with a $base-font-size. Would be great to learn more, and see how to improve that.

@Snugug

This comment has been minimized.

Show comment
Hide comment
@Snugug

Snugug Mar 26, 2015

Member

It doesn't matter. It's not based on that. It's based on the internal browser core font size, what that 125% is a percentage of. What you're changing when you change that is the display font size, not the browser's inherent font size. The way that changes (and why em based media queries are so useful) is if a user goes into a browser's settings and changes the font size there.

To change that inherent size yourself, go into chrome://settings/ -> Show advanced settings… -> Web content -> Font size. That's also where you change your default serif, sans-serif, and monospace fonts.

Member

Snugug commented Mar 26, 2015

It doesn't matter. It's not based on that. It's based on the internal browser core font size, what that 125% is a percentage of. What you're changing when you change that is the display font size, not the browser's inherent font size. The way that changes (and why em based media queries are so useful) is if a user goes into a browser's settings and changes the font size there.

To change that inherent size yourself, go into chrome://settings/ -> Show advanced settings… -> Web content -> Font size. That's also where you change your default serif, sans-serif, and monospace fonts.

@zellwk

This comment has been minimized.

Show comment
Hide comment
@zellwk

zellwk Mar 28, 2015

Ahhhh. Okay i get it. This means I didn't have to use $base-font-size and rem in the first place. I could have just stuck with em!

zellwk commented Mar 28, 2015

Ahhhh. Okay i get it. This means I didn't have to use $base-font-size and rem in the first place. I could have just stuck with em!

@Snugug Snugug closed this Feb 21, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment