Skip to content

Feature Request: Add css ability for other properties #1660

Closed

Description

@NathanaelA

Did you verify this is a real problem by searching

yes

Tell us about the problem

I'd like to be able to do

StackLayout {
  orientation: horizontal;
}

Which platform(s) does your issue occur on?

Both

Please provide the following version numbers that your issue occurs with:

v1.6x (and before)

Please tell us how to recreate the issue in as much detail as possible.

CSS does not appear to be able to set orientation on StackLayout.

Grid: Rows, Columns, row, column, colSpan, rowSpan would also be nice to be able to control in CSS

Activity

  1. enchev commented on Mar 1, 2016

    @enchev
    Contributor

    Hey @NathanaelA,

    At the moment we are trying to avoid CSS properties that are supported only for specific components. For example you cannot set orientation for Button. Furthermore orientation is not valid CSS property name.

    [UPDATE]
    Maybe we should allow finally component specific properties to be available globally even they are supported only in some of the components (similar to browsers) and we can expose {N} specific properties with a -ns- prefix. For example:

    StackLayout {
      -ns-orientation: horizontal;
    }
  2. NathanaelA commented on Mar 1, 2016

    @NathanaelA
    Author
  3. enchev commented on Mar 2, 2016

    @enchev
    Contributor

    Hey @atanasovg, @hshristov, @ligaz, @tjvantoll what do you think? Should we:

    1. Expose CSS properties that will work only on some of the elements similar to browsers
    2. Expose custom CSS properties valid for NativeScript only with a -ns- prefix similar to other vendor prefixes: https://developer.mozilla.org/en-US/docs/Glossary/Vendor_Prefix
  4. atanasovg commented on Mar 2, 2016

    @atanasovg
    Contributor

    That's definitely an interesting discussion. As of now we do have properties that do not make sense for some views - for example font-size does not affect most of the views directly but rather the text-displaying ones. Still, if the property is inheritable - like the font-size one - then it is useful to apply it at root level and let interested descendants inherit and utilize the value. With that said:

    • My vote goes for adding CSS properties regardless of whether they are applicable to each view type or not.
    • IMO @NathanaelA has a point as to prefixing non-CSS standard properties with -ns-. Since {N} is the only CSS parsing engine such an additional separation seems artificial to me.
  5. tjvantoll commented on Mar 2, 2016

    @tjvantoll
    Contributor

    Before I get into specifics about the syntax, I’ll start by agreeing with @NathanaelA that this is a very important use case that I’ve also wanted. @NathanaelA’s orientation plugin for instance is slick, but I find that the biggest thing I want to change is the orientation of a <StackLayout>, or the rows/columns of a <GridLayout>, which currently you can’t do in CSS. Beyond orientation, this opens the door for things like media queries in the future. I’d love to be able to say, for instance, column B takes up 50% of the screen on phones, but 75% of the screen on tablets—and to do so in CSS.

    My vote goes for adding CSS properties regardless of whether they are applicable to each view type or not.

    +1. The browser has set the precedent here. For example, the browser’s list-style property makes no sense outside of a <ul>; table-layout only applies to <table>s; etc.

    IMO @NathanaelA has a point as to prefixing non-CSS standard properties with -ns-. Since {N} is the only CSS parsing engine such an additional separation seems artificial to me.

    I could go either way on this one. The semantics aren’t all that important to me as long as we provide something that allows me to accomplish the task. I will note, however, that we’re already broken this rule in a way—our horizontal-align property isn’t a thing in CSS 😀

  6. self-assigned this
    on Mar 16, 2016
  7. added this to the milestone on Mar 16, 2016
  8. lock commented on Aug 30, 2019

    @lock

    This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

  9. locked and limited conversation to collaborators on Aug 30, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Type

No type

Projects

No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions