flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carlos Rovira <carlos.rov...@codeoscopic.com>
Subject Re: [FlexJS] get rid of inline styles (was Re: [FlexJS]Layout problems)
Date Fri, 02 Dec 2016 17:52:26 GMT
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 <joshtynjala@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" <aharui@adobe.com> wrote:
>
> > Re-ordering your post so I can address higher-level points first:
> >
> >
> > On 12/1/16, 4:55 PM, "carlos.rovira@gmail.com on behalf of Carlos
> Rovira"
> > <carlos.rovira@gmail.com on behalf of carlosrovira@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.

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message