On 10/27/10 3:21 AM, Darin Fisher wrote:
I have no problem with hinting to the implementor that the result is
expected to be used as a Blob so they can optimistically store it to
disk. My problem is with then making it impossible to get it as a
string if needed later (which
On 10/27/10 3:24 AM, Darin Fisher wrote:
So, it sounds like we just need to present you with some concrete
examples of XHRs being used to fetch large responses as Text or XML, and
then you will be convinced?
Uh... no. I'm sure these happen. The question is whether their
existence is
On 10/27/10 3:40 AM, Boris Zbarsky wrote:
On 10/27/10 3:24 AM, Darin Fisher wrote:
So, it sounds like we just need to present you with some concrete
examples of XHRs being used to fetch large responses as Text or XML, and
then you will be convinced?
Uh... no. I'm sure these happen
On 10/27/10 5:54 AM, Anne van Kesteren wrote:
Okay, so even for responseBlob you think it should be the implementor
handling the complexity.
I think we should at least seriously consider that, yes.
I realize the webkit folks will disagree en masse. ;)
Would be good to hear what others
On 10/27/10 7:12 AM, Keean Schupke wrote:
Actually the problem with this is the internal memory usage by the
browser to have a single page with 5000 divs in a list, each of which
has a layout with say 20 elements, so about 100,000 elements. The memory
used by the browser for the DOM tree
In
On 10/27/10 2:56 PM, Geoffrey Garen wrote:
Quietly providing multiple copies of data creates a subtle memory use problem.
Yes, agreed.
Explicitly throwing an exception at the site that tries to access the data in
the wrong way obviously and immediately points a finger at the problem.
Sort
On 10/27/10 3:23 PM, Michael Nordman wrote:
Darin mentioned it earlier in this thread, having XHR return the raw
data and providing other interfaces to interpret/decode the raw data
into strings/xmlDocs. I like that decomposition.
If we were designing from scratch, yes.
Or is the proposal
On 10/27/10 3:46 PM, Michael Nordman wrote:
Note, by the way, that for XML and HTML types, one is required (per
current XHR spec) to instantiate an XML or HTML parser,
respectively, to produce the responseText (because the data can
declare its own encoding in things like meta
On 10/27/10 6:14 PM, Geoffrey Garen wrote:
But, now clarified, your objection is about a much more minor case than
originally specified: In the case of an intervening layer that not only wraps
an XHR but also reads its data behind the scenes
Which is all of them that I've seen. I haven't
On 10/26/10 5:03 AM, Keean Schupke wrote:
Backend? Frontend? Are you suggesting that IndexedDB could be
implemented on top of an SQL database?
Firefox implements IndexedDB on top of SQLite.
q2 = q1.restrict(rdb.eq(function(row) {row[myColumn] == myValue}));
...
select * from myTable where
On 10/26/10 5:27 AM, Anne van Kesteren wrote:
Boris, do you see value in the asBlob / responseBlob proposal currently
in the draft?
The idea there being that you don't have to have the data in memory at
all unless the page explicitly asks for it, and then giving the page the
option of only
On 10/26/10 6:39 PM, Chris Rogers wrote:
Alexey and James Robinson from Google have experienced noticeable
performance-related issues with keeping two copies.
OK, what sort? And again, was the problem with keeping both in
perpetuity, or with having both live at any point in time?
Mobile
On 10/26/10 7:55 PM, Chris Marrin wrote:
Hmm... But will people still be accessing .responseText on those? And if so,
wouldn't they be broken by the proposals so far in this thread?
Probably not. But you'd either need to convert data from the raw form to the
desired form on every call to
On 10/25/10 6:42 PM, Alexey Proskuryakov wrote:
That may become more common when people start downloading arbitrary files, and
storing them to disk with FileWriter. But even years ago, we've been getting
performance bugs forcing us to ensure responseText didn't have to be copied for
On 10/25/10 7:05 PM, Chris Marrin wrote:
I don't think we can say that. responseArrayBuffer is going to enable new uses
of XHR. Floating point arrays for 3D mesh animation can easily get into the
multi-megabyte range.
Hmm... But will people still be accessing .responseText on those? And
On 10/25/10 7:07 PM, Jeremy Orlow wrote:
Can you think of any use cases where a developer would need both though?
Most any use case where there are multiple developers involved (page +
library, multiple people working on scripts in the page, whatever) and
some want the bytes and others
On 10/18/10 8:51 PM, Erik Arvidsson wrote:
When DOM was first spec'ed the collection interfaces all had some kind
of item method. These methods sometimes return like null[1] and
sometimes other values such as an empty string [2]. The JavaScript
bindings for these allows us to use indexed getters
On 10/18/10 9:34 PM, Garrett Smith wrote:
\.item\(\d+\s*\)\s*===\s*null lang:javascript
Doesn't catch cases when the argument to item is not a numeric constant,
most simply.
-Boris
On 10/4/10 7:09 AM, lmarce...@foi.hr wrote:
* read local files,
* show them in web documents, and
* manipulate them
FileAPI does the first thing, and partly the third one. The problem is
that it, as I understand it, loads the complete file into memory
(readAsBinaryString) which is
On 9/28/10 8:09 AM, Anne van Kesteren wrote:
On Tue, 28 Sep 2010 03:22:13 +0200, Michael Nordman
micha...@google.com wrote:
A couple of us have been looking at webkit's XHR impl and realized
that to support performant access to the response via
responseArrayBuffer and
responseText would cause
On 9/28/10 9:25 AM, Anne van Kesteren wrote:
On Tue, 28 Sep 2010 14:37:30 +0200, Boris Zbarsky bzbar...@mit.edu wrote:
I'm not sure. But you could just lazily construct the data based on what
the author requests. If there are no use cases it is unlikely they will
use both.
You can't lazily
On 9/28/10 10:32 AM, Chris Marrin wrote:
I'd hate the idea of another flag in XHR. Why not just keep the raw bits and
then convert when responseText is called? The only disadvantage of this is when
the author makes multiple calls to responseText and I would not think that is a
very common use
On 9/20/10 1:02 AM, Adam Barth wrote:
I've updated the document:
https://docs.google.com/document/edit?id=1r_VTFKApVOaNIkocrg0z-t7lZgzisTuGTXkdzAk4gLUhl=en#
General comments based on a quick read (and ignoring various typos that
I figure we'll fix in due course):
1) The reference chain
On 9/16/10 12:51 AM, Adam Barth wrote:
If you're interested in this topic, I'd encourage you to share your
perspective with the httpbis working group.
I'm not sure there's anything else to share, actually. Sounds like
things are well in hand here.
-Boris
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,
On 9/15/10 1:10 AM, Julian Reschke wrote:
Yes. However, I was only 50% joking. Are we sure that XHR should behave
the same?
Why should it behave differently from every single other HTTP request
the browser makes? That seems like adding complexity for the sake of
complexity...
-Boris
On 9/15/10 1:37 AM, Julian Reschke wrote:
What browsers do today is a bug per spec.
Well, yes, but they implemented it that way as a specific workaround for
broken servers, no?
Use cases for XHR are not identical to surfing web pages. There are
protocols/implementations that expect method
On 9/15/10 2:40 AM, Julian Reschke wrote:
Well, yes, but they implemented it that way as a specific workaround for
broken servers, no?
I'm not sure about that.
Hmm, fair. I just looked up the history of this code in Gecko, and the
best I can give you is
On 9/15/10 2:47 AM, Boris Zbarsky wrote:
So it's possible that the original behavior was just an oversight that
then got copied. Someone with access to a browser version control system
from before 1998 would need to look to make sure...
It's also possible that no UA implementor was willing
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 animg/?
That would be a security hole, sorry.
I understand there are good security reasons for restricting file
reads; you
On 9/3/10 1:37 PM, Anne van Kesteren wrote:
On Fri, 03 Sep 2010 19:24:03 +0200, Jonas Sicking jo...@sicking.cc 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
On 9/3/10 1:48 PM, Anne van Kesteren wrote:
On Fri, 03 Sep 2010 19:45:00 +0200, Boris Zbarsky bzbar...@mit.edu 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
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
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
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
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
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?
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
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
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
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
windows
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
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
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
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
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
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 bytes) be
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
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?
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
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
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
own
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
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 string,
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
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
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
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
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
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
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
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
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
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
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. ;)
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
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
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
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
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
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?
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
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
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,
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
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
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
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
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
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
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
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
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
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:
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
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
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 -
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
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
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
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
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
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
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
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.
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
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
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
Jonas Sicking wrote:
So do I, and most likely the rest of mozilla.
Seconded.
-Boris
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*
601 - 700 of 759 matches
Mail list logo
