|
|
|
|
|
|
by jamesmcintyre
1084 days ago
|
|
|
Link seems to be down just fyi. For various projects in the past I’ve dabbled in generating selectors so I’m curious what you’ve come up with! My more recent interests have been to find a way to generate more robust selectors that could handle slight-to-mild DOM structure changes (also cannot rely fully on classes, ids, html attributes). This wouldn’t necessarily be for testing but could apply. There are applications that need the ability to find an element despite its location in the dom changing slightly (ie its now nested one div deeper). For instance most xpath or “traverse down the dom until find parent div” type selectors would be too fragile. What i’ve been trying to figure out is a way to “fingerprint” the target element and have a algorithm that has a few ways to look for that element, each failure would try a less strict, more flexible method. Just curious if the work you’ve done ventures into anything like this or if in your research you came across anything like that? |
|
|
I like your idea of suggesting multiple selectors. Don't know how that didn't cross my mind.
But in short, I am trying to generate selectors that would rely on the contents rather than attributes (like CSS).
I am also trying to detect selectors that are generated vs manually typed (i.e. likely to remain static vs generated).
Just heads up that the version that is approved by Google Chrome Store does not include all the latest changes. I've made a ton of improvements to this over the last two days, and they take quite a while to review.
I am also going to make this open-source as a separate package.