Mailing-List: contact dev-help@flex.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@flex.apache.org
MIME-Version: 1.0
In-Reply-To: <CAMFKFRjb8cAu22s+WucX4pfPG2_tSONnNRUaipr8ZB7fssxmtw@mail.gmail.com>
References: <CAMFKFRiWsGPf2dy7U4dcGWPKXbSag58vckF6bhLBrYM4t5eQOQ@mail.gmail.com>
 <D465FC0E.7BCB4%aharui@adobe.com> <CAMFKFRhmzx21-2_P99YUvbu9Cb_ju530ePS_LbYCtMGOeXYogA@mail.gmail.com>
 <D466564A.7BD2F%aharui@adobe.com> <CADZSWG5M7inCuAqcHUV68AWjQCA2biFWZ70Hf3UVTrUh5TAWug@mail.gmail.com>
 <CAMFKFRjb8cAu22s+WucX4pfPG2_tSONnNRUaipr8ZB7fssxmtw@mail.gmail.com>
From: flex capacitor <flexcapacitor@gmail.com>
Date: Sat, 10 Dec 2016 10:13:34 -0600
Message-ID: <CANcBHEDS_ip07QChJvZrS1=G329yLwZE8qDTu_Wgioy4PGBRdQ@mail.gmail.com>
Subject: Re: [FlexJS] get rid of inline styles (was Re: [FlexJS]Layout problems)
To: dev <dev@flex.apache.org>
Content-Type: multipart/alternative; boundary=94eb2c04b9181158b2054350273f
archived-at: Sat, 10 Dec 2016 16:13:45 -0000

--94eb2c04b9181158b2054350273f
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

In Radiate I convert Flex UIComponents to HTML components and had this
problem. I made an option to allow styles to be defined inline or in a
style sheet. If the option was stylesheet then if the component had an id
the styles were declared by id. This included position, size, etc:

#myLabel {
     style: value;
}

If the component didn't have an id too bad. I'd give it an id using Flex
naming utils class and again declare styles there.

But I added an option to let developers override the styles per component
and that might work here.

So you would have a components style declaration by id and then in Radiate
there is a user styles field. Any values in that field would be declared in
the style declaration but they would be placed at the end. Everybody knows
that last declaration wins, even grandma.

#myLabel {
     style: value; /*define by framework */
     style: newValue; /*  defined by user */
}

You could also declare style: inherit and I think that resets the value.
Yes, the style is declared twice. Who cares. But yes to look pretty, I plan
to remove the first declaration or comment it out in a future update.

If Flex JS made some combination of class and class#id it might be an
option so that you can declare your own style declaration afterwards and
restore the defaults. Yes there might be two style declarations but at
least then they wouldn't be defined inline.

On Dec 2, 2016 11:52 AM, "Carlos Rovira" <carlos.rovira@codeoscopic.com>
wrote:

> Hi Josh,
>
> right. As I get some few components more, I think I could refactor removi=
ng
> 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 soun=
ds
> > cleaner to me, Carlos. Kind of the same idea from the other day where a=
ll
> > components should be possible to recreate from UIBase with the right se=
t
> 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 o=
ld
> > > 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 ar=
e
> > > 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 ar=
e
> > 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 accoun=
t
> > the
> > > >actual styles, but I think that if MDL or Bootstrap does not need al=
l
> 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 caus=
e
> > > 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 b=
e
> > > 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) s=
o
> > > >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.  The=
re
> > > was a version of Flex where only the type-selectors with the same nam=
e
> 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 t=
he
> > > super classes and their styles. But customers really complained becau=
se
> > if
> > > you subclassed Button and made a MyButton, you had to know which styl=
es
> > 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 th=
is
> > > >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=3Dfalse also sets a style: display:none.
> > > >
> > > >
> > > >that's one of the styles I historically use when doing some html, an=
d
> > > >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 functiona=
l
> > > styles, I'm not sure it is the easiest API to make folks work with al=
l
> 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 =3D "none".  Yes it means yo=
u
> > 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
> > > =3D "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 lik=
e
> > > 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=C3=B3n privilegiada o confidencial. Si ha recibido este mensaje=
 por
> error, le rogamos que nos lo comunique inmediatamente por esta misma v=C3=
=ADa y
> proceda a su destrucci=C3=B3n.
>
> De la vigente Ley Org=C3=A1nica de Protecci=C3=B3n 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=C3=B3n de=
l
> servicio o informaci=C3=B3n solicitados, teniendo usted derecho de acceso=
,
> rectificaci=C3=B3n, cancelaci=C3=B3n y oposici=C3=B3n de sus datos dirigi=
=C3=A9ndose a nuestras
> oficinas c/ Paseo de la Habana 9-11, 28036, Madrid con la documentaci=C3=
=B3n
> necesaria.
>

--94eb2c04b9181158b2054350273f--