It sounds like your problem is with the CSS WG and not with css3test. In that case, please feel free to discuss your issue with them (though I can almost guarantee you that nothing will come out of it since you want to change things that have been in browsers for years). This is not the right place for it. End of discussion.

Originally posted by @LeaVerou in https://github.com/LeaVerou/css3test/issues/169#issuecomment-441402153

You've still not understood the definition of "compatible" units which is a core part of SVG (and then of CSS by later reference). Compatible means that there exists a function transforming one to another but this transform is NOT necessarily unique. In SVG this transform changes when you change the CTM: there's NO single "constant" that allows converting them directly by a simple scalar product. This conversion passes through the CTM which is changed in various ways in SVG (and CSS) !!!

I've never said that conversions between "cm", "in", "px" were "incompatible" as you think (or if you misread me). That's the opposite: not only they are compatible but they are statically defined with a constant (because they are on the same group, they are ALL in the gorup of "absolute" units. But this is NOT the case for other units.

SVS and CSS in fact are working with a combination of at least FIVE transform matrixes which allows mapping

"line-height relative" units to font-relative units (two variants depending on which unit it used to define the line-height, the font will be the first one specified for the current element if this font-size is unit-less, or for the first ancestor element whose font-size is not unit-less, or for the default font-size of the document's root otherwise).
"font relative" units to other relative units or absolute units (depending on how fonts are sized with their own unit)
"view relative" units to other relative units or absolute units (depending on how views are sized with their own unit)
"absolute" units to document-root relative units
"document-root relative" units to media/page units.

All these 5 groups are composable recursively and each one has its own transform matrix ! But there's NO unique conversion factor between these units belonging to distinct groups. So SVG and CSS have to handle 5 matrixes simultaneously and update them where needed for each element to reflect the matrix to use in their children elements.

All units in these 5 groups are "compatible" if they are in the same dimension (e.g. units of length). But they have simple conversion factors only if the two units to convert from/to belong exactly to the same group.

So I maintain that you're wrong. And it's a fact that it is perfectly testable in a QUICK test in Javascript. And a proof is that there are other "benchmark" tests that properly test if the renderer are correctly "nesting" their conversions, without incorrectly assuming that the 5 groups (for length units) are convertible with the same conversion matrix or a static conversion factor (this is completely wrong).

This is not a problem for the CSS WG, because this is a standard that existed in SVG since the begining (except early versions of SVG where the only units supported were dimension-less, i.e. reduced only to numbers with units, and they were then only relative to the immediate parent element, and all others were in a single group "absolute" units...) long before CSS was integrated ("absolute" is a old bad/confusive terminology of SVG, when "absolute" units are in fact always relative to another base defined by a selected element in the SVG tree, but not necessarily the same element throughout the SVG DOM tree; but this terminology was kept; the only really "absolute" units are those used for the @media queries in CSS, not defined at all in SVG itself!)

But I'm NOT asking you to test CSS @media queries immediately; but at least test units that are part of SVG independantly of CSS media queries.

But remember that your test suite is named "CSS3test" and should then test also the @media queries and their related units (like dpx). This is exactly what your test is suppose to track ! It is directly a goal of your test.

All this is already defined by the CSS WG. I cannot ask them to change or discuss changes when all is already precisely defined by them (and not jsut for CSS3, as it is already standard since CSS 1.0 and has not changed in CSS 2.0), and it's up to you to support their existing and well defined standard, only because you misinterepreted some specs you found in SVG (where the 5 groups of units are clearly an unambiguously defined and already said to be "compatible", which does not indicate that they are linked by a single universal static scaling factors between all pairts of "compatible" units).

Reread the standar scrupulously ! You'll see the confusion or incorrect assumption you made with the term "compatible" (which is accurately and unambiguously defined in SVG and CSS, but not by the simple way you think, i.e. NOT by a single universal scaling factor).

So THis is the CORRECT place to discuss it: this is a RFE (Request for enhancement) only for YOUR test. There's nothing to change in CSS or SVG. This is only something that for now you do not test at all (even if it's really easy to do!), but which is absolutely needed for CSS3 conformance (what your benchmark is supposed to test).

I claim that your test offers only partial converage for a fundamental module used in both CSS and SVG (all versions! and now HTML5 as well!) that is much simpler to test than all your very useful but complex tests, whose accuracy may then be fooled if the essential "units module" is not first tested properly.

LeaVerou / css3test