Programming Puzzles & Code Golf Stack Exchange is a question and answer site for programming puzzle enthusiasts and code golfers. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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" true
  • index_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.

share|improve this question

closed as off-topic by Martin Büttner, rink.attendant.6, Hosch250, Beta Decay, Wrzlprmft Nov 20 '14 at 22:03

This question appears to be off-topic. The users who voted to close gave this specific reason:

  • "Questions without an objective primary winning criterion are off-topic, as they make it impossible to indisputably decide which entry should win." – Martin Büttner, rink.attendant.6, Hosch250, Beta Decay, Wrzlprmft
If this question can be reworded to fit the rules in the help center, please edit the question.

    
Why limitation on starts with and other types are disallowed? – Qwertiy Nov 19 '14 at 23:56
    
@Qwertiy sure if you can see a way to achieve this goal with other types of selector that would work too. – Cris Nov 20 '14 at 11:47
    
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. – Hosch250 Nov 20 '14 at 20:23
up vote 0 down vote accepted

You could always try something of the form

<tag h="111" t="11111" o="1">

where you use your unary encoding for each of the hundreds (h), tens (t) and ones (o) attributes.

A greater-than CSS selector would then look like

tag[h^="1111"],tag[h="111"][t^="111111"],tag[h="111"][t="11111"][o^="1"] { ... }

but frankly, if your tags are just retaining some property that persists in spite of reordering, etc., why not just run a script that selects the last n marked tags on DOM load and assigns the class iamlast, then use the .iamlast CSS selector?

share|improve this answer
    
That's good, I like your idea for using radix plus unary. It works. Radix sort has a similar idea. I understand your suggestion for iamlast however it would not work because the number of elements we may wish to select is dynamic. We might want to select 10 elements after some modifications have been made, 20 elements next time, 5 the time after, 57 the time after that. So keeping track of real order, regardless of the document order, for the whole life of the page, is necessary. – Cris Nov 20 '14 at 11:45

Not the answer you're looking for? Browse other questions tagged or ask your own question.