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] CSS (was Re: [FlexJS] Mobile Apps)
Date Mon, 24 Oct 2016 21:16:14 GMT
I love beads, but in this case I think it would be very verbose don't you
think?

for example in Button:

All has the same two selectors : mdl-button mdl-js-button (in my
implementation this goes always)

Then we have 8 optional selectors that could be combined in many ways.

So for me de default button is the one with two selectors, then people will
use normal a combinations of 1 to 3 of the 8.

So instead of

<mdl:Button>
    <mdl:Beads>
        <mdl:effect1>
        <mdl:effect2>
        <mdl:effect3>
    </mdl:Beads>
</mdl:Button>

Taking into account that this is only a class selector assign...

I will prefer:

<mdl:Button effect="effect1 effect2 effect3"/>

I think beads would be great to encapsulate more complex optional
code,...but in this case, don't you think is very bloated for this
particular case?

If finaly you all think beads is better, we would go that way...but for me
at least, seems not the right way.

Thanks

just my 2...

C.





2016-10-24 22:09 GMT+02:00 OmPrakash Muppirala <bigosmallm@gmail.com>:

> +1 for implementing it based on beads.
>
> mdl:DefaultMDLButton would look like this:
> <mdl:Button>
>     <mdl:Beads>
>         <mdl:InkRipple>
>         <mdl:FAB>
>     </mdl:Beads>
> </mdl:Button>
>
> We could simply use DefaultMDLButton in our code instead of having to write
> out all the beads, if the user so chooses.
>
> Thanks,
> Om
>
>
> On Mon, Oct 24, 2016 at 12:10 PM, Josh Tynjala <joshtynjala@gmail.com>
> wrote:
>
> > I like Alex's suggestion of making beads for each variation you can add
> > (fab, ripple, etc.). Feels like the FlexJS way to do it.
> >
> > - Josh
> >
> > On Oct 24, 2016 11:18 AM, "Carlos Rovira" <carlos.rovira@codeoscopic.com
> >
> > wrote:
> >
> > Ok, I see,
> >
> > right now I'm using something like you say:
> >
> > while the base class selectors are asigned in AS3 MDL Button Code
> > component:
> >
> > element.className = 'mdl-button mdl-js-button';
> >
> > In example's use I specialize, since there is 8 selectors, and seems to
> me
> > many combinations to make classes, So:
> >
> > <!-- Fab button -->
> >                     <mdl:Button mdlEffect="mdl-button--fab
> > mdl-button--colored">
> >                         <i class="material-icons">add</i>
> >                     </mdl:Button>
> >
> >                     <!-- Fab with Ripple -->
> >                     <mdl:Button mdlEffect="mdl-button--fab
> > mdl-js-ripple-effect">
> >                         <i class="material-icons md-48">face</i>
> >                     </mdl:Button>
> >
> > So you think this is the best we could get to simplify?
> >
> >
> >
> >
> > 2016-10-24 17:21 GMT+02:00 Alex Harui <aharui@adobe.com>:
> >
> > >
> > >
> > > On 10/24/16, 2:42 AM, "carlos.rovira@gmail.com on behalf of Carlos
> > Rovira"
> > > <carlos.rovira@gmail.com on behalf of carlosrovira@apache.org> wrote:
> > >
> > > >> Here's another idea idea:  what if there was a compiler option that
> > > >>would
> > > >> override the xmlns in the MXML files?
> > > >>
> > > >>   mxmlc -compiler.mxml.xmlns=js,library://ns.apache.org/flexjs/mdl
> > > >>
> > > >>
> > > >That would be ok, but it seems a bit tacky to me...my vote would be
> not
> > > >introduce things like this and keep it as clean as possible.
> > > >
> > > >
> > > >
> > > >>
> > > >> Just so I'm clear, is your concern that you don't like setting the
> > > >> className property in ActionScript?  But isn't that essentially how
> > you
> > > >> would do it in HTML?  IOW, you would open an HTML editor and write:
> > > >>
> > > >>    <html>
> > > >>      <body>
> > > >>         <button class="mdl-button" />
> > > >>
> > > >> IMO, what we are doing in writing AS components is taking common
> > > >>patterns
> > > >> from HTML and reproducing them in AS.  So I'm not really sure it is
> > > >>wrong
> > > >> to be setting className="mdl-button" in the Button.as for the
> MDL.swc.
> > > >>
> > > >
> > > >What I don't really one is to end declaring a "height" or "color" or
> > > >"className" in component code. I feel it like is very bad. don't you?.
> > >
> > > I don't think setting className is bad if it is what you normally do
> when
> > > hand-coding HTML.  Setting height in code would probably be bad.
> Setting
> > > height in a defaults.css may be ok if that is the default you want for
> > > that component set.
> > >
> > >
> > > >I do it in order to continue progressing, but don't like it as final
> > since
> > > >this shouldn't be applied in the component.
> > > >If I have a MDL component set...is clear that I should use
> "mdl-button"
> > > >(in
> > > >a button), but there's some optional params to get different mdl
> buttons
> > > >(fab, raised, with ripple...i.e: mdl-button--fab) so maybe in the MDL
> > > >Button it could be a tag attribute like "mdlEffect", that could set as
> > > >"fabAndRipple" or "raised"... (but in my actual implementation, that I
> > > >don't think it should be final).
> > > >
> > > >Thinking about what I would like to have: if we want to end with
> > js:Button
> > > >getting a MDL style and effect, that's not the way. First, we must
> make
> > > >possible to clean all styles inside component code (Core.js or
> HTML.swc
> > > >should not have any style config in code), and then apply it as
> external
> > > >CSS. If I want to change default for mdl style, I think we could
> > introduce
> > > >something new like:
> > > >
> > > >js|Button {
> > > > className: mdl-button mdl-js-button mdl-button--fab
> > mdl-button--colored;
> > > >
> > > >}
> > > >
> > > >(maybe thinking loud)
> > > >
> > > >...or something similar. This would allow great flexibility without
> > mixing
> > > >control and styling.
> > > >
> > > >Of course, in addition I should need to change DOM composition
> > overriding
> > > >the Button's createElement method (...and maybe this could be done as
> > well
> > > >vía config ?...but maybe to think at later time ;))
> > > >
> > > >what do you think?
> > >
> > > IMO, being able to change the DOM subtree based on CSS is not a good
> idea
> > > unless the browsers can do it for you.  Otherwise, there will be
> if/then
> > > statements in our code examining the CSS and determining what elements
> to
> > > create.  That is not pay-as-you-go.  As a code minimalist, if/then
> > > statements are a bad thing if you don't need to change something at
> > > runtime.  Assuming many folks pick their theme at compile time, the
> tool
> > > chain should select the right code tuned for that theme.  That's why I
> > > want to pair a SWC with components with different createElement
> subtrees
> > > with the defaults.css that goes with it.
> > >
> > > IMO, the fact that CSS has "class" selectors means that they intended
> for
> > > the "class" property to define new classes for the CSS Engine.  So,
> IMO,
> > > each unique set of class selectors should map to a true ActionScript
> > class
> > > in FlexJS.  So, not only would you have a Button class, but also a
> > > RaisedButton, FabButton, and even a FabAndRaisedButton.  That way the
> API
> > > documentation better identifies the common patterns available.
> > >
> > > If there are other class selector options that are more like attributes
> > or
> > > flavors instead of classes, or you think the number of combinations
> would
> > > be overwhelming, you could also define beads and have the FabBead
> append
> > > the mdl-button--fab to the className list.
> > >
> > > If you have a "base" set of selectors that all Buttons must have, you
> can
> > > override the className setter to make sure those selectors are
> > > automatically added to the list.  There is also a "typeNames" property
> > > that appends certain selectors to the list of classNames. If we need to
> > > have some prepended, we could add that as well.
> > >
> > > Of course, anyone is welcome to build out a component set that does
> take
> > > the time to switch the dom tree at runtime, but the basic component set
> > > probably shouldn't do that, and the tool chain is going to learn how to
> > > package styles with code in a SWC and have replacement of SWCs replace
> > the
> > > defaults.css as well.  It occurred to me this morning that I don't
> really
> > > know why the Button selector keeps ending up in the output in the first
> > > place.  I will look at that at some point.
> > >
> > > -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.
> >
>



-- 

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