Re: responseXML/responseText exceptions and parseError

2008-06-19 Thread Boris Zbarsky
Julian Reschke wrote: Could you please provide some more information or give an example about when this would be the case? Here's a simple past example, if I understand your question correctly. One can set an onerror handler on Window that will trigger if an exception is thrown and not

[selectors-api] What's the final call on NSResolver?

2008-06-20 Thread Boris Zbarsky
We'd like to actually ship a Selectors API implementation in the near future, and since we implement namespaces in CSS we need some resolution on the NSResolver thing. Is it in? Is it out? Are we replacing it with a string instead? Can we ship something sane without NSResolver at all?

Re: [D3E] Possible Changes to Mutation Events

2008-07-15 Thread Boris Zbarsky
Sergey Ilinsky wrote: 1) Clearly defined use cases seem to be missing from the proposal, would it be possible to bring them all to the table? It's more a matter of sanity of implementation than anything else, for what it's worth. 2) The changes contradict with DOM-Level-2 Events where

Re: [selectors-api] Investigating NSResolver Alternatives

2008-07-15 Thread Boris Zbarsky
Lachlan Hunt wrote: Given that IE, Webkit and Opera seem to be in favour of dropping NSResolver, if Mozilla will agree, I'm more than happy to do so OK. We talked it over, and this sounds like the best way going forward for now. -Boris

Re: [D3E] Possible Changes to Mutation Events

2008-07-15 Thread Boris Zbarsky
Doug Schepers wrote: 2) If DOMNodeRemoved is fired after the mutation, event won't be capable of bubbling I don't believe that is correct. DOM3 Event states: At the beginning of the dispatch, implementations must first determine the event object's propagation path. I think Sergey's point

Re: [selectors-api] Investigating NSResolver Alternatives

2008-07-16 Thread Boris Zbarsky
Lachlan Hunt wrote: Although it still has the requirement to throw a NAMESPACE_ERR when namespace prefixes that need to be resolved are encountered http://dev.w3.org/2006/webapi/selectors-api/ In theory it might be better to throw NOT_SUPPORTED_ERR so going forward you can distinguish

Re: [D3E] Possible Changes to Mutation Events

2008-07-16 Thread Boris Zbarsky
Laurens Holst wrote: I see, so the motivation for the change request to DOMNodeRemoved is that the second change request (throwing events at the end, after all operations) is be impossible to do if events are not always thrown at the end. And the motivation for throwing events at the end

Re: [selectors-api] Investigating NSResolver Alternatives

2008-08-20 Thread Boris Zbarsky
Lachlan Hunt wrote: The way I see it, all current impls should throw something if more than one arg is passed Which exception should be thrown? Is this something I should define in this spec, or is it something for WebIDL or some other spec to deal with? Honestly, I don't care much on that

Re: [selectors-api] Investigating NSResolver Alternatives

2008-08-20 Thread Boris Zbarsky
Lachlan Hunt wrote: The developers implementing this in Opera has given me feedback saying that this shouldn't throw an exception because JS allows additional arguments to be passed to any method, including other DOM APIs, like getElementById(), etc. Is there a good reason why this should

Re: [whatwg] WebIDL and HTML5

2008-08-25 Thread Boris Zbarsky
Garrett Smith wrote: [Null=Null, Undefined=Null] [Null=Null, Undefined=Empty] [Null=Empty, Undefined=Empty] [Null=Null, Undefined=String] [Null=Empty, Undefined=String] [Null=String, Undefined=String] ...so that we can do, e.g.: Window open([Null=String, Undefined=String] in

Re: [whatwg] WebIDL and HTML5

2008-08-25 Thread Boris Zbarsky
Garrett Smith wrote: I already expressed my opinion, agreeing with Liorean. For domstring arguments, call the internal ToString on the input would be the general rule, unless otherwise stated. This would seem to cover the majority of cases. window.open is one of the cases when things are not

Re: [whatwg] WebIDL and HTML5

2008-08-25 Thread Boris Zbarsky
Garrett Smith wrote: window.open(); Which should be equivalent to window.open(undefined) (and isn't in some UAs), right? What should window.open(null) do? If the first argument is null or undefined or the empty string, no uri is loaded and an blank/empty window is displayed. This is

Re: [whatwg] WebIDL and HTML5

2008-08-25 Thread Boris Zbarsky
Garrett Smith wrote: The addition operator results in concatenation when either operand is a string. This results in a calls to the internal ToString, which is what I'm suggesting should be the general rule. All I'm saying is that this will require annotating a very large number of API

Re: [whatwg] WebIDL and HTML5

2008-08-26 Thread Boris Zbarsky
Garrett Smith wrote: That can be the default, perhaps. But I suspect usually null should become , not null. Why? Honestly? Because that's what Firefox does right now, except in certain That is not true. Firefox has Spidermonkey. The Spidermonkey part is irrelevant for purposes of this

Re: [whatwg] WebIDL and HTML5

2008-08-26 Thread Boris Zbarsky
Garrett Smith wrote: There is no DOM method calld doStuff. Can you provide a concrete example? Boris couldn't think of one either. Uh, what? You never said, I don't understand that this applies to all DOM methods that take a DOMString, so I'd like to have some specific examples. In any

Re: [whatwg] WebIDL and HTML5

2008-08-26 Thread Boris Zbarsky
Garrett Smith wrote: Using ToString, the following result would be obtained: Yes, I know what you get with ToString. After the method createElement(null) is called, there will be no need to tell apart null and null. I see that. Why is that a problem? There are other methods where you DO

Re: [whatwg] WebIDL and HTML5

2008-08-26 Thread Boris Zbarsky
Garrett Smith wrote: Null is not the empty string. No one claimed that it was. A number of DOM methods are specified as treating them equivalently, however. -Boris

Re: [whatwg] WebIDL and HTML5

2008-08-26 Thread Boris Zbarsky
Garrett Smith wrote: 2) It violates the DOM Level 3 Core specification, which says: On setting, any possible children this node may have are removed and, if it the new string is not empty or null, replaced by a single Text node containing the string this attribute is set to. Thus, clearly

Re: [whatwg] WebIDL and HTML5

2008-08-26 Thread Boris Zbarsky
Garrett Smith wrote: Well, I'm not so sure. I corresponded with Jonas who indicated that he though null should convert to . Jonas was saying that the default behavior for a DOM method passed a null DOMString should be the same as the behavior if passed . That's not the same as saying that

Re: [whatwg] WebIDL and HTML5

2008-08-27 Thread Boris Zbarsky
Garrett Smith wrote: I do not see where the spec describes the particular effect when setting to nul. Maciej quoted the exact text. So did I. I suggest selecting that text, copying it, going to your browser, opening up the find dialog or equivalent, pasting it, and thus getting to see

Re: [whatwg] WebIDL and HTML5

2008-08-27 Thread Boris Zbarsky
Garrett Smith wrote: I contend that the textContent example is not designed in a useful manner and that having null - sometimes and null - null others introduces complexity. Sure. And we're stuck with this complexity. Now where do we go from here? -Boris

Re: [whatwg] WebIDL and HTML5

2008-08-27 Thread Boris Zbarsky
Garrett Smith wrote: Given that, I suggest moving forward: Test, then document those methods as having special behavior. Do this not by a null-value mapping, but by documenting the method's algorithm in simple terms. e.g. if X is not a string, throw an error But giving a (per-method)

Re: [whatwg] WebIDL and HTML5

2008-08-27 Thread Boris Zbarsky
Garrett Smith wrote: I can appreciate the desire to make the task of implementing the spec in an automated fashion. That is a desire, however, not a need. So is everything else. This particular desire has great benefits, however, so it needs to have great drawbacks as well to not be done,

Re: [whatwg] WebIDL and HTML5

2008-08-27 Thread Boris Zbarsky
Garrett Smith wrote: So is everything else. This particular desire has great benefits, however, so it needs to have great drawbacks as well to not be done, right? The drawback would be inconsistency with current implementations How so? Anything that specifies interoperable behavior would

Re: [whatwg] WebIDL and HTML5

2008-08-27 Thread Boris Zbarsky
Garrett Smith wrote: If I'm reading the right spec[1], OMG IDL defines the string type string consisting of all possible 8-bit quantities except null. DOMString isn't an OMG IDL String. It's defined as [1]: valuetype DOMString sequenceunsigned short; And no, I'm not sure you're looking

Re: [whatwg] WebIDL and HTML5

2008-08-27 Thread Boris Zbarsky
Garrett Smith wrote: It is not compatible? Where? How? Node.textContent. A spec mentioning null for a method that accepts a string does not make null a string. See long post with an analysis of the exact OMG IDL meaning of the DOMString type (which is NOT quite the same as ECMAScript

Re: [whatwg] WebIDL and HTML5

2008-08-27 Thread Boris Zbarsky
Garrett Smith wrote: Java does not include null value for String type. You can ignore the null type and just pretend that null can be of any reference type, but that does not make null a string. Any Java method that takes a String can have null passed to it. That's the only question here:

Re: [whatwg] WebIDL and HTML5

2008-08-27 Thread Boris Zbarsky
Boris Zbarsky wrote: See long post with an analysis of the exact OMG IDL meaning of the DOMString type (which is NOT quite the same as ECMAScript string, note). I should note that there is one thing adding to the confusion. The use of String in the ECMAScript language bindings for the DOM

Re: [whatwg] WebIDL and HTML5

2008-08-28 Thread Boris Zbarsky
Garrett Smith wrote: Any Java method that takes a String can have null passed to it. Yes, and this is true for any reference type, not only String. Yep. Point is, DOMString is defined as a reference type. Are you concerned with what can be passed to a method, or what is a String? The

Re: XDomainRequest Integration with AC

2008-09-05 Thread Boris Zbarsky
Anne van Kesteren wrote: On Fri, 05 Sep 2008 09:43:29 +0200, Jonas Sicking [EMAIL PROTECTED] wrote: http://foo.com and http://foo.com:80 are the same origin but have different string representations. Yes, authors would have to use the former. (The former is also what Origin will tell them

Re: Support for compression in XHR?

2008-09-09 Thread Boris Zbarsky
Dominique Hazael-Massieux wrote: The Mobile Web Best Practices Working Group is interested to know whether XmlHTTPRequest has any actual or planned support for compression HTTP has Content-Encoding and Transfer-Encoding, no? No special effort on the part of XMLHttpRequest is needed to make

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

2008-09-19 Thread Boris Zbarsky
Michael(tm) Smith wrote: It's intended in part to be a way to keep all our law-abiding citizen readers in the general public informed about what progress if any the group is making on the spec. But if the information is months out of date, is it useful? Seems to me that it would be better

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

2008-09-19 Thread Boris Zbarsky
Julian Reschke wrote: Maybe I'm missing something, but why not leave it alone if the MIME type isn't text/* (the only ones where charset is really relevant)? An excellent example right there of why! For example, it's relevant for some application types: application/xml,

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

2008-09-19 Thread Boris Zbarsky
Julian Reschke wrote: Why would you ever *want* to set charset on application/xml or application/*+xml? That's a really good question, but people do... In any case, my other example (JavaScript) remains. -Boris

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

2008-09-19 Thread Boris Zbarsky
Anne van Kesteren wrote: Well, correcting charset is fine. The suggestion for not putting it there at all unless the media type is text or it is already present makes some sense though. I might be convinced of that, I suppose... but read on. In any case, my other example (JavaScript)

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

2008-09-19 Thread Boris Zbarsky
Anne van Kesteren wrote: Well 1) quite a few browsers don't add charset automatically yet like Firefox True, but the reason we started adding it is that it was non-obvious otherwise what charset the string was encoded in (UTF-8? Page encoding?) and this was causing real problems. and 2)

Re: [selectors-api] LCWD comments

2008-11-16 Thread Boris Zbarsky
Krzysztof MaczyXski wrote: The CSS WG is currently wondering whether elements should be able to be descendants of some pseudo-elements (notably :selection, :first-line and :first-letter). So this note may need correction. Not relevant here. The CSS WG is wondering whether elements should

Re: [selectors-api] Liveness versus NodeList

2008-11-21 Thread Boris Zbarsky
Stewart Brodie wrote: This is considered to be a bug in the DOM Core specs, which will hopefully be fixed by Web DOM Core, which is a proposal Simon Pieters is working on. You will still need a new type, as I don't see how you can possibly change the existing behaviour so dramatically under

Re: [widgets] Content-type sniffing and file extension to MIME mapping

2008-12-02 Thread Boris Zbarsky
Marcos Caceres wrote: Do you have any suggestions as to how we might move forward? Or a different approach to solving the problem? The problem being that a ZIP file doesn't know anything about the types of files in it? What Gecko does right now for jar: URIs is somewhat similar to what it

Re: Call for Consensus - Selectors Last Call

2008-12-07 Thread Boris Zbarsky
Sean Hogan wrote: - All the getElement* selectors are matched by straight-forward ways for checking if an element-node matches the desired constraint. e.g. getElementsByTagName and tagName, getElementById and id, getElementsByClassName and className / classList Honestly, className is not a

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

2008-12-07 Thread Boris Zbarsky
Doug Schepers wrote: Please add an example such as this one: html xmlns=http://www.w3.org/1999/xhtml; body svg xmlns=http://www.w3.org/2000/svg; font id=mysvgfont ... /font /svg font face=ArialExample/font svg:font id=anothersvgfont

Re: [selectors-api] Comment on Interoperability Considerations

2008-12-14 Thread Boris Zbarsky
Norbert Lindenberg wrote: I would expect the specification to prescribe - either that the implementation raises an exception when given a This is in fact required in the normative definitions of querySelector and querySelectoAll. This could be mentioned in the informative section here, I

Re: Use cases for Selectors-API

2008-12-26 Thread Boris Zbarsky
Giovanni Campagna wrote: - XMLPath and DOM3 XPath actually are implemented: even FF2 supports document.evaluate, instead selectors api are included only in the very latest browser (Opera 10 and FF3.1 AFAIK) And Safari and IE8. But yes, the point that XPath is already supported as a

Re: Use cases for Selectors-API

2008-12-27 Thread Boris Zbarsky
Giovanni Campagna wrote: - Selectors is designed to be fast to match, while XPath had no such design criterion; as a result it's very easy to write pathologically slow XPath queries, even by accident. For non-pathological cases, Selectors are still faster, whether because

Re: Proposal: Detecting when the user leaves a page due to hitting the back button or typing in a URL or going to a favorite

2009-01-02 Thread Boris Zbarsky
Shropshire, Andrew A wrote: 4)Should a web page designer cancel all navigations away from the page just to be malicious, the user can still close the page (since closing the page does not fire the onNavigateToNewPage event). That loses the user's navigation history in that window, so

Re: Proposal: Detecting when the user leaves a page due to hitting the back button or typing in a URL or going to a favorite

2009-01-05 Thread Boris Zbarsky
Giovanni Campagna wrote: Probably treating the onbeforeunload as a real cancelable event But the key is that the page must not be able to prevent navigation away from itself without explicit OK by the user. In other words, while the UA needs to be able to cancel the unload, the page has no

Re: Proposal: Detecting when the user leaves a page due to hitting the back button or typing in a URL or going to a favorite

2009-01-05 Thread Boris Zbarsky
Giovanni Campagna wrote: What if we follow completely Andrew's proposal? That is, we allow cancellation of beforeunload events, but we add an UI control that may be used to froze JS (in HTML5 terms), preventing a further beforeunload to be handled and canceled. That places UI requirements

Re: Proposal: Detecting when the user leaves a page due to hitting the back button or typing in a URL or going to a favorite

2009-01-05 Thread Boris Zbarsky
Shropshire, Andrew A wrote: I am working a dialog problem now and I have discovered another problem with Onbeforeunload: It is called even for javascript URLs which clearly aren't exiting the page. I believe this is only the case in some browsers. For example, IE/Windows does this, but

Re: Proposal: Detecting when the user leaves a page due to hitting the back button or typing in a URL or going to a favorite

2009-01-06 Thread Boris Zbarsky
Shropshire, Andrew A wrote: One use case for this is to customize the text in the dialog. For example, right now the developer is forced to use Are you sure you want to navigate away from this page? ... Press OK to continue, or Cancel to stay on the current page. This doesn't make sense if

Re: Proposal: Detecting when the user leaves a page due to hitting the back button or typing in a URL or going to a favorite

2009-01-06 Thread Boris Zbarsky
Shropshire, Andrew A wrote: It would appear that there are countless ways to crash the browser and/or lose navigation history Depends on the browser. If your browser allows web pages to do this, either complain to the vendor or vote with your feet and switch to a better browser. ;) 2.

Re: Proposal: Detecting when the user leaves a page due to hitting the back button or typing in a URL or going to a favorite

2009-01-06 Thread Boris Zbarsky
Shropshire, Andrew A wrote: For those that don't, making the unload event cancellable won't break anything (it won't be fired multiple times because the first time it's fired is the last for the page because it gets unloaded on the first fire since these existing web apps don't know that it can

Re: Proposal: Detecting when the user leaves a page due to hitting the back button or typing in a URL or going to a favorite

2009-01-06 Thread Boris Zbarsky
Shropshire, Andrew A wrote: These pages deserve to be broken :) That's true of most pages on the web if you apply that criterion. In fact, I have yet to run into any real-life (not example, not testcase) web page that wouldn't be true of. Breaking sites like that is a non-starter for

Re: Proposal: Detecting when the user leaves a page due to hitting the back button or typing in a URL or going to a favorite

2009-01-06 Thread Boris Zbarsky
Shropshire, Andrew A wrote: One could simply deprecate the onunload (but still support it) and create a new version onDestroy that is called as well. Old apps won’t know about onDestroy so it will be harmless and won’t break them. New apps simply don’t need to implement onunload and will

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

2009-01-09 Thread Boris Zbarsky
A few comments: 1) In section 7.3, boolean attributes are defined to use case-insensitive matching. Why is that? There doesn't seem to be a definition of case-insensitive here, which worries me, since case-folding is always tricky business (see below). I would suggest requiring a

Re: http://dev.w3.org/2006/waf/widgets/#the-widget-element height and width default values

2009-01-14 Thread Boris Zbarsky
Kai Hendry wrote: Was wondering how you came up with 150x300 as the default size for a widget. Possibly because that's the default size of a replaced element in CSS? And that's because that's how big iframes are by default in browsers, last I checked. Perhaps pixel definitions are

Re: tag: uri scheme

2009-01-21 Thread Boris Zbarsky
Larry Masinter wrote: Yes, using Zip is a different overall serialization than MIME multipart, but aren't the problem spaces similar enough that differences from what is already widespread practice? MIME multipart would have the side benefit of specifying MIME types. At the same time,

Re: tag: uri scheme

2009-01-21 Thread Boris Zbarsky
Larry Masinter wrote: I'm not sure about 'authoring might be more complicated', though. The author/sender/creator of a package has a lot more insight about the types of the components of the package than the recipient, and if there's any guesswork to be done, putting the burden on the author

Re: tag: uri scheme

2009-01-21 Thread Boris Zbarsky
Larry Masinter wrote: First, it usually isn't authors who personally assign MIME types to anything. Indeed. That's one saving grace, since we want more authors creating web content than there are people who even know what a MIME type is. MIME types are generally assigned by the HTTP

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

2009-01-28 Thread Boris Zbarsky
Marcos Caceres wrote: Ok, that sounds like a completely reasonable proposal. And you are right, I had thought about this in totally the wrong way. I did as you suggested: * widget engines may now support SVG 1.1. * authors, however, should try to conform to SVG Tiny 1.2. * conformance

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

2009-01-28 Thread Boris Zbarsky
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

2009-01-28 Thread Boris Zbarsky
Giovanni Campagna wrote: 2009/1/28 Boris Zbarsky bzbar...@mit.edu: 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

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

2009-01-28 Thread Boris Zbarsky
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: SVG as Widget Icon

2009-01-29 Thread Boris Zbarsky
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: SVG as Widget Icon

2009-01-30 Thread Boris Zbarsky
Jere Kapyaho wrote: Treating svg icons in widgets in the same mode as img 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

Re: Required support for SVG in widgets

2009-02-03 Thread Boris Zbarsky
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: Call for Consensus - Selectors API to Candidate Rec

2009-02-06 Thread Boris Zbarsky
Jonas Sicking wrote: So do I, and most likely the rest of mozilla. Seconded. -Boris

Re: Call for Consensus - Selectors API to Candidate Rec

2009-02-12 Thread Boris Zbarsky
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:

Re: Call for Consensus - Selectors API to Candidate Rec

2009-02-12 Thread Boris Zbarsky
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

2009-02-13 Thread Boris Zbarsky
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

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

2009-03-04 Thread Boris Zbarsky
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

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

2009-03-05 Thread Boris Zbarsky
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.

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

2009-03-06 Thread Boris Zbarsky
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] Test Suite Missing tests for Namespace Selectors

2009-03-12 Thread Boris Zbarsky
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. DOM

Re: Selectors API

2009-03-23 Thread Boris Zbarsky
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

Re: Selectors API

2009-03-23 Thread Boris Zbarsky
Anne van Kesteren wrote: On Mon, 23 Mar 2009 14:49:17 +0100, Boris Zbarsky bzbar...@mit.edu 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

Re: Selectors API

2009-03-23 Thread Boris Zbarsky
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: Web Storage SQL

2009-04-09 Thread Boris Zbarsky
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: Web Storage SQL

2009-04-09 Thread Boris Zbarsky
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 ISO

Re: Web Storage SQL

2009-04-09 Thread Boris Zbarsky
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 this

Re: Web Storage SQL

2009-04-10 Thread Boris Zbarsky
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

Re: Web Storage SQL

2009-04-10 Thread Boris Zbarsky
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 -

Re: Storage 'length' and enumeration

2009-04-29 Thread Boris Zbarsky
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: File API Feedback

2009-06-18 Thread Boris Zbarsky
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:

Re: Web IDL syntax

2009-06-30 Thread Boris Zbarsky
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: XMLSerializer should run HTML serialization algorithm when input doc is HTML

2009-07-02 Thread Boris Zbarsky
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: [selectors-api] Test Suite Progress

2009-07-24 Thread Boris Zbarsky
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: [selectors-api] Test Suite Progress

2009-07-24 Thread Boris Zbarsky
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

Re: Window Modes todo

2009-07-27 Thread Boris Zbarsky
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

Re: Is localStorage read and write-able offlne?

2009-07-30 Thread Boris Zbarsky
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: [selectors-api] Summary of Feature Requests for v2

2009-09-24 Thread Boris Zbarsky
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

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

2009-09-24 Thread Boris Zbarsky
On 9/24/09 2:17 PM, Garrett Smith wrote: On Thu, Sep 24, 2009 at 6:06 AM, Boris Zbarskybzbar...@mit.edu 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 liberal,

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

2009-09-24 Thread Boris Zbarsky
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

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

2009-09-24 Thread Boris Zbarsky
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

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

2009-09-24 Thread Boris Zbarsky
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

Re: [selectors-api] Scoped Selectors

2009-09-25 Thread Boris Zbarsky
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

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

2009-09-25 Thread Boris Zbarsky
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

Re: [selectors-api] Scoped Selectors

2009-09-26 Thread Boris Zbarsky
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: Web IDL Garden Hose

2009-09-27 Thread Boris Zbarsky
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

Re: Web IDL Garden Hose

2009-09-27 Thread Boris Zbarsky
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

[WebIDL] Trying to understand IndexGetter/NameGetter

2009-09-30 Thread Boris Zbarsky
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

  1   2   3   4   5   6   7   8   >