Test effective support of absolute units

[verdy-p]

None of your tests show if absolute units (independant of the viewport or viewbox and scaling, but only dependant on the root element) are supported.

These absolute units are relative to the user's view: m, cm, mm, in...

Most browsers for now do not support them (not even Chrome). Instead they map them as multiples of relative units, i.e. relative to the viewport metrics (such as px, pc) or to the 1st current font metrics (em, rem), either in the root element or the current element, which are scaled by the font-size measured relatively to the viewport metrics, or relative to the line-heigh (lh, rlh) which are relative to the font-size.

This makes for example impossible to properly scale sizes according to user's experience: all generated images are necessarily adjusted proportionally to the viewport or viewbox, and if the viewport size changes, all thin strokes or small text for example will be rescaled, maning them unreadable.

For accessibility, we need to be able to use absolute heights, independantly of viewports and viewboxes. Then we an adapt the viexbox content by altering the shapes when needed (this means for example that a round button containing text may become a rounded rectangle, borders will will not be rescaled but the content of borders will have to be adapted (e.g. dimensioning correctly a legend on top of a scalable image).

As well bitmap images are always scaled in relative units (px), and they are scaled relatively to the viewport and not relatively to user's visibility/readability demand (which is determined by the default units of the root element). We should be able to scale these images according to user's preferences to show effective details. But most browsers do not support it, even if absolute units (like mm, in, or viewing angle in steradians) are in CSS since ever (browsers still don't correctly estimate these units and do not even use units of the root element, but incorrectly emulate them using the current element, which is obviously completely wrong: for example they assume that 96px (relative to the current element) = 1in (absolute size estimated from the root element) which is obviously completely wrong (because the measure "1in" will vary visually depending on each element if they use different scales, when the mesure should ALWAYS be invariant throughout the document)!

[verdy-p]

one way to test if absolute units are supported, would be to test creating in the DOM canvas two objects defining their own viewport, but using very distinct scales (e.g. one set with 1:1, the other with 1:16 scale), then add a simple square element in each of them (sized in absolute units like "mm" or "in"), then query the sizes of both squares scaled according to sizes rescaled to their common parent element (the parent should be using a relative unit like "px" or "em"): these rescaled sizes should be clearly very different (with one size being effectively 16 times bigger than the other one; I choose 16 to avoid minor rounding errors on 1 or 2 low-order bits when representing the conversion matrix, whose precision should use 32-bit floats at least, i.e. a 24-bits of minimal precision and which should be always rounded correctly if 1 or 2 low-order bits have some errors, meaning that the matrix but use floats which are exact with at least 20 bits of precision with any rounding mode, i.e SVG is usable even for accurately represents any bitmap that are about 1 million pixels wide or high).

[LeaVerou]

This is how these units are defined in the spec, they assume a 96dpi screen. In fact, often the OS does not have access to physical measurements, and cannot generate such physical lengths.

Also, even if this were a spec violation, css3test.com is not intended as a comprehensive testsuite of every single CSS feature, but a quick benchmark of which newer features are supported.

[verdy-p]

Your comment is clearly wrong (as well as your early closing of this bug, which is really justified).

The 96dpi screen is specified ONLY for the root element of the SVG document, on which the absolute and relative units are (of course) necessarily tied (the SVG engine may have access to some external measurements to link "px" measurement with effective "dpx" measurements, in which case the 96dpi assumption will be void even in the root element (this 96dpi assumption is just a default when we cannot get access to the physical measures). But this asumption does not even apply when there's a CTM-based transform or view in a child element "px", "in", "mm" are still bound by the "96dpi" definition, but no longer bound to the same resolution as the parent element in the same document !

The OS itself may provide other hints (such as the type of ouput, the device driver giving the effective size of a display, or its intended use such as a screen or a projector or sheet of paper where the observer can be safely assumed to be at an estimated distance; the total size of the display also gives an hint about the distance of the observer, whose ideal viewing angle to see the whole display should remain within about 45 degrees to see the whole surface). When printing, the exact size of the display area is normally known, just like other properties like the "mask" of ink droplets, plus possibly some information about the diffusion of ink on the type of "paper" which helps determining the incremental step of masks, i.e. the effective "pixel size" (or subpixel sizes if there are multiple color masks). These hints are only used to scale the root element, and have no impact on relative units used by children views or transforms which allremain linked to the units used by the root element.

My concern was that a SVG defines multiple view and that units like "px" are NOT absolute, but ARE defined to be relative to each parent view or transform (so they are ABSOLUTELY NOT tied to the absolute "dpi" definition of the root element).

The specifications CLEARLY distinguish units that are "relative" from those that are "absolute" (and then can vary or not according to the current transform or view or CTM), even if they are said to be "compatible" in terms of "dimension" (e.g. angles, lengths, durations are not compatible with each other, because there's no defined transform or CTM to convert them).

And browsers that assume that both types of units (relative and absolute) are in the same category ARE violating the standard: changing the CTM by transforms or views (within the SAME SVG document) must impact ONLY the relative units, but NEVER the absolute ones !

And this is VERY EASY (and VERY QUICK) to test from javascript, even if we don't know the physical measures and scaling applied to the root element itself (except by "@media" queries in CSS) !

@LeaVerou: So please REOPEN THIS BUG (actually a RFE) which is a real concern (non-portability across SVG implementations), and testable !!! It is perfectly relevant for your goal of performing a "quick benchmark of which newer features are supported" (but you should also not ignore older features that are still incorrectly supported, notably relative units since the first version of SVG but which are absolutely needed for all SVGs, including to support new features correctly, and portably!)

Note: that there are other SVG benchmarks that ALREADY test the conformance of implementations in SVG renderers or web browsers: this is done exclusively within the same document by comparing units after applying transforms (with distinct scales, or non-null rotations and skews) to child elements (it is also possible to do that for the 3D "linear" transforms that use 3x3 matrices, or 3D "affine" transforms that use 4x3 matrices, or 3D "perspective" transforms that use 4x4 matrices).

[verdy-p]

The link you provided only speaks about absolute units (cm, mm, Q, in, pt, pc, px...)

It does not apply to relative units:

• unitless numbers are relative to the CTM (they are definitely NOT equivalent to "px");
• "%,vw,vh,vi,vb,vmin,vmax" units are relative to the viewport;
• "em,ex,cap,ch,ic" units are relative to the "font-size property" which is itself relative to another absolute or relative unit, and the 1st font-family and the specified font-size/font-variant;
• "lh" units are relative to em-units and the "line-height" property...)
• "rem, rlh" are like "em,lh" but according to their definition in the root element of the document (independantly of the CTM applied to child elements).

All these relative units can be tested (including "rem" to make sure it matches the font styles of the root element).

Note:

• there are other absolute units (like "dpx") that conditionally link the "absolute" units or unitless measures, to "@media{}" properties which are also testable (some of these properties are designed for accessibility but may be used to test the color capabilities, dimensions and resolution of the media device).

And in fact most SVGs are designed with relative units only (but they may be bound to the viewport using attributes like viewPort, viewBox, and other scale-matching properties in the root element or in child elements, and all these properties are also animatable; you'll also be concerned when you'll design effects with 3D rotations, perspectives, or even with SVG filters, specified for now only in 2D planes), simply because relative units allow clean designed to be transparently rescaled.

But then, internally the SVG designs must then use relative only units when they use arbitrary layers of children elements with CTM-based transforms (this even prohibits using "px", "mm"... units in these designs, but it is perfectly allowed to use "%" and viewport-relative units, and font-size relative units, provided that font-sizes are set using only relative units not statically bound to "px" units).

New features needed for accessible and responsive SVG designs are based on @media-absolute units (like "dpx", bound to the maximum physical resolution and color capabilities for subpixels) and media dimensions (total screen size or printed page size), and they can be tested as well (this is a requirement to adapt websites and presentations of applications, especially on mobile devices whose size and resolution vary much more than typical screen displays, but also for large smartTV/home cinema displays, and for other viewing conditions for which the environment may also provide physical sensors or information: e.g. ambiant lightness, date and time of day and geographic location to estimate night and day conditions, user preferences about white temperature, or their ability to distinguish colors or their prefered viewing angle, or the proximity of the viewer with the screen, or for other non-display units an input of the ambiant sound/noise, as well as linguistic preferences for aural synthesis of audio, or audiogram capabilities of users with their prefered audible frequencies).

[svgeesus]

All of the absolute length units are compatible, and px is their canonical unit.

For a CSS device, these dimensions are anchored either

• by relating the physical units to their physical measurements, or
• by relating the pixel unit to the reference pixel.

For print media at typical viewing distances, the anchor unit should be one of the physical units (inches, centimeters, etc). For screen media (including high-resolution devices), low-resolution devices, and devices with unusual viewing distances), it is recommended instead that the anchor unit be the pixel unit. For such devices it is recommended that the pixel unit refer to the whole number of device pixels that best approximates the reference pixel.

My italics.

[LeaVerou]

@verdy-p 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.