I didn't consider that ids were supported in classic Flex SDK CSS. In that case, I guess it really was global then. With that in mind, I guess I'm okay with adding the option to use localID instead of id when you want a member variable but not an HTML id.
I suppose this change will require compiler changes. If we wanted to avoid that, for any reason, we might consider an alternative of adding a boolean property to UIBase (or whatever) that tells the component not to set the HTML id. Maybe something like this: <MyComp id="something" noGlobalID="true"/> I think I'd prefer localID over this option, though. I just thought I'd mention it, since it came to mind. - Josh On Mon, May 22, 2017 at 8:56 PM, Alex Harui <aha...@adobe.com.invalid> wrote: > Hmm. I'm just now catching up on this thread. Are we sure this > 'globalID' proposal is the right one? What happened to Piotr's concern > that 3rd party libraries might recommend setting the 'id' property. Or > similarly, that some CSS theme is expecting you to set 'id'. I'd be > worried we'd be constantly having to tell folks to use the 'globalID' > property. > > There might be other options: Maybe there is some directive that you use > in an MXML file that doesn't result in code that sets the id property on > the object. How often do folks have more than one instance of an MXML > class in the DOM at one time? I think mainly in item renderers? > > I have no idea how to execute on the compiler detecting multiple uses of > id. I don't think the compiler knows that a class in a SWC was generated > from MXML and sets the id property. Or that someone set id from an > ActionScript class. I think someone could write a bead that watches for > multiple setting of the 'id' property. > > I'm not sure the "backward compatibility" of the 'id' property should win > out over the mapping of 'id' to the actual 'id' in the DOM. Regular Flex > supported 'id' selectors. How would that work in the 'globalID' proposal? > If 'id' doesn't get set then someone's old code that used an 'id' > selector will not work. They will have to modify their code to use > globalID instead. > > So, I think the factors are: > 1) There are existing CSS files for Flex that use ID selectors. > 2) There are existing CSS files for JS libraries and themes that use ID > selectors > 3) The MXML item renderers might use IDs resulting in more than one > instance with the same ID in the DOM, and also multiple pairs of IDs if > you make up IDs based on parent + child. > > Anyway, are folks thinking we need to do something about this for this > release? I'd rather not delay the release for this only to find out we > missed out on some ramification. > > Thoughts? > -Alex > > On 5/22/17, 4:47 PM, "Harbs" <harbs.li...@gmail.com> wrote: > > >+1 > > > >> On May 22, 2017, at 3:13 PM, Josh Tynjala <joshtynj...@gmail.com> > wrote: > >> > >> Yes, with my proposal, globalID would be translated to HTML. With id, it > >> would go back to the classic behavior of adding a member variable to the > >> class only and not being translated to a global HTML id. > >> > >> This change would indeed break existing FlexJS applications that used > >>the > >> HTML id in some way (like in CSS). However, we're pre-1.0, so breaking > >> changes are still to be expected while we smooth things over. I would > >> rather fix id to put it back to the original behavior of affecting the > >> current class only than add a workaround like localID/mxmlID for the > >>fact > >> that id was overloaded to mean something at the global-level too. > >> > >> - Josh > >> > >> > >> On Mon, May 22, 2017 at 11:37 AM, piotrz <piotrzarzyck...@gmail.com> > >>wrote: > >> > >>> Hi Alex, > >>> > >>> I was going to expand my thoughts on same concerns what Chris mention. > >>>If > >>> we > >>> introduce "localId" which will be responsible for identifying > >>>components in > >>> MXML we need to also generate "id" - based on those "localId" - cause > >>>in > >>> many cases "id" will be required in HTML once we set "localId". > >>> > >>> Some external library may require those "id". > >>> > >>> Summarize a bit we have so far following ideas: > >>> 1) Introduce "localId" or "mxmlId" as entity which is not translated to > >>> HTML > >>> 2) Introduce "globalId" which will be translated to HTML, but "id" not > >>> necessary (Josh Am I understand you right ?) - But that would break > >>> existing > >>> applications, cause we have right now "id" translation to HTML. > >>> > >>> Related to introduced new property: > >>> 1) Have the compiler check that HTML ids are not used more than once. > >>> (Harbs > >>> - Globally ?, If id is used more than once in many views ?) > >>> 2) Ability set HTML ids (Harbs I need a bit more elaboration on this, > >>> cause > >>> I do not fully understand) > >>> 3) "id" should be generated based on "localId" or make generation > >>>based on > >>> Chris's suggestions (Piotr, Chris) > >>> > >>> If I miss something or didn't understand enough please correct me. > >>> > >>> Thanks for a good discussion on that! > >>> Piotr > >>> > >>> > >>> > >>> > >>> ----- > >>> Apache Flex PMC > >>> piotrzarzyck...@gmail.com > >>> -- > >>> View this message in context: http://apache-flex- > >>> development.2333347.n4.nabble.com/FlexJS-MXML-ids-and- > >>> classNames-tp54361p61745.html > >>> Sent from the Apache Flex Development mailing list archive at > >>>Nabble.com. > >>> > > > >
