Ah. I did not understand you. So you are saying that if you don’t care about multiple IDs (or are making sure your IDs are unique, you can just use id. If you don’t want the MXML id to propagate to the DOM, you’d use mxmlID for the MXML instead.
Did I get it? > I also wonder if FlexJS should translate id > selectors to class selectors automatically. We do that to extend the Type > Selectors already. I did not understand this. On Aug 8, 2016, at 7:49 PM, Alex Harui <[email protected]> wrote: > > > On 8/8/16, 8:29 AM, "Harbs" <[email protected]> wrote: > >> I don’t get it. >> >> Why is having MXML tags the opposite? >> >> I don’t like the idea of having one property used for two very different >> things. I think that’s more confusing than requiring a slightly >> non-standard name. > > I might be missing something, but I would introduce an mxmlID property > that would do what "id" currently does. The "id" property would set both > mxmlID and id on the element. That way, using "id" in MXML and CSS works > in simple cases. The compiler would generate slots in the document for > both "id" and mxmlID. If you plan to have multiple instances of an > MXMLComponent, use "mxmlID" instead of "id". > > I'm still pondering whether the top tag in an MXML file could determine > whether id gets set on the element or not. The cool thing about MXML in > FlexJS is that it generates a data structure instead of code, so the > MXMLDataInterpreter could see that the "id" property is being set and do > something different. If there are ItemRenderer base classes that are used > in MXML item renderers, they could set a flag so that MXMLDataInterpreter > sets mxmlID instead of "id" or otherwise tells the child component to not > set the element's id. I also wonder if FlexJS should translate id > selectors to class selectors automatically. We do that to extend the Type > Selectors already. > > Thoughts? > -Alex >
