GRAVITY has one big opponent, DOM changes. GRAVITY has been developed to reduce enterprise learning costs as well as effort to always repeat said costs on updates. There is a circumstance which makes it difficult for us, to support content owners with automatically tracking their content. As we have seen in Microsoft's cloud environment there are changes in the DOM tree (the structural representation of a website) we just can not track. There is no affordable1 way to track certain changes, disregarding the cases where it would not even make sense. Check our example below to see the borders of our magic!
Our "finding" algorithm has five levels of forensics:
- Exact selector match (example: #container > table.main > tr:eq(2) > td.first:eq(1) > div.name:contains('New')). That approach gives us 100% accuracy in defining the element, but is vulnurable to any kind of changes in content and DOM structure. Works fine in most cases, but is not suitable for elements, that are different on per user basis.
- Selector without element's text information (example: #container > table.main > tr:eq(2) > td.first:eq(1) > div.name). Gives high accuracy of selection and can handle localization, but is still vulnurable to DOM structure changes. It also can give false-Positive in case elements order changes, for example changing orders in menus.
- Selector without the element with defined ID or BODY element (example: table.main > tr:eq(2) > td.first:eq(1) > div.name:contains('New')). Gives high accuracy of selection and can handle situations, when the ID of the element is changed, but the DOM structure inside is the same. Can give false-Positives on the sites with the same DOM blocks structure.
- Selector without indexes (example: #container > table.main > tr > td.first > div.name:contains('New')). Gives medium accuracy. Can handle situations, when the order or number of the elements inside the DOM is changed, but the elements themselves are still there. Can give false-Positives on similar DOM structure.
- EXPERIMENTAL Cutting the selector from the left side (example: tr:eq(2) > td.first:eq(1) > div.name:contains('New')). Gives low accuracy. Can handle most DOM changes, but has the risk of false-Positives increasing with each step of cutting.
Cold case, no hotspot is ever lost!
They are never lost, we designed a cozy place for all of them, called the "collector". Most of the No cases can also be solved by our Hotspot Grid. All the examples below apply to DOM mode.
| Case | Can we rebind the content |
|---|---|
| DOM element class name changed | No, element.className is our primary handle, if it changes, we can never find the element again (see div.name above) |
| DOM element's parent class name changed | Yes |
| Text of a button changed from "New" to "Create" | Yes (see finding step 2) |
| Position of a button changed inside his parent container | No, not yet, it may come with step 5 soon. |
| Position of a button has changed abroad his parent container | Yes (see finding step 3) |
| Text and class name of a button changed | Still no, element.className is vital |
| Position in a list of links changed | Yes (see step 4) |
A few words
The border where we can no more track a change and the border where it makes sense to track the change are the same.
If a button disappears, it is totally logic that it's bound content goes to the collector and from there most certainly to trash. If a buttons classname changes, or his type, the change is assumably that big, so that it makes sense for a content owner to check if the content he provides is still accurate. Imagine a "New" button changes from being a clickable div with class "foo" to a input dropdown with the class "bar". It is a dropdown now, also it looks (according to "bar") completely different, a content owner needs to check, if the content is still accurate! We try to auto-find all cases which make sense and with step 5 even more, but since DOM tree can overnight completely change but still look the same, or completely change but still be "clear" for a user, we have no way to auto-find all changes.
Explanations
1 We fancy algorithms which track everything and everyone and can bind any ever created content, but since we have no relation to the foreign DOM tree there would only be some image recognition AI solution magic, which we can not yet afford.