HI Alex 2018-03-12 17:02 GMT+01:00 Alex Harui <aha...@adobe.com.invalid>:
> Hi Carlos, > > As I said in my last post, you are welcome to write different layout > classes. We don't all have to agree on "one right answer". There often > isn't one right answer. Code up what you want to see and document why you > like it. Our users will then be able to choose. We will probably not > sweep the entire framework and only use one. > > You approach is valid, but I'm pretty sure when you finish it, it will be > slightly larger and run slightly more code, and require a few more > browser/cpu cycles to run. But that's ok. That's why we'll probably keep > what we have now and users will be able to choose. > ok, I'm trying to do that right now. I'll let you know as I get a something working. > > 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. thanks! Carlos > > Thanks, > -Alex > > On 3/12/18, 3:44 AM, "carlos.rov...@gmail.com on behalf of Carlos Rovira" > <carlos.rov...@gmail.com on behalf of carlosrov...@apache.org> wrote: > > >Hi, > > > >I must say that I was wrong in some part of my argumentation. I though the > >problem was in UIBase setting up things like display:block, but after > >looking at layout code since Harbs pointed me try to duplicate it by my > >side I saw is the vertical layout what was setting the inline styles. For > >that reason removing the display :block code I found in UIBase, doesn't > >make effect (what makes me think what that code does really or if is dead > >code, anyway something to look in the future). > > > >So I tried to create my own layout in Jewel and only seeing what happen > >commenting the part where the hardcoded is setup and change to a className > >assignation. > > > >As a test I put the following rule in jewel.css > > > >.vertical-layout-padding-gap { > > display: block !important; > >} > > > >and that work right :). > > > >To make paddings and gap I think the right way is to separate in different > >rules one for the vertical layout and others for padding, gap, and so, > >using cascading, maybe I should use pseudo-selectors like :before and > >:after for first and last elements. > > > >In the end since Harbs thinks inline is right, and I'm in the opposite > >thinking. I can make my own layouts for Jewel. > >It's like CSS. basics I discussed in other thread, I think I'll not > >affected by that since although I'm extending basic, I'm using my own > >class > >selectors and html structure. > > > >If you're all right with this I think we can go this way. > > > >Let me know what do you think > > > >Thanks > > > >Carlos > > > > > > > >2018-03-12 11:39 GMT+01:00 Carlos Rovira <carlosrov...@apache.org>: > > > >> > >> 2018-03-12 11:29 GMT+01:00 Harbs <harbs.li...@gmail.com>: > >> > >>> > >>> Can you explain why you care about inline CSS? I’m not getting it. > >>> > >>> > >> As I get the basis of jewel and jewel theme working right, I want to > >>start > >> creating blog examples with the code and I know, people out there that > >> wants to see if we are a option for their problems will look at the > >>code we > >> produce. If they see lots of styles hardcoded, my presumption is that > >>will > >> not had a good feeling about us and its one thing that can make us not > >>be > >> elegible us their technology of choice. I want to avoid that. > >> > >> > >>> If find it much easier to understand inline CSS. It’s sometimes > >>>difficult > >>> to figure out what sets specific inline styles, but it’s also difficult > >>> sometimes to figure out what sets classes. Working through complex CSS > >>> style sheets and figuring out which sheet is setting what style and > >>>why is > >>> a *very* time consuming process. In my experience, style sheets makes > >>> debugging more difficult and not easier. > >>> > >>> > >> But that's where documentation comes in. If you see a clean html line > >> where a button tag has organized semantic class like "jewel button > >>primary > >> vertical-layout", that's for me better than lots of styles there. Then > >>in > >> docs you can see that vertical-layout stands for > >> > >> .vertical-layout > >> { > >> display: block; > >> } > >> > >> for that's more clear. The html more leaner. Maybe as you point, the > >> performance is not as good as inline, but don't think that will be > >>enough > >> to not consider all the benefits. In the end things goes to separate > >>html > >> from css, so I think that's the principal pattern and browser devs has > >>in > >> mind to get performant css. > >> > >> > >> -- > >> Carlos Rovira > >> > >>https://na01.safelinks.protection.outlook.com/?url= > http%3A%2F%2Fabout.me% > >>2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com% > 7C4e82b3ca849c44dc4a9408 > >>d5880657b1%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0% > 7C63656448354452207 > >>6&sdata=nn%2B5FpOQnNAYN5SdSdSTZ99WhKgGKhOse3w5S7ct2Vc%3D&reserved=0 > >> > >> > > > > > >-- > >Carlos Rovira > >https://na01.safelinks.protection.outlook.com/?url= > http%3A%2F%2Fabout.me%2 > >Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com% > 7C4e82b3ca849c44dc4a9408d5 > >880657b1%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0% > 7C636564483544522076&s > >data=nn%2B5FpOQnNAYN5SdSdSTZ99WhKgGKhOse3w5S7ct2Vc%3D&reserved=0 > > -- Carlos Rovira http://about.me/carlosrovira