On Dec 7, 2013, at 8:33 PM, Rafael Weinstein <[email protected]> wrote:
> On Sat, Dec 7, 2013 at 6:56 PM, Ryosuke Niwa <[email protected]> wrote:
>
> > On Dec 7, 2013, at 3:53 PM, Rafael Weinstein <[email protected]> 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
