Also sprach Chris DiBona:
> To be clear, there are two situations here:
>
> Situation 1:
>
> (a) Party A gives Party B a library licensed under the LGPL 2.1 along
> with a patent license which says only Party B has the right to use it
> (b) Party B wants to distribute the library to other
2009/6/1 Bil Corry :
> Den.Molib wrote on 6/1/2009 4:55 PM:
>> follow the last one, as it's the one provided nearer the content.
>
> And by the same logic, the header closest to the content could be the one
> that was injected by an attacker (via application hole) -- so might choosing
> the first
On Mon, Jun 1, 2009 at 6:02 PM, Alex Russell wrote:
> On Mon, Jun 1, 2009 at 5:53 PM, Garrett Smith wrote:
>> On Fri, Apr 24, 2009 at 2:41 PM, Alex Russell wrote:
>>> On Fri, Apr 24, 2009 at 11:46 AM, Boris Zbarsky wrote:
Erik Arvidsson wrote:
[...]
>
> ...wow. Not sure I should engage w
I'd like to address some questions that have been raised about the use
of FFmpeg in Chromium and Chrome as well as H.264 decoding in Chrome
(Google's distribution of Chromium). The use of FFmpeg in Chromium and
Chrome is fully compliant with the obligations of the associated
licenses. It feels a li
Alex Russell wrote:
Think bigger. I want to create a concrete Element class (that's what a
is, for all intents and purposes)
As a minor nit, a is basically an HTMLElement, not an Element.
and make it subclassable (or treat it as a Trait for purposes of composition) so
that we can do a compo
On Mon, Jun 1, 2009 at 5:53 PM, Garrett Smith wrote:
> On Fri, Apr 24, 2009 at 2:41 PM, Alex Russell wrote:
>> On Fri, Apr 24, 2009 at 11:46 AM, Boris Zbarsky wrote:
>>> Erik Arvidsson wrote:
To help out with this scenario
it would be good if an implementation of the EventTarget i
On Fri, Apr 24, 2009 at 2:41 PM, Alex Russell wrote:
> On Fri, Apr 24, 2009 at 11:46 AM, Boris Zbarsky wrote:
>> Erik Arvidsson wrote:
>>>
>>> To help out with this scenario
>>> it would be good if an implementation of the EventTarget interface
>>> could be exposed to JavaScript.
>>
>> Why do you
Den.Molib wrote on 6/1/2009 4:55 PM:
> follow the last one, as it's the one provided nearer the content.
And by the same logic, the header closest to the content could be the one that
was injected by an attacker (via application hole) -- so might choosing the
first header be more prudent?
- B
The only case of double headers I can think of is when using scripts
that set a content-type, then try to set it again and the language
itself don't prevent it.
I think the "right" option in such case would be to follow the last one,
as it's the one provided nearer the content.
So I vote for using
On Mon, 1 Jun 2009, Simon Pieters wrote:
> On Mon, 01 Jun 2009 21:09:56 +0200, Ian Hickson wrote:
>
> > > Please change "the body element" to "body
> > > elements".
> >
> > Really? Do you have a test case demonstrating this?
>
> http://software.hixie.ch/utilities/js/live-dom-viewer/saved/124
H
On Mon, 01 Jun 2009 21:09:56 +0200, Ian Hickson wrote:
Please change "the body element" to "body
elements".
Really? Do you have a test case demonstrating this?
http://software.hixie.ch/utilities/js/live-dom-viewer/saved/124
--
Simon Pieters
Opera Software
On Mon, 1 Jun 2009, Simon Pieters wrote:
>
> > Modified: source
> > ===
> > --- source 2009-05-30 02:33:07 UTC (rev 3150)
> > +++ source 2009-05-30 03:49:18 UTC (rev 3151)
> > @@ -80436,9 +80436,10 @@
> > form { margin-bottom: 1em;
Boris Zbarsky wrote:
The other use case is doing createImageData, followed by filling in the
pixels, followed by putImageData.
I just saw the example in the spec that does just this, but bases the
values it puts in on numbers it gets out of getImageData. For that case
you would of course wan
Maciej Stachowiak wrote:
In some environments, a CSS pixel may be more than one device pixel.
Yes, I'm well aware.
In this case, getImageData followed by putImageData will lose resolution.
Right. I did mention that in my reply to Oliver.
It seems that there are two significantly different
On Sat, 30 May 2009 05:49:20 +0200, wrote:
Author: ianh
Date: 2009-05-29 20:49:18 -0700 (Fri, 29 May 2009)
New Revision: 3151
Modified:
index
source
Log:
[] (0) Try to make the magic margin collapsing rule more accurate.
Modified: source
===
On Mon, Jun 1, 2009 at 7:13 PM, Maciej Stachowiak wrote:
>
> On May 31, 2009, at 9:08 PM, Robert O'Callahan wrote:
>
> Here are a couple of relevant threads:
> http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2007-May/011284.html
>
> http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2008-Feb
On May 31, 2009, at 9:08 PM, Robert O'Callahan wrote:
Here are a couple of relevant threads:
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2007-May/011284.html
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2008-February/013906.html
Then there was a discussion on #whatwg more recentl
On May 31, 2009, at 6:55 PM, Boris Zbarsky wrote:
3) It's not clear to me why imagedata actually exposes device
pixels,
nor is it clear to me how this is supposed to work if the same
document is being rendered to multiple devices. Is a UA allowed
to have a higher internal res
18 matches
Mail list logo