Using id as the element id would probably lead to duplicate element ids somewhat frequently, I suspect. Any time there are multiple instances of the same component on screen, you'd have duplicates. In the worst case, a custom item renderer where a sub-component has an id would result in many duplicates.
- Josh On Mon, Aug 8, 2016 at 4:38 AM, Harbs <[email protected]> wrote: > 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 > > > >
