On Nov 10, 2010, at 3:40 PM, Ojan Vafai wrote:
> Heh. There's clearly still a good deal of confusion about what the intended
> behavior here is. Well, I'm confused anyways. :)
>
> On Fri, Nov 5, 2010 at 9:32 PM, James Craig wrote:
>> Ojan Vafai wrote:
>>> How is [ DOMAttributeChangeRequestEvent
On Nov 10, 2010, at 2:33 PM, Daebarkee Jung wrote:
> I found that the following lines made errors:
> // OwnPtrCommon.h
> template inline void deleteOwnedPtr(T* ptr)
> {
> typedef char known[sizeof(T) ? 1 : -1];
> if (sizeof(known))
> delete ptr;
> }
>
> I am very curiou
Heh. There's clearly still a good deal of confusion about what the intended
behavior here is. Well, I'm confused anyways. :)
On Fri, Nov 5, 2010 at 9:32 PM, James Craig wrote:
> Ojan Vafai wrote:
>
> How is [ DOMAttributeChangeRequestEvent ] any different than
> DOMAttrModified? The spec claims
Hi,
I found that the following lines made errors:
// OwnPtrCommon.h
template inline void deleteOwnedPtr(T* ptr)
{
typedef char known[sizeof(T) ? 1 : -1];
if (sizeof(known))
delete ptr;
}
I am very curious about why the author wrote like the above.
What could be the author's i
Generally I just open in another browser. Doesn't seem worth the
effort, but I don't think anyone is going to stop you. :)
On Wed, Nov 10, 2010 at 1:48 PM, Ryosuke Niwa wrote:
> Hi,
> Can we modify the bugzilla so that we can edit the details of attachments
> without opening the attachments on t
Hi,
Can we modify the bugzilla so that we can edit the details of attachments
without opening the attachments on the right pane? When the attachment is
crash reproduction, I can't edit the details on WebKit / Chromium because it
crashes my browser as soon as I open the details.
Best,
Ryosuke Niw
I frequently copy & paste function names, variable names, etc... into my
comment so I like the new behavior.
- Ryosuke
On Wed, Nov 10, 2010 at 10:18 AM, Adam Barth wrote:
> Yeah, Darin and Alexey asked for this change. I thought about
> emailing webkit-dev, but I was worried that would have be
Yeah, Darin and Alexey asked for this change. I thought about
emailing webkit-dev, but I was worried that would have been too spamy.
Hopefully the new behavior works for everyone.
Adam
On Wed, Nov 10, 2010 at 6:36 AM, David Levin wrote:
> (Single) Click on the line numbers to leave comments.
Sorry for a delayed response - I hoped for someone else to weigh in.
This approach is certainly better than having code in shipping WebCore. But I
still think that testing via platform APIs is much more desirable than
implementing and maintaining a separate "pseudo-API" for mocks. This can't be
10.11.2010, в 01:59, Alex Milowski написал(а):
>> Moving or copying essential information about a document into HTTP headers
>> is frustrating for charset declarations, why do that for anything else? With
>> charsets, there is at least the explanation that many text formats don't
>> have a pla
On Wed, Nov 10, 2010 at 2:12 PM, Alex Milowski wrote:
>
> * If it is an external library, like XSLT 1.0 support is today, what
> are the integration criteria (e.g. platform library vs. statically
> linked, etc.)?
>
One more datum, that I just discovered, Apple has implemented XPath
2.0, XSLT 2.0,
On 11/09/2010 09:00 PM, Eric Seidel wrote:
> This conversation is heading in a dangerous direction... :)
>
> Allowing QXML parser support to be added to WebKit was probably a
> mistake. Adding custom QXPath or QXSLT support would be another.
I agree with the first statement but disagree with the
On Wed, Nov 10, 2010 at 11:25 AM, Maciej Stachowiak wrote:
>
>
> Do most existing XSLT 1.0 stylesheets have an explicit 1.0 label? Does XSLT
> require this? How would unlabeled stylesheets be processed?
You are required to have a version attribute and it is a static error
if it does not. As a r
Even for prefetching this seem rather worthless as it won't allow
prefetching start significantly earlier over the resources specified
in the document source.
There is also (based on the experience in similar things) a high
chance that whatever is listed in the Link header won't match what the
doc
The first thing we should figure out is whether XSLT 2.0 is something we even
want to implement. If it's not backwards compatible with XSLT 1.0 and other
browsers are not planning on implementing it, then it's a significant risk to
move to XSLT 2.0. We'd likely break backwards compatibility wit
On Nov 10, 2010, at 2:54 AM, Alex Milowski wrote:
> On Wed, Nov 10, 2010 at 10:29 AM, Maciej Stachowiak wrote:
>>
>> The first thing we should figure out is whether XSLT 2.0 is something we
>> even want to implement. If it's not backwards compatible with XSLT 1.0 and
>> other browsers are not
On Wed, Nov 10, 2010 at 10:29 AM, Maciej Stachowiak wrote:
>
> The first thing we should figure out is whether XSLT 2.0 is something we even
> want to implement. If it's not backwards compatible with XSLT 1.0 and other
> browsers are not planning on implementing it, then it's a significant risk
On Tue, Nov 9, 2010 at 8:00 PM, Eric Seidel wrote:
> This conversation is heading in a dangerous direction... :)
>
> Allowing QXML parser support to be added to WebKit was probably a
> mistake. Adding custom QXPath or QXSLT support would be another.
>
> WebKit is one platform. If XSLT or XPath 2
On Tue, Nov 9, 2010 at 6:01 PM, Alexey Proskuryakov wrote:
>
> Moving or copying essential information about a document into HTTP headers is
> frustrating for charset declarations, why do that for anything else? With
> charsets, there is at least the explanation that many text formats don't have
19 matches
Mail list logo