Yes, I agree. What might alleviate that pain would be: • move all the styles metadata into the skin instead of the component. have the component declare skin styles like we declare skin parts, so [SkinStyle(name="color", required=true)] • or allow styles to be declared in the skin and make the compiler add those styles to the list of styles available to that component type for code completion and compilation • or add a compiler flag to ignore attributes it is not aware of (highlight in a different color?) and treat those unknown attributes as styles. • or add a styles proxy object on the component for styles not known to the component
<button> <styles color="red" cornerRadius="8" /> </button> I would prefer the above to inline, "color:red;cornerRadius:8". The more I think about it MXML should be a generic XML description of an application. Since we want MXML to output to other languages things like binding expressions and inline name value pairs like, style="fontFamily:Arial;fontWeight:bold" are getting away from the one of the reasons that XML was created; that being readability. I think another feature of an XML spec is that it defines guidelines for parsers. E4X is an advanced notation to get right to the information you need in an XML document. With, style="color:yellow;fontFamily:Times New Roman" you would need to use E4X to get the attribute and then another expression engine, RegExp, to get the names and values you need. I'm not saying no to inline styles but to keep in mind MXML's roots. In time, as MXML is adopted, the tooling and the developer base will grow as well and I would think we'd want a distributable document to be as portable and parsable as possible (say that 3 times fast). Are you using the style property as a proxy to the CSS class now? MXML, <style source="styles.css"/> <button style="MyStyles" /> HTML, <stylesheet src="styles.css"></stylesheet> <input class="MyStyles"></input> On Tue, Sep 3, 2013 at 7: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. > 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. > > Thoughts? > -Alex > > >
