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
