On 10/10/16, 2:43 PM, "Alex Harui" <aha...@adobe.com> wrote:
> >IMO, there are at least two valid approaches. I honestly don't favor one >over the other. I thought of a third, that may or may not work for MDL depending on how much, if at all, MDL requires configuration via CSS. There will someday be a skinnable component set for FlexJS. It won't be as lightweight as the basic set, but that is PAYG. Then, MDL is implemented more or less like other Flex themes. Vectors and code (and maybe some CSS) describe the visuals. AIUI, FXG would be used on the SWF side and converted to SVG on the JS side. -Alex > >1) Custom Component Set. This is sort of what we tried in Flat.swc. We >created subclasses of existing components and customized some CSS (based >on the FlatUI css files) to get the look and feel we wanted. In doing so, >for now at least, we "dumbed-down" the CSS to what FlexJS is currently >capable of (simple class and id selectors). There are no advanced >selectors. Anything requiring advanced selectors was skipped, or was >re-engineered via subclassing and the extensible type selector model I >mentioned above. The important takeaway is that by doing "more work", you >can probably create any look and feel you want today in FlexJS >2) CSS as Theme. At some point in time, I think we want to allow someone >to build out their UI in MXML, set className and id properties, and then >drop in an existing third-party CSS file and it would "just work" just >like if you switched the css file out on an equivalent .html file. Or >maybe you'd have to thinly-wrap the third-party code, I don't know. The >JS side is probably mostly ready to do this, but it would require a lot of >work on the SWF side to handle a CSS lookup that is essentially >standards-compliant. The SWF side code would have to handle all advanced >CSS selectors and directives since in my brief tour of Flat and BootStrap, >they leverage a lot of fancy CSS. > >In sum, if you've got time, we could probably fashion a set of components >that look like they follow MDL. But the dream is that we would thinly >wrap an existing 3rd-party library and it would "just work". That is >currently more work today, but someday, that might be the preferred path.
