Viewport characteristics media features
Christopher Schnick
crschnick at xpipe.io
Sun Jul 13 01:46:02 UTC 2025
Yeah that would definitely improve the situation when it comes to
repetitiveness. Would I need to define such custom media queries per
stylesheet or can they apply globally?
On 12/07/2025 20:24, Michael Strauß wrote:
> Maybe @custom-media queries can get you part of the way there:
> https://www.w3.org/TR/mediaqueries-5/#custom-mq
>
> So instead of repeating a media query multiple times, you can define a
> custom media query like this:
> @custom-media --sm (width >= 40);
>
> And use it with the regular syntax:
> @media (--sm) {
> // ...
> }
>
> On Sat, Jul 12, 2025 at 8:13 PM Christopher Schnick
> <crschnick at xpipe.io> wrote:
>
> Assuming this would be available, I would implement custom css
> breakpoints to refer to common layout changes for our application.
> This would prevent a lot of repetition. For example, something
> similar to the tailwindcss breakpoints:
>
>
> I could also use it to define more advanced breakpoint conditions
> that are not possible to achieve with just css expressions.
>
> In general, having the media queries only available in css is also
> limiting for many more advanced customizations. If I want to for
> example subscribe to a certain states, e.g. when the width crosses
> a certain breakpoint, to run a listener that changes some node
> properties.
>
> Custom media queries can also just be implemented using a listener
> that sets pseudo class states on the root node for each scene.
> However, always found it annoying having to specify something like
> .root:xl .button {} to replicate these breakpoints. If there was
> such a thing as recursive pseudo classes that would allow querying
> them in css via .button:xl when they are only set for a parent or
> root node, that would work as well as an alternative.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250713/9cce3b31/attachment-0001.htm>
More information about the openjfx-dev
mailing list