W3C home > Mailing lists > Public > www-style@w3.org > June 2015

Re: [mediaqueries] undefined behavior for the resolution media query

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Tue, 16 Jun 2015 14:57:05 -0700
Message-ID: <CAAWBYDBiq=iRr6jmKoTVCGR16DXrFFUOXBxomFumOsohU5dn5A@mail.gmail.com>
To: Florian Rivoal <florian@rivoal.net>
Cc: www-style list <www-style@w3.org>
On Sat, Jun 13, 2015 at 3:49 AM, Florian Rivoal <florian@rivoal.net> wrote:
> The resolution media query [1] defines what it should do when the environment is a screen made of pixels, and when the environment is a printer, which also has a finite resolution (the resolution for printing dots of arbitrary color).
>
> However, rendering css directly to a printer almost never happens, and in typical print scenarios, you render to an intermediary format (PDF / postscript / XPS ...), and send that to the printer.
>
> That intermediary format more often that not, is a vector format without a meaningful concept of a resolution, and the media queries spec does not say what to do in that case.
>
> This render-to-pdf (or equivalent) scenario is even divided in two sub-cases:
>
> a) no constraints at all on resolution: vector graphics (including fonts) in the page are preserved as vector graphics, and embedded raster images of any resolution are kept as is.
>
> b) vector graphics in the page are preserved as vector graphics, but embedded raster images whose resolution exceed a threshold are down sampled. This is fairly common in pdf exports with a quality setting.
>
> The behavior of the resolution media query is undefined in both cases.
>
> == Suggestion 1 ==
>
> For both case a and b, the value of the media query is infinity, with the following semantics:
> @media (resolution) { /* Applied */ }
> @media (resolution: X) { /* Not applied, regardless of the value of X */ }
> @media (resolution < X) { /* Not applied, regardless of the value of X */ }
> @media (resolution <= X) { /* Not applied, regardless of the value of X */ }
> @media (resolution > X) { /* Always applied, regardless of the value of X */ }
> @media (resolution >= X) { /* Always applied, regardless of the value of X */ }
>
> == Suggestion 2 ==
>
> In case a, the value of the media query is infinity, with the same semantics as above, but in case b,
> the resolution media feature is based on the threshold resolution.
>
> == Suggestion 3 ==
>
> Do the same as suggestion 2, but also introduce another media feature: rasterize.
> When rendering to screen or directly to a printer, or to any media that is quantized into pixels or similar small dots, the (rasterize) evaluates to true, but when outputting to a vector format, even one that down samples embedded rasters, (rasterize) evaluates to false.
>
>
> I think suggestion 3 is the one we want, because you're not always querying for resolution for the same reason. If you are querying to pick between different raster assets, then you wouldn't care about the rasterize media feature (but then again, you might not even use media queries at all, and use src-set / image-set instead).
>
> On the other hand, if you for example want to switch to sans-serif fonts on low resolution medium for legibility reasons, it is relevant, as you don't want to switch if you're in a pdf exporter which down-samples images but preserves fonts in font/vector form.
>
> @media (rasterize) and (resolution < 2dppx) { font-family: sans-serif; }
>
>  - Florian
>
> [1] http://dev.w3.org/csswg/mediaqueries/#resolution

I'd prefer Suggestion 4: same as 1, but we adopt a rasterize media
feature with the same syntax, which gives the rasterization threshold
resolution.  Add a "none" value to both 'resolution' and 'rasterize'
which indicate there's no threshold/the resolution is infinity; you
can then use them in a boolean context to indicate whether the output
format is vector (`(resolution)` is false) and whether there's a
rasterization threshold (`(rasterize)` is true).

~TJ
Received on Tuesday, 16 June 2015 21:57:52 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:54 UTC