HI Alex,

2018-03-12 8:17 GMT+01:00 Alex Harui <aha...@adobe.com.invalid>:

> IMO some styles (padding, margin, font*) determine the "boxes", other
> styles (position, display) place the boxes.

I think almost the same

> The layouts will likely set
> position and display directly on the outer box of a component.

can this be done in "framework CSS"? instead of be hardcoded in HTML? (for
*directly on* you can be referring to inline in styles as we do, or in a
*framework CSS* (a CSS that's not part of a theme, but part of the
Basic.css and is included always as a companion piece of code). I think the
later is the right way, since it enforces separation of concerns,
organization, modularization and in the end will result in better code and
less wight in final app (we'll get rid of all 'styles' in each line)

> The
> defaults.css in Basic should not have any styles that determine the boxes.
>  Those styles should be in basic.css (the default theme).

I think I agree, but again that phrase can result in ambiguity. I think the
default.css in Basic.swc (code part) must be set up all the things we put
now inline in 'style', and basic.css in theme, should but the rest (font
sizes, colors, backgrounds, and more). There can be discussion on
particular properties (i.e should 'cursor' by in one or another?)...but
that's the right way without any doubt.

> If some part of the framework that is "outside" the component is setting
> the display style on an subcomponent, that is probably a bug and needs
> discussion.

Right. I think that's what layouts (like VerticalLayoutWithGapAndPadding)
are doing. That works right now, but best way should be to assign className
to all the children affected, instead of hardcoded styles in component.
This result in the same effect but more clean, and the code is reusable and
make the html leaner. I think all of this are benefits.

> If you are using a layout inside the component then you
> should expect it to set the placement styles on the subcomponents.
Rigth, I think is what I described in the previous paragraph

> If the Button is in a HorizontalLayout it will set display:inline-block,
> otherwise Div's won't layout horizontally.

Right, but assign the className to the components. That's what all
recognized sets do out there. All work in the same way.

> If you want to write smarter
> layouts that check to see if the child doesn't default to inline display,
> feel free to do so.

I can do what I described, i.e: I can create a
VerticalLayoutWithGapAndPadding that assign a className instead of hardcode
the style,
If I do so and fix all the things described, can be think about make this
change through all the framework?

> I'm curious why your theme sets display on the outer
> component.

mmm...don't know if I understand right this. Jewel Button set
display:inline-block in its CSS. Button in not an *outer compoent* in
relation with its own css rule...that's what I don't understand in your
sentence. I see that is how all before mentioned frameworks do.
do you see a problem there?,


> Thanks,
> -Alex
> On 3/11/18, 3:19 PM, "Harbs" <harbs.li...@gmail.com> wrote:
> >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
> >>>>
> >>>>https://na01.safelinks.protection.outlook.com/?url=
> http%3A%2F%2Fabout.m
> >>>>e%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%
> 7C4ce3d3c8b3524d3c07
> >>>>ea08d5879e3b40%7Cfa7b1b5a7b34438794aed2c178de
> cee1%7C0%7C0%7C63656403602
> >>>>4734333&sdata=5W6y5A1faCSeqpBuA2wYSHba9gvZWG
> cfcujn37sXLtQ%3D&reserved=0
> >>>
> >>>
> >>
> >>
> >> --
> >> Carlos Rovira
> >>
> >>https://na01.safelinks.protection.outlook.com/?url=
> http%3A%2F%2Fabout.me%
> >>2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%
> 7C4ce3d3c8b3524d3c07ea08
> >>d5879e3b40%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
> 7C63656403602473433
> >>3&sdata=5W6y5A1faCSeqpBuA2wYSHba9gvZWGcfcujn37sXLtQ%3D&reserved=0
> >

Carlos Rovira

Reply via email to