On Sat, 27 Jan 2007 02:31:11 -0500, Ian Hickson [EMAIL PROTECTED] wrote:
On Fri, 26 Jan 2007, Boris Zbarsky wrote:
So I would hope that the spec says that not only is this implementation
defined but may differ depending on the actual network connection in
use
I haven't actually looked
Hi Ellen,
On Tue, 23 Jan 2007 12:03:59 -0500, Ellen Siegel [EMAIL PROTECTED]
wrote:
1) MouseWheelEvent
There was a WheelEvent in the SVG spec that the SVG WG has requested be
added to DOM 3. The current status is that a substantially similar
MouseWheelEvent has been added to the current
ISSUE-106: Should Progress be required to fire?
http://www.w3.org/2005/06/tracker/webapi/issues/106
Raised by: Charles Mccathienevile
On product: Progress Event
Well, raised by Ian really in his message http://www.w3.org/mid/
[EMAIL PROTECTED]
The issue is whether the progress event MUST
ISSUE-107: Is there a required frequency for progress events?
http://www.w3.org/2005/06/tracker/webapi/issues/107
Raised by: Charles Mccathienevile
On product: Progress Event
See http://lists.w3.org/Archives/Public/public-webapi/2007Jan/
thread.html#msg98 - how often should the events fire,
Hi folks,
I have made a new editor's draft available, and in order to get wider
comment I
would like to move it to a W3C Public Working Draft.
If people are happy to do this, please say so on the maikling list, or
there wil
be a teleconference next Monday, 5th February, and on the agenda
Hi SVG,
in order to satisfy ACTION-196 (from WebAPI - hey tracker, learn some
namespace
mechanism would you?), which was assigned to the runaway Berjon, I am
telling
you not to specify a timing interface.
This is because we are allegedly going to get around to it, if I recall
correctly.
On Sat, 27 Jan 2007, Ian Hickson wrote:
I haven't actually looked at the spec, but, I would recommend something
along the lines of:
Apparently I should have given rationales, so:
MUST fire at zero bytes
...so that progress bars can be initialized with the right length, or
On 1/27/07, Ian Hickson [EMAIL PROTECTED] wrote:
It's important, in terms of API design, to make the main use cases
trivial. I believe the above design would do that.
Adding to that, I see there is an issue open on whether timings should
be standardized to some degree. I believe they
On 1/27/07, Jim Ley [EMAIL PROTECTED] wrote:
The arbritrariness of the value is why I do not feel it should be in the
spec, but left to vendors.
I'd be interested to hear from browser vendors that want to change or
delete the values in Hixie's proposal.
--
Robert Sayre
On 1/27/07, Anne van Kesteren [EMAIL PROTECTED] wrote:
On Thu, 25 Jan 2007 15:04:52 -0500, David Håsäther [EMAIL PROTECTED]
wrote:
Yes, but grabbing the first node has its own method. Grabbing the second
or last does not. What I don't understand is _why_ there is a special
method for
* Robert Sayre wrote:
On 1/27/07, Jim Ley [EMAIL PROTECTED] wrote:
The arbritrariness of the value is why I do not feel it should be in the
spec, but left to vendors.
I'd be interested to hear from browser vendors that want to change or
delete the values in Hixie's proposal.
I'd be
On Sat, 27 Jan 2007 13:30:58 -0500, Bjoern Hoehrmann [EMAIL PROTECTED]
wrote:
This is out of scope of the document. The method would return all
elements that match the selector. When an element matches a selector
is defined by the CSS Selectors specification. If that specification
is unclear
On Sat, 27 Jan 2007 18:03:35 -0500, Martijn [EMAIL PROTECTED]
wrote:
I don't see any difference:.
document.getElementBySelector(html p)
is the same as document.getElementListBySelector(html p)[0]
document.getElementBySelector(html p:not(:first-child))
is the same as
On 1/27/07, Anne van Kesteren [EMAIL PROTECTED] wrote:
Yes, they are prolly slightly different (although I haven't actually seen
any documentation on how getElementById exactly works).
MSDN says it returns the first object.
On 1/28/07, Anne van Kesteren [EMAIL PROTECTED] wrote:
On Sat, 27 Jan 2007 18:03:35 -0500, Martijn [EMAIL PROTECTED]
wrote:
I don't see any difference:.
document.getElementBySelector(html p)
is the same as document.getElementListBySelector(html p)[0]
document.getElementBySelector(html
* Anne van Kesteren wrote:
On Thu, 25 Jan 2007 15:04:52 -0500, David Håsäther [EMAIL PROTECTED]
wrote:
Yes, but grabbing the first node has its own method. Grabbing the second
or last does not. What I don't understand is _why_ there is a special
method for grabbing the first node? I just
On Sat, 27 Jan 2007 18:17:37 -0500, Martijn [EMAIL PROTECTED]
wrote:
Given that the latter returns a StaticNodeList you can't do fancy stuff
such as lazy evaluation. So they become different in terms of speed.
Well, typically the first thing I do is using a variable, like:
var
* Anne van Kesteren wrote:
Yes, they are prolly slightly different (although I haven't actually seen
any documentation on how getElementById exactly works). Do you have any
proposed text? Or should we wait until it's clear how getElementById
really works?
Well, something like:
Note:
On Jan 27, 2007, at 2:57 PM, Jim Ley wrote:
Anne van Kesteren [EMAIL PROTECTED]
On Sat, 27 Jan 2007 12:59:00 -0500, Charles McCathieNevile
[EMAIL PROTECTED] wrote:
This is because we are allegedly going to get around to it, if I
recall
correctly. If you're keen, I would suggest you
On Jan 27, 2007, at 7:25 AM, Charles McCathieNevile wrote:
On Fri, 26 Jan 2007 22:06:04 -0500, Maciej Stachowiak
[EMAIL PROTECTED] wrote:
Congratulations, design by committee has once again failed to
meetanyone's requirements (in other words, I object to these names).
Thanks. Your
On Sat, 27 Jan 2007 12:59:00 -0500, Charles McCathieNevile
[EMAIL PROTECTED]
wrote:
... I am telling you not to specify a timing interface.
This is because we are allegedly going to get around to it, if I recall
correctly. If you're keen, I would suggest you further track exactly
where
Björn,
thanks for the comments. Some of the simple stuff I did already, and is now
reflected in another draft
http://dev.w3.org/cvsweb/~checkout~/2006/webapi/progress/Progress.html?rev=1.4
but some I decided not to spend my Saturday night working on, and there
are a
couple of questions
* Charles McCathieNevile wrote:
So I agree, adjusted the example to look for the error case, but didn't do
the rest yet.
Note that in if !(evt.total == 0) the condition must be in braces, so
e.g. if (!(evt.total == 0)).
* there is also no need to use scripting to change the xlink:href
On Sat, 27 Jan 2007 18:49:28 -0500, Maciej Stachowiak [EMAIL PROTECTED]
wrote:
On Jan 27, 2007, at 7:25 AM, Charles McCathieNevile wrote:
On Fri, 26 Jan 2007 22:06:04 -0500, Maciej Stachowiak [EMAIL PROTECTED]
Congratulations, design by committee has once again failed to
meetanyone's
On Jan 27, 2007, at 5:36 PM, Charles McCathieNevile wrote:
You have seen the minutes draft already (assuming everyone is happy
with that it
will be available to the public in a week), and probably the raw
IRC log. To
that I can only add that various working group members objected
[Please follow up only to webapi...]
On Sat, 27 Jan 2007 19:14:24 -0500, Maciej Stachowiak [EMAIL PROTECTED]
wrote:
On Jan 26, 2007, at 1:54 PM, Charles McCathieNevile wrote:
Hi,
following our face to face meeting, we are planning some changes to
progress:
Based on my experience
These are horrid. There are some outstanding action items - ACTION-174 and
ACTION-175, and although it has been closed you could see the thread
associated
with http://www.w3.org/2005/06/tracker/webapi/actions/25 (where there was
some
actual stuff done).
Now they are Doug's, with ACTION-227
On Sat, 27 Jan 2007, Jim Ley wrote:
Ian Hickson [EMAIL PROTECTED]
MUST fire again at the end, even if that is zero bytes
...so that progress bars can be easily guarenteed to reach the 100%
mark, which is important for usability.
Using onload is sensible for that, there is no
Jim Ley wrote:
up to 54ms is used by other browser vendors in similar situations
I'd be interested in further information on this. We (Mozilla) found
that using anything bigger than 10ms (due to a problem in the timer impl
we were doing 16ms for a while) led to a lot of angst on the part
Robert Sayre wrote:
MSDN says it returns the first object.
http://msdn.microsoft.com/workshop/author/dhtml/reference/methods/getelementbyid.asp
For what it's worth, that's not what Gecko does, and I personally would
rather not try to enforce that -- it's somewhat expensive to do so in
the
Bjoern Hoehrmann wrote:
Note: .foo(#id) is not equivalent to document.getElementById('id')
if multiple elements have the same ID. This method returns the first
element in document order with the given ID, while getElementById's
behavior is undefined in this case.
I would like to put
Thanks. I, for one, welcome my new legacy keyboard overlords.
-Doug
Charles McCathieNevile wrote:
These are horrid. There are some outstanding action items - ACTION-174 and
ACTION-175, and although it has been closed you could see the thread
associated
with
Boris Zbarsky [EMAIL PROTECTED]
Jim Ley wrote:
up to 54ms is used by other browser vendors in similar situations
I'd be interested in further information on this. We (Mozilla) found that
using anything bigger than 10ms (due to a problem in the timer impl we
were doing 16ms for a while)
On Sun, 28 Jan 2007, Jim Ley wrote:
Could you elaborate on this backwards compatibility problem?
Sure, if authors go
.post() - update UI to indicate something's started happening
event.onprogress - indicate progress
event.onprogress (complete) - update UI to indicate things have
34 matches
Mail list logo
