Subclass, change it and remember to test as I pointed with some custom className setted in the example. See what happen.
Looking forward to the results. Thanks, Piotr 2018-03-12 19:30 GMT+01:00 Carlos Rovira <carlosrov...@apache.org>: > Hi Piotr, > subclass will be most to test the use of element.classList, a part from the > reverse order. I think element.classList will remove the need of much code > in jewel components about how to setup classes in those components > > 2018-03-12 19:27 GMT+01:00 Piotr Zarzycki <piotrzarzyck...@gmail.com>: > > > Since it is some kind of exception which you are trying to resolve, you > > should create beads (layouts) which indicates resolution for that > exception > > in their name. - At least that's how I think about PAYG. > > > > Btw. Sub classing UIBase to have an different order in className is a bit > > overkill to me. > > > > 2018-03-12 19:21 GMT+01:00 Alex Harui <aha...@adobe.com.invalid>: > > > > > Hi Carlos, > > > > > > These layout classes have worked fine for dozens of example. They are > > > small, simple and stupid. > > > > > > I don't understand why, if you want vertical layout, you want to set a > > > child's display to "inline-block". That would not layout vertically > > > unless you are counting in line-wrapping. To me, that is an exception > > > case, and extra code and an additional layout class is the PAYG way to > > > deal with it. > > > > > > To me, there is no excess HTML code because we do not generate much > HTML > > > at all! We do run a bunch of JS that creates HTMLElements, but that is > > > not tags in an HTML file that has to be parse by the browser, so other > > > than some opinion of what is "best", we need to run profiling to > > determine > > > the trade-offs. Harbs claims that having JS set the style object is > > > better than having JS set classnames. You will need to prove him > wrong. > > > > > > And still, I don't believe whether we use the style object or not is > > going > > > to cause people to not use Royale. We can clean this up later. > > > > > > My 2 cents, > > > -Alex > > > > > > On 3/12/18, 11:11 AM, "carlos.rov...@gmail.com on behalf of Carlos > > Rovira" > > > <carlos.rov...@gmail.com on behalf of carlosrov...@apache.org> wrote: > > > > > > >Hi Alex, > > > > > > > >no, I want the normal effect of a vertical layout, since finaly is get > > in > > > >both ways. > > > >The problem for me is : > > > > > > > >1) people that wants to change it must subclass layout to modify, > > instead > > > >of override css rule > > > >2) there's an excess of html code since in each component inside the > > > >layout > > > >the current approach with inline styles are generating the style > > attribute > > > >for all components, so this ends in bloated code that I don't see in > any > > > >example of UI sets out there > > > > > > > > > > > > > > > >2018-03-12 18:41 GMT+01:00 Alex Harui <aha...@adobe.com.invalid>: > > > > > > > >> > > > >> > > > >> On 3/12/18, 10:11 AM, "carlos.rov...@gmail.com on behalf of Carlos > > > >>Rovira" > > > >> <carlos.rov...@gmail.com on behalf of carlosrov...@apache.org> > wrote: > > > >> > > > >> >> > > > >> >> I still don't get why, if your Button is a subcomponent, some > > > >>framework > > > >> >> code was setting display style on it unless you were using a > layout > > > >> >>class > > > >> >> in the component itself. > > > >> >> > > > >> > > > > >> >that's the side effect of inline styling, as I put the button > inside > > a > > > >> >vertical layout, the layout imposes display: block > > > >> >while my css dictates display: inline-block. The browser shows the > > > >>later > > > >> >strikes out. For me that behavior can be right > > > >> >if I can change easily from CSS overriding rule, but not if is a > line > > > >>of > > > >> >code inside a framework that makes me override a whole class > > > >> >to change an inline style. > > > >> > > > >> Just to be sure I understand, your goal was to use vertical layout > but > > > >> make one child not layout vertically? Sort of like > "includeInLayout" > > in > > > >> Flex? > > > >> > > > >> Handling exceptions usually requires more code. So it sounds like > you > > > >>are > > > >> creating layouts that allow for exceptions, which seems like a > > > >>reasonable > > > >> thing to do. The existing layouts will be more simple (and > > essentially > > > >> stupid) but will do the job with the least code when exceptions are > > not > > > >> needed. > > > >> > > > >> That's how I understand it. > > > >> -Alex > > > >> > > > >> > > > > > > > > > > > >-- > > > >Carlos Rovira > > > >https://na01.safelinks.protection.outlook.com/?url= > > > http%3A%2F%2Fabout.me%2 > > > >Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com% > > > 7Ccfb1cb035125479752cb08d5 > > > >8844b0f1%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0% > > > 7C636564751009995999&s > > > >data=ULF%2BQF6eX22uPYf%2BgxjeJL6xIzk18iFBhuPI5Wgvwfo%3D&reserved=0 > > > > > > > > > > > > -- > > > > Piotr Zarzycki > > > > Patreon: *https://www.patreon.com/piotrzarzycki > > <https://www.patreon.com/piotrzarzycki>* > > > > > > -- > Carlos Rovira > http://about.me/carlosrovira > -- Piotr Zarzycki Patreon: *https://www.patreon.com/piotrzarzycki <https://www.patreon.com/piotrzarzycki>*
