Add CSS variables custom metrics

[LeaVerou]

Details here: https://github.com/leaverou/css-almanac/issues/1#issuecomment-664842386

Please note that this is written assuming a recent version of Chrome. If WPT runs an older one, please let me know so I can make changes.

Progress on https://github.com/HTTPArchive/almanac.httparchive.org/issues/898

[pmeenan]

@LeaVerou WPT auto-updates to the latest stable automatically and is running the current version.

[LeaVerou]

@pmeenan Yup, I finally managed to run custom metrics on WPT and verified it is indeed running Chrome 84 :)

[rviscomi]

@LeaVerou are there any good test cases you could share from the WPT results? Here's one from Smashing Magazine, but I'm not sure if this exercises the code sufficiently: https://www.webpagetest.org/custom_metrics.php?test=200729_EE_9aad73ca91dfdb7136100742b2412302&run=1&cached=0

For example, in the computed array results, should we expect element and children to be empty? At a quick glance I never actually saw these populated in any items.

{
  "element": {},
  "children": [],
  "declarations": {
    "--bio-image-border-color": {
      "value": "#fff"
    },
    "--bio-image-border-radius": {
      "value": "11px"
    },
    "--bio-image-border-width": {
      "value": "5px"
    }
  }
}

Is there anyone you can recommend to review this from the CSS custom properties perspective? I'll give it a thorough review from the WPT/HA integration perspective. So far the results look reasonable.

One suggestion I have is to combine this with the css.js file created by @dooman87 in #175, once that's merged.

[LeaVerou]

For example, in the computed array results, should we expect element and children to be empty? At a quick glance I never actually saw these populated in any items.

No, that is certainly not normal, I will investigate.

Is there anyone you can recommend to review this from the CSS custom properties perspective?

@tabatkins would be the perfect person for this, but not sure if he has the time to be involved.

One suggestion I have is to combine this with the css.js file

I thought we could keep that for smaller metrics, and keep the Sass and CSS vars ones in their own files, since they are fairly large-ish (200-300 loc). Would that be ok?

[rviscomi]

I thought we could keep that for smaller metrics, and keep the Sass and CSS vars ones in their own files, since they are fairly large-ish (200-300 loc). Would that be ok?

SGTM.

[LeaVerou]

FWIW this seems to be a WPT issue, the code runs fine from a console import("https://leaverou.github.io/css-almanac/runtime/var-tree.js"). Investigating why this happens.

LGTM modulo empty element feedback.

It's not just the empty element, the empty children is far more concerning.

[LeaVerou]

Alright, turns out that was actually an easy fix, I just wasn't using my own serialization function, so the replacer argument that removed empty arrays and serialized elements into nice tagName.class1.class2#id sequences wasn't running. In terms of output, the largest tree I have seen by far is on my website, quite ironically (and predictably, I suppose), here it is: https://gist.github.com/LeaVerou/25854b1d91480c9b949893c608383574

[rviscomi]

Tested your site on WPT: https://www.webpagetest.org/custom_metrics.php?test=200730_V9_a35832e21be04e79bee4559aa1bc0794&run=1&cached=0. The newly fixed children property does make the output really large and I see how deeply nested it can get. I think this may make the analysis more difficult.

For your queries that depend on the computed object, do you have a good sense for how you would go about extracting insights and aggregating them over the corpus? Would a flatter structure make analysis any easier in your opinion, or would that lose any granularity?

[LeaVerou]

It’s not newly fixed, it’s just that the previous output included it when empty (and it is frequently empty). I did mention that the output can get large with overly liberal selectors using custom properties (a In my website’s case) but that this should be very rare in the wild. Preserving nesting is the whole point of building a dependency graph, otherwise we could just go on from the stylesheet info. There is one potential optimization however. Notice that in the huge tree generated on my website there are many identical entries on the same nesting level. Those add nothing to the analysis, and bloat the output. Do you have any ideas on how I could compress/eliminate them?

[tabatkins]

While I can't commit to anything large, I can do small reviews. I can't tell from this thread what I'm being asked to review, tho. A little help?

[LeaVerou]

Thanks Tab! Did you see this comment? It has both the algorithm and sample data.