2011/10/6 Ryosuke Niwa
> 2011/10/6 Alexey Proskuryakov
>
>>
>> 06.10.2011, в 13:49, Scott Graham написал(а):
>>
>> The first revision of the spec (from the Scope section) is intended to
>> handle:
>>
>> ... support for devices common to current gaming systems including
>> gamepads, directional p
On Thu, Oct 6, 2011 at 2:07 PM, Alexey Proskuryakov wrote:
>
> 06.10.2011, в 13:49, Scott Graham написал(а):
>
> The first revision of the spec (from the Scope section) is intended to
> handle:
>
> ... support for devices common to current gaming systems including
> gamepads, directional pads, jo
2011/10/6 Alexey Proskuryakov
>
> 06.10.2011, в 13:49, Scott Graham написал(а):
>
> The first revision of the spec (from the Scope section) is intended to
> handle:
>
> ... support for devices common to current gaming systems including
> gamepads, directional pads, joysticks, wheels, pedals, acce
06.10.2011, в 13:49, Scott Graham написал(а):
> The first revision of the spec (from the Scope section) is intended to handle:
>
> ... support for devices common to current gaming systems including gamepads,
> directional pads, joysticks, wheels, pedals, accelerometers.
Why does the spec title
Hi Alexey,
The first revision of the spec (from the Scope section) is intended to
handle:
... support for devices common to current gaming systems including gamepads,
directional pads, joysticks, wheels, pedals, accelerometers.
This is based on a somewhat generic treatment of axes and buttons t
On Thu, Oct 6, 2011 at 1:42 PM, Alexey Proskuryakov wrote:
>
> 06.10.2011, в 13:23, Peter Kasting написал(а):
>
> Why are you convinced there is input device fragmentation here? My
> understanding is that the spec as proposed already handles multi-axis
> digital and analog controls so things you
06.10.2011, в 13:23, Peter Kasting написал(а):
> Why are you convinced there is input device fragmentation here? My
> understanding is that the spec as proposed already handles multi-axis digital
> and analog controls so things you mentioned earlier like wheels and 3d mice
> would all "just w
On Thu, Oct 6, 2011 at 11:50 AM, Alexey Proskuryakov wrote:
> I don't want to take a particularly strong stance against Joystick/Gamepad
> specifically, but I see codifying input device fragmentation in Web specs
> and APIs as a move in a wrong direction.
>
Why are you convinced there is input d
I'm not sure Digiplayer is some sort of web standards we want to
implement in WebKit project.
See http://www.webkit.org/contact.html, this kind of question should
have been sent to webkit-help first.
--
Ariya Hidayat, http://ariya.ofilabs.com
___
webk
06.10.2011, в 11:12, James Robinson написал(а):
> Would you mind raising this concern in the relevant standards body (in this
> case, webevents-pub...@w3.org seems to be relevant)? Debating issues with
> standards on webkit-dev is unproductive - it does not include all parties who
> have an i
In RenderBlockLineLayout.cpp, I'm trying to read face of the font from pointer
to a structure named f below:
RenderText* t = toRenderText(o);
const Font& f = t->style(firstLine)->font();
the data I need exist in:
f.m_fontlist.m_ptr->m_cachePrimarySimpleFontData->m_platformData.m_face
I have
On Thu, Oct 6, 2011 at 11:07 AM, Alexey Proskuryakov wrote:
>
> I share Simon's concern that that providing low level access to every
> possible controller creates fragmentation, with purportedly "HTML" content
> that only works on a few devices. There is no clear cut border here - it's
> been me
On Thu, Oct 6, 2011 at 11:07 AM, Alexey Proskuryakov wrote:
>
> I share Simon's concern that that providing low level access to every
> possible controller creates fragmentation, with purportedly "HTML" content
> that only works on a few devices. There is no clear cut border here - it's
> been me
I share Simon's concern that that providing low level access to every possible
controller creates fragmentation, with purportedly "HTML" content that only
works on a few devices. There is no clear cut border here - it's been mentioned
that even touch events can be seen as rare - and then I advo
>From what I tested on iOS5 Mobo Safari, it also overscroll's the
overflow:scroll case (generally div's).
On Thu, Oct 6, 2011 at 1:47 PM, Fady Samuel wrote:
> Hi Anders,
>
> At this point in time, we see no reason to allow for non-zero padding in
> overflow:scroll regions because you can always
Hi Anders,
At this point in time, we see no reason to allow for non-zero padding in
overflow:scroll regions because you can always just move the page into a
unobstructed area and then scroll through that overflow region.
Thanks,
Fady
On Thu, Oct 6, 2011 at 1:43 PM, Anders Carlsson wrote:
> Do
Do you envision this being useful on overflow:scroll regions as well or is it
just frames? If it's just frames, then it seems like something we could keep in
ScrollView? (I haven't looked at the patch yet).
- Anders
On Oct 6, 2011, at 10:41 AM, Fady Samuel wrote:
> Hi Anders,
>
> Thanks for y
Hi Anders,
Thanks for your reply.
Yes, you are correct. This padding would be between the content and the
overhang area.
Thanks,
Fady
On Thu, Oct 6, 2011 at 1:32 PM, Anders Carlsson wrote:
> Hi Fady,
>
> so if I'm understanding correctly, in the context of rubber-band scrolling,
> this paddi
Hi Fady,
so if I'm understanding correctly, in the context of rubber-band scrolling,
this padding would be between the content and the overhang area?
As far as constrainsScrollingToContentEdge goes, I'd like to get rid of it and
just have two scroll functions, one that constrains to the content
On Oct 6, 2011, at 10:11 AM, Gavin Peters (蓋文彼德斯) wrote:
> Dan,
>
> You're right. I'm adding #if PLATFORM(CHROMIUM) to this change shortly.
Thank you.
>
> - Gavin
>
> On 6 October 2011 13:07, Dan Bernstein wrote:
>
> On Oct 6, 2011, at 9:40 AM, gav...@chromium.org wrote:
>
>> Modified: t
On Oct 6, 2011, at 10:12 AM, Darin Fisher wrote:
> I agree that this seems like something to #ifdef. Out of curiosity, did you
> just stumble upon this, or did you actually notice a measurable performance
> regression from this?
I just noticed the patch go by.
>
> -Darin
>
>
> On Thu, Oct
I agree that this seems like something to #ifdef. Out of curiosity, did you
just stumble upon this, or did you actually notice a measurable performance
regression from this?
-Darin
On Thu, Oct 6, 2011 at 10:07 AM, Dan Bernstein wrote:
>
> On Oct 6, 2011, at 9:40 AM, gav...@chromium.org wrote:
Dan,
You're right. I'm adding #if PLATFORM(CHROMIUM) to this change shortly.
- Gavin
On 6 October 2011 13:07, Dan Bernstein wrote:
>
> On Oct 6, 2011, at 9:40 AM, gav...@chromium.org wrote:
>
> Modified: trunk/Source/WebCore/dom/ScriptElement.h (96818 => 96819)
>
> --- trunk/Source/WebCore/
On Oct 6, 2011, at 9:40 AM, gav...@chromium.org wrote:
> Modified: trunk/Source/WebCore/dom/ScriptElement.h (96818 => 96819)
>
> --- trunk/Source/WebCore/dom/ScriptElement.h 2011-10-06 16:37:35 UTC (rev
> 96818)
> +++ trunk/Source/WebCore/dom/ScriptElement.h 2011-10-06 16:40:47 UTC (rev
> 96
Hi all,
We'd like to provide a general mechanism in WebKit for embedders to scroll
page content so that it is not hidden by embedder-provided UI elements that
overlap the page.
In some cases, if a floating UI element overlaps the edge of the page, we'd
like to allow the embedder to scroll beyond
This proposal has matured somewhat, so an update is in order.
FYI:
http://dvcs.w3.org/hg/webevents/raw-file/default/gamepad.html
http://www.w3.org/2010/webevents/charter/2011/Overview.html
We are working behind the ENABLE(GAMEPAD) flag at the moment. Mozilla is
also building a prototype of this
Hi there,
I've generated
WebKit/Source/WebCore/page
digiplayer.cpp
digiplayer.h
and digiplayer.idl
The idl file looks as follows
module window {
interface [
LegacyDefaultOptionalArguments,
OmitConstructor
] digiplayer {
void videoSetup(in DOMString url,
27 matches
Mail list logo
