I am still trying to inspect and figure out my way through the entire concept but this is pretty cool. I do have a few of questions.
1) How is it that the results are being filtered with zero JS? I see "onkeyup="this.setAttribute('value', this.value)" JS event being called for on the search box.
2) How accessible is this content? I am wondering about sites that support screen readers for the blind or with other disability.
3) Despite the DOM and the CSS file being unusually large the search page is being loaded pretty quickly. I saw that class and id names were chosen to be very short. Besides that and compressing CSS, is there any other magic happening in the background to optimize for speed and efficiency?
Much appreciated!
Report
@sshakeel it's probably async since users can't search at the moment the website loads
@sshakeel
Great questions. We are going to post a technical explanation on our blog soon, but here are a few answers.
1) We had to bend the truth a little. There is a single JavaScript instruction, that updates the `value` attribute of the input whenever you type something in it. CSS can only read the value that is set in the HTML, not the one you dynamically type, so that's why this little bit of JS is needed.
2) Content is generated through :before/:after pseudo classes, so at its core it depends if the screen readers can read it or not. That being said, many of the tricks of the demo rely on unconventional markup (and a custom font) that makes it really bad in terms of accessibility. It was all meant to be an April Fools joke, not a real product :)
3) There are two things to take into account here: filesize, and parser speed.
Filesize:
My first attempts created a 11MB filesize, for ~60 records. By slightly changing the markup and use the power of the cascade as much as possible I was able to remove many duplicate rules. I also used a minifier to merge rules that share the same selectors (but most of the minifiers still choke on the huge number of rules needed). I also went with one-letter identifiers as to make everything shorter, and replaced `!important` in rules in favor of higher priority rules (using the nice trick of `#id[id]` to artificially increase the weight of a selector)
Parser speed:
My first attempt used selectors like `label[for=foo]` and `:nth-child` selectors. The display was really sluggish. By moving to #id selectors, I made the parser job much easier and matching was instant.
Thanks again for the questions :)
Excited to try this. You just need to understand CSS and HTML to implement it? When will it be available? Would like to try it on a project I'm launching soon.
@geoffreyweg It was an April Fools joke. The demo works because we are in a controlled environment with a small dataset, not many typos handled and search only in a few attributes. The filesize does not scale well. We're already at 4MB for less than 100 records.
If you want to implement search with the whole range of features of our API, I recommend using our https://community.algolia.com/in... library instead. It is much more powerful and only requires minimal configuration to have it working.
Replies
Algolia
Algolia
Algolia
Keen
MostPopular.xyz
Algolia
MostPopular.xyz
CRO Tactics