On Thu, Dec 1, 2016 at 4:55 PM, Carlos Rovira <carlosrov...@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.
Some component developers use the *!important *rule to 'protect' their
carefully constructed css classes.
> > 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
> > do it is to set a style. Again, I'm not sure that should be settable in
> > 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