Skip to content

Add CSS classes to root views to target platform/device/orientation/modals #7313

Closed

Description

@MartoYankov

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

Additional Info
CSS Color Adjustment Module for Browsers (regarding dark/light mode in OS) - https://www.w3.org/TR/css-color-adjust-1/


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

Activity

  1. NathanaelA commented on Jun 5, 2019

    @NathanaelA
  2. MartoYankov commented on Jun 6, 2019

    @MartoYankov
    ContributorAuthor

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

  3. NathanaelA commented on Jun 6, 2019

    @NathanaelA
  4. MartoYankov commented on Jun 6, 2019

    @MartoYankov
    ContributorAuthor

    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?

  5. bundyo commented on Jun 6, 2019

    @bundyo
    Contributor

    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. 🙂
  6. NathanaelA commented on Jun 6, 2019

    @NathanaelA
  7. self-assigned this
    on Jul 24, 2019
  8. vchimev commented on Aug 19, 2019

    @vchimev
    Contributor

    A sample for orientation styling:

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

    orientation-styles

  9. vchimev commented on Aug 19, 2019

    @vchimev
    Contributor

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

  10. lsapan commented on Oct 22, 2019

    @lsapan

    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?

  11. bundyo commented on Oct 22, 2019

    @bundyo
    Contributor

    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.

  12. vchimev commented on Oct 23, 2019

    @vchimev
    Contributor

    Dark Mode support tracking issue: #7800.

  13. locked as resolved and limited conversation to collaborators on Oct 23, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions