You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Add CSS classes to root views to target platform/device/orientation/modals #7313
Describe the solution you'd like
This came up as a request from @bundyo based on the re-work of the NativeScript theme. The idea is to add a CSS class to the root view of the application for specific states. This would allow much more flexible theming and styling. Here is a list for the app root view:
default
.ns-root
platform
.ns-ios
.ns-android
device type
.ns-phone
.ns-tablet
orientation
.ns-portrait
.ns-landscape
os theme mode (optional)
.ns-os-dark or .ns-dark
.ns-os-light or .ns-light
We should also add a class to the root view of any modal view
default
.ns-modal
Describe alternatives you've considered
The alternative, which was used until now, is to have state specific files, e.g. app.android.css, app.ios.css, app.land.css. The problem with these is they can't be chained, there are no device type specific and modal ones (and don't work with webpack).
@NathanaelA Yep, we are aware of the plugins, they are great and they were part of the reason why these weren't added in the core of NativeScript. They would still be very useful for the additional specific classes. Now, with the re-work of the theme, it came up that we might need the classes listed above to come from the core, so that the plugins are not a requirement for the core theme.
The .ns-root one makes sense if you consider web-mobile shared apps. The .ns-modal one is exactly for the purposes of the theme.
There is a point in not needing the .ns-portrait and .ns-phone, but ultimately, I think it's better to have them. I don't think performance would be a problem and having more options for specificity is always good. Perhaps @bundyo can also share his thoughts.
The idea of .ns-root isn't about cross-platform, but more about cross-technology. For now, the only two platforms we support are android and ios. If another comes up, we will add more classes.
We would like to release this for 6.0, but I don't think we can commit and guarantee it for sure.
Regarding the rest of the classes that are provided by the plugins, I think it would be better if they stay in a separate plugin as they are. Is there a problem with the users getting them from a plugin?
I think Marto already said everything that is to say. I will add some notes:
We rather need .ns-root to set any inheritable properties on the root of the app, as it is not guaranteed anymore that it will be a page.
The sizing groups system is rather sub-optimal as classes and maybe should remain as a plugin until proper media query support gets implemented.
The notch has a point, but there are devices with weird notches on the sides for instance. Also .notch and softnav can be merged to something like .notch-top, .notch-bottom.
The device name classes are an overkill for sure. 🙂
Great to see that these were merged in! It looks like ns-os-dark and ns-os-light didn't make the cut though. Is there a reason they were left out, or will they be added in a future release?
This issue is a bit misleading, since the dark mode support is a completely different feature - the classes would be ns-light/ns-dark and would arrive with {N} 6.2. The classes are the same as the ones the Theme uses, so that they will initiate auto dark/light mode switching.
Activity
NathanaelA commentedon Jun 5, 2019
MartoYankov commentedon Jun 6, 2019
@NathanaelA Yep, we are aware of the plugins, they are great and they were part of the reason why these weren't added in the core of NativeScript. They would still be very useful for the additional specific classes. Now, with the re-work of the theme, it came up that we might need the classes listed above to come from the core, so that the plugins are not a requirement for the core theme.
The
.ns-rootone makes sense if you consider web-mobile shared apps. The.ns-modalone is exactly for the purposes of the theme.There is a point in not needing the
.ns-portraitand.ns-phone, but ultimately, I think it's better to have them. I don't think performance would be a problem and having more options for specificity is always good. Perhaps @bundyo can also share his thoughts.NathanaelA commentedon Jun 6, 2019
MartoYankov commentedon Jun 6, 2019
The idea of
.ns-rootisn't about cross-platform, but more about cross-technology. For now, the only two platforms we support are android and ios. If another comes up, we will add more classes.We would like to release this for 6.0, but I don't think we can commit and guarantee it for sure.
Regarding the rest of the classes that are provided by the plugins, I think it would be better if they stay in a separate plugin as they are. Is there a problem with the users getting them from a plugin?
bundyo commentedon Jun 6, 2019
I think Marto already said everything that is to say. I will add some notes:
NathanaelA commentedon Jun 6, 2019
vchimev commentedon Aug 19, 2019
A sample for orientation styling:
vchimev commentedon Aug 19, 2019
Available with
tns-core-modules@next, to be officially released with 6.1.0.lsapan commentedon Oct 22, 2019
Great to see that these were merged in! It looks like
ns-os-darkandns-os-lightdidn't make the cut though. Is there a reason they were left out, or will they be added in a future release?bundyo commentedon Oct 22, 2019
This issue is a bit misleading, since the dark mode support is a completely different feature - the classes would be
ns-light/ns-darkand would arrive with {N} 6.2. The classes are the same as the ones the Theme uses, so that they will initiate auto dark/light mode switching.vchimev commentedon Oct 23, 2019
Dark Mode support tracking issue: #7800.