Hi, I agree in most of the points explained here, but want to expose a point that maybe will change this particular case.
A Polyfill for me is a JS implementation of an API that will be part of all browsers natively, and use to be already implemented by 1 or 2 browsers, but not for all the most important ones. So to be able to use actually people use a JS implementation until all browsers implement it. So the bead approach is ok to me when we implement things to be supported cross targets, and we can create a bead for animation and in JS do strand["animate"], but still would want JS (through Royale) could make a dot access and not that kind of bracket access that seems to me not what people should end to do. In this case we are talking to a new Element API, so I was figuring is this could be added vía prototype something like: Element.prototype.animate I see lots of this in typedefs and we should not forget that animate method is coming vía Web Animations API, so I think is something sooner or later we'll be on the HTML apis So for me there's two separate things, one make a bead implementation to ensure cross target consistency in APIs, and other, in this case centered on HTML target, how to deal with a new API that will be part of all browsers to support it sooner vía pollyfill. (Notice that we still need to add @keyframe to CSS parsing in Royale that is still unsupported, and this is the way to do the same as animate vía CSS) thoughts? El dom., 5 may. 2019 a las 14:02, Yishay Weiss (<[email protected]>) escribió: > > >if you can get yourself away from trying to access features on concrete > instances > (…) > > >var animateBead:IAnimateBead = > indicator_content.getBeadByType(IAnimateBead); > >animateBead.animate(); > > Is this PAYG? getBeadByType iterates through an array. > Also, animateBead may turn out to be null which adds a level of > uncertainty as to whether or not this will run. > > -- Carlos Rovira http://about.me/carlosrovira
