Automatic node finding

148 views
Skip to first unread message

David Avenante

unread,
Feb 13, 2014, 10:54:40 AM2/13/14
to polym...@googlegroups.com
Hi,

I look more and more on the WebComponent approach and so on Polymerjs.

I'm surprising of the add "Automatic node finding" on the lib.
What is the interest of this practice cause in the HTML specification "The ID must be unique in a document"  (https://developer.mozilla.org/en-US/docs/Web/API/element.id)

I see already the result in this case.

https://github.com/djalmaaraujo/gravatar-image/blob/gh-pages/src/gravatar.html

If you look at the template :

<a id="username">
<img id="username_image" />
</a>

So the creator of the component use a facility of polymer who is a bad practice at the document level.
In this case if I have a collection of gravatar images my dom looks like :

<ul>

<li>
<gravatar-image username="xxxx" size="80" hash="">
<a id="username" href="http://www.gravatar.com/xxxx">
<img id="username_image" src="http://www.gravatar.com/avatar/xxxx.jpg?s=80">
</a>
</gravatar-image>
</li>

<li>
<gravatar-image username="yyyy" size="80" hash="">
<a id="username" href="http://www.gravatar.com/yyyy">
<img id="username_image" src="http://www.gravatar.com/avatar/yyyy.jpg?s=80">
</a>
</gravatar-image>
</li>

</ul>

So many same id on my document.

Maybe the Automatic node finding is not a good solution and add an another question in an another thread ;)





Scott Miles

unread,
Feb 13, 2014, 1:07:16 PM2/13/14
to David Avenante, polymer-dev
ShadowDOM provides a scope that restores IDs to usefulness.

You don't in fact get this:

<li>
<gravatar-image username="xxxx" size="80" hash="">
<a id="username" href="http://www.gravatar.com/xxxx">
<img id="username_image" src="http://www.gravatar.com/avatar/xxxx.jpg?s=80">
</a>
</gravatar-image>
</li>

You do get this:

<li>
<gravatar-image username="xxxx" size="80" hash="">
#shadow-root
</gravatar-image>
</li>

The IDs are inside the shadow root, so there is no duplication at the document level.

Do some tests using Chrome Canary w/ experimental-web-platform-features enabled if you want to use the DOM inspector to study the features of ShadowDOM.

On browsers that need it, the ShadowDOM Polyfill provides the same scoped environment to your application, but the DOM inspector shows only the raw tree, which is misleading.

Scott




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 polymer-dev...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/polymer-dev/830e5bce-4d95-4635-a3d7-c713d665b380%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Rob Dodson

unread,
Feb 13, 2014, 1:24:54 PM2/13/14
to polym...@googlegroups.com, David Avenante
To expand a little on what Scott is saying, it's my understanding that the polyfill patches the document.getElementById method so it won't select elements that are supposed to be in the Shadow DOM. It does mean that a document level CSS style for #username would affect all of those username fields (because it's hard to polyfill CSS features) but, at least from the JavaScript side, you should be protected. And if you're using a browser with native Shadow DOM then you're totally protected :)

David Avenante

unread,
Feb 13, 2014, 1:58:26 PM2/13/14
to polym...@googlegroups.com, David Avenante
Yes you're right

Using Chrome Canary w/ experimental-web-platform-features in console when I use the jquery selector $('#username') I obtain an empty array.
But with chrome classic and Firefox I obtain a none empty array. So potentially a risk of side effect.

The question is more general in fact and raise a real use case.
In real life, when I write for example a jquery plugin or a component with juste html / js. I avoid the usage of id and use class or specific attribute (like data-role in jquery mobile) to select element in the context of my sub dom.
I think in a case of a more complex component who have more usage of DOM manipulation you need more an helper on the DOM and not on id,  maybe a minimaliste functional DOM selector like zepto or other (just a DOM selector)

I like the approach of backbonejs who expose a $el who is the representation of a jquery selector on the element.
So in polymerjs a this.$ or this.$el to reference the root element processed with a DOM selector to write some expression like this.$.find('option:selected') ...

David

Daniel Freedman

unread,
Feb 13, 2014, 2:02:18 PM2/13/14
to David Avenante, polymer-dev
In Polymer elements, 'this' *is* the element at all times.

If you want to, you could use this.querySelector, or this.shadowRoot.querySelector for elements in the shadowroot.
There is no need for another selector library because DOM has one built in.


David Avenante

unread,
Feb 13, 2014, 2:33:33 PM2/13/14
to polym...@googlegroups.com, David Avenante
You're right it's works.

Thank you.
Reply all
Reply to author
Forward
0 new messages