Carlos, Does your code with mentioned issue is in jewel branch ?
2018-03-12 10:15 GMT+01:00 Carlos Rovira <carlosrov...@apache.org>: > Hi Harbs, > > the frameworks I'm watching are MDL, Semantic and Bootstrap (all top > frameworks) to see what they do in different cases and guide me to find the > best way to implement the HTML Jewel should output in royale in Royale. All > of this frameworks are only HTML/JS/CSS (not builds from other code), but I > think that's not the point, since in the end both build front end > interfaces with controls and layouts > > So are you telling me that our output is better than theirs? That our way > of put somethings in the own html markup is better than theirs? I don't > think so, since they do the same but with better results: better optimized > and less weight html code. > > In the other hand, you are telling me to write a bead to override or > correct something the framework is hardcoding? I suppose you are referring > to a bead that removes all styles hardcoded, so that doesn't strikes out my > CSS styles... I think that's not the way to solve this. If I were making an > App maybe that's could be the solution as a workaround, but we are > framework developers, not users. > > I think that solution was good to start with, but now it demands to > refactor to something better. > > Harbs, are we trying to make the best framework out there? I think this > concrete point will make people reject us when they started to see the html > we product all bloated with styles, when that's not necessary and can be on > a "first level" CSS that be part of the lib code (not a theme) and be > included always. I think that's the right solution and we'll get the same > we have now but in the right insertion point. > > Thanks > > > 2018-03-11 23:19 GMT+01:00 Harbs <harbs.li...@gmail.com>: > > > 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 <carlosrov...@apache.org> > > 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 <harbs.li...@gmail.com>: > > > > > >> 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 <carlosrov...@apache.org> > > >> 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 > > > > > > > -- > Carlos Rovira > http://about.me/carlosrovira > -- Piotr Zarzycki Patreon: *https://www.patreon.com/piotrzarzycki <https://www.patreon.com/piotrzarzycki>*
