Forwarding two messages from Jerry Seeger, whose e-mails aren't getting to the
list yet.
Answering Jerry's comment, I think that targeting the spec to explicitly
address gaming use case is better than the current situation. A very large
group of devices is undoubtedly built with gaming and onl
12.10.2011, в 16:43, Scott Graham написал(а):
>> - Spec development process that ignores feedback. Multiple people who want
>> this feature (including one of spec editors) were aware of feedback but
>> didn't act on it. We had consensus on webkit-dev that the name was bad
>
> I was indeed awar
2011/10/12 Alexey Proskuryakov :
>
> The issues that I see are:
>
> - Immaturity that's manifesting itself even in the name. You can't really ask
> someone to meaningfully review a spec when its scope is so unclear.
What about the scope is unclear? I feel that the Scope section of the
spec and th
On 10/12/2011 4:12 PM, Ryosuke Niwa wrote:
Given that Gecko is implementing the unprefixed getItems (see
https://bugzilla.mozilla.org/show_bug.cgi?id=591467), I don't see
benefits in implementing with webkit prefix. Also, it's still under a
compile-time flag so we can prefix it before enabling
On Wed, Oct 12, 2011 at 3:58 PM, Alexey Proskuryakov wrote:
> Quoting what I actually said in the bug, "I don't think that we should
> accept an implementation of a spec that's so immature that it doesn't even
> have a meaningful name."
>
That the name is not meaningful, and that this is a sign
Given that Gecko is implementing the unprefixed getItems (see
https://bugzilla.mozilla.org/show_bug.cgi?id=591467), I don't see benefits
in implementing with webkit prefix. Also, it's still under a compile-time
flag so we can prefix it before enabling the flag by default if we strongly
feel like it
12.10.2011, в 14:10, Adam Barth написал(а):
> I don't think it's worth blocking development of the feature based
> solely on the name.
Quoting what I actually said in the bug, "I don't think that we should accept
an implementation of a spec that's so immature that it doesn't even have a
meanin
Its obvious that a naming nit is a not a good reason to block development
behind a flag.
Is the the true basis for that r- expressed in this comment?
"The concern here as I understand it is that providing low level access to
every possible controller creates fragmentation, with purportedly "HTML"
I don't think it's worth blocking development of the feature based
solely on the name. I'd recommend sorting out the name issue before
enabling the feature by default though, because that's the point in
time after which changing the name will become painful. If the name
is really a sticking point
On Wed, Oct 12, 2011 at 12:56 PM, Cedric Sodhi wrote:
> Dear Adam,
>
> thank you for the the description. In line with my argument, that there
> is nothing intrinsically special with resources residing under file://
> than there is with other resources let me ask coversely - very much
> because I
Hi all,
Alexey appears to strongly dislike the name of this API specification (
http://dvcs.w3.org/hg/webevents/raw-file/default/gamepad.html), so much so
that he is blocking development of the API behind a flag.
As a reminder, this API is being developed through the WebEvents WG jointly
with oth
Dear Adam,
thank you for the the description. In line with my argument, that there
is nothing intrinsically special with resources residing under file://
than there is with other resources let me ask coversely - very much
because I understand exactly what you mean:
Why do you consider the possibi
As far as I know, every modern browser prevents non-local HTML
document (e.g., those with http or https schemes) from embedding
resources (e.g., images or iframes) from the local file system.
This restriction prevents remote parties from probing the user's local
file system for information. For e
I'm of the opinion that there is no need to distinguish between local
and non-local schemes, such as it is in the case where a non-local (say,
http) URI cannot load or embed a local (say, file) scheme.
I've heard that there must have been reasons for such a restriction to
be introduced.
I hereby
I think my issue some kind of lack of knowledge in C++. I'm trying to redesign
the the text placement engine in webkit. For my purpose I need to get access to
font face which is stored in the place I mentioned. I know that they are
private but I want to read them, and I know it is possible to do
./Tools/Scripts/update-webkit --chromium
./Tools/Scripts/build-webkit --chromium
That will build the Chromium WebKit unit tests as well.
Adam
On Wed, Oct 12, 2011 at 10:31 AM, Fady Samuel wrote:
> Hi all,
> I apologize for sending this out to such a broad audience, but I'd like to
> know how t
Hi all,
I apologize for sending this out to such a broad audience, but I'd like to
know how to compile the chromium webkit unit tests on Mac? I tried this:
xcodebuild -project
third_party/WebKit/Source/WebKit/chromium/WebKit.xcodeproj -configuration
Debug -target webkit_unit_tests
It complains a
On Oct 12, 2011, at 3:15 AM, just2 contribute wrote:
> Has anybody tried building the latest webkit-trunk for Safari on windows?
>
> I am getting some build errors while building WebCore :)
>
> Can anybody share the latest working SVN Revision Number that I can try?
http://build.webkit.or
What are you trying to do here? Clearly, all member variables are private
here so you shouldn't be accessing directly by "m_fontlist.m_ptr->m_
cachePrimarySimpleFontData->m_platformData.m_face".
I don't know much about the rendering engine but perhaps other contributors
can help you out if you giv
Hi,
Has anybody tried building the latest webkit-trunk for Safari on windows?
I am getting some build errors while building WebCore :)
*Can anybody share the latest working SVN Revision Number that I can try?
*
--
Justin
___
webkit-dev mailing lis
20 matches
Mail list logo