Re: CfC - publish Selectors API as CR
BlackBerry 9700 browser: (Kartikaya Gupta from RIM e-mailed me off list about this to tell me, I'm unable to verify these results myself without access to the device.) Baseline Tests: HTML/CSS2.1:PASS Additional Tests: HTML/CSS3: PASS Additional Tests: XHTML+SVG/CSS3: PASS Slight correction, the 9700 publicly-available build has some of the tests failing. The BlackBerry 9550 does pass all tests though. I ran the tests on the device simulator available from http://na.blackberry.com/eng/developers/resources/simulators.jsp and grabbed the following screenshots of the completed tests: http://stakface.com/pub/mango/selapi-suite1.jpg http://stakface.com/pub/mango/selapi-suite2.jpg http://stakface.com/pub/mango/selapi-suite3.jpg Note that if you plan to try this out yourself on a device or the simulator you'll need to uncheck the Terminate slow-running scripts checkbox in the browser options for it to work, since otherwise our javascript watchdog will kick in and kill the script before it's done. Cheers, kats
Re: Touch and gestures events
On Tue, 13 Oct 2009, Garrett Smith wrote: I would like to see input from Palm, RIM, Opera, and other developers of mobile browsers and touch screen devices on this thread. As a RIM developer, we do not currently support touch events in our browser; we just map them to mouse events where a mapping exists. We do not currently provide a gesture API at all. We *have* been asked a couple of times if we support touch events, so I do believe there is a non-zero demand for it. Beyond that I don't really have much to say. kats
[progress events] editorial fixes and module
On Mon, 29 Dec 2008 17:24:03 +1100, Charles McCathieNevile cha...@opera.com wrote: On Mon, 29 Dec 2008 13:33:35 +1100, Kartikaya Gupta lists.weba...@stakface.com wrote: On Mon, 29 Dec 2008 11:30:42 +1100, Charles McCathieNevile cha...@opera.com wrote: Please review and send brickbats, comments, etc. ... 3. The description for the totalArg parameter of initProgressEvent says ... the value of this parameter is not a non-negative number Why not just say ... the value of this parameter is a negative number ...? (redundant double negative removal). All agreed and fixed. I'll put out another version in a few days that includes all these changes. The loadedArg parameter has the same not a non-negative number double-negative that should probably be fixed. Also, the two operations defined in the IDL are missing the semi-colon after the argument list as required by WebIDL. I would also like to know which module the ProgressEvent interface will end up in, so I can generate Java bindings appropriately. For now I'm assuming it will go into org.w3c.dom.events since that seems to be the appropriate place IMO. And finally, is there a timeline for pushing this spec forward? It hasn't been touched for the last 5 months, and I would like to see this spec move somewhere rather than die a death of apathy like so many specs have... even a publication from editor's draft to a new WD would be better than nothing :) Cheers, kats
Re: [selectors api] test suite red values
On Sun, 19 Jul 2009 08:05:32 + (UTC), Ian Hickson i...@hixie.ch wrote: On Sat, 18 Jul 2009, Kartikaya Gupta wrote: I was wondering if the test suite for selectors-api to could be modified to include #FF (uppercase) as a valid red value in addition to (255, 0, 0), #ff, and red. This doesn't seem to be specced anywhere, and our implementation retuns uppercase for hex colors, so some of the tests are failing even though we support the functionality. In fact according to this, uppercase is the only correct serialisation: http://dev.w3.org/csswg/cssom/#css-value (We really should find someone to maintain that draft and publish it.) Hmm, I missed that, thanks. I would still like to see the test suite updated, though; this draft hasn't been touched in a really long time, and I don't think the selectors-api test suite should rely on it excessively in its current state. kats
Re: [whatwg] DOMTimeStamp binding
On Thu, 12 Feb 2009 07:03:22 +0100, Simon Pieters sim...@opera.com wrote: On Wed, 11 Feb 2009 21:14:44 +0100, Kartikaya Gupta lists.weba...@stakface.com wrote: I updated to Safari 3.2 on Windows (which looks it also has WebKit 525.27.1) and you're right, it is now showing number instead of object. I guess this was changed not too long ago. So then my question is: why was it changed? And seeing as Opera, WebKit, and Gecko are in agreement now to return a number rather than a Date in ECMAScript, will the DOM 3 Core spec be updated? Or will this get rolled into Web DOM Core and/or HTML5? Right now Web DOM Core says: A DOMTimeStamp represents a number of milliseconds. typedef unsigned long long DOMTimeStamp; ...and then refers to WebIDL for what that means to ECMAScript. It seems to me the simplest approach would be to bind DOMTimeStamp to a number for ECMAScript (the typedef should then make it unnecessary to explicitly define in WebIDL), and create a new type to represent things that actually return Date objects like the HTMLInputElement.valueAsDate in HTML5. This is likely what I'll end up doing for our IDL files anyhow so that all the bindings get generated correctly. Cheers, kats
Re: DOMTimeStamp binding
On Wed, 11 Feb 2009 10:06:14 -0800, Darin Adler da...@apple.com wrote:
However, when I do this:
var e = document.createEvent('Events');
alert( typeof e.timeStamp );
I get number in Opera and Firefox, and object in Webkit.
I get number in WebKit.
-- Darin
Interesting. What version did you try on? I used Chrome 1.0.154.48 and Safari
3.1 (525.13) on Windows.
Cheers,
kats
Re: DOMTimeStamp binding
On Wed, 11 Feb 2009 10:58:00 -0800, Darin Adler da...@apple.com wrote: On Feb 11, 2009, at 10:51 AM, Kartikaya Gupta wrote: Interesting. What version did you try on? I used Chrome 1.0.154.48 and Safari 3.1 (525.13) on Windows. The relevant version is the WebKit version rather than the Safari version. They have separate version numbers. I used WebKit/525.27.1 (the version that came with Safari 3.1.1) on Mac OS X and also WebKit tip of tree on Mac OS X. I also inspected the code and saw nothing that would create an object in the JavaScript binding for this. I updated to Safari 3.2 on Windows (which looks it also has WebKit 525.27.1) and you're right, it is now showing number instead of object. I guess this was changed not too long ago. So then my question is: why was it changed? And seeing as Opera, WebKit, and Gecko are in agreement now to return a number rather than a Date in ECMAScript, will the DOM 3 Core spec be updated? Or will this get rolled into Web DOM Core and/or HTML5? Cheers, kats
Re: Call for Consensus - Selectors API to Candidate Rec
On Thu, 05 Feb 2009 01:21:09 +0100, Charles McCathieNevile cha...@opera.com wrote: Hi folks, this is a call for consensus to move the Selectors API [1] to Candidate Recommendation, following the end of the last call. [1] http://dev.w3.org/2006/webapi/selectors-api/ One minor fix: s/and to be/to be/. Otherwise, looks good. kats
Re: CfC to publish Errata for Element Traversal Recommendation; deadline February 2
On Mon, 26 Jan 2009 10:07:08 -0500, Arthur Barstow art.bars...@nokia.com wrote: WebApps WG Members - this is a Call for Consensus (CfC) to publish the Element Traversal errata as proposed by Cameron: http://lists.w3.org/Archives/Public/public-webapps/2009JanMar/ 0168.html As with all of our CfCs, positive response is preferred and encouraged and silence will be assumed to be assent. The deadline for comments is Feb 2. -Regards, Art Barstow I just noticed that the java binding file has a link to ww.w3.org instead of www.w3.org. Cheers, kats
Re: Progress draft 1.27 - ready for last call?
On Mon, 29 Dec 2008 11:30:42 +1100, Charles McCathieNevile cha...@opera.com wrote: Please review and send brickbats, comments, etc. before I ask for a consensus to publish last call. Especially appreciated are examples and test cases :) 1. s/are not be/are not/ 2. Section 2.2, second-last bullet point has an uppercase 'O' in Operation for no apparent reason. 3. The description for the totalArg parameter of initProgressEvent says ... the value of this parameter is not a non-negative number Why not just say ... the value of this parameter is a negative number ...? (redundant double negative removal). 4. s/prooress/progress/ 5. Example 1 in section 3 seems to have been truncated. 6. There's a reference to HTML5 in example 3 but it's not hyperlinked to anything. 7. Example 3 has two worky(evt) functions defined. I think one of those was meant to be whatForYouDoThat(evt). 8. Shouldn't the child[1] in example 3 be child[0]? Cheers, kats
[DOM2 Range] bug in example to handle insertions
Found an issue in DOM2 Range that doesn't seem to be addressed anywhere that I could find: Section 2.12.1 (handling insertions) says that the boundary point offset should only be adjusted if the insertion point's offset is strictly less than it. However, the first example they give doesn't do this. In the example the start boundary point and insertion point both have an offset of 10 and they adjust the offset anyway, so that inserted text stays out of the range. Opera and Firefox both do what the text says and so inserted text ends up in the range (Webkit doesn't seem to handle this very well, it doesn't update anything so the range ends up selecting inserted ). I agree with Opera/FF's behavior, so I think the example should be corrected to include the inserted text. Cheers, kats
Re: [XHR] Error flag
On Wed, 10 Dec 2008 16:28:25 +0100, Anne van Kesteren [EMAIL PROTECTED] wrote: Actually, clearing it when you invoke send() should be enough. Made that change to the editor drafts. I see the change in the XHR2 draft, but not the XHR draft. Also, will the IDL be updated to reflect exceptions thrown from the various methods and property accessors? This may already be on the to-do list, but I thought I'd mention it in case it wasn't. I was not planning on doing this. It makes the IDL unreadable in my opinion and I believe it is not required in Web IDL (and if it is we should change that :-)). It does hamper readability somewhat, but it also increases usefulness. I guess the question is whether the IDL is informative or normative. If it's normative, then I think the exceptions should be added for correctness. The [Null] and [Undefined] extended attributes are much worse for readability, IMO. And on the topic of IDL, I assume you're sticking with your plan of not specifying a module/namespace? Cheers, kats
[XHR] Error flag
The editor's draft of the XHR spec doesn't say when to clear the error flag. Based on experimentation I'm guessing it's supposed to be cleared in step 21 of the open() algorithm. Is this correct? Also, will the IDL be updated to reflect exceptions thrown from the various methods and property accessors? This may already be on the to-do list, but I thought I'd mention it in case it wasn't. Cheers, kats
[XHR] IDL namespace (was: [Selectors-API] IDL namespace)
On Mon, 24 Nov 2008 14:51:53 +, Kartikaya Gupta [EMAIL PROTECTED] wrote: On Mon, 24 Nov 2008 15:10:03 +0100, Lachlan Hunt [EMAIL PROTECTED] wrote: Kartikaya Gupta wrote: Also, I noticed that the draft still points to public-webapps as the discussion list. Should that be updated to public-webapi? No, you've got that backwards. public-webapi is the old list. This list is public-webapps. :-) Oh, so it is. I must have been asleep or something... Apologies. Aha! It was the XHR draft that I was looking at that has the pointer to public-webapi instead of public-webapps. Also, I have the same question for XHR that I had for Selectors-API: what module/java-package will it be in? Cheers, kats
Re: [XHR] IDL namespace
On Tue, 02 Dec 2008 15:41:23 +0100, Anne van Kesteren [EMAIL PROTECTED] wrote: Also, I have the same question for XHR that I had for Selectors-API: what module/java-package will it be in? I'd hope non-ECMAScript languages have a better API for dealing with HTTP :-) In other words, does it really matter? For some of the stuff we're working on, yes it does. Even though there are other APIs for making HTTP connections, XHR offers some useful abstractions that developers are comfortable with and know how to use. It makes switching between platform-based programming in Java and web-based programming in Javascript much easier. That being said, if you don't want to specify a module in the spec, then I don't really care much; we can make up our own namespace and put it in there. I just didn't want there to be interop concerns later if other vendors put it in a different namespace. Cheers, kats
Re: [WebIDL] Java package mapping
On Mon, 1 Dec 2008 11:12:13 +1100, Cameron McCormack [EMAIL PROTECTED] wrote: Done: http://dev.w3.org/2006/webapi/WebIDL/#idl-modules http://dev.w3.org/2006/webapi/WebIDL/#Prefix http://dev.w3.org/2006/webapi/WebIDL/#java-modules The example in the java-modules section has a typo; it says org.foo.ext.FooDocument instead of org.foo.ext.ExtendedFooDocument. Also, I'm not sure if this matters, but while implementing I realized that having both [TheExtendedAttribute=identifier] and [TheExtendedAttribute=ScopedName] leads to an ambiguous grammar, since [foo=bar] can be interpreted as both. Presumably this would lead to shift-reduce conflicts with a context-free parser generator. For my implementation I always resolve it to be a ScopedName and then use either the prefixed name or the unprefixed name depending on which attribute it is. Cheers, kats
Re: [WebIDL] Java package mapping (was: Re: [Selectors-API] IDL namespace)
On Fri, 28 Nov 2008 21:42:08 +1100, Cameron McCormack [EMAIL PROTECTED] wrote:
Alternatively: is it worth hard coding a Java package prefix into the
spec, so that [JavaPackage] is not normally needed? (This could map a
module called âdomâ to org.w3c.dom, and other modules at the top
level to org.w3c.dom.foo (for module events, module svg, etc.), unless
overridden.) And would this make Web IDL too specific for use by W3C
specifications, and if it does, is that really a problem?
I would prefer not hard-coding a package prefix. The implementation I just
finished writing basically auto-generates a bunch of stuff from the DOM IDL
files. Since it worked pretty well, we decided to create IDL files for some
other proprietary interfaces so that we could auto-generate stuff for those
interfaces too in a consistent manner. Those interfaces aren't in the org.w3c
namespace, and hard-coding that prefix would make things more complicated. (My
current implementation uses the [Prefix=...] xattr from an earlier draft,
which I'm fine with changing to Package or JavaPackage or whatever, as long as
it allows specifying things outside of org.w3c as well).
On a somewhat related note, I realized that the [ImplementedOn] xattr takes an
identifier rather than a fully-qualified name, which means that it can't
properly be used for interfaces in another module. I thought that a typedef
might be able to solve the problem but it doesn't in all cases:
module modA {
interface intA {
};
};
module modB {
// typedef modA::intA intA; // this would work, if not for the intA below
interface intA {
};
[ImplementedOn=intA] // this resolves to modB::intA. what if i want
modA::intA?
interface intB {
};
};
I noticed you added a new [TheExtendedAttribute=packagename] production; I just
thought it might be prudent to generalize that a bit more so that it can be
used for [ImplementedOn] to specify a scoped name, or something to disambiguate
the scenario above. The scenario itself is pretty unlikely, but if you're
adding to the grammar anyway, then it shouldn't be too much effort to deal with
this too.
Cheers,
kats
[WebIDL] questions
A couple of questions I have after quickly looking over the WebIDL spec: 1. Although no mention is made of case-sensitivity in the spec, I assume that all the tokens are case sensitive. Is this correct? By tokens I'm including the names/values of the extended attributes (e.g. PutFowards, Empty) and things like getraises and setraises. 2. There is a sentence in section 3.8.8 that says The [PutForwards] extended attribute MUST take an identifier that is the identifier of an attribute that exists on the interface and which has the same type as this attribute. This sentence is pretty confusing and I'm not sure what which refers to in this sentence. It seems to imply the attribute being forwarded to should have the same type as the attribute with the PutForwards extended attribute, but the example below doesn't do that. Cheers, kats
Re: [D3E] Possible Changes to Mutation Events
On Thu, 17 Jul 2008 17:51:42 -0700, Jonas Sicking [EMAIL PROTECTED] wrote: As for when the events fire (note that this is just clarifications of the spec, not changes to it): For events that fire after the mutation takes place I propose that we add a concept of a compound operation and state that while compound operations are in progress no mutation events are fired. I was thinking about this some more, and it seems to me that a compound operation is more or less a lightweight transaction (transaction in the sense that is referred to in 1.6.4 of L2 events). It might be useful to expose this functionality to authors as well. If a couple of methods were added to allow authors to indicate the start and end of a compound operation/transaction, and it were guaranteed that no mutation events would be dispatched until the end of the compound operation, they would have to worry less about dealing with interference from other mutation listeners while they're doing a high-level compound operation. It would be pretty trivial to implement on top of internal compound events, and would solve the problem of revalidating assumptions for authors as well as implementors. The only pitfall I can see is if authors started a compound operation and never ended it, causing an unbounded queue of events. We'd have to allow implementations to drop the queue (or some events) if it got too large. Thoughts? kats
Re: [D3E] Possible Changes to Mutation Events
On Tue, 15 Jul 2008 12:39:16 +0200, Sergey Ilinsky [EMAIL PROTECTED] wrote: Specific concerns: 1) If DOMNodeRemovedFromDocument is fired after the mutation, then in the listener for this event there is no way to know where Node was removed from. (This does not apply to DOMNodeRemoved, since it has a relatedNode property pointing to node removed) 2) If DOMNodeRemoved is fired after the mutation, event won't be capable of bubbling +1. If you make these events fire after the mutation, then they won't go anywhere since the target of the event (the removed node) is free-standing. In order to listen for these events, you'd have to register a listener on every single DOM node, which seems pretty silly. Even if you changed one or both of the events to fire on the parent node, it would still be impossible to determine exactly where the removed node was removed from (i.e. what was the removed node's .nextSibling before it was removed?) The same problem applies to batching up mutations and firing them at the end; there might be operations whose mutation events get discarded because some other mutation happens to the tree before the event is fired. kats
Re: [D3E] Possible Changes to Mutation Events
On Tue, 15 Jul 2008 11:20:17 -0400, Boris Zbarsky [EMAIL PROTECTED] wrote: Kartikaya Gupta wrote: The same problem applies to batching up mutations and firing them at the end; there might be operations whose mutation events get discarded because some other mutation happens to the tree before the event is fired. I'm not sure I follow this. What exactly is the problem here? Sorry, I misread the original thread and misunderstood the scope of the change. Never mind.
