- From: Rik Cabanier <cabanier@gmail.com>
- Date: Fri, 22 Nov 2013 11:43:34 -0800
- To: Maciej Stachowiak <mjs@apple.com>
- Cc: Jonathan Kew <jfkthame@googlemail.com>, www-style list <www-style@w3.org>
- Message-ID: <CAGN7qDCfmw48n5GCcmNsE5fyB-RTvahAWxFFdfvD-J6Q6utitQ@mail.gmail.com>
On Fri, Nov 22, 2013 at 11:06 AM, Maciej Stachowiak <mjs@apple.com> wrote: > > On Nov 14, 2013, at 4:41 AM, Jonathan Kew <jfkthame@googlemail.com> wrote: > > > On 14/11/13 04:22, Dean Jackson wrote: > >> > >> On 14 Nov 2013, at 12:15 pm, Tab Atkins Jr. <jackalmage@gmail.com> > wrote: > >> > >>> On Wed, Nov 13, 2013 at 8:10 PM, Dean Jackson <dino@apple.com> 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