- From: Maciej Stachowiak <mjs@apple.com>
- Date: Fri, 22 Nov 2013 11:06:57 -0800
- To: Jonathan Kew <jfkthame@googlemail.com>
- Cc: www-style list <www-style@w3.org>
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. > 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). 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.) Regards, Maciej
Received on Friday, 22 November 2013 19:07:38 UTC