If you are trying to override the values, you probably need different beads.
There’s no other well known framework which builds HTML from code. At best they stick pseudo-code inside HTML. That’s a huge difference between Royale and anything else. > On Mar 12, 2018, at 12:17 AM, Carlos Rovira <[email protected]> wrote: > > Hi Harbs, > > but you are losing one important point here: When I try to override the > value with CSS I can't since style is always take before my css. > So my styles in my theme are not valid due to the styles in the framework. > And more over, did you see only one example out there in any well-known ui > framework that puts styles in the components hard-coded? > > > 2018-03-11 22:43 GMT+01:00 Harbs <[email protected]>: > >> Display:block is almost always the right choice. It’s set in the Layout >> bead. >> >> I don’t agree on “clean” HTML. The only reason to use css classes is to >> enable restyling (i.e. skinning) of an ap with different CSS sets. >> Otherwise, inline CSS is probably more efficient than css files. >> >>> On Mar 11, 2018, at 7:18 PM, Carlos Rovira <[email protected]> >> wrote: >>> >>> Hi, >>> >>> coming back to this topic. I think is important, and that it deserves its >>> own thread like I said in other one covering this and other topics. >>> >>> Current problem: In jewel button display is set to "inline-block", but >>> since there's a default style, this make this assignment unused (appears >>> strike out in browsers, since style="display:block" takes precedence. >> This >>> happens in all through any royale app what I think is something bad. I >>> think this is serious right? >>> >>> Another side effect is that we should no create any "style" in html tags >>> due to: >>> >>> * bloated code (anyone looking at the html code we produce will see this >>> problem and will think in this as a "bad point" for us) >>> * as I notice, all styles in that tags takes precedence. And the last >> word >>> should be in devs hands, not in royale framework devs hands. >>> * if you see demos from other ui frameworks like material, semantic, >> etc.. >>> you'll never site ugly style attributes in any tag through all the demo, >>> and they do what we do, so we can't say, "we must use style tags since >>> there's no other way to do that". I think that's not true. This should be >>> what "Core" or "Basic" CSS should do. "Basic" should not say nothing >> about >>> font sizes, colors, backgrounds, etc.. but should do things like assign >>> display, other needs more near to the framework code. >>> >>> I propose to start looking to display:block to see how to remove, and >> then >>> progress to other styles like white-space: nowrap, margins, paddings...so >>> we can end seeing no "style" attribute set by our framwork. >>> >>> So centering on display:block only: I'm trying to find where is the line >>> where the framework assigns "display: block" to all components to find >>> alternatives. >>> I think it should be in Basic, but after comment all lines where I see >> this >>> kind of assignament it still appears. Could someone point me to the line >>> where this happen? >>> my thinking on this particular assignment is that it could remove from >> all >>> components easily. >>> >>> >>> thanks >>> >>> -- >>> Carlos Rovira >>> http://about.me/carlosrovira >> >> > > > -- > Carlos Rovira > http://about.me/carlosrovira
