Hey, thanks for opening this PR. However, this fix is very fragile. What if the line numbers plugin changes its padding? Also, if the code area has padding, this will override it.

My main concern with this is whether the fix belongs here, or in the line-numbers plugin

Unfortunately, this will be unclear until a fix is known. If the fix depends on the line numbers plugin, then it belongs there. If the fix just needs the alignment code to be more robust, then it belongs here.

Even if it's a lie, I think it's better for an unknown printer to pretend that it covers the sRGB gamut, as we've been printing sRGB colors to our inadequate home printers for decades.

Yes we have, and the result is a lot of puzzlement about "why does this color print so differently?".

I don't think it's useful for a print stylesheet to resolve (in-gamut: rgb(255 0 0)), say, as false, at least for a color printer

But it is out of gamut! Almost certainly unless it's some particularly fancy professional printer. Don't we want the results to be useful?

I finally pushed improved code for this. I'd say this was by far the hardest (non-custom) metric to compute. First, I tried the Apriori algorithm. I tried two different libraries but did not get great (or even meaningful) results. Once the property sets in the training data were more than a dozen or so, it would produce no association rules, even with very low min_support and confidence.

So I ad hoc implemented a custom algorithm somewhat inspired from Apriori. I will try to document it here before I forget how it works myself 😛

• First, an object literal is built with properties and the rules they appear in.
• Then, the object is iterated, and for properties appearing in more than MIN_TOTAL_FOR_DESCENT rules, we find the properties they appear together with, and store the rules that contain both
• Pairs that appear in <= MAX_TOTAL_FOR_PRUNE rules or <= MAX_PERCENT_FOR_PRUNE * 100% of the rules the individual properties appear in are pruned
• The process is recursively repeated on the pairs, for combinations that appear in more than MIN_TOTAL_FOR_DESCENT rules, when the new combination (with the addition of one property) appears in MIN_PERCENT_FOR_DESCENT * 100% of the rules the subset appears in.

After this process, we have an object literal like this (from Smashing's CSS).

We then traverse this object and store the combinations in an object literal, with values being the % of total rules the combination appears in. Currently this structure is not pruned since I figured aggregation will do so anyway, but it can easily be pruned for efficiency. The end result is a literal like this.

Whoops! Thank you!!

Stats on which font-variant-* longhands such as font-variant-numeric or font-variant-east-asian are being used.

Also whether the font-variant shorthand is being used with the none value, to reset all the longhands.

After consulting with @rviscomi, it appears the overlap with the Fonts chapter is too significant, so we will not have a Fonts section. Therefore, I'm closing this.

Try to detect and show numbers for the native font stack variations, compared to the other popular font families like Open Sans and Roboto.

(by @catalinred)

After consulting with @rviscomi, it appears the overlap with the Fonts chapter is too significant, so we will not have a Fonts section. Therefore, I'm closing this.

Just pushed JS for this. In addition to the metrics we have discussed, I'm also counting properties in which calc() appears.

Sample output for the Smashing Magazine CSS:

{
	"total": 276,
	"properties": {
		"font-size": 73,
		"width": 40,
		"padding": 23,
		"margin": 17,
		"margin-top": 16,
		"margin-bottom": 16,
		"top": 12,
		"max-width": 9,
		"padding-top": 9,
		"height": 8,
		"margin-left": 7,
		"line-height": 7,
		"padding-left": 7,
		"left": 6,
		"margin-right": 6,
		"min-height": 4,
		"right": 4,
		"bottom": 3,
		"grid-row-gap": 2,
		"transform": 2,
		"max-height": 1,
		"padding-bottom": 1,
		"background-position": 1,
		"background-size": 1,
		"grid-template-columns": 1
	},
	"units": {
		"vw": 220,
		"em": 184,
		"px": 65,
		"%": 43,
		"rem": 22,
		"vh": 21,
		"deg": 2
	},
	"number_of_different_units": {
		"1": 10,
		"2": 262,
		"3": 4
	},
	"operators": {
		"+": 237,
		"-": 68,
		"/": 20,
		"*": 15
	},
	"number_of_operators": {
		"0": 1,
		"1": 230,
		"2": 32,
		"3": 8,
		"4": 4,
		"6": 1
	},
	"number_of_parens": {
		"0": 251,
		"1": 18,
		"2": 6,
		"4": 1
	},
	"constants": []
}

I'd go with option 1, in which the focus is more on the CSS than the fonts themselves.

@rviscomi in which of the issues I linked did you feel the focus was on the fonts and not on the CSS? It seems to me that all of them are about the CSS, yet some overlap anyway.

The utils may be useful, so it's worth offering, but my hunch is that it'd be easier for them to reuse 2019 SQL.

Ah ok then. I didn't realize they were using last year's SQL.

My advice would be to have the Fonts section with a few of the most relevant/interesting stats, and include a note at the end like "see the Fonts chapter for more data on fonts usage". It would be good to coordinate with the Fonts chapter lead to ensure that the results are all harmonious.

Ok, so these are our fonts-related issues:

• Opentype features leaverou/css-almanac#23 - Most seems covered by the Fonts chapter
• Variable fonts leaverou/css-almanac#2 - Most seems covered by the Fonts chapter
• Font families and stacks leaverou/css-almanac#15 - All seems covered by the Fonts chapter but I'm not sure and nobody responded to my question here
• line-height units leaverou/css-almanac#16 - Not covered by the Fonts chapter

I see these options:

1. Have a Fonts section that primarily discusses things like units, font names, or shorthands, and pointing to the Fonts chapter for everything else
2. Not have a Fonts section and discuss things like units, font names, or shorthands in other sections, such as e.g. Values & Units
3. Go ahead and measure whatever we'd normally measure if I hadn't noticed the overlap and yolo it 😅

Actually, looking at the Fonts queries I wonder if the overlap is less than I thought, which makes me more inclined to go with 3. Btw they may find the Rework Utils useful since they're doing similar things.

Thoughts?

One complication is that we don't really know what CSS selectors match. We can guess in certain cases (e.g. html or :root, but we don't know what e.g. .foo is. I could:

• store the CSS selectors that these values are found on, and hope that they'd aggregate nicely over the website corpus, OR
• just measure dir values regardless of what selector they come from, OR
• measure dir values broken down by a) obviously <html>, b) obviously <body>, c) any other selector lumped together

Thoughts?

Just pushed JS for this.

It counts:

• Shorthands used (total by property)
• Longhands used (total and by property)
• Shorthands used before their longhand in the same rule
• Longhands used before their shorthands in the same rule
• Number of values for shorthands (only if the value is "simple", to avoid errors)

Sample output for Smashing Magazine's CSS:

{
	"shorthands": {
		"total": 74,
		"border": 14,
		"padding": 11,
		"margin": 7,
		"border-color": 7,
		"flex": 6,
		"outline": 6,
		"background": 6,
		"overflow": 4,
		"border-style": 4,
		"text-decoration": 4,
		"font": 2,
		"border-radius": 2,
		"border-width": 1
	},
	"longhands": {
		"total": 155,
		"margin-block-start": 20,
		"margin-block-end": 20,
		"background-color": 18,
		"margin-inline-start": 17,
		"font-size": 16,
		"margin-inline-end": 15,
		"font-weight": 10,
		"padding-inline-start": 5,
		"align-items": 5,
		"list-style-type": 4,
		"line-height": 4,
		"padding-inline-end": 3,
		"background-image": 2,
		"font-family": 2,
		"left": 2,
		"right": 2,
		"margin-top": 1,
		"padding-block-start": 1,
		"padding-block-end": 1,
		"align-self": 1,
		"flex-direction": 1,
		"overflow-x": 1,
		"overflow-y": 1,
		"font-style": 1,
		"top": 1,
		"bottom": 1
	},
	"longhands_before_shorthands": {
		"total": 0
	},
	"shorthands_before_longhands": {
		"line-height": 1,
		"total": 1
	},
	"values": {
		"margin": {
			"1": 5,
			"2": 2
		},
		"overflow": {
			"1": 3,
			"2": 1
		},
		"border-style": {
			"1": 4
		},
		"border-width": {
			"1": 1
		},
		"border-color": {
			"1": 2
		},
		"border": {
			"1": 2,
			"2": 4,
			"3": 5
		},
		"font": {
			"1": 1,
			"2": 1
		},
		"padding": {
			"1": 3,
			"2": 3,
			"4": 2
		},
		"flex": {
			"1": 6
		},
		"border-radius": {
			"1": 1
		},
		"outline": {
			"1": 2,
			"3": 2,
			"4": 1
		},
		"text-decoration": {
			"1": 3,
			"2": 1
		}
	}
}

Thanks! Merged!

Just pushed JS for this. It measures use of all logical properties or properties with logical keywords (except those with the logical keyword, since AFAIK that's not supported anywhere). Sample output for the Chrome UA stylesheet:

{
	"logical": {
		"total": 86,
		"margin": 72,
		"padding": 10,
		"text-align": 3,
		"min-size": 1
	},
	"physical": {
		"total": 49,
		"size": 30,
		"inset": 6,
		"text-align": 5,
		"min-size": 4,
		"overflow": 2,
		"margin": 1,
		"resize": 1
	}
}

I just noticed this, sorry if it was there before. You are getting the selector URL param, setting the input to that if it exists, and then setting the selector URL param to the value of the input... which was the URL param you just got! So you're setting it to itself. Unless I'm missing something, this line can just be deleted.

We could deduplicate durations at the page level before aggregating if that would give you the data you're looking for.

I'm just not sure if a website should be weighed higher than others in this aggregate based on how they are using CSS animations.

A few more questions about things that have come up:

• We had originally planned a bunch of font-related metrics, however it looks like there is huge overlap with the Fonts chapter. I'm not sure exactly how much overlap, but definitely >70%. Should we not have a Fonts section perhaps? I looked at the 2019 Almanac and it did have a Fonts section, which stats clearly distinct from the Fonts chapter, but this year it looks like the Fonts chapter is doing a lot of CSS-based stats.
• In many stats, the output data structure is an object literal whose keys are values we are measuring and the values are frequencies, i.e. how many times it appeared in the CSS. We should come up with a plan for aggregating these over the website corpus to find the most common whatever. Again, it's the same question as for the durations above: Is it a good idea for a given website to be weighed higher than others based on its CSS usage?

Nice! sRGB is a good default for screen media, but not so much for print media (if a printer can actually output the entire sRGB gamut, that's pretty impressive). I would suggest a different default for print, ideally one that is a good average of home printers (since those are the ones most likely to be missing a profile), such as an appropriate FOGRA or US uncoated SWOP, with a SHOULD so that UAs can decide a different default (or a user configurable default).

I decided to only do nonexistent properties, as the other one with the semicolon would yield too many false positives to be interesting.

I still see it, just in less of the diff:

As to why it looks normal in your editor, I wonder if you have set tab size to 2 or something like that.

Would like to see numbers on various ways of hiding DOM elements, by trying to guess on: [aria-hidden], .hidden, .hide, .sr-only, .visually-hidden, .visuallyhidden, .invisible or [hidden].

(by @catalinred)

I went with traversing every declaration inside MQs regardless of whether it was also nested in other rules too.

I just pushed JS for which custom properties are animated, but we should also write some JS that operates on the cssvars custom metric to extract CSS properties with a type. That's sufficiently simple that it can be done directly in the SQL.

Now the comment is out of sync with the code, just remove it :)

Indentation is now correctly with tabs but seems to be 1 level more indented than before?!

Hi @rviscomi,

Thank you for the thoughtful response. In general, I agree with your points.

However, I'm not sure the reason for any deadline slippage is infrastructure. Out of its three analysts:

• One dropped out
• Another had their laptop out of order for TWO (!) weeks, and only got limited time on their spouse's laptop when said spouse was not working.
• And the third analyst is also an analyst in a number of other chapters and project manages the whole project, so has very limited time to contribute to this one.

Furthermore, the analysis is not split across three repos, only two: this one and css-almanac. The fact that my work in the Almanac inspired me to write two libraries (Parsel and Rework Utils) isn't a fragmentation of the analysis effort any more than Rework being in its own repo is a fragmentation of effort.

The remaining two repos mainly reflect the lack of consensus about where the analysis should happen, not an insufficiently scrappy workflow: I have so far exclusively worked in css-almanac, and you have almost exclusively worked in this one.

So what's the best way to go forwards? I propose adopting your proposal, with a few slight tweaks:

• Responding to your point, I just wrote a small Node script to build rework-utils.js in the rework-utils repo. So, all we need to do to update it in BigQuery is literally cp, which hardly slows us down. If you're sure BigQuery does not support modules (I assumed it did since Chrome 75 does), I can do something similar with Parsel as well.
• We can iterate on JS in the css-almanac repo, and once the JS is ready, we can iterate on the SQL here, which gives us the best of both worlds. This can happen concurrently, as the JS is pending for many metrics, whereas others are ready for SQL. You can see the different states of each one here. I don't think this is any less agile, since we can't write JS without running it to see if it works!

If that happens, the contingency plan would be to release it post-launch, which I'm afraid would cause it to lose out on a lot of early readership.

Yes, we should definitely avoid that at any cost. What is the next hard deadline? I see the roadmap lists September as analyzing data, so we're still within that and I'm confident we can finish the analysis and results review by the end of the month. I do see we're past the Sep 7 and Sep 14 sub-deadlines, but since I'm also the main author, and I review stats as we go, that's a much tighter, and therefore faster, feedback cycle. I can reach out to the other authors as we go to review stats for their own sections.

My ideal is to have 1-1 query-to-metric, optimizing for the readers' experience of wanting to scrutinize how the stats were calculated or remix the query themselves. That said, it's ok to have a query with multiple similar/related metrics.

Thanks, I will keep that in mind. I think the specific example I asked about definitely falls in the category of "similar/related metrics", so I guess we're good.

The UDF JS operates on one CSS payload at a time, so one pattern we could use here would be to extract an array of durations in the JS, then UNNEST each duration in SQL, and aggregate the distribution of all durations across all stylesheets/pages.

If I'm reading this right, wouldn't a CSS file with e.g. 100 durations be weighed 100 times higher than another with only one? Is this desirable? (not a rhetorical question, I could argue this both ways :) )

The summary stats we've typically used for distributions are the 10, 25, 50, 75, and 90th percentiles, as opposed to average/mode. Do those work for you?

Sure, that's better!

Are authors still using these？Which ones are most prevalent that work with common versions of browsers? If possible to determine, which problems are being solved that can’t be solved with @supports?

For reference: http://browserhacks.com/

I'm afraid we need to let this one go in favor of the other metrics.

• We're running late, and this doesn't even have a clear algorithm yet of what we're measuring and how, only a URL. It would be a tremendous effort to measure all hacks in that URL.
• Most importantly, many of them are not even parseable by Rework, making analysis impossible. If we restrict analysis to those which are valid CSS, then the statistic becomes less interesting, while still being very time consuming to calculate.

If the selector param in the URL is empty, the if will be skipped anyway, so there's no need to do || selectorText.value.

Algorithm:

Walk selectors, and count:

• ids in attribute equality
• compound selectors with the same class name more than once
• Descendant selectors with html or :root as the first one.

Unfortunately :not(#nonexistent) cannot be determined by looking at the AST :/

Are .clearfix, .clear or .cf still popular? How popular considering the current flexbox and grid usage?

(by @catalinred)

What are we really trying to measure here? Essentially we're measuring usage of floats by proxy, it's not that clearfix by itself is interesting. However, usage of floats is measured in #14. So, unless there's any objection, I'm going to close this.

Usage of inherit, initial, unset, revert, overall and by property.

Algorithm is pretty obvious.

Algorithm: Count the different values of the display, position properties, as well as the incidence of float.

• What percentage of declarations has !important?
• Of those, what's the breakdown by property?

Algorithm: Walk all declarations, count how many have !important and how many there are total. Of those with !important, count which property it is.

Thanks!

This is actually part of the calculation for #11

Hi there again,

I was wondering if there are any plans to calculate stats for font stacks and popular font names via the font/font-family properties? Looking at the content outline, I couldn't figure out whether this is planned or not (there is something about popular fonts, but not sure if it refers to web fonts only).

I'm asking to see if https://github.com/LeaVerou/css-almanac/issues/15 overlaps (in which case we have one less query to do, yay)

• How many websites use variable fonts?
• What variation axes do they declare/use?
• Do they mostly use the low-level font-variation-settings, or the higher level properties (where available)?
• What custom axes do they use?

As much as I would love to, I'm afraid I don't have time to write queries for other chapters, since we already have ~40 metrics to calculate here. However, I would be happy to provide help with the algorithm or JS to whomever needs it. Looking at the content outline it appears that pretty much all of these metrics are planned for the Fonts chapter, so I'm gonna go ahead and close this.

Just pushed some JS which extracts all area names and puts them in a sorted object literal by frequency. If Object.keys(ret).length === 0, then this feature is not used in the CSS at all.

E.g. for this CSS:

.foo {
	grid-template-areas: 
            "a a ."
            "a a ."
            ". b c";
}

the output is:

{
	"a": 4,
	".": 3,
	"b": 1,
	"c": 1
}

@rachelandrew is there any website you'd recommend testing the JS on? Or actually, you can test it yourself by running testQuery("33-grid-template-areas") here (after you enter a link to the CSS file): http://projects.verou.me/rework-utils/

The JS I just pushed calculates:

• frequency of length units, percentages, unitless 0 overall
• frequency of length units, percentages, unitless 0 by property

Sample output (for the Smashing Magazine CSS):

{
	"0": 834,
	"byProperty": {
		"line-height": {
			"0": 5,
			"total": 61,
			"<number>": 30,
			"em": 15,
			"px": 6,
			"vw": 3,
			"%": 2
		},
		"margin": {
			"0": 223,
			"total": 398,
			"em": 154,
			"vw": 9,
			"px": 6,
			"rem": 3,
			"vh": 2,
			"<number>": 1
		},
		"height": {
			"0": 7,
			"total": 103,
			"px": 41,
			"%": 29,
			"em": 22,
			"vh": 2,
			"vw": 2
		},
		"font-size": {
			"total": 335,
			"em": 253,
			"vw": 50,
			"px": 15,
			"rem": 10,
			"%": 5,
			"vh": 2
		},
		"outline-width": {
			"0": 1,
			"total": 1
		},
		"letter-spacing": {
			"0": 7,
			"total": 74,
			"px": 66,
			"em": 1
		},
		"bottom": {
			"0": 7,
			"total": 17,
			"px": 5,
			"em": 4,
			"vw": 1
		},
		"outline": {
			"0": 3,
			"total": 9,
			"px": 5,
			"em": 1
		},
		"max-width": {
			"total": 122,
			"%": 65,
			"px": 30,
			"em": 15,
			"vw": 9,
			"ch": 2,
			"rem": 1
		},
		"padding": {
			"0": 211,
			"total": 635,
			"em": 335,
			"px": 48,
			"vw": 19,
			"rem": 15,
			"vh": 5,
			"%": 2
		},
		"top": {
			"0": 18,
			"total": 86,
			"%": 24,
			"em": 22,
			"px": 15,
			"vw": 4,
			"rem": 3
		},
		"width": {
			"0": 7,
			"total": 285,
			"%": 167,
			"px": 58,
			"em": 28,
			"vw": 18,
			"rem": 3,
			"vh": 3,
			"ch": 1
		},
		"transform-origin": {
			"0": 13,
			"total": 62,
			"%": 49
		},
		"padding-left": {
			"0": 25,
			"total": 91,
			"em": 41,
			"px": 11,
			"rem": 8,
			"vw": 4,
			"%": 2
		},
		"flex": {
			"0": 9,
			"total": 24,
			"<number>": 14,
			"px": 1
		},
		"padding-right": {
			"0": 2,
			"total": 30,
			"em": 16,
			"px": 8,
			"rem": 4
		},
		"flex-basis": {
			"0": 4,
			"total": 85,
			"%": 73,
			"px": 6,
			"em": 2
		},
		"margin-left": {
			"0": 33,
			"total": 113,
			"%": 38,
			"em": 35,
			"px": 5,
			"vw": 2
		},
		"margin-right": {
			"0": 28,
			"total": 95,
			"em": 49,
			"px": 8,
			"%": 7,
			"vw": 3
		},
		"margin-top": {
			"0": 43,
			"total": 167,
			"em": 94,
			"px": 9,
			"vw": 9,
			"rem": 5,
			"vh": 4,
			"<number>": 2,
			"%": 1
		},
		"padding-top": {
			"0": 13,
			"total": 71,
			"em": 38,
			"%": 7,
			"vw": 5,
			"px": 5,
			"vh": 2,
			"rem": 1
		},
		"min-height": {
			"0": 2,
			"total": 19,
			"px": 7,
			"vh": 4,
			"rem": 2,
			"vw": 2,
			"%": 1,
			"em": 1
		},
		"border": {
			"0": 7,
			"total": 41,
			"px": 29,
			"<number>": 5
		},
		"border-top": {
			"total": 4,
			"px": 3,
			"em": 1
		},
		"margin-bottom": {
			"0": 44,
			"total": 165,
			"em": 102,
			"vw": 11,
			"px": 7,
			"vh": 1
		},
		"border-bottom": {
			"0": 2,
			"total": 24,
			"px": 22
		},
		"grid-row-gap": {
			"total": 4,
			"em": 2,
			"vw": 2
		},
		"padding-bottom": {
			"0": 6,
			"total": 50,
			"em": 30,
			"px": 11,
			"rem": 2,
			"%": 1
		},
		"column-gap": {
			"0": 1,
			"total": 4,
			"px": 2,
			"em": 1
		},
		"background-position": {
			"0": 2,
			"total": 80,
			"%": 56,
			"em": 20,
			"vw": 1,
			"px": 1
		},
		"tab-size": {
			"<number>": 2,
			"total": 2
		},
		"border-radius": {
			"0": 41,
			"total": 161,
			"px": 106,
			"%": 9,
			"em": 5
		},
		"left": {
			"0": 20,
			"total": 59,
			"%": 18,
			"em": 12,
			"px": 5,
			"vw": 3,
			"rem": 1
		},
		"background-size": {
			"total": 146,
			"%": 76,
			"px": 48,
			"em": 22
		},
		"scroll-margin-top": {
			"rem": 1,
			"total": 1
		},
		"border-left": {
			"total": 9,
			"px": 8,
			"em": 1
		},
		"min-width": {
			"0": 3,
			"total": 18,
			"px": 12,
			"%": 2,
			"em": 1
		},
		"border-right": {
			"total": 7,
			"px": 5,
			"<number>": 2
		},
		"max-height": {
			"0": 3,
			"total": 13,
			"em": 4,
			"px": 4,
			"vh": 1,
			"%": 1
		},
		"right": {
			"0": 21,
			"total": 40,
			"em": 7,
			"px": 6,
			"vw": 3,
			"%": 3
		},
		"border-color": {
			"<number>": 2,
			"total": 2
		},
		"text-indent": {
			"0": 1,
			"total": 2,
			"%": 1
		},
		"border-bottom-right-radius": {
			"0": 4,
			"total": 4
		},
		"border-bottom-left-radius": {
			"0": 5,
			"total": 5
		},
		"border-left-width": {
			"0": 2,
			"total": 2
		},
		"border-width": {
			"0": 2,
			"total": 8,
			"px": 6
		},
		"vertical-align": {
			"em": 1,
			"total": 1
		},
		"border-top-left-radius": {
			"0": 4,
			"total": 4
		},
		"text-decoration-thickness": {
			"em": 1,
			"total": 1
		},
		"outline-offset": {
			"em": 1,
			"total": 1
		},
		"border-right-width": {
			"0": 2,
			"total": 2
		},
		"columns": {
			"<number>": 1,
			"total": 1
		},
		"grid-gap": {
			"0": 1,
			"total": 4,
			"em": 3
		},
		"border-top-right-radius": {
			"0": 2,
			"total": 2
		}
	},
	"total": 3750,
	"em": 1340,
	"%": 639,
	"px": 630,
	"vw": 160,
	"<number>": 59,
	"rem": 59,
	"vh": 26,
	"ch": 3
}

Indeed, I'd classify this as a bug.

Hi @AbbyTsai,

Happy to help! What do you mean by samples? Samples of CSS?

Yes, the "in-gamut" MQ case is being discussed in #5045; I think it's a great idea.

Thank you, I'm glad you think it's a great idea! However, what I was discussing in the quote was a MQ to check if a color space is available, i.e. something like @media (color-space-exists: --forgra39).

After discussing this with @svgeesus, it seems that there's a bunch of things we need to decide about color() fallbacks and validity before we serialize to spec prose.

• If a color() specifies an invalid color but its fallback is valid, is the color() call valid? It seems like it should be, as this is how var() fallbacks work, but we need to resolve.
• It is currently specified that if a color space is not supported, the color is invalid. However, if the color space is a <dashed-ident>, the color should be invalid at computed value time, since the color space may always be loaded later. Keyword-defined color spaces can be invalid at parse time, which means their fallbacks can be provided via the cascade.
• If the <dashed-ident> color space is available, but the arguments are incorrect, the color should still be invalid at computed value time, because the @color-profile rule can always be removed and replaced with a different one, for which the arguments are valid. Contrary, for a keyword color space, the validity of the arguments is known at parse time.
• If the fallback applies both when the (<dashed-ident>) color space is not available and when the color is out of the screen gamut, how do you reasonably provide separate fallbacks for these two cases? I imagine the fallback one may want to provide could be significantly different for manual gamut mapping or for an undefined color space. For example, if the color space is unavailable, the fallback must be in a different color space. Whereas, if the color space is available but the color is out of gamut, the fallback could still be in the same color space, just with different arguments.
• Similarly, if the fallback is applied in both cases, how does one specify that if the color is OOG they want to use the browser's built-in gamut mapping, but still provide a fallback if the color space is not available? Would it be useful to have the ability to specify separate fallbacks?
• I wonder if it would be best to provide a media query or other type of conditional to check if a color space is available?
• How does one provide a fallback to lch()? It's not available as a predefined color space on color(), and the lch() function doesn't have a fallback parameter. I suppose it's possible via color(--nonexistent, lch(...), fallback) but that's clunky (and depends on having multiple fallbacks, which I'm not convinced we need). Then again, perhaps the in-gamut MQ can resolve these cases.

To test a single color to be in-gamut, for additive colorspaces, you just need to check if any component is negative, or greater than 1.0 / 100%. (While using a code path that does not prematurely clip, obviously).

Note that the proposal is a MQ that checks if a particular color is within the output device's gamut, not within the gamut of the color space it's specified in.

I've pushed JS to extract all classes, ids, attribute names, pseudo-class & pseudo-element names (instead of the ad hoc JS that I had written for #6).

I'm going to drop the "longest selector" for now, unless @estelle can define how she envisioned that within the next few days.