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,
Awesome work guys. Thanks!
On Tuesday, September 23, 2014 6:11:58 PM UTC-7, Valentin Gosu wrote:
> As of next week we intend to turn on resource timing. It has been developed
>
> behind the dom.enable_resource_timing pref.
>
>
>
> == Summary ==
>
>
>
> The Resource Timing API allows web app
As of next week we intend to turn on resource timing. It has been developed
behind the dom.enable_resource_timing pref.
== Summary ==
The Resource Timing API allows web applications to access timing
information for resources in a document.
== Platform Coverage ==
Resource timing works on all pla
On Tue, Aug 26, 2014 at 8:23 AM, Chris AtLee wrote:
> Just a short note to say that this experiment is now live on
> mozilla-inbound.
>
> ___
> dev-tree-management mailing list
> dev-tree-managem...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/
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
Robert Strong wrote on 09/22/2014 11:07 AM:
Hi Robert,
> All of the major changes for Mac v2 signing have landed on the Oak branch.
> This will allow us to test installing and updating before landing on
> mozilla-central.
[..]
>
> If no serious issues are found we are hoping to be able to land o
Robert Strong wrote on 09/22/2014 09:50 AM:
>> I see. So I will investigate what's necessary to get those builds
> running in
>> parallel via Mozmill CI.
>
> Specifically, the 32bit plugin-container and libraries that it loads.
The one and only plugin we make use of for tests is Adobe Flash. The
19 matches
Mail list logo
