> 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
