Nativescript: Support media queries in CSS

Created on 24 Apr 2015  路  31Comments  路  Source: NativeScript/NativeScript

_From @vakrilov on March 19, 2015 8:28_

Support for CSS media queries in the CSS. The issue is related to #154 and the propose is to allow more flexibility when targeting different devices with different resolutions.

_Copied from original issue: NativeScript/cross-platform-modules#203_


Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

backlog css medium

Most helpful comment

+1

There are a lot of things in the media queries spec, some of which apply to {N}, and some which don't. I think the most important ones to support are orientation, min-height/max-width, and min-height/max-height. I'd love to be able to use syntax like this in my apps:

@media (orientation: landscape) {
    button { width: 50%; }
}
@media (orientation: portrait) {
    button { width: 80%; }
}
@media (min-width: 700) {
    button { width: 20%; }
}

All 31 comments

+1

There are a lot of things in the media queries spec, some of which apply to {N}, and some which don't. I think the most important ones to support are orientation, min-height/max-width, and min-height/max-height. I'd love to be able to use syntax like this in my apps:

@media (orientation: landscape) {
    button { width: 50%; }
}
@media (orientation: portrait) {
    button { width: 80%; }
}
@media (min-width: 700) {
    button { width: 20%; }
}

@tjvantoll +1

I have figured out a way to do this now with the new 1.6 runtimes. Not as cleanly as the above example; but I can now create a lot of my visual style based on css and it the screen changes orientation has it automatically applies the proper css. The code is relatively simple and I've been using it to good use in one of my apps that I want to fully support P/L modes and look nice! If you guys are interested; I can do up a blog post to show how to do this.

If you guys are interested; I can do up a blog post to show how to do this.

I am very interested 馃榾

Actually I was able to abstract the pieces into a simple plugin that can handle the entire heavy lifting, and make it completely automated except for any item that can't be controlled by css. For that case; if you export a "orientation" function on any screen that needs it, it will be called when the page starts and any time it rotates, so that you can manually adjust any of those settings. I'm currently using it and it works very very NICELY. I'll try to get documentation and get this released this weekend. Ping me Monday, if I get busy and forget. :grinning:

@NathanaelA: Fantastic! Make sure to ping me when it鈥檚 ready so I can try it out.

The new http://github.com/nathanaela/nativescript-orientation plugin will allow you at least target when the orientation changes so that the CSS can be completely different based on Landscape or Portrait. You can target other size screens by using separate css files for the sizes.

Do you have plan to support min-device-pixel-ratio?

Any updated thinking on this item?

I have a scenario where I need to adjust styles for the big 12" iPad due to it's extra layout space, and media queries would be a perfect solution.

Obviously, I try to support with multiple files, but media queries would be cleaner. So just re-adding a +1 to this item. :)

I still think this one is quite relevant (especially in angular where the screen-size-qualifiers do not work: NativeScript/nativescript-angular#404).

It gets pushed back in the back log, due to more urgent issues though.

Got it. Good point on the Angular support/problem, too! Forgot about that.

Hopefully we can get it prioritized over the summer. Very powerful enhancement for efficiently supporting multiple screen sizes.

@toddanglin - Sounds like you need my NativeScript-scaledFonts plugin... ;-) It actually handles this really really well. It has several settings to help you deal with Phones and Tablets, including separate scaling systems for each if need be...

However, I don't know if it is 3.0 compatible yet...

If you watch the animation you can see; the right side is using my scaled plugin, the left side is default behavior. (BTW: The three bottom lines should have been scaled on the right side, but I did this demo before I even noticed (& fixed) that bug; and so I totally missed them. and I have been too busy to redo the demo yet...)

non-scaled

Oh, also I should mention my free NativeScript-Platform-CSS actually allows you to do this manually; it actually will allow you to create

.ios1024 {
  font-size: 22;
}
.ios414 {
  font-size: 16;
}
.ios {
font-size: 12;
}
.android380 {
  font-size: 10;
}

If you combine my nativescript orientation plugin above with this one you can even do:

.landscape.ios1024 {
  font-size: 20;
}
.ios1024 {
  font-size: 22;
}

And you will get 22 on a 1024 dpi screen in portrait and font size 20 in landscape... ;-)

@NathanaelA This look pretty neat.

Just a side note: When using DIPs, the size of the text will have (nearly) the same physical size, no matter the device. It is true that the text looks tiny in an iPad simulator, but keep in mind that it renders the 4" iPhone 5s screen and the 10" iPad screen with the same size on your monitor. If you run you app on an actual iPad you will probably want to have different layout instead of having a giant (5"-6" wide button). Of course it depends on the app you are building.

@vakrilov - Agreed; that is why my scaled fonts plugin actually allows two separate scaling systems (if need be), some apps I have done -- I want it to look identical no matter if it is a phone or a ipad. Everything just needs to be (in some cases much much) larger.

Other apps; I want the phones to scale one way and they use a phone xml file and then the tablets have their own xml file and they use an independent tablet scaling system where you set its starting break point and it scales all the tablets based on that information. This allows you to use the two different xml files to create unique layouts, and use two different scaling systems so that they look great no matter if the device is a phone or a tablet. ;-)

By combining NSF (ns-scaledFonts) with my free NPC (nativescript-platform-css), and my free NSO (nativescript-orientation) plugin I can make each screen look great no matter the resolution or device, or orientation; without doing a lot of manual work. But those who want 100% free can use the NPC with its media-dpi settings to do the same "font" sizing thing manually. I typically use the NPC to deal with my layout & image sizing at different dpi's where I need to tweak an image or some size of a button/layout for some reason.

The NSF is used to deal with all the font sizes; because I only have to set the font size once and make it look good on one phone at the base DPI (and tablet in some cases), and the font will automatically be scaled properly to every other device.

Media queries can also be used to apply different css rules for different platforms. That way we wouldn't have to create a new css file for each platform. For example:

````css
@media (platform : android) {
Label { text-align : left; }
}

@media (platform : ios) {
Label { text-align : center; }
}
````

Edit: for now I can use https://plugins.nativescript.rocks/plugin/nativescript-platform-css plugin, but it would be better if this were a core feature.

Edit2: No need for a plugin. You can use Nativescript's platform and device classes. Check this link. https://docs.nativescript.org/angular/ui/styling#root-views-css-classes

I also agree with @erkanarslan and think that FULL MEDIA QUERIES SUPPORT should be included as a core feature.

+1

Any update on this feature being implemented?

We really need this please add this to the roadmap!

Any updates on supporting this yet?

Any updates?

Any updates?

I'd also like to see this added to core 馃憤馃徎

With {N} 6.0 coming soon and defaulting to Webpack builds (which do not support the Core screen size qualifiers), it seems essential to now support some alternative method for specifying styles for different screen sizes (media queries or otherwise).

It's probably the right time to also consider deprecating this feature since it's increasingly unsupported on most flavors of {N} (and will not be supported in the 6.0 default path).

@toddanglin - Who said it (screen size qualifiers) wasn't going to be supported in NS6 via WebPack? If that is removed; that is a major breaking change, imho; I use it in several of my apps, because the tablet screen layout (.xml) file is different than the phone layout file...

I don't disagree with getting media queries -- however, NS-Platform-CSS can handle this extremely well....

@NathanaelA I don't think the support is being removed, per se, but {N} 6.0 will make Webpack builds the default build process for all new projects. So for any new projects starting with 6.0, or projects that choose to upgrade to Webpack, these filename conventions will not be available. As I such, I think it is probably time to offer a new, "official" way forward for handling the use cases once covered by file name conventions.

That said, the nativescript-platform-css plugin is a good workaround. Good point.

@toddanglin - Ah, good -- there is a bug report already in for this issue; so I hope that it is actually fixed because it is one of the better features that NS-Core offers over all the other flavors. :)

Any update on this?

The fix proposed by @NathanaelA has been depreciated for NS v6.7.4 and has been moved to a paid subscription model which just isn't viable for most developers.

Hi @radiohe4d, My plugin isn't depreciated for NS 6; it still fully works in NS 6; and I still use it in lots of projects -- but you are correct that the only one that I continue to maintain is the ProPlugins version. It fully supports all the latest versions of NativeScript, including the upcoming all new iOS v8 engine.

I'm also not sure why you think a paid subscription model doesn't work; ProPlugins has actually been quite successful in paying for all the maintenance to keep all these plugins top quality quite well -- the community appears to like it also, as they now have a source of high quality KNOWN WORKING plugins that they don't have to fix...

However, Brian, if your time really isn't worth the cost of a subscription -- I'm also fully behind the community trying to maintain any of these existing public plugins, I didn't remove any source, so that the community would have the option of being able to maintain it. So please feel free to use your own time and fix any of the issues you find and I'll happily merge the PR and push a new version with your changes to the open npm for those in the community actually willing to put their time towards fixing issues.

+1 This is really needed and has been on the backlog for a while now. Any timeline for implementing this yet?

Was this page helpful?
0 / 5 - 0 ratings