Misleading API

[Jakub Sarnowski]

So when I'm doing a media.lessThan('1024px')) I'd expect the media query to look like: @media (max-width: 1023px) { }, because that's what the API states: lessThan. The same issue applies to greaterThan.

What I'd suggest here is:

1. Rename the functions to: lessThanOrEqual/greaterThanOrEqual
2. Make lessThan always substract 1 from passed value, and greaterThan add 1 to the value

We could also leave the API as is and add the -OrEqual variations.

What do you think about it?

[Tim Hagn]

Hi @sarneeh,

you've got a point there, thanks for spotting it, it isn't exactly grammatically / logically correct.

Though, at least in my humble opinion, duplicating the code to another function with one minor change would lead to code bloat - as we can't just take out lessThan, cause it might suddenly break some code out there (just had a look, styled-media-query is at 5,274 weekly downloads on npmjs % ).

Just changing the behavior of it wouldn't work for the same reason,
but this could be open for discussion in #11, methinks.

I'd rather go with a second parameter in generateMedia for the moment, making it possible switching back and forth to your suggested behavior. I'm thinking of a Boolean like capIntegers with a default of false here - so we could avoid mentioned code bloat or any breaking changes.

I'm interested in what the others or @morajabi think about it...

[Jakub Sarnowski]

@timhagn Obviously we do not want to change it as a minor version bump, as my suggestion is certainly a breaking change :) But I think it would be cool to consider this behavior in the next major. Also waiting for other to discuss this, thanks for your opinion 😃

[Tim Hagn]

@sarneeh Well, the Boolean could be done with a minor addition... But let's wait and see, what the others say, any ideas @ApacheEx, @brajabi or @morajabi? Definitely thnx for bringing it up : )!

[Oleg Kuzava]

I think we need to improve documentation instead of changing API.

To solve your issue, you can generate custom breakpoints with suffix min and max like bootstrap does (see https://getbootstrap.com/docs/3.4/customize/#media-queries-breakpoints)

[Tim Hagn]

Of course users can build their own workarounds, @ApacheEx, and i completely concur with your incentive to improve the docs on this matter - but I still think @sarneeh, has a Point there...
Edit: "on this matter" instead of "on this point" - I don't like duplication ; )

[Jakub Sarnowski]

@ApacheEx Of course, I can solve my issue with a workaround, but I'm pretty sure I'm not and won't be the only one who will expect from this library this kind of option. And we're building libraries to make our lives easier, aren't we? :) I think that the change is so small compared to what already has been done here that I think we shouldn't argue if it should be done at all but how to approach this problem 😄

[Andy Hook]

I think this is very important, currently if you perform a layout switch at a specific breakpoint using lessThan and moreThan you will have a 1px conflict zone where both sets of rules apply at the same time, yes you can write a workaround by I can't see a use case where someone would want this behaviour by default?

[Tim Hagn]

@andy-hook you're running through open doors on my side - that's one more point in favor of changing the API (though I'm still for the small addition of a Boolean so it won't break any production code before 3.0.0, see above ; ). Still waiting for an answer from @morajabi and I'd quickly implement it...

[Connor]

@andy-hook Can you tell me why you would have both a lessThan and a moreThan set at the same breakpoint? It seems like it could only be redundant. Any CSS outside of your lessThan is effectively a moreThan, and vice versa. Unsure why you would need both at the same breakpoint.

[Andy Hook]

@acnebs There are many reasons why you would structure your code this way, the method you suggest inherently relies on cascade / declaration order, by assuming code outside a lessThan block means it is moreThan would require that code to be declared before the the lessThan block, this causes compositional issues and also means you must overwrite that old value later inside another media query if you no longer need it.

A better approach is to apply style rules in size ranges, so that they only take effect when they are needed, this vastly simplifies managing complex layout as you don't have to keep resetting previously set rules, they also don't appear in your inspector and you can compose different classes together to apply responsive behaviour with complete confidence that their style code is only applied within the given media query range.

This is partially achievable using between but as soon as you attempt to chain a moreThan after that range you will have a 1px conflict zone.

[vitordino]

opinion: i think below, above and between both makes sense and are more compact to read. (i myself just use above on my libs and projects)

---

and as the use, i‘ve used both above('md') and above.md , i don’t recal if i ever used md.above
_{md being a name (key) of a breakpoint}

---

ref: griding’s above function

[Deleted user]

How about this for a syntax:

{
  huge: '1440px',
  large: '1170px',
  medium: '768px',
  small: '450px',
}

${below('medium')}              // max-width: 768px
${oneBelow('medium')}       // max-width: 767px
${above('medium')} .           // min-width: 768px
&{oneAbove('medium')}      // min-width: 769px

Or, perhaps something like this:

${below('medium')}              // max-width: 768px
${justBelow('medium')}       // max-width: 767.98px
${above('medium')} .           // min-width: 768px
&{justAbove('medium')}      // min-width: 768.02px