Re: [mediaqueries] resolution and device-pixel-ratio

On Fri, Nov 22, 2013 at 11:06 AM, Maciej Stachowiak <> wrote:

> On Nov 14, 2013, at 4:41 AM, Jonathan Kew <> wrote:
> > On 14/11/13 04:22, Dean Jackson wrote:
> >>
> >> On 14 Nov 2013, at 12:15 pm, Tab Atkins Jr. <>
> wrote:
> >>
> >>> On Wed, Nov 13, 2013 at 8:10 PM, Dean Jackson <> wrote:
> >>>> The issue isn't where CSS (or whatever) defined them. It's that
> Safari doesn't follow that definition, and is unlikely to change. This is
> the reason for proposing a new name.
> >>>>
> >>>> (Yes, it's Apple's fault that we implemented something and didn't
> bring it to the standards groups with a clear description that the value
> was supposed to be constant)
> >>>
> >>> Blink *has* changed, and would like to keep the new definition.
> >>
> >> Ummm... we knew Blink has changed and that you would like to keep your
> new definition. This is exactly why Apple is suggesting another definition.
> Am I missing something?
> >>
> >> The alternatives here are:
> >>
> >> (a) Safari changes and breaks content
> >> (b) Mozilla and Chrome change and break content
> >> (c) We compromise on something new
> >>
> >> Note that content is already incompatible thanks to (a) and (b). That's
> why we agreed on (c).
> >
> > But that doesn't really address the existing incompatibility.
> >
> > I think we're all well aware that "deprecating" the existing
> device-pixel-ratio isn't going to magically stop people using it, and
> indeed (thanks to persistent outdated advice, cargo-cult authoring, etc.)
> continuing to create content using it that only works as intended on a
> subset of browsers. In this respect, the web would surely remain fragmented
> for a long time.
> >
> > If it was possible and acceptable for Blink to change in order to
> conform to the agreed standard for device-pixel-ratio (realizing that some
> content could be affected), shouldn't it be possible for Safari to do the
> same?
> >
> > How much content would "break" as a result, and how bad is said
> "breakage"?
> I'd guess the worst case is pages that attempt to size a canvas and get a
> non-integer multiple of the base resolution when they expected an integer.
> This could cause drawing to be completely garbled. Note: I have not tried
> to find content where this actually happens and I don't know for sure that
> it exists.

Why would content become garbled?
I can see that lines and text would become blurry because they don't fall
on whole pixels any more but geometry should not be affected.

> > If the main result is that some pages may fail to use the
> optimum-resolution bitmap assets in certain cases - e.g. when page-zoom is
> not 100% - but otherwise continue to work, ISTM that may be a reasonable
> price to pay for converging on a single standard instead of leaving a
> non-standard, incompatible implementation to pollute the web indefinitely.
> Would you favor changing the spec and the non-Safari implementations to
> match Safari instead? That would also achieve the goal of converging on a
> single standard.
> The reason matching only the 1:1 zoom CSS pixel ratio makes sense is:
> (1) Most content using devicePixelRatio was originally created with iOS in
> mind, and therefore would not expect the page zoom to be factored in, since
> on iOS there is no page zoom.
> (2) If the value is based on 1:1 zoom, then it won't change over time on
> the same page.
> (3) It seems weirdly inconsistent to factor in page zoom but not pinch
> zoom (and pinch zoom really can't be factored in due to #1).

pinch zoom just changes the viewport and doesn't cause layout. It would be
strange to combine it with user zoom which does cause layout.

> I realize there's arguments either way, but if a value with the page zoom
> factored in is useful, then surely it could have another name instead of
> conflicting.
> (Though for the record, what are the reasons to include the page zoom? If
> they are documented elsewhere, a pointer would be sufficient.)

For instance, if zoom is 110%, devicepixelratio becomes 1.1.
If you have a canvas of 1000x1000 css pixels, you will need to set a
backing store of 1100x1100 pixels and apply a scale of (1.1, 1.1)

Received on Friday, 22 November 2013 19:44:07 UTC