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

> On 18 Jun 2015, at 01:33, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
> 
> On Wed, Jun 17, 2015 at 2:51 AM, Florian Rivoal <florian@rivoal.net> wrote:
>>> 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).
>> 
>> I am not 100% sure what you mean by "the rasterization threshold". If you mean the resolution at which vector things are rasterized, that's what 'resolution' does already (expect we haven't defined what it does when vector things don't rasterize).
>> 
>> If you mean the threshold to which high res rasters are down sampled to, it should be called something else. Maybe downsampling-threshold?
> 
> Yes, that one.
> 
>> Either way, since you have 2 numeric queries, your system is somewhat more expressive, since you can express "vectors get rasterized to 600dpi, and high res images get downsampled to 450 dpi" or other variations of the situation where vectors are rasterized to a resolution that is different from the one rasters are downsampled to. However, I am not convinced that this is actually useful to expose, and it makes the whole thing a lot less intuitive.
> 
> I think the exact opposite!  (rasterize)+(resolution) means
> (resolution) gets two different meanings, depending on the whether
> (rasterize) is true or false: if true, it represents the output
> medium's resolution (the meaning as currently defined); if false, it
> represents the downsampling threshold.  This means you have to use
> (rasterize) and (resolution) together in a number of non-obvious
> cases; exactly what queries distinguish between "printing" and "PDF
> with down-sampled raster images" isn't obvious.
> 
> Having (resolution) continue to mean the output format's resolution
> (with a value added for infinity), and then having (raster-resolution)
> or (downsample-resolution) or (image-resolution) or something with the
> same grammar (and a value for infinity) makes the situations directly
> analogous.  (image-resolution) will always be less than or equal to
> (resolution) (by definition; the output medium can't represent an
> image at a higher resolution than itself), and it's clearer what jobs
> each is meant for.

After thinking again, now with the naming cleared up, I guess what was confusing me with your solution when trying to write sample media queries for various scenarios was not so much the way you split it between resolution and image-resolution, but rather the fact that you had a none value rather than an infinity value. infinity plays a lot nicer with inequalities:

Given an vector output with no pixels, this:
  @media (resolution >= 2ddpx) { }
is a lot nicer than that:
  @media (resolution >= 2ddpx) or (resolution: none) { }

And also, the fact that this:
  @media (resolution: none) { /* vector output */ }
would be different from that:
  @media (not (resolution)) { /* vector output or non graphical medium */ }
is lousy.

If you're ok with infinity rather than none, I'm ok with your "solution 4" (as long as we use appropriate naming given the semantics, like downsample-resolution or image-resolution, not rasterize).

Deal?

 - Florian

Received on Thursday, 18 June 2015 11:33:50 UTC