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>*
