Sounds like there is consensus to implement Material. Again, though, I would like to see the Basic components be as basic as possible: a <button /> for Button, a <span /> for Label, etc. AIUI, there is no way to get control over every pixel. On my Mac, with the OS theme I've selected, the browser is going to show a blue radio for the radio button. And preferably, the CSS files we end up will not be huge. Hopefully, that will be sufficient for folks if what we end up with for the Basic components isn't true Material.
A separate component set is probably needed to fully implement Material and control every pixel. I would like to see that happen too. And it would be fine for early versions of the SWF equivalents to not replicate every pixel, and wireframe the right bounding boxes, but I believe that the SWF-side CSS implementation would need upgrading to even do that. Especially to take an existing Material implementation on the JS side and emulate it on the SWF-side. The kinds of advanced CSS I've seen in the FlatUI theme, for example is beyond what even regular Flex could do. Also on our to-do list is better Media Query support so you can have different settings for different media/platforms/devices etc. -Alex On 6/15/16, 8:58 AM, "carlos.rov...@gmail.com on behalf of Carlos Rovira" <carlos.rov...@gmail.com on behalf of carlos.rov...@codeoscopic.com> wrote: >Peter, I think the same, a good looking white-grey default theme would be >perfect as default. >Then people could customize or change theme. > >Thanks > >2016-06-15 16:06 GMT+02:00 Peter Ent <p...@adobe.com>: > >> 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, >> below. >> >> ‹peter >> >> On 6/15/16, 4:57 AM, "carlos.rov...@gmail.com on behalf of Carlos >>Rovira" >> <carlos.rov...@gmail.com on behalf of carlos.rov...@codeoscopic.com> >> wrote: >> >> >I think as well that Material Design should be the base and Bootstrap >> >would >> >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 >> >in >> >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 if >> >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. >> >> > >> >Thanks >> > >> >2016-06-15 9:11 GMT+02:00 jude <flexcapaci...@gmail.com>: >> > >> >> What I ran into with the drop in themes is that they sometimes change >> >>the >> >> size and shape of the components. I had a project where I dropped in >> >>FlatUI >> >> 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 >> >>add >> >> 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 <aha...@adobe.com> wrote: >> >> >> >> > >> >> > >> >> > On 6/14/16, 3:25 PM, "jude" <flexcapaci...@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 >>like >> >> > >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 >>skinning >> >> set >> >> > >because the components aren't aware of them (they are backgrounds) >> >>but >> >> > >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 >> >>maybe >> >> > we can create a simple enough version for our current CSS support. >> >>Looks >> >> > 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 >>simple/single >> >> > HTMLElements. In general, Material and Bootstrap designers want to >> >>style >> >> > a few things that CSS doesn't allow you to style such as the actual >> >>radio >> >> > or check visuals in radio buttons and check boxes, so they wrap a >> >>radio >> >> or >> >> > check with a bunch of other stuff to make it work. What I think we >> >>want >> >> > for our basic set is the nicest possible look you can get without >>all >> >>of >> >> > that wrapping. Is the browser-native radio and check in violation >>of >> >>the >> >> > Material spec? If so, we may need to do some "approximating". >> >> > >> >> > Supporting Material as SVG might also be cool, but IMO, loading >>all of >> >> > those background doesn't make for the minimal set. But definitely >> >>worth >> >> > pursuing as a separate theme/component set. >> >> > >> >> > -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.
