On Tue, Apr 26, 2011 at 7:50 PM, Maciej Stachowiak wrote:
>
> On Apr 26, 2011, at 1:45 PM, Dimitri Glazkov wrote:
>
>> On Tue, Apr 26, 2011 at 1:27 PM, Jer Noble wrote:
>>>
>>>
>>> FWIW, WebKit/mac generates these images programmatically, so there's not
>>> really a URL for "play button hover sta
On Apr 26, 2011, at 1:45 PM, Dimitri Glazkov wrote:
> On Tue, Apr 26, 2011 at 1:27 PM, Jer Noble wrote:
>>
>>
>> FWIW, WebKit/mac generates these images programmatically, so there's not
>> really a URL for "play button hover state" which can be targeted. That
>> said, if the URL scheme could
To be clear, the reason "undefined" converts to 0 in this case is
because the argument uses Web IDL type "long", so the argument is
converted using ToInt32 (defined in ECMA-262 in terms of ToNumber).
ToNumber converts undefined to NaN, and ToInt32 then converts NaN to
+0.
-Ken
On Tue, Apr 26, 201
It would be extremely easy to limit it to UA sheets only.
:DG<
On Tue, Apr 26, 2011 at 2:05 PM, Sam Weinig wrote:
> Would we want this to be web facing? Or should we limit it to inside the
> built-in stylesheets?
>
> -Sam
>
> On Apr 26, 2011, at 1:18 PM, Dimitri Glazkov wrote:
>
>> Hello,
>>
>>
Would we want this to be web facing? Or should we limit it to inside the
built-in stylesheets?
-Sam
On Apr 26, 2011, at 1:18 PM, Dimitri Glazkov wrote:
> Hello,
>
> SUMMARY: we would like to introduce a "webkit-resource" URL scheme for
> CSS, which would refer to images baked into WebKit.
>
>
On Tue, Apr 26, 2011 at 1:27 PM, Jer Noble wrote:
>
> On Apr 26, 2011, at 1:18 PM, Dimitri Glazkov wrote:
>
> SOLUTION: Looking at the current media controls implementations, most
> of the -webkit-appearance states are kind of like background images,
> each reflecting appearance of an element at a
Kenneth pointed out that NaN should then be converted to 0 per ECMA. So
we're doing the right thing in our code generators. Since File API has been
updated to get this issue clarified, we're fine here with nothing particular
that needs to be done. Thanks for all your help.
On Mon, Apr 25, 2011 at
On Apr 26, 2011, at 1:30 PM, David Kilzer wrote:
> On Apr 25, 2011, at 4:59 PM, Stephanie Lewis wrote:
>
>> One point brought up during the compile time discussion today was that if
>> you pulled once a day, you were likely to have rebuild the world. I thought
>> it would be interesting to see
On Apr 25, 2011, at 4:59 PM, Stephanie Lewis wrote:
> One point brought up during the compile time discussion today was that if you
> pulled once a day, you were likely to have rebuild the world. I thought it
> would be interesting to see which files were contributing to rebuilding the
> world
On Apr 26, 2011, at 1:18 PM, Dimitri Glazkov wrote:
> SOLUTION: Looking at the current media controls implementations, most
> of the -webkit-appearance states are kind of like background images,
> each reflecting appearance of an element at a particular state. Thus,
> it seems we should be able t
Hello,
SUMMARY: we would like to introduce a "webkit-resource" URL scheme for
CSS, which would refer to images baked into WebKit.
BACKGROUND: in order to style media controls today, we rely on the
ControlPart enum
(http://codesearch.google.com/codesearch/p#OAMlx_jo-ck/src/third_party/WebKit/Sourc
I think it's ok to keep WML code if we can avoid the form control issue.
We can terminate the form control abstraction for HTML and WML. e.g.
- Merge dom/InputElement to html/HTMLInputElement
- Merge dom/InputElement to wml/WMLInputElement
- Remove dom/InputElement
- Copy RenderTextControlSingleL
On 2011-04-26, at 05:11, Alan Swartz wrote:
> That's good to know. It's not the support of the Cocoa event model and
> CoreGraphics that appears broken, it's that the code that checks these
> options appears to be compiled out by the NP_NO_CARBON #define for 64 bit
> builds in PlugInViewMac.m
I talked with Dave at the contributor meeting and I think we should try to move
our existing tests over to GTest and see if we can get them all to pass and not
be any slower. If that is doable, I think we should switch over. If, in the
future, we find GTest to not have the features we need and
Hi,
I am trying to build a set of requirements for an anti-fingerprinting API in
WebKit. I have a wiki page where I've started dumping all the things such
an API needs to worry about:
https://trac.webkit.org/wiki/Fingerprinting
>From an implementation point of view I've started by looking at t
That's good to know. It's not the support of the Cocoa event model and
CoreGraphics that appears broken, it's that the code that checks these options
appears to be compiled out by the NP_NO_CARBON #define for 64 bit builds in
PlugInViewMac.mm.
With the current code, I don't see how any NPAPI p
16 matches
Mail list logo
