On 11/26/10 11:39 PM, Simon Fraser wrote:
But CSS gradients are already requiring interpolation in premutiplied space,
right?
I think you're thinking of CSS Transitions, which we decided should run in
premultiplied.
No. http://dev.w3.org/csswg/css3-images/#color-stop-syntax currently says:
On Nov 26, 2010, at 6:38 PM, Boris Zbarsky wrote:
> On 11/26/10 4:09 PM, Simon Fraser wrote:
>> This would be hard for WebKit, which relies on Core Graphics for gradients
>> on some platforms. CG doesn't allow us to interpolate in premultiplied
>> space.
>
> But CSS gradients are already requiri
On 11/26/10 4:09 PM, Simon Fraser wrote:
This would be hard for WebKit, which relies on Core Graphics for gradients
on some platforms. CG doesn't allow us to interpolate in premultiplied
space.
But CSS gradients are already requiring interpolation in premutiplied
space, right?
-Boris
On Nov 23, 2010, at 12:43 PM, Tab Atkins Jr. wrote:
> Implementors, does
> this sounds like a change you can get behind? We already changed
> canvas shadows to match behavior with CSS shadows; this is a much
> smaller change for spec-equivalence.
This would be hard for WebKit, which relies on C
All,
You may have seen me posting to the list, posting defects related to the
accessibility of the Canvas element. If you've followed those threads,
you've seen others on the list rebuke my use cases, as inappropriate
uses of existing APIs. This has happened twice, recently. In both cases,
I'
Silvia Pfeiffer schrieb am Thu, 25 Nov 2010
20:01:37 +1100:
> Also, implementing WebM or Ogg Theora encoding is just as royalty-free
> as decoding them, so Mozilla, Opera and Google wouldn't need to worry
> there.
Slightly offtopic: Anyone considering the low-bandwith audio use case?
Surely, spe
On 2010-11-23 18:24, Anne van Kesteren wrote:
On Fri, 19 Nov 2010 19:50:42 +0100, Per-Erik Brodin
wrote:
We are about to start implementing stream.record() and StreamRecorder.
The spec currently says that “the file must be in a format supported by
the user agent for use in audio and video elem
On 11/26/2010 11:59 PM, Julian Reschke wrote:
On 26.11.2010 16:55, Brett Zamir wrote:
On 11/26/2010 7:13 PM, Julian Reschke wrote:
On 26.11.2010 11:54, Brett Zamir wrote:
...
My apologies for the lack of clarity on the approval process. I see
all
the protocols listed with them, so I wasn't c
On 26.11.2010 16:55, Brett Zamir wrote:
On 11/26/2010 7:13 PM, Julian Reschke wrote:
On 26.11.2010 11:54, Brett Zamir wrote:
...
My apologies for the lack of clarity on the approval process. I see all
the protocols listed with them, so I wasn't clear.
In any case, I still see the need for both
On 11/26/2010 7:13 PM, Julian Reschke wrote:
On 26.11.2010 11:54, Brett Zamir wrote:
...
My apologies for the lack of clarity on the approval process. I see all
the protocols listed with them, so I wasn't clear.
In any case, I still see the need for both types being reserved (and for
their subn
On 26.11.2010 11:54, Brett Zamir wrote:
...
My apologies for the lack of clarity on the approval process. I see all
the protocols listed with them, so I wasn't clear.
In any case, I still see the need for both types being reserved (and for
their subnamespaces targeted by the protocol handler), i
On 11/26/2010 6:18 PM, Julian Reschke wrote:
On 26.11.2010 05:20, Brett Zamir wrote:
I'd like to propose reserving two protocols for use with
navigator.registerProtocolHandler: "urn" and "xri" (or possibly xriNN
where NN is a version number).
See http://en.wikipedia.org/wiki/Extensible_Resource
On 26.11.2010 05:20, Brett Zamir wrote:
I'd like to propose reserving two protocols for use with
navigator.registerProtocolHandler: "urn" and "xri" (or possibly xriNN
where NN is a version number).
See http://en.wikipedia.org/wiki/Extensible_Resource_Identifier for info
on XRI (basically allows
13 matches
Mail list logo
