You could combine the two prefered names and call it "webcomponents-platform.js" then?
Or be very explict and use "webcomponents-platform-shim.js" or "webcomponents-platform-polyfill.js". Very clear and descriptive name. Does what it says on the tin! This is some serious bikeshedding :) B. On Wednesday, February 12, 2014 4:53:40 AM UTC, Scott Miles wrote: > > Thanks for the thoughtful (as usual!) feedback. > > The collected polyfills don't have a strong identity for me. We made them > simply as a way to get to using these technologies when we had the sad > realization that web components were a long way from actual implementation > in browsers (when we started this process ~18 months ago). > > We worked hard to layer the polyfills so that folks could remix them as > needed. This was useful in particular for Mozilla, who cherry picked Custom > Elements polyfill for x-tags/brick. > > Polymer itself refers to the library we have created that provides a > common sugaring layer and declarative support for custom elements. This is > where we express our opinions about how to utilize the web components > technologies, and is really the end-product we sought to produce. Polymer > proper is not beholden to any spec or committee, the Polymer team decides > how it should be (incorporating as much feedback as we can from our awesome > users like yourself!). For this reason, it's much more deserving of a brand > than the polyfills IMO. > > Also, on top of Polymer we vend one or more element sets, but I'm equally > anxious to separate those element sets from Polymer itself. Ideally the > ecosystem of elements is vast and interoperable, and the Polymer team can > vend elements just like everybody else. Conceptually one need not know if > one is using a Polymer element, an X-Tag element, plain vanilla custom > element, or some mixture. The underlying technologies are hidden and the > elements can work together. > > >> I'd recommend selecting a name that suggests the *role* the polyfill > library fills: > > The notion of 'platform.js' is to say 'normalize the platforms', which IMO > *is* the role of those collected polyfills. Unfortunately, that name is > quite generic. Although fully aware that it's less correct, I suggest > `webcomponents.js` believing it more likely to communicate the necessary > concept for newbies (that this file provides those futuristic features). > > Scott > > > On Fri, Feb 7, 2014 at 4:32 PM, Jan Miksovsky <[email protected]<javascript:> > > wrote: > >> Based on my understanding of the Polymer strategy, I wonder if any name >> that speaks to directly to web components will prove too limiting in the >> future. >> >> On a separate >> thread<https://groups.google.com/forum/#!msg/polymer-dev/7UT-mCiHAVM/P1t9adywlgQJ>, >> >> I presented the view that the current polyfill strategy is suitable for >> much more than web components, and could (and should) be adopted for future >> specs. The fact that, for example, Pointer Events and Web Animations are >> grouped under the "web components" umbrella seems more a historical >> accident than intention. In the case of Pointer Events, that shipped >> independently in IE, and both of those technologies could be used in a page >> that has no component nature at all. I hear Google referring to these as >> web component technologies, when to me they're just new web technologies. >> >> The same thing will surely happen going forward. The next time someone >> proposes a new, polyfillable spec for a feature that has nothing to do with >> components. Having to create a new polyfill library just for that one spec >> seems overly complex. Won't the most natural thing to do be to include that >> in platform.js? If that library is renamed webcomponents.js, it seems >> likely that name will eventually become increasingly inappropriate. (Cf. >> jQuery) >> >> My two cents: Polymer is a great name. It's catchy, memorable, and has an >> etymology that can be explained. If it were up to me, I'd rename >> platform.js to polymer.js. Polymer would be the "brand" by which the world >> refers to a vendor-independent browser compatibility library. >> >> Otherwise, I'd recommend selecting a name that suggests the *role* the >> polyfill library fills: standards.js, or compat.js. >> >> The thing I'd rename is actually polymer.html. In my understanding, >> polymer.html has a more focused responsibility: support the creation of >> custom elements. That role seems unlikely to evolve much over time. If >> that's correct, then a descriptive name like customelements.html would be >> attractive. (Of course, I could easily be misunderstanding the boundary >> between platform.js and polymer.html. Please correct me if I'm wrong!) >> >> On Friday, January 31, 2014 4:20:12 AM UTC-8, Addy Osmani wrote: >>> >>> Whilst I like platform.js, webcomponents.js makes the literal >>> distinction between Polymer and the polyfills all the more clear. >>> >>> Hope that rename happens :) >>> >>> On Thursday, 30 January 2014 20:53:10 UTC, Steve Orvell wrote: >>>> >>>> +1 >>>> >>>> We've been consdering re-naming platform to webcomponents as well. >>>> >>>> >>>> On Thu, Jan 30, 2014 at 12:50 PM, John Messerly <[email protected]>wrote: >>>> >>>>> Hello polymerites, >>>>> >>>>> I'm going to create a Pub (http://pub.dartlang.org/) package for >>>>> polymer's platform.js, to replace our individual polyfill pkgs: >>>>> shadow_dom, >>>>> html_imports, and custom_elements. The individual pkgs have been a bit of >>>>> a >>>>> headache as they get out of sync, etc. Plus it would be awesome to reuse >>>>> exactly the same JS code from the corresponding Bower[1] package. Since >>>>> "platform" is a really generic name, I was thinking of calling this >>>>> package >>>>> "web_components". Any objections? >>>>> >>>>> Note: template_binding and observe would stay separate pkgs on Pub, so >>>>> they wouldn't be included conceptually. >>>>> >>>>> Cheers! >>>>> - John >>>>> >>>>> >>>>> [1]: leaving aside for now the question of Pub interoping directly >>>>> with Bower. That's a good long term solution but will take a while to get >>>>> there. >>>>> >>>>> Follow Polymer on Google+: plus.google.com/107187849809354688692 >>>>> --- >>>>> You received this message because you are subscribed to the Google >>>>> Groups "Polymer" group. >>>>> To unsubscribe from this group and stop receiving emails from it, send >>>>> an email to [email protected]. >>>>> To view this discussion on the web visit https://groups.google.com/d/ >>>>> msgid/polymer-dev/CAJup4OUyk0TnFvL%2B7Hd%2BCO% >>>>> 2BgoRUsJfih_cf3h0WDtWA01GuLHA%40mail.gmail.com. >>>>> For more options, visit https://groups.google.com/groups/opt_out. >>>>> >>>> >>>> Follow Polymer on Google+: plus.google.com/107187849809354688692 >> --- >> You received this message because you are subscribed to the Google Groups >> "Polymer" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected] <javascript:>. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/polymer-dev/df1a28de-1117-4e98-b233-3416939e4bb2%40googlegroups.com >> . >> >> For more options, visit https://groups.google.com/groups/opt_out. >> > > Follow Polymer on Google+: plus.google.com/107187849809354688692 --- You received this message because you are subscribed to the Google Groups "Polymer" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/polymer-dev/f7d224fc-a187-4ca9-8c9b-d08435bcbe40%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
