On 09/25/2014 10:29 AM, Ehsan Akhgari wrote:
>> I don't see this temporary difference as particularly problematic,
>> particularly given that "pixelated" is primarily an upscaling feature,
>> and given that we'll match them before too long. But if others
>> disagree, I'm open to holding off on shi
On 09/25/2014 09:10 AM, Jet Villegas wrote:
> Would it be wise to allow for "image-rendering: pixelated"
> that applies to any scale operation, and give us an option
> to add other operations (eg. "image-rendering: smooth" or
> "image-rendering: bilinear") later?
Down the line, we can definitely a
On 09/25/2014 08:24 AM, James Graham wrote:
> So, are we sure that this is what the spec *should* say? can we imagine
> a scenario in which authors either use hacks to specify different
> properties for different browsers
Bad news: we are already in that world. Right now, if authors want
pixelated
On 2014-09-25, 12:43 PM, Daniel Holbert wrote:
On 09/25/2014 09:16 AM, Ehsan Akhgari wrote:
No, sorry for not being clear, I didn't mean pixel for pixel identical
results. My question was: are we going to have the same behavior for
pixelated in the downscaling case, since now the spec allows tw
On 25/09/14 05:23, Daniel Holbert wrote:
> It depends on what you mean by "interoperable". If you're asking if
> they'll produce the exact same result, pixel-for-pixel, when downscaling
> an image, then no. But that's likely already the case, with the default
> scaling behavior; I'd be surprised
On 09/25/2014 09:16 AM, Ehsan Akhgari wrote:
> No, sorry for not being clear, I didn't mean pixel for pixel identical
> results. My question was: are we going to have the same behavior for
> pixelated in the downscaling case, since now the spec allows two
> different behaviors for that case.
Gotc
On 2014-09-25, 12:23 AM, Daniel Holbert wrote:
Is what
they're going to ship in Chrome 38 going to be interoperable with our
implementation?
It depends on what you mean by "interoperable". If you're asking if
they'll produce the exact same result, pixel-for-pixel, when downscaling
an image, th
Daniel Holbert"
To: "Ehsan Akhgari" , "L. David Baron"
, dev-platform@lists.mozilla.org
Sent: Thursday, September 25, 2014 12:27:12 AM
Subject: Re: Intent to implement: "image-rendering: pixelated" CSS
property-value
On 09/24/2014 09:23 PM, Daniel Holbert wr
On 09/24/2014 09:23 PM, Daniel Holbert wrote:
> So, it's not required to behave exactly the same everywhere; it simply
> codifies an author's intent. (OK, I suppose it *is* required to behave
> exactly the same everywhere in the case of "pixelated" & upscaling,
> since that requires a particular a
On 09/24/2014 06:26 PM, Ehsan Akhgari wrote:
> Hmm, doesn't that basically allow non-interoperable implementations? :(
> I think Jonas' idea on having separate properties for the upscale vs.
> downscale cases is much better.
I'm unconvinced about the usefulness of exposing that much control. This
On 2014-09-24, 9:12 PM, Daniel Holbert wrote:
On 09/24/2014 09:32 AM, L. David Baron wrote:
Or, alternatively, it seems like the use case here would be
addressed by doing what the spec said before.
Following up more on this: the CSSWG has now resolved to *allow* (but
not require) the formerly-
On 09/24/2014 09:32 AM, L. David Baron wrote:
> Or, alternatively, it seems like the use case here would be
> addressed by doing what the spec said before.
Following up more on this: the CSSWG has now resolved to *allow* (but
not require) the formerly-required-by-spec prettier downscaling
behavio
On Wed, Sep 24, 2014 at 7:21 PM, Daniel Holbert
wrote:
> On 09/24/2014 07:38 AM, Ehsan Akhgari wrote:
> >> This makes the implementation considerably simpler, which is great. It
> >> also means that "pixelated" will essentially just be a
> >> more-interoperable version of "-moz-crisp-edges", for
On 09/24/2014 07:38 AM, Ehsan Akhgari wrote:
>> This makes the implementation considerably simpler, which is great. It
>> also means that "pixelated" will essentially just be a
>> more-interoperable version of "-moz-crisp-edges", for the time being.
>
> So, what are we planning to do with -moz-cr
On 09/24/2014 09:32 AM, L. David Baron wrote:
> Or, alternatively, it seems like the use case here would be
> addressed by doing what the spec said before. Is it really that
> much harder to do?
No, it's not much harder.
> Is it just that we'd need to add another value to pass through
> variou
On Tuesday 2014-09-23 17:15 -0700, Justin Dolske wrote:
> On 9/23/14 4:24 PM, Jonas Sicking wrote:
> >>This makes the implementation considerably simpler, which is great. It
> >>also means that "pixelated" will essentially just be a
> >>more-interoperable version of "-moz-crisp-edges", for the tim
On 2014-09-23, 7:07 PM, Daniel Holbert wrote:
On 09/23/2014 02:56 PM, Daniel Holbert wrote:
FWIW, I also emailed www-style to sanity-check my understanding & to see
if there are any other reasons for this behavior-difference:
http://lists.w3.org/Archives/Public/www-style/2014Sep/0340.html
Tu
On 09/23/2014 10:30 PM, Daniel Holbert wrote:
> As noted elsethread (in my response to Martin), it looks like the
> canonical definition of this property-value is actually in a different
> ED -- the "level 3" ED. (whereas the link above is currently the "level
> 4" ED).
(This change -- moving the
On 09/23/2014 01:53 PM, Daniel Holbert wrote:
> Link to standard:
> http://dev.w3.org/csswg/css-images/#valuedef-pixelated
As noted elsethread (in my response to Martin), it looks like the
canonical definition of this property-value is actually in a different
ED -- the "level 3" ED. (whereas the l
On 09/23/2014 10:08 PM, Martin Thomson wrote:
> On 2014-09-23, at 13:53, Daniel Holbert wrote:
>
>> Link to standard:
>> http://dev.w3.org/csswg/css-images/#valuedef-pixelated
>
> Reading the spec it doesn’t say anything about what to do when the image is
> scaled up on one axis and down on the
On 2014-09-23, at 13:53, Daniel Holbert wrote:
> Link to standard:
> http://dev.w3.org/csswg/css-images/#valuedef-pixelated
Reading the spec it doesn’t say anything about what to do when the image is
scaled up on one axis and down on the other. It’s probably not a particularly
valid use case,
On 9/23/14 4:24 PM, Jonas Sicking wrote:
This makes the implementation considerably simpler, which is great. It
also means that "pixelated" will essentially just be a
more-interoperable version of "-moz-crisp-edges", for the time being.
Would it make sense to have separate properties for "sca
On 09/23/2014 04:38 PM, Daniel Holbert wrote:
> On 09/23/2014 04:24 PM, Jonas Sicking wrote:
>> Would it make sense to have separate properties for "scale up" and
>> "scale down"? With image-rendering being a shorthand for setting both?
>
> Firstly: per my replies on the subthread started by ehsan
On 09/23/2014 04:24 PM, Jonas Sicking wrote:
> Would it make sense to have separate properties for "scale up" and
> "scale down"? With image-rendering being a shorthand for setting both?
Firstly: per my replies on the subthread started by ehsan, the
distinction in "scale up" vs. "scale down" behav
On 24/09/14 09:24, Jonas Sicking wrote:
Would it make sense to have separate properties for "scale up" and
"scale down"? With image-rendering being a shorthand for setting both?
Separately, isn't "image-rendering" a bit too generic of a name for
setting scaling strategy?
I guess it was chosen
On Tue, Sep 23, 2014 at 4:07 PM, Daniel Holbert wrote:
> On 09/23/2014 02:56 PM, Daniel Holbert wrote:
>> FWIW, I also emailed www-style to sanity-check my understanding & to see
>> if there are any other reasons for this behavior-difference:
>> http://lists.w3.org/Archives/Public/www-style/2014S
On 09/23/2014 02:56 PM, Daniel Holbert wrote:
> FWIW, I also emailed www-style to sanity-check my understanding & to see
> if there are any other reasons for this behavior-difference:
> http://lists.w3.org/Archives/Public/www-style/2014Sep/0340.html
Turns out there wasn't a strong reason for the
On 09/23/2014 02:39 PM, Daniel Holbert wrote:
> On 09/23/2014 02:16 PM, Ehsan Akhgari wrote:
>> Why are upscaling and downscaling treated differently for pixelated?
>
> I'm not entirely sure what the origin of that distinction is, but my
> understanding (mostly from reading Tab's comments/response
On 09/23/2014 02:16 PM, Ehsan Akhgari wrote:
> Why are upscaling and downscaling treated differently for pixelated?
I'm not entirely sure what the origin of that distinction is, but my
understanding (mostly from reading Tab's comments/responses on the Blink
intent-to-implement thread) is that Near
On 2014-09-23, 4:53 PM, Daniel Holbert wrote:
NOTES:
- Blink has already implemented "pixelated"[1] and it'll be shipping[2]
in Chrome 38 [3]. So, if & when we ship it, there will be
interoperability between at least 2 engines here. (Other rendering
engines expose similar behavior, albeit unde
Summary: The CSS declaration "image-rendering: pixelated" allows authors
to request that we scale up images by effectively making the pixels
larger (using a "nearest-neighbor" algorithm). This is in contrast to
the default (non-pixelated) scaling behavior, which tends to blur the
edges between an
31 matches
Mail list logo
