You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@flex.apache.org by Carlos Rovira <ca...@apache.org> on 2016/12/02 00:01:04 UTC
[FlexJS] get rid of inline styles (was Re: [FlexJS]Layout problems)
to separate things:
Such as? Depending on your layout, left, top, width, and height will be
> set in CSS. In UIBase, setting the x value sets style.left, etc. If
> there is an alternative, please let me know what it is.
> -Alex
>
>
I get this:
<div style="position: relative;"><span class="Label" style="white-space:
nowrap; cursor: default; pointer-events: none;">some text</span><button
type="button" class="TextButton" style="position: relative;">a
button</button></div>
from this:
<js:Container>
<js:Label text="some text"/>
<js:TextButton text="a button"/>
</js:Container>
in my MDLExample (take into account that I use exclude default CSS compiler
param)
So as you see there's lots of "style" properties above that should not be.
The right output should be:
<div><span class="Label">some text</span><button type="button"
class="TextButton">a button</button></div>
So as I use compiler option exclude default css file I ensure my app only
has the css I put, and not carry anything I don't want.
why this is happen? To take only one example. In js:Container line 104
there's:
positioner.style.position = 'relative';
this should remove from there and put in defaults.css line 93
Container
{
position = 'relative';
....
Do you agree with that?
I could do that refactor if you want
--
Carlos Rovira
http://about.me/carlosrovira
Re: [FlexJS] get rid of inline styles (was Re: [FlexJS]Layout problems)
Posted by OmPrakash Muppirala <bi...@gmail.com>.
On Thu, Dec 1, 2016 at 4:55 PM, Carlos Rovira <ca...@apache.org>
wrote:
> > I wish I could agree, but I don't think I can. IMO, some component
> > features can only be implemented by setting style properties. In the
> > example above, to keep Label as single-line (so you don't have to us
>  
> > and can just use space), we must set white-space:no-wrap. Allowing folks
> > to tweak things like that in the CSS seems dangerous to me.
> >
> >
> But, this is user choice. If I stick with styles in css, or I want some of
> it, I'm free to keep them or remove for my
> use case. keeping It hard-code to avoid people that don't want that be
> forced to use is very bad policy IMHO.
>
> You could as well use documentation to expose requirements and make people
> know that 2 or 3 styles are required and if they remove from CSS things
> could break. We could prepare as well a MVCSS (minimum viable CSS) so
> people would not need to use the remove default compiler flag, and have
> another with relative positions, borders and other no-so required things,
> but needed in basic comp set.
>
Some component developers use the *!important *rule to 'protect' their
carefully constructed css classes.
https://css-tricks.com/when-using-important-is-the-right-choice/#article-header-id-0
>
>
>
> > Similarly, Label isn't supposed to be interactive, so we turn off mouse
> > events. It is the equivalent of mouseEnabled in SWF. The way we found
> to
> > do it is to set a style. Again, I'm not sure that should be settable in
> a
> > CSS theme.
> >
> >
> I think so. If we could set the style in CSS and we are not doing this
> because we are afraid of our user...that's a very bad policy. There's other
> methods to avoid that. For example, if in MDL mouseEnabled is not
> contemplated...I would left in my CSS.
>
>
>
> > The way we handle visible=false also sets a style: display:none.
>
>
> that's one of the styles I historically use when doing some html, and
> always put in CSS...there's no reason not doing the same in FlexJS moreover
> taking into account this is a framework to craft things and nothing final.
>
>
> >
> > But position is a tricky and separate topic. Someone needs to prove that
> > none of the examples break if we don't set position to relative or
> > absolute the way we do it now.
>
>
> Right, If I'd make the changes I would have to test examples as I move
> things from code to CSS. and if something can not be done left untouched or
> until we get a way to do it.
>
>
> > The comment in Container.as says:
> >
> > // absolute positioned children need a non-null
> > // position value in the parent. It might
> > // get set to 'absolute' if the container is
> > // also absolutely positioned
> >
> > So that implies that if you put a child in a Container and set its x or y
> > value, it won't work unless we set position to absolute or relative.
> > That's making me think that the test case is a nested set of Containers
> > with a child in the inner container with x,y position.
>
>
> Right, but again that's in the people using the basic set, and not for
> potential user that will want to use FlexJS for their own use cases.
>
> We are setting the basis of the technology. The building blocks. And as
> building block, those should come free of charges.
>
> I'm creating MDL only to show people some beautiful FlexJS screens that
> make people jump (since people buys for what they see more quick and I
> think this is a urgent need for us right now)...but I assume that few
> people will end using that (I think) and will want to customize more their
> experiences. Maybe I could expect 5%-15%...people using MDL set? I think
> Basic set (as is) will not be used at all since the final visuals are not
> production ready, so you know people will need this level of customization
> or they will never join FleJS for sure. But Basic set is at the core of
> all. Is at the core of MDL set and here you have the first example of many
> of the styles in flexjs needs to be removed in order to get the MDL branch
> working ok, and so will happen with others like Bootstrap, and so on...
> Only if we create our own FlexJS style design could take into account the
> actual styles, but I think that if MDL or Bootstrap does not need all of
> that, we should not need creating our own CSS set in the end (I can't say
> much more here since I'm not a CSS expert to affirm that, but based on what
> I see...is clear that it's the reality).
>
>
>
> --
> Carlos Rovira
> http://about.me/carlosrovira
>
Re: [FlexJS] get rid of inline styles (was Re: [FlexJS]Layout problems)
Posted by flex capacitor <fl...@gmail.com>.
In Radiate I convert Flex UIComponents to HTML components and had this
problem. I made an option to allow styles to be defined inline or in a
style sheet. If the option was stylesheet then if the component had an id
the styles were declared by id. This included position, size, etc:
#myLabel {
style: value;
}
If the component didn't have an id too bad. I'd give it an id using Flex
naming utils class and again declare styles there.
But I added an option to let developers override the styles per component
and that might work here.
So you would have a components style declaration by id and then in Radiate
there is a user styles field. Any values in that field would be declared in
the style declaration but they would be placed at the end. Everybody knows
that last declaration wins, even grandma.
#myLabel {
style: value; /*define by framework */
style: newValue; /* defined by user */
}
You could also declare style: inherit and I think that resets the value.
Yes, the style is declared twice. Who cares. But yes to look pretty, I plan
to remove the first declaration or comment it out in a future update.
If Flex JS made some combination of class and class#id it might be an
option so that you can declare your own style declaration afterwards and
restore the defaults. Yes there might be two style declarations but at
least then they wouldn't be defined inline.
On Dec 2, 2016 11:52 AM, "Carlos Rovira" <ca...@codeoscopic.com>
wrote:
> Hi Josh,
>
> right. As I get some few components more, I think I could refactor removing
> the dependencies from some HTML comps so we could manage better MDL set. So
> for example, I will took things from Core, like UIBase or ContainerBase
> while removing html things like TextButton, Container and so on...(in the
> end removing HTML.swc dependency at all). In this way I think MDL will be
> more independent.
>
> 2016-12-02 16:55 GMT+01:00 Josh Tynjala <jo...@gmail.com>:
>
> > Alex's first point about using the same beads, but not subclassing sounds
> > cleaner to me, Carlos. Kind of the same idea from the other day where all
> > components should be possible to recreate from UIBase with the right set
> of
> > beads. You should consider trying that out for MDL.
> >
> > - Josh
> >
> > On Dec 1, 2016 11:09 PM, "Alex Harui" <ah...@adobe.com> wrote:
> >
> > > Re-ordering your post so I can address higher-level points first:
> > >
> > >
> > > On 12/1/16, 4:55 PM, "carlos.rovira@gmail.com on behalf of Carlos
> > Rovira"
> > > <carlos.rovira@gmail.com on behalf of carlosrovira@apache.org> wrote:
> > > >
> > > >But Basic set is at the core of
> > > >all. Is at the core of MDL set
> > > >
> > > >
> > >
> > > This statement doesn't have to be true, and makes me think that the old
> > > Flex SDK mentality is persisting. IMO, the MDL set has no obligation
> to
> > > subclass the Basic set. The top-level components in the Basic set are
> > > supposed to be compositions of beads. MDL can just compose the same or
> > > different beads without having to subclass Basic components.
> > >
> > > One of the problems of having a core and inheritance is that you have
> to
> > > get it right, but often there isn't one right answer.
> > >
> > > >I think
> > > >Basic set (as is) will not be used at all since the final visuals are
> > not
> > > >production ready, so you know people will need this level of
> > customization
> > > >or they will never join FleJS for sure. and here you have the first
> > > >example of many
> > > >of the styles in flexjs needs to be removed in order to get the MDL
> > branch
> > > >working ok, and so will happen with others like Bootstrap, and so
> on...
> > > >Only if we create our own FlexJS style design could take into account
> > the
> > > >actual styles, but I think that if MDL or Bootstrap does not need all
> of
> > > >that, we should not need creating our own CSS set in the end (I can't
> > say
> > > >much more here since I'm not a CSS expert to affirm that, but based on
> > > >what
> > > >I see...is clear that it's the reality).
> > > >
> > >
> > > In my mind, there are going to be two kinds of themes: pre-existing
> ones
> > > like MDL and custom ones like the themes that regular Flex SDK
> customers
> > > used to brand their applications. In the second kind, I don't think it
> > > matters as much as to what default styles are. Folks will simply
> override
> > > the defaults in their themes.
> > >
> > > I was a bit surprised that MDL didn't override everything we set as
> > > defaults for HTML.swc. That means to me that if someone has certain
> > > styles set elsewhere, even in their browser settings, that could cause
> > > really strange and unexpected results. But OK, that's the way it is,
> and
> > > so we should think of other ways to have a default look for HTML.swc,
> > > although again, as I said above, the MDL library has no obligation to
> > > inherit from HTML.swc.
> > >
> > > If we really need to support more inheritance, then maybe all visual
> > > styles should be moved from HTML into some default theme. It would be
> > > nice to have a better set of defaults that are a bit more production
> > ready
> > > for Basic so we can see how and why there are collisions between
> themes.
> > >
> > > >You could as well use documentation to expose requirements and make
> > people
> > > >know that 2 or 3 styles are required and if they remove from CSS
> things
> > > >could break. We could prepare as well a MVCSS (minimum viable CSS) so
> > > >people would not need to use the remove default compiler flag, and
> have
> > > >another with relative positions, borders and other no-so required
> > things,
> > > >but needed in basic comp set.
> > > >
> > > >
> > >
> > > Way back in early Flex, we found our customers didn't like this. There
> > > was a version of Flex where only the type-selectors with the same name
> as
> > > the component was applied. So CheckBox extended Button and lots of
> > styles
> > > important to Button needed to be copied to the CheckBox type selector.
> > > This was way faster at runtime because we didn't have to chase down the
> > > super classes and their styles. But customers really complained because
> > if
> > > you subclassed Button and made a MyButton, you had to know which styles
> > to
> > > copy to a MyButton type selector or the component wouldn't work. I'm
> > sure
> > > our documentation was not sufficient, but even then, folks thought it
> was
> > > a pain.
> > >
> > > If you want to ensure no styles are specified in code for the MDL
> library
> > > feel free to do so. I'm just not sure how important tat is for the
> Basic
> > > set.
> > >
> > > >
> > > >> Similarly, Label isn't supposed to be interactive, so we turn off
> > mouse
> > > >> events. It is the equivalent of mouseEnabled in SWF. The way we
> > found
> > > >>to
> > > >> do it is to set a style. Again, I'm not sure that should be
> settable
> > > >>in a
> > > >> CSS theme.
> > > >>
> > > >>
> > > >I think so. If we could set the style in CSS and we are not doing this
> > > >because we are afraid of our user...that's a very bad policy. There's
> > > >other
> > > >methods to avoid that. For example, if in MDL mouseEnabled is not
> > > >contemplated...I would left in my CSS.
> > > >
> > > >
> > > >
> > > >> The way we handle visible=false also sets a style: display:none.
> > > >
> > > >
> > > >that's one of the styles I historically use when doing some html, and
> > > >always put in CSS...there's no reason not doing the same in FlexJS
> > > >moreover
> > > >taking into account this is a framework to craft things and nothing
> > final.
> > >
> > > IMO, there are styles that are functional like display:none and
> > > pointer-events and no-wrap and styles that are visual. For functional
> > > styles, I'm not sure it is the easiest API to make folks work with all
> of
> > > these CSS styles instead of through properties on the component,
> > > especially properties that have a high likelihood of changing at
> runtime.
> > > So that's why Basic has a visible and alpha properties. Seems nicer to
> > > set those than have to set style.display = "none". Yes it means you
> > can't
> > > set things invisible by changing CSS themes, but again, someone is
> > welcome
> > > to create a different component set that does make folks use
> > style.display
> > > = "none".
> > >
> > > Again, going back to the first point. There is often no right answer,
> so
> > > we are working hard to make sure FlexJS can support multiple
> independent
> > > component sets so customers can choose the API surfaces that they like
> > > best.
> > >
> > > My 2 cents,
> > > -Alex
> > >
> > >
> >
>
>
>
> --
>
> Carlos Rovira
> Director General
> M: +34 607 22 60 05
> http://www.codeoscopic.com
> http://www.avant2.es
>
> Este mensaje se dirige exclusivamente a su destinatario y puede contener
> información privilegiada o confidencial. Si ha recibido este mensaje por
> error, le rogamos que nos lo comunique inmediatamente por esta misma vía y
> proceda a su destrucción.
>
> De la vigente Ley Orgánica de Protección de Datos (15/1999), le comunicamos
> que sus datos forman parte de un fichero cuyo responsable es CODEOSCOPIC
> S.A. La finalidad de dicho tratamiento es facilitar la prestación del
> servicio o información solicitados, teniendo usted derecho de acceso,
> rectificación, cancelación y oposición de sus datos dirigiéndose a nuestras
> oficinas c/ Paseo de la Habana 9-11, 28036, Madrid con la documentación
> necesaria.
>
Re: [FlexJS] get rid of inline styles (was Re: [FlexJS]Layout problems)
Posted by Carlos Rovira <ca...@codeoscopic.com>.
Hi Josh,
right. As I get some few components more, I think I could refactor removing
the dependencies from some HTML comps so we could manage better MDL set. So
for example, I will took things from Core, like UIBase or ContainerBase
while removing html things like TextButton, Container and so on...(in the
end removing HTML.swc dependency at all). In this way I think MDL will be
more independent.
2016-12-02 16:55 GMT+01:00 Josh Tynjala <jo...@gmail.com>:
> Alex's first point about using the same beads, but not subclassing sounds
> cleaner to me, Carlos. Kind of the same idea from the other day where all
> components should be possible to recreate from UIBase with the right set of
> beads. You should consider trying that out for MDL.
>
> - Josh
>
> On Dec 1, 2016 11:09 PM, "Alex Harui" <ah...@adobe.com> wrote:
>
> > Re-ordering your post so I can address higher-level points first:
> >
> >
> > On 12/1/16, 4:55 PM, "carlos.rovira@gmail.com on behalf of Carlos
> Rovira"
> > <carlos.rovira@gmail.com on behalf of carlosrovira@apache.org> wrote:
> > >
> > >But Basic set is at the core of
> > >all. Is at the core of MDL set
> > >
> > >
> >
> > This statement doesn't have to be true, and makes me think that the old
> > Flex SDK mentality is persisting. IMO, the MDL set has no obligation to
> > subclass the Basic set. The top-level components in the Basic set are
> > supposed to be compositions of beads. MDL can just compose the same or
> > different beads without having to subclass Basic components.
> >
> > One of the problems of having a core and inheritance is that you have to
> > get it right, but often there isn't one right answer.
> >
> > >I think
> > >Basic set (as is) will not be used at all since the final visuals are
> not
> > >production ready, so you know people will need this level of
> customization
> > >or they will never join FleJS for sure. and here you have the first
> > >example of many
> > >of the styles in flexjs needs to be removed in order to get the MDL
> branch
> > >working ok, and so will happen with others like Bootstrap, and so on...
> > >Only if we create our own FlexJS style design could take into account
> the
> > >actual styles, but I think that if MDL or Bootstrap does not need all of
> > >that, we should not need creating our own CSS set in the end (I can't
> say
> > >much more here since I'm not a CSS expert to affirm that, but based on
> > >what
> > >I see...is clear that it's the reality).
> > >
> >
> > In my mind, there are going to be two kinds of themes: pre-existing ones
> > like MDL and custom ones like the themes that regular Flex SDK customers
> > used to brand their applications. In the second kind, I don't think it
> > matters as much as to what default styles are. Folks will simply override
> > the defaults in their themes.
> >
> > I was a bit surprised that MDL didn't override everything we set as
> > defaults for HTML.swc. That means to me that if someone has certain
> > styles set elsewhere, even in their browser settings, that could cause
> > really strange and unexpected results. But OK, that's the way it is, and
> > so we should think of other ways to have a default look for HTML.swc,
> > although again, as I said above, the MDL library has no obligation to
> > inherit from HTML.swc.
> >
> > If we really need to support more inheritance, then maybe all visual
> > styles should be moved from HTML into some default theme. It would be
> > nice to have a better set of defaults that are a bit more production
> ready
> > for Basic so we can see how and why there are collisions between themes.
> >
> > >You could as well use documentation to expose requirements and make
> people
> > >know that 2 or 3 styles are required and if they remove from CSS things
> > >could break. We could prepare as well a MVCSS (minimum viable CSS) so
> > >people would not need to use the remove default compiler flag, and have
> > >another with relative positions, borders and other no-so required
> things,
> > >but needed in basic comp set.
> > >
> > >
> >
> > Way back in early Flex, we found our customers didn't like this. There
> > was a version of Flex where only the type-selectors with the same name as
> > the component was applied. So CheckBox extended Button and lots of
> styles
> > important to Button needed to be copied to the CheckBox type selector.
> > This was way faster at runtime because we didn't have to chase down the
> > super classes and their styles. But customers really complained because
> if
> > you subclassed Button and made a MyButton, you had to know which styles
> to
> > copy to a MyButton type selector or the component wouldn't work. I'm
> sure
> > our documentation was not sufficient, but even then, folks thought it was
> > a pain.
> >
> > If you want to ensure no styles are specified in code for the MDL library
> > feel free to do so. I'm just not sure how important tat is for the Basic
> > set.
> >
> > >
> > >> Similarly, Label isn't supposed to be interactive, so we turn off
> mouse
> > >> events. It is the equivalent of mouseEnabled in SWF. The way we
> found
> > >>to
> > >> do it is to set a style. Again, I'm not sure that should be settable
> > >>in a
> > >> CSS theme.
> > >>
> > >>
> > >I think so. If we could set the style in CSS and we are not doing this
> > >because we are afraid of our user...that's a very bad policy. There's
> > >other
> > >methods to avoid that. For example, if in MDL mouseEnabled is not
> > >contemplated...I would left in my CSS.
> > >
> > >
> > >
> > >> The way we handle visible=false also sets a style: display:none.
> > >
> > >
> > >that's one of the styles I historically use when doing some html, and
> > >always put in CSS...there's no reason not doing the same in FlexJS
> > >moreover
> > >taking into account this is a framework to craft things and nothing
> final.
> >
> > IMO, there are styles that are functional like display:none and
> > pointer-events and no-wrap and styles that are visual. For functional
> > styles, I'm not sure it is the easiest API to make folks work with all of
> > these CSS styles instead of through properties on the component,
> > especially properties that have a high likelihood of changing at runtime.
> > So that's why Basic has a visible and alpha properties. Seems nicer to
> > set those than have to set style.display = "none". Yes it means you
> can't
> > set things invisible by changing CSS themes, but again, someone is
> welcome
> > to create a different component set that does make folks use
> style.display
> > = "none".
> >
> > Again, going back to the first point. There is often no right answer, so
> > we are working hard to make sure FlexJS can support multiple independent
> > component sets so customers can choose the API surfaces that they like
> > best.
> >
> > My 2 cents,
> > -Alex
> >
> >
>
--
Carlos Rovira
Director General
M: +34 607 22 60 05
http://www.codeoscopic.com
http://www.avant2.es
Este mensaje se dirige exclusivamente a su destinatario y puede contener
información privilegiada o confidencial. Si ha recibido este mensaje por
error, le rogamos que nos lo comunique inmediatamente por esta misma vía y
proceda a su destrucción.
De la vigente Ley Orgánica de Protección de Datos (15/1999), le comunicamos
que sus datos forman parte de un fichero cuyo responsable es CODEOSCOPIC
S.A. La finalidad de dicho tratamiento es facilitar la prestación del
servicio o información solicitados, teniendo usted derecho de acceso,
rectificación, cancelación y oposición de sus datos dirigiéndose a nuestras
oficinas c/ Paseo de la Habana 9-11, 28036, Madrid con la documentación
necesaria.
Re: [FlexJS] get rid of inline styles (was Re: [FlexJS]Layout problems)
Posted by Josh Tynjala <jo...@gmail.com>.
Alex's first point about using the same beads, but not subclassing sounds
cleaner to me, Carlos. Kind of the same idea from the other day where all
components should be possible to recreate from UIBase with the right set of
beads. You should consider trying that out for MDL.
- Josh
On Dec 1, 2016 11:09 PM, "Alex Harui" <ah...@adobe.com> wrote:
> Re-ordering your post so I can address higher-level points first:
>
>
> On 12/1/16, 4:55 PM, "carlos.rovira@gmail.com on behalf of Carlos Rovira"
> <carlos.rovira@gmail.com on behalf of carlosrovira@apache.org> wrote:
> >
> >But Basic set is at the core of
> >all. Is at the core of MDL set
> >
> >
>
> This statement doesn't have to be true, and makes me think that the old
> Flex SDK mentality is persisting. IMO, the MDL set has no obligation to
> subclass the Basic set. The top-level components in the Basic set are
> supposed to be compositions of beads. MDL can just compose the same or
> different beads without having to subclass Basic components.
>
> One of the problems of having a core and inheritance is that you have to
> get it right, but often there isn't one right answer.
>
> >I think
> >Basic set (as is) will not be used at all since the final visuals are not
> >production ready, so you know people will need this level of customization
> >or they will never join FleJS for sure. and here you have the first
> >example of many
> >of the styles in flexjs needs to be removed in order to get the MDL branch
> >working ok, and so will happen with others like Bootstrap, and so on...
> >Only if we create our own FlexJS style design could take into account the
> >actual styles, but I think that if MDL or Bootstrap does not need all of
> >that, we should not need creating our own CSS set in the end (I can't say
> >much more here since I'm not a CSS expert to affirm that, but based on
> >what
> >I see...is clear that it's the reality).
> >
>
> In my mind, there are going to be two kinds of themes: pre-existing ones
> like MDL and custom ones like the themes that regular Flex SDK customers
> used to brand their applications. In the second kind, I don't think it
> matters as much as to what default styles are. Folks will simply override
> the defaults in their themes.
>
> I was a bit surprised that MDL didn't override everything we set as
> defaults for HTML.swc. That means to me that if someone has certain
> styles set elsewhere, even in their browser settings, that could cause
> really strange and unexpected results. But OK, that's the way it is, and
> so we should think of other ways to have a default look for HTML.swc,
> although again, as I said above, the MDL library has no obligation to
> inherit from HTML.swc.
>
> If we really need to support more inheritance, then maybe all visual
> styles should be moved from HTML into some default theme. It would be
> nice to have a better set of defaults that are a bit more production ready
> for Basic so we can see how and why there are collisions between themes.
>
> >You could as well use documentation to expose requirements and make people
> >know that 2 or 3 styles are required and if they remove from CSS things
> >could break. We could prepare as well a MVCSS (minimum viable CSS) so
> >people would not need to use the remove default compiler flag, and have
> >another with relative positions, borders and other no-so required things,
> >but needed in basic comp set.
> >
> >
>
> Way back in early Flex, we found our customers didn't like this. There
> was a version of Flex where only the type-selectors with the same name as
> the component was applied. So CheckBox extended Button and lots of styles
> important to Button needed to be copied to the CheckBox type selector.
> This was way faster at runtime because we didn't have to chase down the
> super classes and their styles. But customers really complained because if
> you subclassed Button and made a MyButton, you had to know which styles to
> copy to a MyButton type selector or the component wouldn't work. I'm sure
> our documentation was not sufficient, but even then, folks thought it was
> a pain.
>
> If you want to ensure no styles are specified in code for the MDL library
> feel free to do so. I'm just not sure how important tat is for the Basic
> set.
>
> >
> >> Similarly, Label isn't supposed to be interactive, so we turn off mouse
> >> events. It is the equivalent of mouseEnabled in SWF. The way we found
> >>to
> >> do it is to set a style. Again, I'm not sure that should be settable
> >>in a
> >> CSS theme.
> >>
> >>
> >I think so. If we could set the style in CSS and we are not doing this
> >because we are afraid of our user...that's a very bad policy. There's
> >other
> >methods to avoid that. For example, if in MDL mouseEnabled is not
> >contemplated...I would left in my CSS.
> >
> >
> >
> >> The way we handle visible=false also sets a style: display:none.
> >
> >
> >that's one of the styles I historically use when doing some html, and
> >always put in CSS...there's no reason not doing the same in FlexJS
> >moreover
> >taking into account this is a framework to craft things and nothing final.
>
> IMO, there are styles that are functional like display:none and
> pointer-events and no-wrap and styles that are visual. For functional
> styles, I'm not sure it is the easiest API to make folks work with all of
> these CSS styles instead of through properties on the component,
> especially properties that have a high likelihood of changing at runtime.
> So that's why Basic has a visible and alpha properties. Seems nicer to
> set those than have to set style.display = "none". Yes it means you can't
> set things invisible by changing CSS themes, but again, someone is welcome
> to create a different component set that does make folks use style.display
> = "none".
>
> Again, going back to the first point. There is often no right answer, so
> we are working hard to make sure FlexJS can support multiple independent
> component sets so customers can choose the API surfaces that they like
> best.
>
> My 2 cents,
> -Alex
>
>
Re: [FlexJS] get rid of inline styles (was Re: [FlexJS]Layout
problems)
Posted by Alex Harui <ah...@adobe.com>.
Re-ordering your post so I can address higher-level points first:
On 12/1/16, 4:55 PM, "carlos.rovira@gmail.com on behalf of Carlos Rovira"
<carlos.rovira@gmail.com on behalf of carlosrovira@apache.org> wrote:
>
>But Basic set is at the core of
>all. Is at the core of MDL set
>
>
This statement doesn't have to be true, and makes me think that the old
Flex SDK mentality is persisting. IMO, the MDL set has no obligation to
subclass the Basic set. The top-level components in the Basic set are
supposed to be compositions of beads. MDL can just compose the same or
different beads without having to subclass Basic components.
One of the problems of having a core and inheritance is that you have to
get it right, but often there isn't one right answer.
>I think
>Basic set (as is) will not be used at all since the final visuals are not
>production ready, so you know people will need this level of customization
>or they will never join FleJS for sure. and here you have the first
>example of many
>of the styles in flexjs needs to be removed in order to get the MDL branch
>working ok, and so will happen with others like Bootstrap, and so on...
>Only if we create our own FlexJS style design could take into account the
>actual styles, but I think that if MDL or Bootstrap does not need all of
>that, we should not need creating our own CSS set in the end (I can't say
>much more here since I'm not a CSS expert to affirm that, but based on
>what
>I see...is clear that it's the reality).
>
In my mind, there are going to be two kinds of themes: pre-existing ones
like MDL and custom ones like the themes that regular Flex SDK customers
used to brand their applications. In the second kind, I don't think it
matters as much as to what default styles are. Folks will simply override
the defaults in their themes.
I was a bit surprised that MDL didn't override everything we set as
defaults for HTML.swc. That means to me that if someone has certain
styles set elsewhere, even in their browser settings, that could cause
really strange and unexpected results. But OK, that's the way it is, and
so we should think of other ways to have a default look for HTML.swc,
although again, as I said above, the MDL library has no obligation to
inherit from HTML.swc.
If we really need to support more inheritance, then maybe all visual
styles should be moved from HTML into some default theme. It would be
nice to have a better set of defaults that are a bit more production ready
for Basic so we can see how and why there are collisions between themes.
>You could as well use documentation to expose requirements and make people
>know that 2 or 3 styles are required and if they remove from CSS things
>could break. We could prepare as well a MVCSS (minimum viable CSS) so
>people would not need to use the remove default compiler flag, and have
>another with relative positions, borders and other no-so required things,
>but needed in basic comp set.
>
>
Way back in early Flex, we found our customers didn't like this. There
was a version of Flex where only the type-selectors with the same name as
the component was applied. So CheckBox extended Button and lots of styles
important to Button needed to be copied to the CheckBox type selector.
This was way faster at runtime because we didn't have to chase down the
super classes and their styles. But customers really complained because if
you subclassed Button and made a MyButton, you had to know which styles to
copy to a MyButton type selector or the component wouldn't work. I'm sure
our documentation was not sufficient, but even then, folks thought it was
a pain.
If you want to ensure no styles are specified in code for the MDL library
feel free to do so. I'm just not sure how important tat is for the Basic
set.
>
>> Similarly, Label isn't supposed to be interactive, so we turn off mouse
>> events. It is the equivalent of mouseEnabled in SWF. The way we found
>>to
>> do it is to set a style. Again, I'm not sure that should be settable
>>in a
>> CSS theme.
>>
>>
>I think so. If we could set the style in CSS and we are not doing this
>because we are afraid of our user...that's a very bad policy. There's
>other
>methods to avoid that. For example, if in MDL mouseEnabled is not
>contemplated...I would left in my CSS.
>
>
>
>> The way we handle visible=false also sets a style: display:none.
>
>
>that's one of the styles I historically use when doing some html, and
>always put in CSS...there's no reason not doing the same in FlexJS
>moreover
>taking into account this is a framework to craft things and nothing final.
IMO, there are styles that are functional like display:none and
pointer-events and no-wrap and styles that are visual. For functional
styles, I'm not sure it is the easiest API to make folks work with all of
these CSS styles instead of through properties on the component,
especially properties that have a high likelihood of changing at runtime.
So that's why Basic has a visible and alpha properties. Seems nicer to
set those than have to set style.display = "none". Yes it means you can't
set things invisible by changing CSS themes, but again, someone is welcome
to create a different component set that does make folks use style.display
= "none".
Again, going back to the first point. There is often no right answer, so
we are working hard to make sure FlexJS can support multiple independent
component sets so customers can choose the API surfaces that they like
best.
My 2 cents,
-Alex
Re: [FlexJS] get rid of inline styles (was Re: [FlexJS]Layout problems)
Posted by Carlos Rovira <ca...@apache.org>.
> I wish I could agree, but I don't think I can. IMO, some component
> features can only be implemented by setting style properties. In the
> example above, to keep Label as single-line (so you don't have to us  
> and can just use space), we must set white-space:no-wrap. Allowing folks
> to tweak things like that in the CSS seems dangerous to me.
>
>
But, this is user choice. If I stick with styles in css, or I want some of
it, I'm free to keep them or remove for my
use case. keeping It hard-code to avoid people that don't want that be
forced to use is very bad policy IMHO.
You could as well use documentation to expose requirements and make people
know that 2 or 3 styles are required and if they remove from CSS things
could break. We could prepare as well a MVCSS (minimum viable CSS) so
people would not need to use the remove default compiler flag, and have
another with relative positions, borders and other no-so required things,
but needed in basic comp set.
> Similarly, Label isn't supposed to be interactive, so we turn off mouse
> events. It is the equivalent of mouseEnabled in SWF. The way we found to
> do it is to set a style. Again, I'm not sure that should be settable in a
> CSS theme.
>
>
I think so. If we could set the style in CSS and we are not doing this
because we are afraid of our user...that's a very bad policy. There's other
methods to avoid that. For example, if in MDL mouseEnabled is not
contemplated...I would left in my CSS.
> The way we handle visible=false also sets a style: display:none.
that's one of the styles I historically use when doing some html, and
always put in CSS...there's no reason not doing the same in FlexJS moreover
taking into account this is a framework to craft things and nothing final.
>
> But position is a tricky and separate topic. Someone needs to prove that
> none of the examples break if we don't set position to relative or
> absolute the way we do it now.
Right, If I'd make the changes I would have to test examples as I move
things from code to CSS. and if something can not be done left untouched or
until we get a way to do it.
> The comment in Container.as says:
>
> // absolute positioned children need a non-null
> // position value in the parent. It might
> // get set to 'absolute' if the container is
> // also absolutely positioned
>
> So that implies that if you put a child in a Container and set its x or y
> value, it won't work unless we set position to absolute or relative.
> That's making me think that the test case is a nested set of Containers
> with a child in the inner container with x,y position.
Right, but again that's in the people using the basic set, and not for
potential user that will want to use FlexJS for their own use cases.
We are setting the basis of the technology. The building blocks. And as
building block, those should come free of charges.
I'm creating MDL only to show people some beautiful FlexJS screens that
make people jump (since people buys for what they see more quick and I
think this is a urgent need for us right now)...but I assume that few
people will end using that (I think) and will want to customize more their
experiences. Maybe I could expect 5%-15%...people using MDL set? I think
Basic set (as is) will not be used at all since the final visuals are not
production ready, so you know people will need this level of customization
or they will never join FleJS for sure. But Basic set is at the core of
all. Is at the core of MDL set and here you have the first example of many
of the styles in flexjs needs to be removed in order to get the MDL branch
working ok, and so will happen with others like Bootstrap, and so on...
Only if we create our own FlexJS style design could take into account the
actual styles, but I think that if MDL or Bootstrap does not need all of
that, we should not need creating our own CSS set in the end (I can't say
much more here since I'm not a CSS expert to affirm that, but based on what
I see...is clear that it's the reality).
--
Carlos Rovira
http://about.me/carlosrovira
Re: [FlexJS] get rid of inline styles (was Re: [FlexJS]Layout
problems)
Posted by Alex Harui <ah...@adobe.com>.
On 12/1/16, 4:01 PM, "carlos.rovira@gmail.com on behalf of Carlos Rovira"
<carlos.rovira@gmail.com on behalf of carlosrovira@apache.org> wrote:
>to separate things:
>
>Such as? Depending on your layout, left, top, width, and height will be
>> set in CSS. In UIBase, setting the x value sets style.left, etc. If
>> there is an alternative, please let me know what it is.
>> -Alex
>>
>>
>I get this:
>
><div style="position: relative;"><span class="Label" style="white-space:
>nowrap; cursor: default; pointer-events: none;">some text</span><button
>type="button" class="TextButton" style="position: relative;">a
>button</button></div>
>
>from this:
>
><js:Container>
> <js:Label text="some text"/>
> <js:TextButton text="a button"/>
> </js:Container>
Ah, ok, I didn't understand what you meant by "kilometric".
>
>in my MDLExample (take into account that I use exclude default CSS
>compiler
>param)
>
>So as you see there's lots of "style" properties above that should not be.
>
>The right output should be:
>
><div><span class="Label">some text</span><button type="button"
>class="TextButton">a button</button></div>
>
>So as I use compiler option exclude default css file I ensure my app only
>has the css I put, and not carry anything I don't want.
>
>
>why this is happen? To take only one example. In js:Container line 104
>there's:
>
>positioner.style.position = 'relative';
>
>this should remove from there and put in defaults.css line 93
>
>Container
>{
> position = 'relative';
> ....
>
>
>Do you agree with that?
I wish I could agree, but I don't think I can. IMO, some component
features can only be implemented by setting style properties. In the
example above, to keep Label as single-line (so you don't have to us  
and can just use space), we must set white-space:no-wrap. Allowing folks
to tweak things like that in the CSS seems dangerous to me.
Similarly, Label isn't supposed to be interactive, so we turn off mouse
events. It is the equivalent of mouseEnabled in SWF. The way we found to
do it is to set a style. Again, I'm not sure that should be settable in a
CSS theme.
The way we handle visible=false also sets a style: display:none. And as I
mentioned, setting x,y,width,height also set style properties, so I think
it is ok for style properties to be set in component code.
I would agree that most or maybe all style properties that affect the
visuals (border, padding, margin, color, fonts) should not be set in
component code and only via defaults.css.
But position is a tricky and separate topic. Someone needs to prove that
none of the examples break if we don't set position to relative or
absolute the way we do it now. The comment in Container.as says:
// absolute positioned children need a non-null
// position value in the parent. It might
// get set to 'absolute' if the container is
// also absolutely positioned
So that implies that if you put a child in a Container and set its x or y
value, it won't work unless we set position to absolute or relative.
That's making me think that the test case is a nested set of Containers
with a child in the inner container with x,y position. IIRC, having
BasicLayout which supports x,y values set the position style on the
Container isn't good enough. Maybe it needs to walk the parent chain and
set position an all parents, but that seems dangerous as well. If you
have time to test that out and propose a better solution, that would be
great.
Thanks,
-Alex