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 <joshtynj...@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" <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 > > > > > -- 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.
