On Dec 7, 2013, at 8:33 PM, Rafael Weinstein <rafa...@google.com> wrote: > On Sat, Dec 7, 2013 at 6:56 PM, Ryosuke Niwa <rn...@apple.com> wrote: > > > On Dec 7, 2013, at 3:53 PM, Rafael Weinstein <rafa...@google.com> wrote: > > > > The issue is that being an element and having shadow DOM -- or any display > > DOM, for that matter -- are orthogonal concerns. > > > > There are lots of c++ HTML elements that have no display DOM. Polymer > > already has an even larger number. > > While that's true in browser implementations, there is very little authors > can do with a plain element without any shadow content it since JavaScript > can't implement it's own style model (i.e. creating a custom frame object in > Gecko / render object in WebKit/Blink) or paint code in JavaScript. > > If the only customization author has to do is adding some CSS, then we don't > need custom element hook at all. > > > I'm was thinking about elements whose purpose isn't presentational. For > example, <link> or <script> in html, or <polymer-ajax> in polymer.
What are advantages of using an element to represent an AJAX request over, say, doing so in JSON or via function call? e.g. Polymer.ajax({url: "http://gdata.youtube.com/feeds/api/videos/", params: '{"alt":"json", "q":"chrome"}', handleAs: 'json', onResponse=handleResponse}) instead of <polymer-ajax auto url="http://gdata.youtube.com/feeds/api/videos/" params='{"alt":"json", "q":"chrome"}' handleAs="json" on-polymer-response="{{handleResponse}}"> </polymer-ajax> It seems strange to have a node in DOM whose sole job is to issue an XHR request and call a handler. Having said that, I could imagine people implementing link[rel=import] like feature using some custom element as a polyfill for a yet-to-be implemented browser feature. - R. Niwa