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
