> 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).