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" <aha...@adobe.com> wrote: > Re-ordering your post so I can address higher-level points first: > > > On 12/1/16, 4:55 PM, "carlos.rov...@gmail.com on behalf of Carlos Rovira" > <carlos.rov...@gmail.com on behalf of carlosrov...@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 > >
