flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Ent <p...@adobe.com>
Subject Re: [FlexJS] Applying Styles
Date Thu, 30 Jun 2016 20:51:14 GMT

I've spent some time looking into styling the basic FlexJS component set.
The result is a new example, StyleExample, which I've just checked into
the FlexJS repository.

I took a very simple approach and in doing so, uncovered a couple of bugs
and added some parts. For example, I broke up the RadioButton and
CheckButton so that you can target the icon part and the <input> part
separately via CSS selectors. I did similar things for other components.
In the end, the exercise is more about providing a how-to rather than
coming up with a default style for the basic components.

There are some differences still between SWF and HTML. For example, the
HTML version has a border around the DataGrid and it is missing in the SWF
version; I'll be working on that now.

Peter Ent
Adobe Systems/Apache Flex Group

On 6/15/16, 10:06 AM, "Peter Ent" <pent@adobe.com> wrote:

>After looking over the Material stuff and seeing what the FlexJS Basic
>component set is capable of, I think a grayscale theme would be best. It
>would be neutral to allow browser-specific colors in controls and focus
>while still providing a decent look to the components.
>I'll let everyone know when I have something.
>Thanks for the input and keep it coming. More comments from me inline,
>On 6/15/16, 4:57 AM, "carlos.rovira@gmail.com on behalf of Carlos Rovira"
><carlos.rovira@gmail.com on behalf of carlos.rovira@codeoscopic.com>
>>I think as well that Material Design should be the base and Bootstrap
>>be good as well, but for me in second place.
>>For SWF, I think FlexJS is more about HTML, so I will put all my efforts
>>good-looking HTML and let SWF version to be wireframe looking with the
>>recipients to make the work, but postpone that work for a later time or
>>people come to volunteer in that part.
>I don't think this is a bad idea, really. SWF can still be used to debug.
>As long as the items take up the same space and are placed correctly, not
>having the right style complexity could be a OK - for the basic component
>set. Once you start getting more complex you'll expect the SWF and HTML
>sides to be closer, I think.
>>2016-06-15 9:11 GMT+02:00 jude <flexcapacitor@gmail.com>:
>>> What I ran into with the drop in themes is that they sometimes change
>>> size and shape of the components. I had a project where I dropped in
>>> and the elements were all cut off because the width and height were
>>> explicitly set. It wasn't hard to fix after the fact but some things
>>> weren't sized and positioned where as I expected. The only thing I can
>>> to this is to make sure the UI in the SWF and HTML match as closely as
>>> possible.
>>> On Tue, Jun 14, 2016 at 6:03 PM, Alex Harui <aharui@adobe.com> wrote:
>>> >
>>> >
>>> > On 6/14/16, 3:25 PM, "jude" <flexcapacitor@gmail.com> wrote:
>>> >
>>> > >If you're using the default HTML elements I would have no
>>>expectation. I
>>> > >would expect the developer or designer to add their own skin set
>>> > >FlatUI at a later time.
>>> > >
>>> > >But if you want a default style I would think there might be a happy
>>> > >medium
>>> > >with SVG skins. A while back Om made a SVG skin that looked
>>>identical to
>>> > >the Spark Button skin. It wouldn't be as much work as a full
>>> set
>>> > >because the components aren't aware of them (they are backgrounds)
>>> > >it's
>>> > >easy to see what was going on and how to change them.
>>> > >
>>> > >Pseudo states
>>> > >https://developer.mozilla.org/en-US/docs/Web/CSS/Pseudo-classes
>>> > >
>>> > >Is the goal for the SWF and the HTML UI to look exactly the same?
>>> >
>>> > Yes, it is a goal.
>>> >
>>> > Seems like we should try to do Material, but in my quick reading, it
>>> > allows for lots of different implementations, which is good because
>>> > we can create a simple enough version for our current CSS support.
>>> > like there are a bunch of different Material UI frameworks out there.
>>> > Supporting them out-of-the-box would be cool, but in looking at a few
>>> > github repos, it looks like they are also not relying on
>>> > HTMLElements.  In general, Material and Bootstrap designers want to
>>> > a few things that CSS doesn't allow you to style such as the actual
>>> > or check visuals in radio buttons and check boxes, so they wrap a
>>> or
>>> > check with a bunch of other stuff to make it work.  What I think we
>>> > for our basic set is the nicest possible look you can get without all
>>> > that wrapping.  Is the browser-native radio and check in violation of
>>> > Material spec?  If so, we may need to do some "approximating".
>>> >
>>> > Supporting Material as SVG might also be cool, but IMO, loading all
>>> > those background doesn't make for the minimal set.  But definitely
>>> > pursuing as a separate theme/component set.
>>> >
>>> > -Alex
>>> >
>>> >
>>Carlos Rovira
>>Director General
>>M: +34 607 22 60 05
>>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
>>proceda a su destrucción.
>>De la vigente Ley Orgánica de Protección de Datos (15/1999), le
>>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
>>oficinas c/ Paseo de la Habana 9-11, 28036, Madrid con la documentación

View raw message