Re: [XHR] Redirects

On 9/15/10 12:13 AM, Julian Reschke wrote: On 14.09.2010 18:52, Darin Fisher wrote: ... That's a good point. Note, resolving the Location header is only one of the issues. Another is knowing what HTTP method to use in response to a redirect. ... Always the same as for the original request, exc

Re: Possible addition to file API

On 8/21/10 3:39 PM, J David Eisenberg wrote: Is it possible to extend the spec to allow a script to read any file that can been loaded as part of the HTML page, such as an? That would be a security hole, sorry. I understand there are good security reasons for restricting file reads; you don't

Re: XBL2

On 9/3/10 1:48 PM, Anne van Kesteren wrote: On Fri, 03 Sep 2010 19:45:00 +0200, Boris Zbarsky wrote: The relevant stylesheets are applied to all documents, because XUL can be used in any XML document, obviously. As a simple example, the binding used for xul:iframe shouldn't be use

Re: XBL2

On 9/3/10 1:37 PM, Anne van Kesteren wrote: On Fri, 03 Sep 2010 19:24:03 +0200, Jonas Sicking wrote: For what it's worth, it's a requirement for us to be able to use namespaces of some sorts since we're planning on implementing XUL using XBL2. There are however multiple ways we can do this and

Re: HTTP access control confusion

On 7/29/10 11:10 AM, Douglas Beck wrote: The basis of our confusion: I create domain-a.com and I want to make an ajax request to domain-b.com. A preflight request is made to domain-b, domain-b responds with if it is safe to send the request. Does it not make more sense for me (the author of doma

Re: Custom DOM events and privileged browser add-ons; Was: Bubbling/Capturing for XHR + other non-DOM objects

On 6/29/10 2:36 PM, Chris Wilson wrote: See, this is exactly why we asked the question - because it seems that behavior is inconsistent, we're not sure what the expectation is. Note that the Firefox behavior I described is irrelevant to specification efforts, because it's not visible to web p

Re: Custom DOM events and privileged browser add-ons; Was: Bubbling/Capturing for XHR + other non-DOM objects

On 6/25/10 5:56 AM, Brett Zamir wrote: I guess in Firefox the document is all part of one big tree that includes the add-on markup, so propagation is indeed within the same DOM tree It's not, actually. In Firefox, an event will bubble from a Window to some object in the browser UI associated

Re: Chromium's support for CORS and UMP

On 5/11/10 1:10 AM, Nathan wrote: it's almost inevitable that somebody will make another OS browser that doesn't respect site origin policies and CORS And sites will then blacklist it, while users using it will get exploited. So it won't gain significant market share, and the problem will re

Re: Chromium's support for CORS and UMP

On 5/11/10 12:27 AM, Nathan wrote: This leaves us in a scenario where it is the norm to download, install and trust an application that runs in the browser Perhaps. The difference is that it's much harder to do a drive-by app install. agree~ish, imho it's more the user giving the Site A po

Re: Chromium's support for CORS and UMP

On 5/10/10 11:14 PM, Nathan wrote: 2: Implement a user UI confirmation screen to allow JS applications xhr access to other origin resources. (Similar to the allow desktop notifications scenario in chromium) Under what conditions would the typical user be able to make an informed decision here?

Re: Chromium's support for CORS and UMP

On 5/10/10 10:21 PM, Nathan wrote: 2: Implement a user UI confirmation screen to allow JS applications xhr access to other origin resources. (Similar to the allow desktop notifications scenario in chromium) Under what conditions would the typical user be able to make an informed decision here?

Re: Status of Selectors API Level 1 Candidate

On 5/6/10 10:44 AM, Stewart Brodie wrote: Taking the null, explicit undefined and implicit undefined test cases together, I don't think I've got any two browsers here that behave the same way. :-/ Yes, that's why we can't exit CR. ;) Note that part of the issue here is that the spec flip-flop

Re: StorageEvent.url (WAS: XMLHttpRequest.responseBlob)

On 4/29/10 12:13 PM, Jeremy Orlow wrote: The following script does not work for me in 3.6. Would love to know what I'm doing wrong: window.onstorage = function() { alert("HI"); } localStorage.foo = localStorage.foo + " "; In Gecko storage events for a change in window X are fired at all wind

Re: StorageEvent.url (WAS: XMLHttpRequest.responseBlob)

On 4/29/10 9:23 AM, Jeremy Orlow wrote: Opera 10.50 does return false for your bit of javascript, but when I enumerate the properties on event after causing a storage event, "url" is there. Weird. All that means is that the property is an own property of the object, not a property getter/sett

Re: Allow to return same NodeList object for queries like getElementsByTagName, getElementsByClassName and getElementsByName

On 2/13/10 6:18 AM, Ian Hickson wrote: I'm concerned about the GC-sensitivity of such behaviour (we might end up snookering ourselves in a situation where specific GC behaviour actually matters for compatibility). We haven't gotten there yet, in 8 years of two different implementations having t

Re: Allow to return same NodeList object for queries like getElementsByTagName, getElementsByClassName and getElementsByName

On 2/12/10 10:09 AM, Anne van Kesteren wrote: It would be interesting to know what exactly that test is. Optimizing for benchmarks is not always useful :-) Point 1: Optimizing for benchmarks is sadly all that people report on. They don't even bother making up new benchmarks, so you can optimiz

Re: Allow to return same NodeList object for queries like getElementsByTagName, getElementsByClassName and getElementsByName

On 2/12/10 8:05 AM, Anne van Kesteren wrote: Is it really a lot of performance? Our developers are not that convinced. It depends on your use case. If you're actually using getElementsByTagName on a largish DOM, then the performance effect of not having to walk that DOM multiple times is in

Re: [widgets] Applying Stylesheets to Resources

On 2/11/10 12:18 PM, Doug Schepers wrote: Ah, interesting... I didn't know that, thanks! Is this [1] the most recent reference on that? I believe so, yes. Still, I think adding a way to do this in the Widgets manifest would be a nice authoring solution. Sure; just have to make sure to defin

Re: [widgets] Applying Stylesheets to Resources

On 2/11/10 11:57 AM, Doug Schepers wrote: One odd part of the separation of content and presentation is that a stylesheet is applied to a file by including a link to the stylesheet in the target file. That is totally backward. Strictly speaking, this is just because most people don't have contr

Re: XHR LC comment: header encoding

On 1/31/10 7:38 AM, Anne van Kesteren wrote: Specifically search for "inflate" and "deflate" throughout the drafts: > To deflate a DOMString into an byte sequence means to remove from > each code point in the DOMString the higher-order byte and let the > resulting byte (all the lower-order byte

Re: Steps to creating a browser standard for the moz-icon:// scheme

On 1/27/10 9:32 PM, Jonas Sicking wrote: Indeed. I think we should make these urls never be considered same-origin as any other origin. Thus a canvas would always get its taint bit set if an icon is drawn. Note that this is effectively the case in Gecko (since -moz-icon URIs have no host, so n

Re: [selectors-api] comments on Selectors API Level 2

On 1/21/10 1:01 PM, Bert Bos wrote: e.querySelector("*") == e Nope. querySelector on an element can only return descendants of the element. In fact, e.querySelector("*") will return the element's first element child, if any. That's surprising... What is the reason to not apply the sel

Re: [selectors-api] comments on Selectors API Level 2

On 1/21/10 11:11 AM, Bert Bos wrote: Here are some examples of relations that always hold. (Assume e is an element != NULL.) e.querySelector("*") == e.querySelector(":root") Not unless we've recently redefined :root. Can you point me to the place where that happened? e.querySele

Re: Publishing Selectors API Level 2 as an FPWD?

On 1/11/10 12:13 PM, Boris Zbarsky wrote: I do wonder how useful queryScopedSelector is, since it can be implemented easily via querySelector... I guess the main value is in fact in situations when one is given a selector string already and not in situations where one is writing one's

Re: Publishing Selectors API Level 2 as an FPWD?

On 1/11/10 8:25 AM, Sean Hogan wrote: If we could assume that commas only ever delimit selectors in a selector-string, This is true for now, but may stop being true in the future. Hence no value is added by queryScopedSelector*(). At least from jquery's point of view, ok. Note that jquery

Re: Publishing Selectors API Level 2 as an FPWD?

On 1/11/10 4:55 AM, Lachlan Hunt wrote: When there's no reference nodes passed and no :scope selector used, the behaviour of querySelector and querySelectorAll is unchanged from v1. If there is a :scope selector used, then it matches the context node. If there are also additional reference nodes

Re: Publishing Selectors API Level 2 as an FPWD?

On 1/11/10 1:24 AM, Sean Hogan wrote: That's correct. jQuery's $(element).find("div") is the equivalent of SelectorsAPI2's element.querySelectorAll(":scope div") or So in fact jquery can simply implement Element.find in terms of querySelectorAll by just prepending ":scope " to the selector str

Re: Publishing Selectors API Level 2 as an FPWD?

On 1/10/10 11:58 PM, Sean Hogan wrote: Even if jQuery deprecates non-standard selectors, the current spec for queryScopedSelector*() doesn't support the jQuery implicitly "scoped" selector "> *". As I understand it, jquery selectors on elements are always scoped in the sense that they behave d

Re: XHR LC comment: header encoding

On 1/5/10 5:03 AM, Anne van Kesteren wrote: More concretely, this means that combined with the rules coming from HTTP a SYNTAX_ERR exception would be raised for the value argument if one of the characters has a code point larger than U+00FF, if the code point is U+007F, or if the code point is sm

Re: XHR LC comment: header encoding

On 1/4/10 3:15 PM, Julian Reschke wrote: But what's the alternative? Decide the encoding in each case? The encoding not being predictable seems to be worse than anything else... Well, one non-destructive alternative is to encode JS strings as bytes by converting each 16-bit code unit into a by

Re: XHR LC comment: header encoding

On 1/4/10 11:44 AM, Julian Reschke wrote: This happens to more or less match "decoding as ISO-8859-1", but not quite. ... Not quite? More precisely, it happens to not quite match what browsers call ISO-8859-1, which is actually Windows-1252. And in particular, ISO-8859-1 doesn't define the

Re: XHR LC comment: header encoding

On 1/4/10 11:17 AM, Julian Reschke wrote: For request headers, I would assume that the character encoding is ISO-8859-1, and if a character can't be encoded using ISO-8859-1, some kind of error handling occurs (ignore the character/ignore the header/throw?). From my limited testing it seems Fir

Re: XMLHttpRequest Comments from W3C Forms WG

On 12/17/09 2:22 PM, Klotz, Leigh wrote: Thank you for the clarification. Surely then this ought to be fixed with an IETF or W3C document describing this fact After some pushback, there is in fact such a document being worked on. It's not quite far enough to reference normatively last I chec

Re: XMLHttpRequest Comments from W3C Forms WG

On 12/17/09 2:10 PM, Klotz, Leigh wrote: I'd be surprised if some of these aren't terms already defined elsewhere. "URL" for example, is surely not given a different definition in HTML5 from the definition in RFC 3986. As it happens, it is. There are various strings that are defined to not

Re: Length of LC comment period [Was: Ready for LC on the various drafts I edit]

On 12/4/09 7:07 AM, Arthur Barstow wrote: Would those that have implemented and/or deployed the above specs please comment on the LC review period length for these specs? Seems reasonable to me, personally. -Boris

Re: CfC - publish Selectors API as CR

On 11/26/09 11:52 AM, Charles McCathieNevile wrote: And I don't see any problem with using public development builds. The main problem I have with them is that they have typically not gone through the sort of full QA cycle that would point out possible problems in the implementation of the "b

Re: CfC - publish Selectors API as CR

On 11/26/09 9:58 AM, Lachlan Hunt wrote: Actually, correction. Minefield and Opera don't meet the condition if we keep the shipping requirement in the exit criteria. Which imo we should. I don't think we want to be opening up that loophole. The Gecko 1.9.2 branch builds have the null/undefine

Re: XMLHttpRequest Comments from W3C Forms WG

On 11/25/09 3:46 PM, Klotz, Leigh wrote: The XMLHttpRequest functionality described in this document has previously been well isolated, and in fact XHR itself has beeen implemented by a number of different desktop browser vendors by copying the original implementations. Note that these were all

Re: [FileAPI] File.mediaType

On 11/10/09 11:58 AM, Anne van Kesteren wrote: True, can you ever get this situation when reading a file from disk? I'm not sure what you're asking... When loading a file from disk, the type is always unknown and has to be determined by the UA somehow, no? Sure, but there's also

Re: [FileAPI] File.mediaType

On 11/10/09 8:33 PM, Anne van Kesteren wrote: This should be a bit more exact as to how the mediaType is returned. I would prefer ASCII-lowercase. Returning "application/octet-stream" rather than null also seems better if the type is not known. That way you do not have to type check. Other parts

Re: childElements, childElementCount, and children

On 10/20/09 11:25 PM, Maciej Stachowiak wrote: It might be worth adding annotations to the spec to say "this API is terrible, do not use" and "this API is terrible, do not follow its design". Are there any DOM Core methods where those notes would not apply? :-) Node.parentNode is mostly ok.

Re: [XHR] Some comments on "charset" in the Content-Type header

On 10/12/09 11:58 AM, Anne van Kesteren wrote: If you do something as simple as application/xhtml+xml;charset=utf-8 it will be corrected so it should be fine. Oh, I see. So you made it so charset is never _added_ if the content-type is set, but will be corrected if present? However, it i

Re: [XHR] Some comments on "charset" in the Content-Type header

On 10/12/09 5:06 AM, Anne van Kesteren wrote: FWIW, this is what I've done now. It gives authors a reasonable level of control over the Content-Type header, it does make sure an incorrect charset parameter is fixed, and includes a charset parameter and MIME type if the author did not include a Co

Re: [XHR] Some comments on "charset" in the Content-Type header

On 10/9/09 7:26 AM, Anne van Kesteren wrote: Are you willing to modify Gecko to a model where if Content-Type has been set by setRequestHeader() the charset parameter is changed if present to the encoding used and is not set when not present. And where if Content-Type has not been set setRequestH

[WebIDL] Trying to understand IndexGetter/NameGetter

In section 4.4.2 of WebIDL, there is the following language: As soon as a name N begins being able to be used to index the host object, a property called the corresponding named property MUST be created on the host object... IndexGetter has similar verbiage. I'm really not clear on this

Re: Web IDL Garden Hose

On 9/27/09 2:28 AM, Maciej Stachowiak wrote: This is not an issue for DOM methods. It's an issue for interfaces such as HTMLCollection and HTMLFormElement that support indexing by function call syntax, for legacy compatibility reasons. Huh. Gecko hasn't supported this, and we haven't had probl

Re: Web IDL Garden Hose

On 9/27/09 3:30 AM, Brendan Eich wrote: I believe we could get rid of custom deleters from the Web platform if Firefox and IE remove support for custom deleters in LocalStorage, refuse to add it back, and refuse to implement it for DOMStringMap. If that happened, I'm sure other browsers and the s

Re: [selectors-api] Scoped Selectors

On 9/26/09 4:36 PM, Lachlan Hunt wrote: A scoped selector string is a string that begins with an exclamation point followed by a the remainder of the selector. This assumes that '!' will never be allowed at the beginning of a CSS selector, right? Have you run this by the CSS working group?

Re: [selectors-api] Summary of Feature Requests for v2

On 9/25/09 1:35 AM, Garrett Smith wrote: No, you did not say it is slow. I'm saying that your laptop is probably a lot more powerful than a mobile device with a browser, such as Blackberry9000. Do you agree with that? Sure. It's a pretty self-evidently true claim. that said, note that on a m

Re: [selectors-api] Scoped Selectors

On 9/25/09 9:59 AM, Lachlan Hunt wrote: Yes, the reference elements parameter will accept either a single element, Array or NodeList. What about HTMLCollection? Or have we finally made that interface inherit from NodeList? Another question I just had reading this, and this is probably a web

Re: [selectors-api] Summary of Feature Requests for v2

On 9/24/09 6:45 PM, Sean Hogan wrote: That is surprising. Does the CSS engine do the same? If the CSS engine doesn't store the parsed selector then it probably doesn't matter for JS calls either. In Gecko the CSS engine stores the parsed selector. In addition, it stores the selectors in vario

Re: [selectors-api] Summary of Feature Requests for v2

On 9/24/09 5:09 PM, John Resig wrote: It's only if it's an array that we have to do the dance. Even in the case where the array of results is already in document order the sort will be incredibly fast (O(N)). O(N) in number of nodes in the array, and that assumes that the array is not being so

Re: [selectors-api] Summary of Feature Requests for v2

On 9/24/09 2:36 PM, Sam Weinig wrote: WebKit now also has an implementation of Element.matchesSelector() (we are calling ours webkitMatchesSelector for the time being). [https://bugs.webkit.org/show_bug.cgi?id=29703] Right. The Gecko one is mozMatchesSelector. I bet we'd both love to rename i

Re: [selectors-api] Summary of Feature Requests for v2

On 9/24/09 2:17 PM, Garrett Smith wrote: On Thu, Sep 24, 2009 at 6:06 AM, Boris Zbarsky wrote: Gecko doesn't. Webkit doesn't. I just checked really quickly, and on my machine (a year-plus old laptop) That is probably many times faster, and can probably be much more libera

Re: [selectors-api] Summary of Feature Requests for v2

On 9/24/09 6:29 AM, Sean Hogan wrote: I would be surprised if an implementation didn't create an internal lookup table keyed off the selector text. Gecko doesn't. Webkit doesn't. I just checked really quickly, and on my machine (a year-plus old laptop) parsing the ".foo .bar .baz" selector a

Re: Is localStorage read and write-able offlne?

Jeremy Orlow wrote: I don't know what you mean by this. LocalStorage only cares about the origin. Ah, indeed. I'd gotten lost in all the spec changes in this area... For reference, https://bugzilla.mozilla.org/show_bug.cgi?id=495337 -Boris

Re: Is localStorage read and write-able offlne?

Jeremy Orlow wrote: > When used in conjunction with AppCache, the offline behavior of > localStorage should be reasonably deterministic. Doesn't localStorage depend on the domain (not origin, mind you!) of the page? What exactly is the domain for a file:// URI? -Boris

Re: Window Modes todo

Robin Berjon wrote: Do other implementers care to chime in with what they do, and if they'd find this change acceptable? As I recall Gecko's behavior, it works more or less like this: 1) Properties listed as readonly in the DOM 2 Events IDL are in fact readonly. 2) init*Event may be call

Re: [selectors-api] Test Suite Progress

Lachlan Hunt wrote: Both Minefield and Webkit trunk are failing those tests for me. I have all but one commented out just so it would make my debugging easier (see lines 287 to 292 in 002.html). Oh, I'd just missed the one failing test. Showing only failing tests helped! I just checked in

Re: [selectors-api] Test Suite Progress

Lachlan Hunt wrote: I've also begun to add tests for the namespace selector syntax [2] to the second set, but they are currently a work in progress and are not functioning properly. If anyone can figure out what I've done wrong, please let me know. I'm glad to try to figure that out, if you

Re: XMLSerializer should run HTML serialization algorithm when input doc is HTML

Giovanni Campagna wrote: Then we need a discussion about the possibility of having a spec for XMLSerializer, having already DOM3LS. Which probably needs changes similar to what Henri proposed to actually work correctly with HTML5. -Boris

Re: Web IDL syntax

Cameron McCormack wrote: Boris Zbarsky: I thought there had been at least some mention of this colliding with existing string types in IDLs that are already in use? I know this will make it much harder for Mozilla to use webidl IDL fragments "as is"... Yes, but then Jonas repl

Re: Web IDL syntax

Cameron McCormack wrote: * Renamed DOMString to string: http://dev.w3.org/2006/webapi/WebIDL/#idl-string I thought there had been at least some mention of this colliding with existing string types in IDLs that are already in use? I know this will make it much harder for Mozilla to use

Re: [selectors-api] Transitioning to CR

Robin Berjon wrote: Yeah, I have this Ecmascript implementation that only supports variable declarations (with a few bugs). But I swear it supports the Selectors API! Yes, that's why there was an "if" in what I said. If only English had clearer grammatical markers for the subjunctive! Serio

Re: [selectors-api] Transitioning to CR

Robin Berjon wrote: * Test failures in a given implementation caused by the lack of support for a particular feature of an independent specification are not counted. ... Out of curiosity, why not make it two interoperable implementations of *all* the tests, except those stemming from a lack

Re: File API Feedback

Ian Hickson wrote: Local display of images before uploading them requires being able to take a File object and poke it into parts of the platform that currently only take URLs. I suggest that the way we address this is by adding an API to a File object that returns a URL like this: scheme:

Re: [webidl] XMLHttpRequest interface object

Ian Hickson wrote: On Thu, 30 Apr 2009, Boris Zbarsky wrote: Sam Weinig wrote: I am not sure this always holds. In the case of the the transition from the initial ("about:blank") document to a loaded document, the window needs to be reused at times. Take for instance, w = w

Re: Mutation events replacement

João Eiras wrote: The overhead of comparing the previous with the new value inside the engine is a fragment of the overhead of calling an ecmascript callback and doing the same comparison in ecmascript. For a given operation that has a callback listening, yes. But most operations do not have

Re: [webidl] XMLHttpRequest interface object

Sam Weinig wrote: I am not sure this always holds. In the case of the the transition from the initial ("about:blank") document to a loaded document, the window needs to be reused at times. Take for instance, w = window.open("testForProperties.html"); w.customWindowProperty = "1"; w.document.

Re: Storage 'length' and enumeration

Sean Hogan wrote: I was following the discussion, and the point is that array-like behavior is implied but not consistently delivered. Implied by what? The presence of the "length" property? Anyway, as you point out, for this interface Firefox gives precedence to NameGetters over IndexGetter

Re: Storage 'length' and enumeration

Sean Hogan wrote: sessionStore[2] = "howdy"; print(sessionStore[2]); // prints null? Where, exactly? That gives "howdy" in Gecko, at least. At least with s/sessionStore/window.sessionStorage/. -Boris

Re: Web Storage & SQL

Nikunj Mehta wrote: One clear problem identified despite these examples is that we do not have a precise enough spec for the query language to make truly independent interoperable implementations possible. There are several different query languages that can be interoperably implemented - Luc

Re: Web Storage & SQL

Maciej Stachowiak wrote: I don't think this one point should be decisive by itself. But I don't think it should be given zero weight either. Agreed (in case that wasn't clear). Note that one of the clients in question is the offline-enabled mobile version of GMail. I think this demonstrates t

Re: Web Storage & SQL

Maciej Stachowiak wrote: I agree that "no such thing as standard SQL" (or rather the fact that implementations all have extensions and divergences from the spec) is a problem. But I am not sure inventing a brand new query language and database model as proposed by Vlad is a good solution to thi

Re: Web Storage & SQL

Giovanni Campagna wrote: Yes. With extensions I mean writing "start transaction" instead of "begin", using the backquotes instead of double quotes for identifires, using INET and spatial data types, using table options... OK. This is not the case. A query written based on that ISO standard

Re: Web Storage & SQL

Giovanni Campagna wrote: We have a standard SQL, and we have DBMS-specific extensions (for SQLite, for MySQL, for SQLServer, etc.). > The latest version is "ISO/IEC 9075:2008 Information technology -- > Database languages -- SQL", released in 2008, but actively being > revised, according to the

Re: Web Storage & SQL

Giovanni Campagna wrote: So why not adding a parameter on openDatabase() to specify what kind of database we want (and what kind of query language we will use)? I mean something like openDatabase(name, version, type, displayName, estimatedSize) where type can be any string so, for example, type =

Re: Selectors API

Maciej Stachowiak wrote: Live lists will almost certainly be slower in the face of DOM mutation concurrent with iterating the list. I don't know of any reason things would be different in Gecko. Yes, they would be. The question is how much, and how often one iterates the whole list as oppose

Re: Selectors API

Anne van Kesteren wrote: http://lists.w3.org/Archives/Public/public-webapi/2007Mar/0066.html http://lists.w3.org/Archives/Public/public-webapi/2007Apr/0009.html I read those. That was long after this was initially discussed though. And also around the time I stopped being the active editor of

Re: Selectors API

Anne van Kesteren wrote: On Mon, 23 Mar 2009 14:49:17 +0100, Boris Zbarsky wrote: Just as a point of record, I believe browser implementors were split on the issue (e.g. I think in Gecko live performance would be as good, if not better in many cases, as non-live performance. I said so at

Re: Selectors API

Anne van Kesteren wrote: I have been told that the reason for not having live collections is for performance, but I find that hard to understand. The current live collections are much faster than their native javascript emulations, I can't see that getting a collection every time it is require

Re: [selectors-api] Test Suite Missing tests for Namespace Selectors

Lachlan Hunt wrote: Interestingly, though, Opera has the opposite bug. We fail when null is passed instead of "". Fun. Maybe the test should just test both. ;) -Boris

Re: [selectors-api] Test Suite Missing tests for Namespace Selectors

Alexey Proskuryakov wrote: This is actually a difference in createElementNS(null, "p") vs. createElementNS("", "p") behavior. I don't know whose bug it is, but in Firefox and Opera, empty and null namespace arguments both result in null namespace for the created element. Interesting question.

Re: [Selectors API] Call for Consensus - approve John Resig's tests

Ian Hickson wrote: For the Selectors API as far as I can tell it's trivial to implement, no? Just put the APIs on the other interfaces directly. That fails for non-JS embeddings of Gecko, for various reasons. So no, pretty nontrivial. -Boris

Re: [Selectors API] Call for Consensus - approve John Resig's tests

Ian Hickson wrote: However, I don't think the things tested in 002 are controversal. In particular, all the UAs have converged on the behaviour tested by 002-001 for other objects Ah, that wasn't the case last I checked. And again, there's no specification I can find that requires it. 002

Re: [Selectors API] Call for Consensus - approve John Resig's tests

Ian Hickson wrote: http://www.hixie.ch/tests/adhoc/dom/selectors/002.html Given the state of WebIDL, it's not clear to me that the test 002 of this test is necessarily required by the spec as it stands. For that matter, it's not clear to me that test 001 is. Also, I would like to ask th

Re: Call for Consensus - Selectors API to Candidate Rec

John Resig wrote: As of last night's nightly WebKit has the first 100% passing implementation. Interesting. Did they do this by violating the "If the user agent also supports some level of CSS, the implementation SHOULD support the same set of selectors in both these APIs and CSS" recommend

Re: Call for Consensus - Selectors API to Candidate Rec

Cameron McCormack wrote: If that does end up being the more common behaviour, I’ll change the default in Web IDL to be to stringify to "undefined" unless overridden, For what it's worth, that's what the current WebIDL draft says in any case. -Boris

Re: Call for Consensus - Selectors API to Candidate Rec

Lachlan Hunt wrote: Firefox appears to have some issues that might related to the API, though I haven't investigated the cause of those yet, so I don't know for sure. On John Resig's tests in particular, every single failure in Gecko is due to a violation of this part of the API: Undefin

Re: DOMTimeStamp binding

Kartikaya Gupta wrote: For Java, DOMTimeStamp is bound to the long type. For ECMAScript, DOMTimeStamp is bound to the Date type because the range of the integer type is too small. I get "number" in Opera and Firefox, and "object" in Webkit. Is there a reason Opera and Firefox bind the timestam

Re: Seeking implementation status of XBL2

Robin Berjon wrote: Oh, I fully agree with that, the point is not to water down the interoperability requirements. I simply want to make sure that JS-based implementations are counted as "real" as there often is a misperception that they are somehow just hacks. I think that should be fine as

Re: Seeking implementation status of XBL2

Robin Berjon wrote: I don't know if there is precedent in counting JS-based implementations as valid implementation to get a spec out the door (maybe the Forms WG did it?) but I see no reason not to. In fact, I could make the argument that they should count *more* as they allow technology to b

Re: Call for Consensus - Selectors API to Candidate Rec

Jonas Sicking wrote: So do I, and most likely the rest of mozilla. Seconded. -Boris

Re: Required support for SVG in widgets

Scott Shattuck wrote: From the SVG Specification, Section G.7 Conforming SVG Viewers ... Specific criteria that apply to only /Conforming Dynamic SVG Viewers/: * *The viewer must have complete support for an ECMAScript binding of the **SVG Document Object Model*

Re: SVG as Widget Icon

Jere Kapyaho wrote: Treating svg icons in widgets in the same mode as pointing to SVG sounds great to me. So in essence you would tell the SVG engine to rasterize the vector image in whatever size is suitable for the widget engine? Not necessarily, no. Of course the rasterization happens a

Re: SVG as Widget Icon

Marcos Caceres wrote: I'm not sure I agree. I think for security reasons, we should tell implementors how to treat SVG icons (no script, no interactivity). They won't have to strip down the SVG viewer, just set up constraints (which they need to do anyway). Ok, I tend to agree with you that

Re: Request for Comments: Last Call WD of Widgets 1.0: Packaging & Configuration spec; deadline 31 Jan 2009

Marcos Caceres wrote: Ok, as I know little of SVG, I've asked Doug Scheppers to help me That sounds like an excellent plan. Thank you! It is, but this affects more than just Zip. See also [3] with the problems Limewire had in respect to normalization of Unicode on MacOs X. Note that this

Re: [selectors-api] SVG WG Review of Selectors API

Giovanni Campagna wrote: 2009/1/28 Boris Zbarsky : Giovanni Campagna wrote: well, assuming that an author will need to match elements across multiple namespaces, it will be easier to use XPath (that also is compatible across multiple browsers) than to use horrible workarounds like "svg

Re: Request for Comments: Last Call WD of Widgets 1.0: Packaging & Configuration spec; deadline 31 Jan 2009

Boris Zbarsky wrote: Sort of. We use JAR, not ZIP. Any JAR file is a ZIP file, but not vice versa. In particular, the JAR spec [1] defines that all non-ASCII bytes are UTF-8. That [1] is http://java.sun.com/j2se/1.4.2/docs/guide/jar/jar.html -Boris

Re: [selectors-api] SVG WG Review of Selectors API

Giovanni Campagna wrote: well, assuming that an author will need to match elements across multiple namespaces, it will be easier to use XPath (that also is compatible across multiple browsers) than to use horrible workarounds like "svg :not(foreignObject) *[href]" (all svg links) I should note

<    3   4   5   6   7   8   9   >