Show HN:jQuery Signature - Getting a unique signature for a dom element | Hacker News Reader

Show HN:jQuery Signature - Getting a unique signature for a dom element

dokeeno.com

6 pointsarunoda13 comments

I just wrapped up some code I've used in similar situations:

https://github.com/rcs/jQuery.relativeSelector

Instead of going all the way to the body, this will find a selector that works given the structure of the page.

For instance, a page like:

  <body><div id="firstdiv">Target!</div></body>

you can get "#firstdiv" back.

For something like

  <body><div id="#firstClass"><div class="firstClass"><div>Target!</div></div></div></body>

You can get "#firstClass div:eq(0)".

If you set the same value for "class" attribute on DIV elements in the example, the generated selector (i.e. "signature") won't be unique.

BTW, if the selected element has an "id" attribute (with -by definition- a unique value), what is the point to generate the full selector (cf. "Go to Hell" with "bbg" id in the example)?

You have good valid point here.

for the first one it's kind of a problem. Do you have any sugessions.

For the second one, answer is simple we may have several elements with same id but in different parents. That's why we need something like this.

This is not 100% unique but a innocent try :)

For the first problem, you could test the generated selector to verify it matches only one element. If not you can use, for example, the nth-child pseudo-class to select the right element.

For the second one, specs say that the "id" value must be unique in the entire document [2].

[1] http://www.w3.org/TR/selectors/#structural-pseudos

[2] http://www.w3.org/TR/html401/struct/global.html#h-7.5.2

Thanks. First one seems nice. I'll implement that. But if the content is changed dynamicly we might face some issues.

BTW: in reality developers do not adhere to [2] and there is no any browser restrictions for that. So I have to think beyond the spec.

> But if the content is changed dynamicly we might face some issues.

Regardless the problem I was raising, if the document changes dynamically, your generated signature has great chances to fail (cf. also comment from bdunn).

> in reality developers do not adhere to [2]

I really hope it's not true because it would really be quite pointless. Let's try by yourself: put the same id name (e.g. "testId") on two different elements in your example and then try this code:

    $("#testId")

It will return only one element. So you'll never be able to find the second one with a selector...

>Regardless the problem I was raising, if the document changes dynamically, your generated signature has great chances to fail (cf. also comment from bdunn).

Yes :)

>It will return only one element. So you'll never be able to find the second one with a selector...

Thanks. I was not aware of that. Now this encourage me even more :) If a bad programmer like me place two ids with same name. Extension developer like x did not able to get the second one. That why I need this

updated the source according to the first recommendation.

It looks like this ascends the list of parents for an element to generate a signature. This falls apart if you move an element somewhere else in the DOM - a different signature, but it's really the same node.

IMO the best approach is still to use $.data('my_element', el)

Yes. You got a valid point here. This does not gonna work for 100% for dynamically generated content. But should work for statically generated contents.

$.data('my_element', el) works if you everything works on the same page without refreshing the window. But I wanted a way to store the signature on a DB and make it highlighted at some point later.

I'm not convinced this is actually a good thing to do. As noted by others, its unsuitable for dynamic content, and less direct than `$.data(...)` barring page refresh.

Just not sure what client-side workflow this kind of tool is used in.

I love the example page.

Create a one yourself If you like :P http://dokeeno.com/login

Reply on news.ycombinator.com