CSS attribute selector efficient "greater than selector" code

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" 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.

Cris

Posted 2014-11-19T22:14:32.877

Reputation: 31

Question was closed 2014-11-20T22:03:09.520

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

Answers

1

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?

COTO

Posted 2014-11-19T22:14:32.877

Reputation: 3 701

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 – 2014-11-20T11:45:58.900