Just a FYI; NS-Platform-css (https://github.com/NathanaelA/nativescript-platform-css/tree/master/src) does add:
.android or .ios, .tablet Andoid/ios screen size ranges, model number, (i.e. .iphone6s) .notch, .softnav, etc... Your entire list plus more... 😀

And if you can use ns-orientation; it will add .landscape when in landscape -- so you can do things like

.ios .landscape .someotherclass { text-color: red; }
.ios .someotherclass { text-color: green; }
 Page.softnav .notch .android1280 { text-color: green; margin-bottom: 10; margin-top: 10; }

I'm not sure their is any point to adding .ns-root as it really doesn't actually tell you anything you didn't already know, and won't as far as I know it won't allow you to do any extra customization as that will cascade down through all the rules, so it seems like a pointless rule. 😀

.ns-modal is also pretty questionable; as the model screen should already have its own css file -- but I can see it for a global theme file... so that one could be slightly useful in that corner case 😀

Having a .portrait or a .phone is also extra information that normally doesn't help any; as if you do:

.somerule {
   all my rules for devices including phones
}
.tablet .somerule {
  special customization's for just tablets (& any overrides to the base rules)
}

You are able to handle both types of devices without adding more processing rules to the css engine to have to process on every element. Same thing with .portrait.

I wrote and have been using my NS-Platform-css/NS-Orientation since NS 1 days, I have NEVER ran into a situation where I felt I actually needed .portrait or .phone (and the reason the plugin supports so many things like .softnav, .notch is because I ran into situations where I needed that info in css). So it would have been trivial to add those extra qualifiers (.portrait, .phone); but sometimes the art of programming is knowing what not to add. 😀 -- So I would rethink if you actually need to pollute the css rules with extra qualifiers that don't actually give you really any more information than you already have and cost more processing time for the css engine...

@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.

Ah, good thought -- I didn't even think about non-mobile. Maybe that should be .ns-mobile rather than .ns-root. Eventually someone might make a "desktop" version of NS and can then use .ns-desktop. :-)

Any time line on if/when this will be added to core? (6.0? 6.2, 7.0)

If this really is being added to core; I would also recommend you plan on moving most of my plugin into core, so that you also add:

• sizing groups system (my poor mans version of media queries 😀); or finally actually add media queries support. 😀 The sizing groups are very very useful, especially on android as you frequently have different screen sizes that do fit inside the groups easily, but you don't want .android1280 .android1200, .android1184 to find out next week that you missed .android1248 and other weird screen size. Simpler just to have a .android1000 & .android1300 and cut the amount of "custom" css down to a couple groups of sizes...

• .notch - if the device has a notch, typically this allows you to do some custom css on full screen apps

• .softnav - If the device has a softnav / or home button (i.e. most new ios devices, many android devices) (same idea as .notch)

• Optionally (or perhaps a updated version of my plugin that removes whatever you add; could handle it) -> the actual device name. I have found it very useful in a couple cases to do .iphonex, .iphonexr, .iphonexsmax { /* some custom css */ } But this one might be out of scope -- but figured I would mention it, as totally eliminating another plugin from maintenance would be cool. 😀

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. 🙂

Well, the only reason I would recommend you move them is so that another plugin can be eliminated as core would take over its duties. 4 years later the NS team has finally decided I was right in my approach at this. 😀 Since you are already taking all primary pieces of the plugin, might as well take the other minor functions. 😀 Adding most of them into core should be rather trivial and just like I was right about the major ones for all these years, adding the minor ones is also the right thing to do. :-)

As for .notch, .softnav - I think that the names are more clear than notch-top/notch-bottom; .softnav has been an android term for a really long time, and so ios just recently added the same concept. So; I prefer .notch, .softnav still. 😀

As an aside; @bundyo -- I did a quick search for phones with side notches and couldn't find one. Any idea which phone you are talking about?

The sizing groups system is rather sub-optimal as classes and maybe should remain as a plugin until proper media query support gets implemented.

Sizing groups acts exactly like media queries (for the sizing part) so I would disagree with sub-optimal. All sizes from X to Y are lumped in .androidXXXX and .iosXXXX so allows you to catch all the devices 1024 to 1200 and treat them as one size, 1200 to 1400 as another; etc... There is even another plugin who took my code and made specific separate height and width versions, so obviously people want things like this... 😀

CSS media queries are the gold standard so it is obviously better to be supported, but it has been on the backlog since NS 2; so maybe something that can be EASILY implemented to move forward would be worth doing... Many times just accepting good enough is way better than accepting nothing at all. 😀

The device name classes are an overkill for sure

Yeah, when I got to that point; I realized that this might be the only reason to keep my plugin around. I don't need that support often, but it does come in handy.... However, if NS wanted to take it over; I would be very happy as that would eliminate another of my plugin into core so that I would no longer have to maintain it. 😀

A sample for orientation styling:

.ns-portrait > Page {
  background-color: orange;
}

.ns-landscape > Page {
  background-color: yellow;
}

Available with tns-core-modules@next, to be officially released with 6.1.0.

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.

Dark Mode support tracking issue: #7800.