No query stored in breakpoint variable about breakpoint HOT 23 CLOSED

My concern with this isn't that we couldn't figure out a way to do this, but rather that being able to do this encourages bad practices when it comes to media queries. Specifically this feature I fear would encourage people to do precisely what you've suggested and define a desktop breakpoint of sorts and build out device-specific media queries (or media queries based on device sizes) without working through the subtleties that are inherit in RWD. Best practices and best mental models are why, for instance, the default media type is all and not screen, why we default you to mobile first MQs, and why we call our no-query support no-query support instead of something like old IE support which were the only user stories we got to build that request. That, or I'm waxing much too philosophical for this early in the morning right after I got up.

Either way. I can see the reason why this would be wanted, but I'm concerned it'll encourage a bad practices. If Mason can convince me otherwise, happy to build it out, otherwise (or possibly, in the mean time) I'd suggest you write a mixin wrapper that will find your No Query stuff in your Media Query definition and pass that all to Breakpoint (this was the interim solution we gave to everyone before we got no query support working, for instance).

On Oct 29, 2012, at 12:59 AM, Luke Brooker [email protected] wrote:

I have previously written my own mixins for breakpoints and had a similar solution for no query support where I would pass true or false to the mixin and that would decide whether or not that content was in included in the no-query/old-ie stylesheet.

I have got this mostly working with breakpoint, except there doesn't seem to be a way to store the $no-query variable in a breakpoint variable.

eg.

$gte-medium: 35em, all, true

That way I don't need to continuously write:

@include breakpoint($gte-medium, $no-query: true)

every time I have something at the medium breakpoint I can just write:

@include breakpoint($gte-medium)

It allows me to set all my breakpoints(with no query specificity) in my settings file incase I decide to change it or when I am working with other developers that don't know what styles should go to old ie etc they can just use the default breakpoint variables without worrying about it.

Is this possible at the moment? Am I missing something?

Thanks,
Luke

—
Reply to this email directly or view it on GitHub.

from breakpoint.

Thanks for your response, I can see how this may be used for some bad practices. Just to get more context of how I might be using it, would you consider this bad practice?

$lte-small              : max-width $breakpoint-medium - .1;
$lte-medium             : max-width $breakpoint-large - .1;
$lte-large              : max-width $breakpoint-huge - .1, true;
$e-medium               : $breakpoint-medium $breakpoint-large - .1, true;
$e-large                : $breakpoint-large $breakpoint-huge - .1, true;
$gte-small              : $breakpoint-small, true;
$gte-medium             : $breakpoint-medium, true;
$gte-large              : $breakpoint-large, true;
$gte-huge               : $breakpoint-huge;

And then style-no-query.scss would contain:

$breakpoint-no-queries: true;
@import "style";

I am fine to create a mixin if needed but I would like to know if there is a problem(bad practices) with my solution in the first place. I usually always develop from a mobile first perspective (using mostly $gte variables), but I have the other options there for specific use cases when there would be too much overriding to do from the bottom up. Once this is all done the no-query stylesheet only includes (almost) exactly what it needs and the default stylesheet doesn't have any of the no-query styles.

And if I want some styles just for no-query, I would write something like:

@if $breakpoint-no-queries {
  [no-query styles]
}

So yeah that is basically my exact use case for it. If it's not a good idea I am fine if it is not included in breakpoint.

PS. Good work on the breaking development podcast :)

from breakpoint.

Haha, thanks!

I will need to look at this more closely when my power is back and I'm at my computer. Hopefully tomorrow, but possibly not until Wed or Thurs. Mason, assuming you're better off, thoughts?

On Oct 29, 2012, at 6:48 PM, Luke Brooker [email protected] wrote:

Thanks for your response, I can see how this may be used for some bad practices. Just to get more context of how I might be using it, would you consider this bad practice?

$lte-medium : max-width $breakpoint-large - .1;
$lte-large : max-width $breakpoint-huge - .1, true;
$e-medium : $breakpoint-medium $breakpoint-large, true;
$e-large : $breakpoint-large $breakpoint-huge, true;
$gte-small : $breakpoint-small, true;
$gte-medium : $breakpoint-medium, true;
$gte-large : $breakpoint-large, true;
$gte-huge : $breakpoint-huge;

And then style-no-query.scss would contain:

```$breakpoint-no-queries: true;
@import "style";
I am fine to create a mixin if needed but I would like to know if there is a problem(bad practices) with my solution in the first place. I usually always develop from a mobile first perspective (using mostly $gte variables), but I have the other options there for specific use cases when there would be too much overriding to do from the bottom up. Once this is all done the no-query stylesheet only includes (almost) exactly what it needs and the default stylesheet doesn't have any of the no-query styles.

And if I want some styles just for no-query, I would write something like:

@if $breakpoint-no-queries {
[no-query styles]
}

So yeah that is basically my exact use case for it. If it's not a good idea I am fine if it is not included in breakpoint.

PS. Good work on the breaking development podcast :)

—
Reply to this email directly or view it on GitHub.

from breakpoint.

I've been w/o power so I couldn't look at this until now.

I think it's usually good to move these settings and configuration to the variable rather than the arguments list. In theory I'm for it. My concern is in keeping the syntax simple, discoverable, and forgiving. That said I think we can handle this and keep the syntax simple.

Each of our four arguments accept a different data type. So long as we don't add more arguments (a big "if") we should be able to accept non-named arguments and assign them to the appropriate internal variable based on the data type.

argument types:

@mixin breakpoint(number, string, or list, string, boolean, number)

Argument 1 will always need special handling. If argument 2 comes in as a boolean we can assign it to the $no-query argument.

What do you think @Snugug?

from breakpoint.

I think that if we're going to add this in (and while we're at it, media type), they should absolutely be named, something like 'media' 'screen', or 'no query' false. The we can sniff specifically for these making out life easier and the syntax for users more obvious.

On Oct 31, 2012, at 9:06 AM, Mason Wendell [email protected] wrote:

I've been w/o power so I couldn't look at this until now.

I think it's usually good to move these settings and configuration to the variable rather than the arguments list. In theory I'm for it. My concern is in keeping the syntax simple, discoverable, and forgiving. That said I think we can handle this and keep the syntax simple.

Each of our four arguments accept a different data type. So long as we don't add more arguments (a big "if") we should be able to accept non-named arguments and assign them to the appropriate internal variable based on the data type.

argument types:

@mixin breakpoint(number, string, or list, string, boolean, number)
Argument 1 will always need special handling. If argument 2 comes in as a boolean we can assign it to the $no-query argument.

What do you think @Snugug?

—
Reply to this email directly or view it on GitHub.

from breakpoint.

Coming over from Snugug/respond-to#9

@Snugug I think not building this feature because "people might use it wrong" is a bad reason. People will mis-use tools and we shouldn't avoid improving them as a consequence.

On the other hand, I think this would be a great DX improvement and I'll have @ChinggizKhan look in to taking the work he did in the above-referenced PR for Respond-to and moving it into Breakpoint directly.

from breakpoint.

I'm OK with adding it in, as long as they are explicit and not fuzzy declarations.

from breakpoint.

I agree. I just looked over the issue on respond-to and I think it makes sense to bring that over here.

from breakpoint.

Yeah--- I will look into where best to migrate the code over....

@Snugug , what do you mean by explicit v fuzzy?

from breakpoint.

I mean that if we're going to store no-query values and media values in the breakpoint variables, they need to explicitly be names as opposed to assuming that true/false/.#{no-query} is no-query or print/tv/handheld/screen are media values. Basically, I want something that looks like the following:

$bkpt: 'media' 'screen', 479px, 'no query' '.no-query';

Instead of

$bkpt: 'screen', 479px, '.no-query';

On Nov 15, 2012, at 6:22 PM, Ian Carrico [email protected] wrote:

Yeah--- I will look into where best to migrate the code over....

@Snugug , what do you mean by explicit v fuzzy?

—
Reply to this email directly or view it on GitHub.

from breakpoint.

It still needs to work with complex queries tho.

$bkpt: 300px min-width, 700 max-height, monochrome, 'media' 'screen', 'no query' '.no-query';

from breakpoint.

not an argument against @Snugug. just making sure we hit all use cases.

from breakpoint.

I agree entirely, although after going over the breakpoint code-- I do not see an easy way to insert this functionality.

Why you ask? Because of the current structure of the code, I can't find an easy method of going through and easily manipulating where and how a query gets built. As a no-query option will not be within the media query directly, and the media type must be first and not be within (), it becomes necessary to write these separate from the current foreach that loops over the media query and returns a string of the current query. Once we do that, we should remove the constant pushing around of extraneous variables (e.g. $media-string), as they will be built out separately.

What I propose:

• @Snugug, merge the current PR open on respond-to, so that this functionality can be used right now.
• Re-factor breakpoint to be able to do this functionality in the meantime, and give plenty of time to test / work the code
• Merge respond-to's code into breakpoint. While doing this, we can keep the functionality of sites currently using this stack, while merging code that is just as useful together.

Am I crazy today? I mean... it is Monday...

from breakpoint.

I think there's a simpler way to approach this than you're using right now. We're talking about testing the values of our initial arguments (as lists) for keywords as their first value. If we find 'media' or 'no query' then we can use the second value in that argument as the value for media or no-query. There's probably more to it, but that's the pattern I'm envisioning.

from breakpoint.

I agree completely--- and that is what I was thinking we should do. The problem is currently, the foreach loops over each item, and goes through those checks individually and adds them to the query line-- then returning just the current string for the query as it lies. If we go over the list, each time checking for the proper pieces (as in breakpoint-switch), then store those values (as in U2V0IHlvdXIgb3duIGRhbW4gY29udGV4dHMh). After that THEN we have the code to actually print out the code together. Which will allow easier support for ensuring 'media' is first, and the no-query value is set.

What I just outlined will touch most of the code, and do it by restructuring how it works now. I also don't know if it is desirable to "cache" these queries, so the code only has to be called once for each break-point--- honestly, I am not sure if that would help the process at all.

on a related note, I noticed last night that when I try and do a "device-pixel-ratio" query with another query, I get errors. I will test it again today to make sure I wasnt just being dumb, but if not I will add it to the issue queue.

from breakpoint.

interesting. I'll have to dive back into the code again myself. I'll try to find the time soon.

If you do find that drp thing is a bug, let us know, and add a test that recreates it in the queue. thanks!

from breakpoint.

I had a brainstorm last night how to do this. I'm going to write up the code today.

On Wednesday, November 21, 2012 at 10:16 AM, Mason Wendell wrote:

interesting. I'll have to dive back into the code again myself. I'll try to find the time soon.
If you do find that drp thing is a bug, let us know, and add a test that recreates it in the queue. thanks!

—
Reply to this email directly or view it on GitHub (https://github.com/canarymason/breakpoint/issues/27#issuecomment-10600715).

from breakpoint.

I have a branch with this working with the following caveats:

• You must include either 'media' or 'no query' (respectively) in your variable.
• Your 'media' must be the first item in your variable.
• Your 'no query' must not be the first item in your variable.
• The 'media' or 'no query' options you have in your vars override the input variables in the mixin

Example of using both media and no-query in var state:

$bkptMedia: 'media' 'tv', 561px;
$bkptQuery: 561px, 'no query' '.no-query';
$bkptAll: 'media' 'handheld', 'no query' '.no-query-2', 561px;
$bkptAll2: 'media' 'print', 'max-width' 561px, 'no query' '.no-print-q';

from breakpoint.

Just leaving a comment here to attach my PR with a proof of concept. The PR is NOT 100% ready as it is missing the prefixing--- but that will be easy enough to add once I get another spare 20-30 min.

Issue #29 is my PR, check it out.

from breakpoint.

Sorry about my absence here lately. I've been busy and a little sick. I'll do my best to catch up soon, I promise.

from breakpoint.

No worries--- gave me time to work on that refactor. Let me know if you have some questions on it..

from breakpoint.

And this is in 2.x.x ---> i.e. lets close this issue.

from breakpoint.

I'm closing this issue as it's in 2.x.x and we're in the final stretches leading up to that launch.

from breakpoint.