1
The goal is to find a way better than the current best known way of encoding the index of a child HTML element, so that encoded indices have the following property.
if (index_i >= index_p) {
assert(encoding(index_i).indexOf(encoding(index_p)) == 0);
}
if (index_i < index_p) {
assert(encoding(index_i).indexOf(encoding(index_p)) !== 0);
}
The current best known way of doing this is with a form of unary encoding (without the usual trailing zero. So, for example, when index_p = 10
:
encoding(index_p) == "11111111111"
trueindex_i = 9; encoding(index_i) == "1111111111"
true"11111111111".indexOf("1111111111") !== 0
true"1111111111".indexOf("11111111111") == 0
true
Application
An application of this is being able to use document.querySelectorAll
for obtaining all child elements "greater than" a certain index, via utilisation of the "starts with" attribute selector, ^=
.
For example, if we have a set of 100 div elements, and each div element has been given an attribute ei
equal to its encoded index value. If our goal is to obtain a list of the last 51 of div elements, one way to do this is to request:
document.querySelectorAll('div[ei^='+Array(50).join("1")+']');
However, if we have interesting numbers of divs (1000, 10000), then we use a lot of memory storing these attribute indexes. So we get the typical "memory" vs "speed" tradeoff for setting up this indexing system.
The question is : is there a way to do the same thing, using an encoded index, such that it is shorter than this pseudo-unary version?
Motivation
One motivation that contributes to this question post here is the following subtle point: the elements may not necessarily be in the indexed order.
This unusual occurrence is by no means something that one would expect in ordinary use of the DOM, but if we are absolutely positioning the elements based on their indices, and we are swapping, inserting and deleting the elements, then it is possible to have a meaningful piece of HTML where document order is actually not related to the rendering order that ends up meaning something to somebody. And in such a case, we may still need to look at a range of elements, such as, all elements with an index larger than 72, and with an indexing method with properties like those described above, then we can use the starts with attribute selector to gather together this set.
Why limitation on starts with and other types are disallowed? – Qwertiy – 2014-11-19T23:56:11.033
@Qwertiy sure if you can see a way to achieve this goal with other types of selector that would work too. – Cris – 2014-11-20T11:47:23.667
This could be an interesting challenge, but as it currently stands, there is no winning criterion, and it is unclear what you are asking. I am voting to close it until it is fixed. If this is not meant to be a challenge, but instead a programming question, you should ask for help at Stack Overflow. – None – 2014-11-20T20:23:00.450