First off, this is <i>fascinating</i>, and I love it. I never thought of doing anything like this, and I have no idea how they came up with it. Awesome idea and great execution.<p>But this:<p>><i>The advantage of using CSS selectors rather than JavaScript indexOf() for search is speed: you only change one element at each keystroke (the <style> tag) instead of changing all the elements matching the query.</i><p>makes it sound like they just don't know how to write DOM-efficient JS, and probably never profiled it or their implementation. I would be <i>shocked</i> if you can't relatively-trivially make a faster JS implementation, and even more if you can't make a significantly faster 'smarter' one with e.g. a more optimized search index, since you can make tradeoffs the CSS processor very likely cannot.
Pretty cool, but yeah, you have to be careful of CSS injection (as mentioned by the author). There isn't too much harm that can be done if the user is typing this in himself or herself, but if the search query is pulled from the URL there might be some security implications.<p>For example, enter this into the search field:<p><pre><code> "]), body, a:not([data-index="
</code></pre>
This will hide the entire page. The last "a:not" selector is really inconsequential-- I just had to close the opening parenthesis and this just happens to work.
This is a very clever idea. There are a few limitations that I think would prevent this from being very usable in practice. One is that it only supports a single word. If you type "Ona Bednar" into the field, you get nothing.<p>Another problem that would only start to show up on a larger dataset is that because the index is all concatenated directly together, it matches strings that span several words. A user searching for their pal Harry Mesbro in the list might be confused to find that typing in his last name also brings up Yvette Hammes.
Interesting, but I can't help feeling that a better implementation would be to split ethe input on white space, and build a slightly more complex selector such that a search for "term1 term2" would set the style to:<p><pre><code> .searchable { display: none; }
.searchable[data-index*="term1"][date-index*="term2"] { display; block; }
</code></pre>
and an empty input would hav eno selectors (or .searchable {display:block;} ).<p>It's <i>slightly</i> more code, but much more usable.
Fun hack but since it relies on JS it's difficult to see why cutting IE8 out makes sense for such a negligible speed up (assuming said speed up actually exists).
This is quite simply a very clever hack. Obviously it isn't up to production standard, but from a hack point-of-view it's thinking outside-of-the-box and I love it. Good to see people thinking of nifty ideas like this. CSS and HTML are getting to the point where they can do what was once only possible in Flash, then Javascript and now in CSS.
That is great, I could immediately think of a few possible uses for this. Client side searching can be quite heavy on the machine if there's a lot of data.
The point about it being efficient because you're only changing one element doesn't sound correct. If you change the styles on the page, the browser is at least going to have to iterate over all of the items with the searchable class (assuming that it doesn't build some sort of index). If you did it in JS, you could try to make it more efficient by indexing the data first.
First off, very clever. Second, I have a case for which I might actually use this.<p>Using multiple textboxes, apply each search term to a nested mongo resultset. Visually narrow down the data structure you want to get out of mongo, and generate the mongo query you'd use to get that data.
It needs separators between the fields in the data attribute, otherwise it could have false positives. e.g. "abe" will find "ona bednar" because "abe" is in the data attribute "an_abe_ndar..."
Pretty cool. The only drawback that I can see right now is the need to send all searchable data twice, increasing overall amount of data that needs to be sent to client.