Hi webkit-dev,
Is there any method to obtain the position (or IntRect) of each option
element in the select element?
So far I can get the offsetLeft & offsetTop via methods of Element class
but this seems to be the screen offset of the select element. Thanks.
Regards,
yang
__
Hi webkit-dev,
In late January 2013, Cameron McCormack (of Mozilla) and I are running a
Browser Miniconf at linux.conf.au, in Canberra, Australia.
Cameron and I proposed the event to provide an opportunity for browser
hackers to get together as a community, regardless of the particular
browser th
This requires weird contortions in the DOM and Render tree and removes
nice guarantees.
For example Node.h has:
TreeScope* treeScope() const;
Document* document() const;
Node* childNode(unsigned index) const;
Returning a const Document* or Node* from childNode makes the DOM
API's suddenly less u
I believe the WebKit project's position, historically, on this topic
is that embedders should supply their own implementation of this API
rather than having the implementation in WebKit proper. The
"external" interface is used in a number of user agents to supply
"external" interfaces that are mor
Hello webkit-dev,
I'm a software developer working for the RIM browser team.
The team would like to add support for the "external" interface. The interface
is defined in http://developers.whatwg.org/timers.html#the-external-interface
We will be submitting a final patch for review soon. Please f
On Thu, Oct 25, 2012 at 3:48 AM, Andreas Kling wrote:
> So, I propose that we allow only these two signature formats for raw
> pointers:
>
> - const Foo* foo() const;
> - Foo* foo();
>
This was part of a discussion I had on this list (IIRC) a while back. The
context was the larger issue of cons
On 10/24/2012 10:52 PM, Darin Adler wrote:
Seems like this must be a difference between clang versions; I suggest updating
to a newer version of Xcode.
If we need to support the older clang, then the fix of reordering the methods
seems OK. There are other fixes we could consider too.
-- Darin
On Thu, Oct 25, 2012 at 10:12 AM, Robert Flack wrote:
> FWIW, I don't plan to have it enabled by default on any platforms until
> we're sure what we want. The discussion with Anne about reusing timestamp
> was before she found out that timestamp calls for a 1970 based time by spec
> (http://lists
I don't understand. The www-dom discussion ends with a clear consensus to
use a new property name. There were no objections to systemTime. The
public-web-perf discussion didn't have an objections and just wanted to
wait until the V2 spec:
http://lists.w3.org/Archives/Public/public-web-perf/2012Oct/
FWIW, I don't plan to have it enabled by default on any platforms until
we're sure what we want. The discussion with Anne about reusing timestamp
was before she found out that timestamp calls for a 1970 based time by spec
(http://lists.w3.org/Archives/Public/www-dom/2012OctDec/0022.html). I think
w
As Elliott pointed out, this property doesn't seem to be on any working
draft or editor's draft yet. And it doesn't seem like either thread on
www-dom or www-perf reached a consensus.
I'd appreciate if you waited until either thread reached a rough consensus
about the feature. Namely, www-dom thre
On Thu, Oct 25, 2012 at 5:04 AM, Stephen Chenney wrote:
> I second the principle. I ran into this kind of code pattern recently in
> fonts and was unnerved by the thought of a mutable pointer emerging from a
> const method.
>
> I am not at all certain that we can simply make the change without som
On Thu, Oct 25, 2012 at 1:48 PM, Andreas Kling wrote:
>
> So, I propose that we allow only these two signature formats for raw
> pointers:
>
> - const Foo* foo() const;
> - Foo* foo();
>
I think this would be an excellent rule to adopt for new code. The
mutable/immutable state pattern is a power
Sorry, forgot to mentiont that the bug for this is:
https://bugs.webkit.org/show_bug.cgi?id=100356
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev
Hi,
in http://webkit.org/b/74802 Adam asked me to conditionalize the XHR
timeout support since not all network backends have support for
setTimeoutInterval. In such a case, default enabling the timeout and
ontimeout properties on XHR would confuse feature detection.
I consider this a tempora
I second the principle. I ran into this kind of code pattern recently in
fonts and was unnerved by the thought of a mutable pointer emerging from a
const method.
I am not at all certain that we can simply make the change without some
heavy refactoring. On the one hand, there are some long const-ne
Yo WebKittens!
After some mild morning discussion in #webkit, I'm wondering if we should
amend our style guide to disallow returning mutable pointers (Foo*) from
const methods, like so:
- Foo* foo() const;
While this is useful when you want to be able to take a strong reference to
the returned o
17 matches
Mail list logo
