You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@royale.apache.org by Carlos Rovira <ca...@apache.org> on 2018/03/11 17:18:21 UTC
Trying to remove "style" attribute set by Royale. First let's focus
on style="display:block"
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
http://about.me/carlosrovira
Re: Trying to remove "style" attribute set by Royale. First let's
focus on style="display:block"
Posted by Carlos Rovira <ca...@apache.org>.
HI Alex,
2018-03-12 8:17 GMT+01:00 Alex Harui <ah...@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
>
> Thanks,
> -Alex
>
>
> On 3/11/18, 3:19 PM, "Harbs" <ha...@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 <ca...@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 <ha...@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 <ca...@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
http://about.me/carlosrovira
Re: Trying to remove "style" attribute set by Royale. First let's
focus on style="display:block"
Posted by Alex Harui <ah...@adobe.com.INVALID>.
IMO some styles (padding, margin, font*) determine the "boxes", other
styles (position, display) place the boxes. The layouts will likely set
position and display directly on the outer box of a component. The
defaults.css in Basic should not have any styles that determine the boxes.
Those styles should be in basic.css (the default theme).
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. If you are using a layout inside the component then you
should expect it to set the placement styles on the subcomponents.
If the Button is in a HorizontalLayout it will set display:inline-block,
otherwise Div's won't layout horizontally. 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'm curious why your theme sets display on the outer
component.
Thanks,
-Alex
On 3/11/18, 3:19 PM, "Harbs" <ha...@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 <ca...@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 <ha...@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 <ca...@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%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C63656403602
>>>>4734333&sdata=5W6y5A1faCSeqpBuA2wYSHba9gvZWGcfcujn37sXLtQ%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
>
Re: Trying to remove "style" attribute set by Royale. First let's
focus on style="display:block"
Posted by Carlos Rovira <ca...@apache.org>.
Hi Piotr,
this issue is affecting all the code since is in basic.
You can check my branch and see it yourself, If you see the html code
you'll see all buttons with hardcoded style properties. What is not good at
all.
2018-03-12 10:20 GMT+01:00 Piotr Zarzycki <pi...@gmail.com>:
> Carlos,
>
> Does your code with mentioned issue is in jewel branch ?
>
>
>
> 2018-03-12 10:15 GMT+01:00 Carlos Rovira <ca...@apache.org>:
>
> > Hi Harbs,
> >
> > the frameworks I'm watching are MDL, Semantic and Bootstrap (all top
> > frameworks) to see what they do in different cases and guide me to find
> the
> > best way to implement the HTML Jewel should output in royale in Royale.
> All
> > of this frameworks are only HTML/JS/CSS (not builds from other code),
> but I
> > think that's not the point, since in the end both build front end
> > interfaces with controls and layouts
> >
> > So are you telling me that our output is better than theirs? That our way
> > of put somethings in the own html markup is better than theirs? I don't
> > think so, since they do the same but with better results: better
> optimized
> > and less weight html code.
> >
> > In the other hand, you are telling me to write a bead to override or
> > correct something the framework is hardcoding? I suppose you are
> referring
> > to a bead that removes all styles hardcoded, so that doesn't strikes out
> my
> > CSS styles... I think that's not the way to solve this. If I were making
> an
> > App maybe that's could be the solution as a workaround, but we are
> > framework developers, not users.
> >
> > I think that solution was good to start with, but now it demands to
> > refactor to something better.
> >
> > Harbs, are we trying to make the best framework out there? I think this
> > concrete point will make people reject us when they started to see the
> html
> > we product all bloated with styles, when that's not necessary and can be
> on
> > a "first level" CSS that be part of the lib code (not a theme) and be
> > included always. I think that's the right solution and we'll get the same
> > we have now but in the right insertion point.
> >
> > Thanks
> >
> >
> > 2018-03-11 23:19 GMT+01:00 Harbs <ha...@gmail.com>:
> >
> > > 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 <carlosrovira@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 <ha...@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 <
> carlosrovira@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
> > > >>> http://about.me/carlosrovira
> > > >>
> > > >>
> > > >
> > > >
> > > > --
> > > > Carlos Rovira
> > > > http://about.me/carlosrovira
> > >
> > >
> >
> >
> > --
> > Carlos Rovira
> > http://about.me/carlosrovira
> >
>
>
>
> --
>
> Piotr Zarzycki
>
> Patreon: *https://www.patreon.com/piotrzarzycki
> <https://www.patreon.com/piotrzarzycki>*
>
--
Carlos Rovira
http://about.me/carlosrovira
Re: Trying to remove "style" attribute set by Royale. First let's
focus on style="display:block"
Posted by Piotr Zarzycki <pi...@gmail.com>.
Carlos,
Does your code with mentioned issue is in jewel branch ?
2018-03-12 10:15 GMT+01:00 Carlos Rovira <ca...@apache.org>:
> Hi Harbs,
>
> the frameworks I'm watching are MDL, Semantic and Bootstrap (all top
> frameworks) to see what they do in different cases and guide me to find the
> best way to implement the HTML Jewel should output in royale in Royale. All
> of this frameworks are only HTML/JS/CSS (not builds from other code), but I
> think that's not the point, since in the end both build front end
> interfaces with controls and layouts
>
> So are you telling me that our output is better than theirs? That our way
> of put somethings in the own html markup is better than theirs? I don't
> think so, since they do the same but with better results: better optimized
> and less weight html code.
>
> In the other hand, you are telling me to write a bead to override or
> correct something the framework is hardcoding? I suppose you are referring
> to a bead that removes all styles hardcoded, so that doesn't strikes out my
> CSS styles... I think that's not the way to solve this. If I were making an
> App maybe that's could be the solution as a workaround, but we are
> framework developers, not users.
>
> I think that solution was good to start with, but now it demands to
> refactor to something better.
>
> Harbs, are we trying to make the best framework out there? I think this
> concrete point will make people reject us when they started to see the html
> we product all bloated with styles, when that's not necessary and can be on
> a "first level" CSS that be part of the lib code (not a theme) and be
> included always. I think that's the right solution and we'll get the same
> we have now but in the right insertion point.
>
> Thanks
>
>
> 2018-03-11 23:19 GMT+01:00 Harbs <ha...@gmail.com>:
>
> > 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 <ca...@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 <ha...@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 <ca...@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
> > >>> http://about.me/carlosrovira
> > >>
> > >>
> > >
> > >
> > > --
> > > Carlos Rovira
> > > http://about.me/carlosrovira
> >
> >
>
>
> --
> Carlos Rovira
> http://about.me/carlosrovira
>
--
Piotr Zarzycki
Patreon: *https://www.patreon.com/piotrzarzycki
<https://www.patreon.com/piotrzarzycki>*
Re: Trying to remove "style" attribute set by Royale. First let's
focus on style="display:block"
Posted by Carlos Rovira <ca...@apache.org>.
Hi Piotr,
don't worry that was some of things I worried so much when working on MDL,
and for that reason I made most of the changes I did at that moment. In
Jewel I'll be doing the same ;)
2018-03-12 19:34 GMT+01:00 Piotr Zarzycki <pi...@gmail.com>:
> 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 <ca...@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 <pi...@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 <ah...@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.rovira@gmail.com on behalf of Carlos
> > > Rovira"
> > > > <carlos.rovira@gmail.com on behalf of carlosrovira@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 <ah...@adobe.com.invalid>:
> > > > >
> > > > >>
> > > > >>
> > > > >> On 3/12/18, 10:11 AM, "carlos.rovira@gmail.com on behalf of
> Carlos
> > > > >>Rovira"
> > > > >> <carlos.rovira@gmail.com on behalf of carlosrovira@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>*
>
--
Carlos Rovira
http://about.me/carlosrovira
Re: Trying to remove "style" attribute set by Royale. First let's
focus on style="display:block"
Posted by Piotr Zarzycki <pi...@gmail.com>.
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 <ca...@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 <pi...@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 <ah...@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.rovira@gmail.com on behalf of Carlos
> > Rovira"
> > > <carlos.rovira@gmail.com on behalf of carlosrovira@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 <ah...@adobe.com.invalid>:
> > > >
> > > >>
> > > >>
> > > >> On 3/12/18, 10:11 AM, "carlos.rovira@gmail.com on behalf of Carlos
> > > >>Rovira"
> > > >> <carlos.rovira@gmail.com on behalf of carlosrovira@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>*
Re: Trying to remove "style" attribute set by Royale. First let's
focus on style="display:block"
Posted by Carlos Rovira <ca...@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 <pi...@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 <ah...@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.rovira@gmail.com on behalf of Carlos
> Rovira"
> > <carlos.rovira@gmail.com on behalf of carlosrovira@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 <ah...@adobe.com.invalid>:
> > >
> > >>
> > >>
> > >> On 3/12/18, 10:11 AM, "carlos.rovira@gmail.com on behalf of Carlos
> > >>Rovira"
> > >> <carlos.rovira@gmail.com on behalf of carlosrovira@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
Re: Trying to remove "style" attribute set by Royale. First let's
focus on style="display:block"
Posted by Piotr Zarzycki <pi...@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 <ah...@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.rovira@gmail.com on behalf of Carlos Rovira"
> <carlos.rovira@gmail.com on behalf of carlosrovira@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 <ah...@adobe.com.invalid>:
> >
> >>
> >>
> >> On 3/12/18, 10:11 AM, "carlos.rovira@gmail.com on behalf of Carlos
> >>Rovira"
> >> <carlos.rovira@gmail.com on behalf of carlosrovira@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>*
Re: Trying to remove "style" attribute set by Royale. First let's
focus on style="display:block"
Posted by Alex Harui <ah...@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.rovira@gmail.com on behalf of Carlos Rovira"
<carlos.rovira@gmail.com on behalf of carlosrovira@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 <ah...@adobe.com.invalid>:
>
>>
>>
>> On 3/12/18, 10:11 AM, "carlos.rovira@gmail.com on behalf of Carlos
>>Rovira"
>> <carlos.rovira@gmail.com on behalf of carlosrovira@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
Re: Trying to remove "style" attribute set by Royale. First let's
focus on style="display:block"
Posted by Carlos Rovira <ca...@apache.org>.
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 <ah...@adobe.com.invalid>:
>
>
> On 3/12/18, 10:11 AM, "carlos.rovira@gmail.com on behalf of Carlos Rovira"
> <carlos.rovira@gmail.com on behalf of carlosrovira@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
http://about.me/carlosrovira
Re: Trying to remove "style" attribute set by Royale. First let's
focus on style="display:block"
Posted by Alex Harui <ah...@adobe.com.INVALID>.
On 3/12/18, 10:11 AM, "carlos.rovira@gmail.com on behalf of Carlos Rovira"
<carlos.rovira@gmail.com on behalf of carlosrovira@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
Re: Trying to remove "style" attribute set by Royale. First let's
focus on style="display:block"
Posted by Piotr Zarzycki <pi...@gmail.com>.
If I would want an Vertical layout which do not affect as much your
children - I would create set of layouts beads which applies FlexBox rules
or Grid rules to the children. The things is that I would do this the same
way - by inline styles instead of css classes.
Why ? Look into my previous statement.
Thanks, Piotr
2018-03-12 18:11 GMT+01:00 Carlos Rovira <ca...@apache.org>:
> HI Alex
>
> 2018-03-12 17:02 GMT+01:00 Alex Harui <ah...@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.rovira@gmail.com on behalf of Carlos
> Rovira"
> > <carlos.rovira@gmail.com on behalf of carlosrovira@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 <ca...@apache.org>:
> > >
> > >>
> > >> 2018-03-12 11:29 GMT+01:00 Harbs <ha...@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
>
--
Piotr Zarzycki
Patreon: *https://www.patreon.com/piotrzarzycki
<https://www.patreon.com/piotrzarzycki>*
Re: Trying to remove "style" attribute set by Royale. First let's
focus on style="display:block"
Posted by Carlos Rovira <ca...@apache.org>.
HI Alex
2018-03-12 17:02 GMT+01:00 Alex Harui <ah...@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.rovira@gmail.com on behalf of Carlos Rovira"
> <carlos.rovira@gmail.com on behalf of carlosrovira@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 <ca...@apache.org>:
> >
> >>
> >> 2018-03-12 11:29 GMT+01:00 Harbs <ha...@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
Re: Trying to remove "style" attribute set by Royale. First let's
focus on style="display:block"
Posted by Alex Harui <ah...@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.
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.
Thanks,
-Alex
On 3/12/18, 3:44 AM, "carlos.rovira@gmail.com on behalf of Carlos Rovira"
<carlos.rovira@gmail.com on behalf of carlosrovira@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 <ca...@apache.org>:
>
>>
>> 2018-03-12 11:29 GMT+01:00 Harbs <ha...@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
Re: Trying to remove "style" attribute set by Royale. First let's
focus on style="display:block"
Posted by Carlos Rovira <ca...@apache.org>.
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 <ca...@apache.org>:
>
> 2018-03-12 11:29 GMT+01:00 Harbs <ha...@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
> http://about.me/carlosrovira
>
>
--
Carlos Rovira
http://about.me/carlosrovira
Re: Trying to remove "style" attribute set by Royale. First let's
focus on style="display:block"
Posted by Carlos Rovira <ca...@apache.org>.
2018-03-12 11:29 GMT+01:00 Harbs <ha...@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
http://about.me/carlosrovira
Re: Trying to remove "style" attribute set by Royale. First let's
focus on style="display:block"
Posted by Harbs <ha...@gmail.com>.
I also care about the HTML output, but in a different way than you (I think). I care that it should be easy to debug and reason out why things are happening.
Can you explain why you care about inline CSS? I’m not getting it.
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.
Harbs
> On Mar 12, 2018, at 12:22 PM, Carlos Rovira <ca...@apache.org> wrote:
>
> Hi,
>
> I see we have very different ways to how we see royale. In the end I see
> Royale like you, but I care about the output we get in HTML in concrete,
> since is different than the code we can produce in other outputs like AS3
> (and maybe some day in Java, Swift,...). HTML is what is delivered to the
> final user, the rest not since are compiled to bytecode and are not as
> inspectable as HTML.
>
> anyway, I think is good to have different points of view but with care so
> the positions could co-exists.
>
> thanks
>
>
> 2018-03-12 10:55 GMT+01:00 Harbs <ha...@gmail.com>:
>
>>> the frameworks I'm watching are MDL, Semantic and Bootstrap (all top
>>> frameworks) to see what they do in different cases and guide me to find
>> the
>>> best way to implement the HTML Jewel should output in royale in Royale.
>> All
>>> of this frameworks are only HTML/JS/CSS (not builds from other code),
>> but I
>>> think that's not the point, since in the end both build front end
>>> interfaces with controls and layouts
>>
>> It’s very much the point. These are all frameworks which attempt to enable
>> a *document markup* (i.e. HTML) to be styled. Sure people use this for web
>> apps, but it’s an abuse of what HTML was originally designed to be.
>>
>> The way I see Royale is an *application framework* which simply uses HTML
>> and browsers as a *rendering engine*. Our goal isn’t and *should not be*
>> pretty HTML markup. That’s only important if you are *writing HTML
>> documents*. The strength of CSS is that it allows the styling to be
>> divorced from the documentation and content. That is *not* an important
>> goal for application development. It *is* important for (a subset of)
>> applications to be easily skinned, but CSS files should be a means (if
>> necessary) and *not* a goal.
>>
>>> So are you telling me that our output is better than theirs? That our way
>>> of put somethings in the own html markup is better than theirs? I don't
>>> think so, since they do the same but with better results: better
>> optimized
>>> and less weight html code.
>>
>> Yes. CSS lookups are inherently inefficient. “Pretty” HTML markup is *not*
>> optimized. If CSS styling is not inlined, the browser must look through
>> (sometimes quite complex) lookup tables to figure out what the styling
>> should be. The fact that browsers can execute CSS lookups as quickly as
>> they do is quite amazing.
>>
>>> In the other hand, you are telling me to write a bead to override or
>>> correct something the framework is hardcoding? I suppose you are
>> referring
>>> to a bead that removes all styles hardcoded, so that doesn't strikes out
>> my
>>> CSS styles... I think that's not the way to solve this. If I were making
>> an
>>> App maybe that's could be the solution as a workaround, but we are
>>> framework developers, not users.
>>
>> I think that any properties in a theme which can only be specified using
>> CSS files should have any inline css zeroed out by a bead. I would look for
>> ways to have the values inlined though. Possibly the themes can be
>> swappable beads which overwrite styles? Don’t know...
>>
>>> I think that solution was good to start with, but now it demands to
>>> refactor to something better.
>>>
>>> Harbs, are we trying to make the best framework out there? I think this
>>> concrete point will make people reject us when they started to see the
>> html
>>> we product all bloated with styles, when that's not necessary and can be
>> on
>>> a "first level" CSS that be part of the lib code (not a theme) and be
>>> included always. I think that's the right solution and we'll get the same
>>> we have now but in the right insertion point.
>>
>> I really don’t think that’s true. If you are talking about people who
>> *like* writing HTML, they’re not going to want to use Royale anyway. To me
>> a big part of the attraction of Royale is that I can avoid (for the most
>> part) writing HTML in my app. The attraction is MXML and ActionScript files
>> and avoiding complex HTML and CSS files.
>>
>> Again: Default inline css can easily be overwritten (or zeroed out) in
>> beads for cases when it’s needed. I see no need for major changes to the
>> architecture.
>>
>> My $0.02,
>> Harbs
>>
>>
>
>
> --
> Carlos Rovira
> http://about.me/carlosrovira
Re: Trying to remove "style" attribute set by Royale. First let's
focus on style="display:block"
Posted by Carlos Rovira <ca...@apache.org>.
Hi,
I see we have very different ways to how we see royale. In the end I see
Royale like you, but I care about the output we get in HTML in concrete,
since is different than the code we can produce in other outputs like AS3
(and maybe some day in Java, Swift,...). HTML is what is delivered to the
final user, the rest not since are compiled to bytecode and are not as
inspectable as HTML.
anyway, I think is good to have different points of view but with care so
the positions could co-exists.
thanks
2018-03-12 10:55 GMT+01:00 Harbs <ha...@gmail.com>:
> > the frameworks I'm watching are MDL, Semantic and Bootstrap (all top
> > frameworks) to see what they do in different cases and guide me to find
> the
> > best way to implement the HTML Jewel should output in royale in Royale.
> All
> > of this frameworks are only HTML/JS/CSS (not builds from other code),
> but I
> > think that's not the point, since in the end both build front end
> > interfaces with controls and layouts
>
> It’s very much the point. These are all frameworks which attempt to enable
> a *document markup* (i.e. HTML) to be styled. Sure people use this for web
> apps, but it’s an abuse of what HTML was originally designed to be.
>
> The way I see Royale is an *application framework* which simply uses HTML
> and browsers as a *rendering engine*. Our goal isn’t and *should not be*
> pretty HTML markup. That’s only important if you are *writing HTML
> documents*. The strength of CSS is that it allows the styling to be
> divorced from the documentation and content. That is *not* an important
> goal for application development. It *is* important for (a subset of)
> applications to be easily skinned, but CSS files should be a means (if
> necessary) and *not* a goal.
>
> > So are you telling me that our output is better than theirs? That our way
> > of put somethings in the own html markup is better than theirs? I don't
> > think so, since they do the same but with better results: better
> optimized
> > and less weight html code.
>
> Yes. CSS lookups are inherently inefficient. “Pretty” HTML markup is *not*
> optimized. If CSS styling is not inlined, the browser must look through
> (sometimes quite complex) lookup tables to figure out what the styling
> should be. The fact that browsers can execute CSS lookups as quickly as
> they do is quite amazing.
>
> > In the other hand, you are telling me to write a bead to override or
> > correct something the framework is hardcoding? I suppose you are
> referring
> > to a bead that removes all styles hardcoded, so that doesn't strikes out
> my
> > CSS styles... I think that's not the way to solve this. If I were making
> an
> > App maybe that's could be the solution as a workaround, but we are
> > framework developers, not users.
>
> I think that any properties in a theme which can only be specified using
> CSS files should have any inline css zeroed out by a bead. I would look for
> ways to have the values inlined though. Possibly the themes can be
> swappable beads which overwrite styles? Don’t know...
>
> > I think that solution was good to start with, but now it demands to
> > refactor to something better.
> >
> > Harbs, are we trying to make the best framework out there? I think this
> > concrete point will make people reject us when they started to see the
> html
> > we product all bloated with styles, when that's not necessary and can be
> on
> > a "first level" CSS that be part of the lib code (not a theme) and be
> > included always. I think that's the right solution and we'll get the same
> > we have now but in the right insertion point.
>
> I really don’t think that’s true. If you are talking about people who
> *like* writing HTML, they’re not going to want to use Royale anyway. To me
> a big part of the attraction of Royale is that I can avoid (for the most
> part) writing HTML in my app. The attraction is MXML and ActionScript files
> and avoiding complex HTML and CSS files.
>
> Again: Default inline css can easily be overwritten (or zeroed out) in
> beads for cases when it’s needed. I see no need for major changes to the
> architecture.
>
> My $0.02,
> Harbs
>
>
--
Carlos Rovira
http://about.me/carlosrovira
Re: Trying to remove "style" attribute set by Royale. First let's
focus on style="display:block"
Posted by Harbs <ha...@gmail.com>.
> the frameworks I'm watching are MDL, Semantic and Bootstrap (all top
> frameworks) to see what they do in different cases and guide me to find the
> best way to implement the HTML Jewel should output in royale in Royale. All
> of this frameworks are only HTML/JS/CSS (not builds from other code), but I
> think that's not the point, since in the end both build front end
> interfaces with controls and layouts
It’s very much the point. These are all frameworks which attempt to enable a *document markup* (i.e. HTML) to be styled. Sure people use this for web apps, but it’s an abuse of what HTML was originally designed to be.
The way I see Royale is an *application framework* which simply uses HTML and browsers as a *rendering engine*. Our goal isn’t and *should not be* pretty HTML markup. That’s only important if you are *writing HTML documents*. The strength of CSS is that it allows the styling to be divorced from the documentation and content. That is *not* an important goal for application development. It *is* important for (a subset of) applications to be easily skinned, but CSS files should be a means (if necessary) and *not* a goal.
> So are you telling me that our output is better than theirs? That our way
> of put somethings in the own html markup is better than theirs? I don't
> think so, since they do the same but with better results: better optimized
> and less weight html code.
Yes. CSS lookups are inherently inefficient. “Pretty” HTML markup is *not* optimized. If CSS styling is not inlined, the browser must look through (sometimes quite complex) lookup tables to figure out what the styling should be. The fact that browsers can execute CSS lookups as quickly as they do is quite amazing.
> In the other hand, you are telling me to write a bead to override or
> correct something the framework is hardcoding? I suppose you are referring
> to a bead that removes all styles hardcoded, so that doesn't strikes out my
> CSS styles... I think that's not the way to solve this. If I were making an
> App maybe that's could be the solution as a workaround, but we are
> framework developers, not users.
I think that any properties in a theme which can only be specified using CSS files should have any inline css zeroed out by a bead. I would look for ways to have the values inlined though. Possibly the themes can be swappable beads which overwrite styles? Don’t know...
> I think that solution was good to start with, but now it demands to
> refactor to something better.
>
> Harbs, are we trying to make the best framework out there? I think this
> concrete point will make people reject us when they started to see the html
> we product all bloated with styles, when that's not necessary and can be on
> a "first level" CSS that be part of the lib code (not a theme) and be
> included always. I think that's the right solution and we'll get the same
> we have now but in the right insertion point.
I really don’t think that’s true. If you are talking about people who *like* writing HTML, they’re not going to want to use Royale anyway. To me a big part of the attraction of Royale is that I can avoid (for the most part) writing HTML in my app. The attraction is MXML and ActionScript files and avoiding complex HTML and CSS files.
Again: Default inline css can easily be overwritten (or zeroed out) in beads for cases when it’s needed. I see no need for major changes to the architecture.
My $0.02,
Harbs
Re: Trying to remove "style" attribute set by Royale. First let's
focus on style="display:block"
Posted by Carlos Rovira <ca...@apache.org>.
Hi Harbs,
the frameworks I'm watching are MDL, Semantic and Bootstrap (all top
frameworks) to see what they do in different cases and guide me to find the
best way to implement the HTML Jewel should output in royale in Royale. All
of this frameworks are only HTML/JS/CSS (not builds from other code), but I
think that's not the point, since in the end both build front end
interfaces with controls and layouts
So are you telling me that our output is better than theirs? That our way
of put somethings in the own html markup is better than theirs? I don't
think so, since they do the same but with better results: better optimized
and less weight html code.
In the other hand, you are telling me to write a bead to override or
correct something the framework is hardcoding? I suppose you are referring
to a bead that removes all styles hardcoded, so that doesn't strikes out my
CSS styles... I think that's not the way to solve this. If I were making an
App maybe that's could be the solution as a workaround, but we are
framework developers, not users.
I think that solution was good to start with, but now it demands to
refactor to something better.
Harbs, are we trying to make the best framework out there? I think this
concrete point will make people reject us when they started to see the html
we product all bloated with styles, when that's not necessary and can be on
a "first level" CSS that be part of the lib code (not a theme) and be
included always. I think that's the right solution and we'll get the same
we have now but in the right insertion point.
Thanks
2018-03-11 23:19 GMT+01:00 Harbs <ha...@gmail.com>:
> 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 <ca...@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 <ha...@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 <ca...@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
> >>> http://about.me/carlosrovira
> >>
> >>
> >
> >
> > --
> > Carlos Rovira
> > http://about.me/carlosrovira
>
>
--
Carlos Rovira
http://about.me/carlosrovira
Re: Trying to remove "style" attribute set by Royale. First let's
focus on style="display:block"
Posted by Harbs <ha...@gmail.com>.
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 <ca...@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 <ha...@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 <ca...@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
>>> http://about.me/carlosrovira
>>
>>
>
>
> --
> Carlos Rovira
> http://about.me/carlosrovira
Re: Trying to remove "style" attribute set by Royale. First let's
focus on style="display:block"
Posted by Carlos Rovira <ca...@apache.org>.
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 <ha...@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 <ca...@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
> > http://about.me/carlosrovira
>
>
--
Carlos Rovira
http://about.me/carlosrovira
Re: Trying to remove "style" attribute set by Royale. First let's
focus on style="display:block"
Posted by Harbs <ha...@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 <ca...@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
> http://about.me/carlosrovira