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
Feature Request: Add css ability for other properties #1660
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:
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.
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 😀
Activity
enchev commentedon Mar 1, 2016
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
orientationis 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:NathanaelA commentedon Mar 1, 2016
enchev commentedon Mar 2, 2016
Hey @atanasovg, @hshristov, @ligaz, @tjvantoll what do you think? Should we:
-ns-prefix similar to other vendor prefixes: https://developer.mozilla.org/en-US/docs/Glossary/Vendor_Prefixatanasovg commentedon Mar 2, 2016
That's definitely an interesting discussion. As of now we do have properties that do not make sense for some views - for example
font-sizedoes not affect most of the views directly but rather the text-displaying ones. Still, if the property is inheritable - like thefont-sizeone - then it is useful to apply it at root level and let interested descendants inherit and utilize the value. With that said:-ns-. Since {N} is the only CSS parsing engine such an additional separation seems artificial to me.tjvantoll commentedon Mar 2, 2016
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
orientationof a<StackLayout>, or therows/columnsof 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.+1. The browser has set the precedent here. For example, the browser’s
list-styleproperty makes no sense outside of a<ul>;table-layoutonly applies to<table>s; etc.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-alignproperty isn’t a thing in CSS 😀lock commentedon Aug 30, 2019
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.