Element queries with precompilation

[wnr]

Hi,

First off, I'm very impressed with your work. I've read the CCSS paper and would never believe somebody actually made a JS port of it. Very cool. I'm writing my Master's Thesis about element queries, so I'm very interested in your approach, since it seems to me that it is the most theoretically sound approach.

From what I've understood, you basically have two problems: performance and compatibility. Those two problems you aim to solve by precompiling GSS into CSS.

However, I fail to see how precompilated CSS can work for element queries on dynamic pages. With a layout that changes dynamically, there is a need for runtime checks to update the style of the element query targeted elements. Am I missing something or is this correct?

I'm sorry if a repo issue is not the preferred way of asking about this.

Kind regards

[Inviz]

We're trying to get GSS to the state where pre-computation is not a requirement in production. Compiling CSS needs a few compromises to the structure of website.

Currently, we're trying to figure out best practicies to use GSS in production. We do that by reducing and separating computation graphs and fixing memory leaks in GSS and cassowary. But the memory consumption can still be quite high. It takes 1s and 30mb to solve >1000 constraints of http://thegrid.io with long tail (150+) of tiny 1-constraint graph. Of 2/3 of time is wasted by GSS, while 4/5 of memory is used by cassowaries.

By separating graphs, we can pre-compute solution individual to big chunks of the site (we call those sections).

You're right that brute-force pre-compilation only works for static pages. Compiling a dynamic page is a lot more involved, and there's no solution to that at the moment - but we have ideas:

1) Bruteforce compilation of results for each screensize. Which is more straightforward, but very limited, as it's static.

2) Research project called anchiornis, which compiles all co-linear values to values and units relative to viewport (vw, calc, and friends). Dynamism would be provided by computing different states of the webpage (e.g. different tabs, steps, and stuff) and computing their deltas to base solution of a graph. If sections are kept separated, a different state would only affect containing section's solution.

3) Use GSS with CSS to reduce workload. Go nuts and use flex-box, floats and stuff for your content and dynamic stuff, while doing GSS for static pieces (e.g. layout)

[wnr]

Thank you for your response, it's very informative.

I see, it makes sense that you still can improve performance a lot by precompiling the static graphs.

Are there are any resources available that you can link to regarding the anchiornis project?

Idea 2 sounds like a valid approach, but if I don't understand it wrong the approach will only work for dynamic pages with a known set of layout configurations. I realise that most use cases probably have known layout configurations, but it is always interesting to know the theoretical limits.

So idea 1 and 3 sounds like they do not support element queries, and since idea 2 is somewhat limited to known layouts at server side, can it be concluded that GSS is not very suitable for element queries practically? I do see the benefits of GSS in other areas.

Thanks

[Inviz]

Just wanted to say that we've built an exporting solution that exports static CSS with media queries and rem units for full-page scaling. It's still have to be a pretty much static page though. You can already try it on ranges2 branch (add ?export=1024x768,800x600 params to the page), but it's highly experimental. We'll roll a production site out using this soon.