Browsers don’t blow up, but they arguably should…[1] ;-) I’m not sure why “elementID” would be confusing.
The other way that I see doing it is to use “id” for the element id, and use some other property for the Flex “id” (uid maybe?) I don’t like the idea of making it a compiler option or MXML tag. [1]http://programmers.stackexchange.com/questions/127178/two-html-elements-with-same-id-attribute-how-bad-is-it-really On Aug 8, 2016, at 8:26 AM, Alex Harui <[email protected]> wrote: > > > On 8/7/16, 2:08 PM, "Harbs" <[email protected]> wrote: >> >> Never mind. I was wrong about this. >> >>> Maybe we need an option about whether id gets set on the element. Or >>> maybe elements in the main view get their ids set. Andy is right about >>> MXML components, but lots of folks only have one instance of each MXML >>> component and expect CSS id selectors to work. >>> >>> Thoughts? >> >> I would suggest having an additional elementID property and the element >> would only have an id assigned if it’s set. > > Hmm. I don't think that would be obvious to CSS users. > > Thinking about this some more, so what if we pass the id on to the element > and you create more than one element? Apparently it won't blow up the > browser. I'd still lean towards having an option to not set the element > id. It might be doable at the document level. Sort of the reverse of > what you suggested: if you set "dontSetElementIds" on the MXML top tag, > the MXMLDataInterpreter could set some other property like mxmlId instead > of id. > > Thoughts? > -Alex >
