Thanks for your prompt reply Alex, I will add JIRA items for defects I did a little bit for deep digging into the CSS file generated & can see that it would barely work. I have a certain itch to make the sample application look beautiful so I will try to make it work with the consensus from group here.
I read both Om's & Alex's option, as a classic Flex application developer, I absolutely love to be able to able to specify basic style overrides on the component declaration itself without sub classing on the CSS; it's a huge productivity boost I guess here are the design considerations 1) Inline styling would though add quite a bit of code to the component, how do we define the basic style properties that would be available for inline declaration (I can see that this can be frustration for few users). 2) I agree with that just in-line styles should not be the way to go & as new style properties come around & start getting supported by modern browsers, SDK modification should not be necessary for consumers to use it. 3) Internet explorer 8 is not going anywhere near term in the enterprises for sure & people would be tempted to use CSS goodies provided by the modern browsers, does SCSS makes more sense? Thanks, Pratyoosh -----Original Message----- From: omup...@gmail.com [mailto:omup...@gmail.com] On Behalf Of OmPrakash Muppirala Sent: Tuesday, September 03, 2013 8:13 PM To: dev@flex.apache.org Subject: Re: [FlexJS] General questions On Tue, Sep 3, 2013 at 5:03 PM, Alex Harui <aha...@adobe.com> wrote: > > > On 9/3/13 4:55 PM, "OmPrakash Muppirala" <bigosma...@gmail.com> wrote: > > >On Tue, Sep 3, 2013 at 4:38 PM, Alex Harui <aha...@adobe.com> wrote: > > > >> Good question. I added a FalconJX and FlexJS component to JIRA. > >> Please submit patches there. There is already a Falcon component. > >> > >> In theory, if you have problems compiling a SWF that FB/MXMLC > >>compiled, then file the bug against Falcon. If Falcon compiled the > >>SWF but you get an error creating the JS version, file the bug > >>against FalconJX, and if there is a bug in the AS or JS code, file > >>the bug against FlexJS. > >> > >> The styling implementation on JS is not yet complete, so you can't > >>use non-standard CSS styles in JS right now. But the goal is to > >>support the appropriate CSS styles in the SWF since those styles should > >>"just work" > >>in > >> the browser. > >> > >> In-line styles (like <basic:Foo color="red" />) isn't supported yet > >> either. I'm on the fence about whether to keep adding > >> styles/properties or just use HTML's styles object (like <basic:Foo > >> style="color:red" />). > >> Some properties like "width" also support being set in CSS. > >> Opinions welcome. > >> > > > >It would be nice if we retained the current Flex way of inlining > >styles/properties, please. > I assume your main reason is compatibility? That's definitely a > strong argument, but here's the counter-argument: > > IMO, a pain point in Flex was that styles had to be specified on the > component when the style implementation was actually in the skin/theme. > For the component developer, yes it was a pain. As an SDK user, this was not a pain point at all :-) My biggest problem with the styles property is that it does not play well with autocomplete. I have the same problems with the setStyle method. I vote for the convenience of being able to set these on the components itself. I think it just makes sense. > The skinning model is different in FlexJS anyway so I think that gives > us license to change the styling model as well. If you ever set a > style on a Flex component that wasn't in your custom theme, or tried > to add a new style to a skin/theme that wasn't declared on the > component, then you know what pain I'm talking about. With FlexJS, > some new browser might come up with a new custom CSS property and you > won't be able to set it in MXML without us rev-ing the entire SDK. > Yes, you should be able to set it in the .CSS file, but just not in-line. > Great points - never thought of that. I agree with the 'just not in-line' part. But support for in-lining should also be available like it is today. For most cases, this convenience is very useful. Thanks, Om > > Thoughts? > -Alex > > > This email is confidential and subject to important disclaimers and conditions including on offers for the purchase or sale of securities, accuracy and completeness of information, viruses, confidentiality, legal privilege, and legal entity disclaimers, available at http://www.jpmorgan.com/pages/disclosures/email.
