Can we usefully assign variables inside @media queries?

[dtgriscom]

Can you usefully set Stylus variables inside media queries? For example:

@media (min-width: 1000px) {
	scale = 1.5094339623;
}

unless scale is defined {
	scale = 1.0;
}

lcdWidth = 848px * scale;
...

I tried, and it seemed not to work, which makes sense (unless Stylus propagated the @media query everywhere the variable was used, which seems really verbose).

If it won't work, then the Stylus @media doc at https://stylus-lang.com/docs/media.html should mention that limitation.

[vendethiel]

Stylus is dynamically scoped. While this might sound like weird advice, if you need this kind of behaviour, it's probably better to use a CSS variable.

[slightlyfaulty]

I think this goes without saying. You can't set a compile-time variable with a runtime condition. That's what CSS custom properties are for.

[dtgriscom]

You can't set a compile-time variable with a runtime condition.

Well, you could, if Stylus did a lot of tapdancing. But, it would be easy to expand the output CSS quadratically with multiple, overlapping @media queries.

So, it's extremely reasonable that Stylus not do this, but it should probably be in the docs.

[slightlyfaulty]

No it's not a reasonable thing to expect. Setting a variable there isn't just setting one value. It's an expression that could be any number of functions and statements that need to be parsed and executed by the compiler. This one simple case might be technically possible, but anything more complex would fail miserably and be impossible to reason about. You won't find any CSS compiler that attempts to do anything like this, for good reason.

[dtgriscom]

So, you don't think this should be documented, as any reasonable user would understand this instinctively?

[vendethiel]

It's mentioned that Stylus is dynamically scoped, and everything comes down to that.

[slightlyfaulty]

So, you don't think this should be documented, as any reasonable user would understand this instinctively?

I'm not against it. But it should be something that explains the fundamental concept of what a CSS preprocessor does as a whole, rather than this one specific case. And I would encourage you to submit a PR if you feel strongly enough about including this in the docs.