On 10/18/11 5:01 PM, Brian Kardell wrote:
This too has come up in some discussions on CSS (CSSOM I think) that I
have had. In the right context - I don't think it would actually be
that hard. It would require a way to provide a sand-boxed evaluation
(read only elements)
This is not that
On 10/18/11 5:23 PM, Brian Kardell wrote:
This is not that easy. Especially because you can reach all DOM objects
from elements, so you have to lock down the entire API somehow.
Right, you would need essentially, to pass in a node list which
iterated 'lite' read-only elements.
So the script
On 10/18/11 5:23 PM, Brian Kardell wrote:
This is not that easy. Especially because you can reach all DOM objects
from elements, so you have to lock down the entire API somehow.
Right, you would need essentially, to pass in a node list which
iterated 'lite' read-only elements.
So the script
On 10/18/11 6:05 PM, Brian Kardell wrote:
They would run in their own sandbox and they would have access to the
parameters passed into the function by way of pattern.
OK; I think that people might have a pretty tough time with a
programming environment like that... but maybe.
The 'match'
On 10/18/11 7:38 PM, Alex Russell wrote:
The resolution I think is most natural is to split on ,
That fails with :any, with the expanded :not syntax, on attr selectors, etc.
You can split on ',' while observing proper paren and quote nesting, but
that can get pretty complicated.
A minor
On 10/18/11 8:08 PM, Alex Russell wrote:
The other excuse is that adding special cases (which is what you're asking
for) slows down all the non-special-case codepaths. That may be fine for
_your_ usage of querySelectorAll, where you use it with a particular limited
set of selectors, but it's
On 10/19/11 4:22 AM, Alex Russell wrote:
Yehuda is representing jQuery. I'll take his opinion as the global
view unless he choses to say he's representing a personal opinion.
Global jQuery view, yes? I stand by a slightly statement that what is
common and needs to be fast for Yehuda may not
On 10/19/11 4:29 AM, Anne van Kesteren wrote:
On Wed, 19 Oct 2011 17:22:46 +0900, Alex Russell
slightly...@google.com wrote:
Yehuda is representing jQuery. I'll take his opinion as the global
view unless he choses to say he's representing a personal opinion.
You misunderstand. Boris is
On 10/19/11 11:17 AM, Boris Zbarsky wrote:
4) Mapping Sizzle(#id) with document a context to
getElementById(id). This isn't a valid optimization for querySelector
because there can be multiple elements with the same id;
And just as a note, since someone asked me off-list how this can
possibly
On 10/19/11 10:07 PM, Jonas Sicking wrote:
I like the general idea here. And since we're changing behavior, I
think it's a good opportunity to come up with shorter names. Naming is
really hard. The shorter names we use, the more likely it is that
we're going to break webpages which are messing
On 10/20/11 6:50 AM, Alex Russell wrote:
Oh, and as a separate issue. I think .findAll should return a plain
old JS Array. Not a NodeList or any other type of host object.
I strongly agree that it should be an Array *type*, but I think just
returning a plain Array is the wrong resolution to
On 10/20/11 7:18 AM, Alex Russell wrote:
No we don't. The fact that there's someone else who has a handle to
the list and can mutate it underneath you
There is no sane way to mutate the list on the part of the browser if
someone else is also messing with it, because the someone else can
On 10/20/11 10:23 AM, Alex Russell wrote:
On Thu, Oct 20, 2011 at 3:14 PM, Boris Zbarskybzbar...@mit.edu wrote:
Right. So you need to vend an apparently-immutable Array, one which
can only be changed by the browser. I think that could be accomplished
in terms of Proxies. But it's still an Array
On 10/20/11 12:02 PM, Erik Arvidsson wrote:
That is an ES violation. A non configurable, non writable data
property is not allowed to change its value.
It's not clear what that means in proxy-land; esp. since it's not clear
whether proxies can even have non-configurable properties... or did
On 10/20/11 4:32 PM, Tab Atkins Jr. wrote:
I don't really see the performance issues. If you use + or ~ off of
:scope, you know for a fact that all the nodes come *after* any
selectors that don't have :scope.
Yes.
1. Run the :scope-carrying selectors across the document together,
On 10/20/11 5:15 PM, Tab Atkins Jr. wrote:
If they *all* carry :scope, then you can just run them all over the
whole tree and get the ordered set in the normal fashion.
You can just prepend :scope to the ones missing it and run them over the
whole tree too.
But that means that now you're
On 10/21/11 11:28 AM, João Eiras wrote:
On Thu, 20 Oct 2011 16:39:56 +0200, Igor Oliveira
igor.olive...@openbossa.org wrote:
Hello,
Currently CSSMatrix and SVGMatrix has an immutable API. None of the
method calls change the Matrix, instead, it creates a new Matrix with
the changed value. It
On 10/31/11 1:42 PM, Charles Pritchard wrote:
I'm almost certain that somewhere, it is specified that the browser
should sniff the first few bytes of the file to see
if it is compressed.
I don't believe it is. In fact, doing that would contradict the specs
as they stand, to my knowledge.
I
On 10/31/11 7:25 PM, Alex Russell wrote:
For JS, it just means having a working .length property (in all the
ways that Arrays allow it to be used). Arrays are identical to other
objects in all other respects.
No, they're not. For example, off the top of my head, they get
serialized
On 10/31/11 9:32 PM, Charles Pritchard wrote:
Structured cloning fails for NodeList, same as postMessage, because of
circular structure.
What circular structure? Structured clone can handle that.
It fails because it's a host object (based on its [[Class]]) that's not
whitelisted in the
All,
At this I've lost track of what the current proposals are on tag names
in the component model. I've been thinking about this a bit, and I
would like us to look at a particular use case: subclassing img and
adding some behavior to it.
An obvious question: Should the localName/tagName
On 11/8/11 10:32 AM, Dominic Cooney wrote:
There are two kinds of components—ones that are a refinement of
something in HTML, like a select element or a button; and ones that have
no genuine peer in HTML.
This is the litmus test: If you were writing this today, would you start
with a div or
On 11/11/11 10:05 PM, Jonas Sicking wrote:
In other words, the returned object is exactly what you'd get if you did:
a = new Array;
a.__proto__ = [some type].prototype;
[some type].prototype.__proto__ = Array.prototype;
For what it's worth, at least some JITs deoptimize |a| if you do that.
On 11/12/11 10:22 AM, Allen Wirfs-Brock wrote:
Note that the only specialness of Array instances relates to what happens when you add
new array elements or dynamically change the value of the length property.
1) In ES5 this is just not true; there are various parts of the spec
that check
On 11/13/11 6:10 AM, Allen Wirfs-Brock wrote:
Class related distinctions are covered in the document I reference:
https://docs.google.com/document/d/1sSUtri6joyOOh23nVDfMbs1wDS7iDMDUFVVeHeRdSIw/edit?authkey=CI-FopgC
and are generally secondary issues related to various library routines.
Yes,
On 11/13/11 8:51 AM, Allen Wirfs-Brock wrote:
It's relevant to this discussion because you have to decide what web developers
actually mean when they say Array.
Yes, agreed.
The most important point is that [[Class]] is neither the only nor the most
important distinguishing characteristic
On 11/19/11 12:52 AM, Julian Reschke wrote:
http://dev.w3.org/html5/workers/#importing-scripts-and-libraries says.
For what it's worth, Gecko's worker loading code runs the same algorithm
to determine the charset as the algorithm used for script src (except
of course it does not have access
What's the current state of matchesSelector? Are we confident enough in
the name and such to unprefix it?
-Boris
On 11/21/11 10:56 AM, Tab Atkins Jr. wrote:
On Mon, Nov 21, 2011 at 7:22 AM, Boris Zbarskybzbar...@mit.edu wrote:
What's the current state of matchesSelector? Are we confident enough in the
name and such to unprefix it?
I think that matchesSelector suffers from the same verbosity that qSA
On 11/21/11 11:31 AM, Tab Atkins Jr. wrote:
1) Make sense.
2) Not break existing content.
3) Be short.
.matches
.is
The sticking point here is obviously item #2. Data needed on use of
matches and is as barewords in on* attributes, specifically.
-Boris
On 11/21/11 8:31 PM, Aryeh Gregor wrote:
The lookup chain is first document
then window, with no elements anywhere, right?
The lookup order is the element the on* attribute is on, then the
element's form if it's a form control (more or less; details are in the
spec), then the document, then
On 11/21/11 9:58 PM, Ojan Vafai wrote:
I think this is the only sane solution to this problem. Lets split up
the Element interface. I'm not attached to these names, but something
like ElementExposed and Element. Element inherits (mixins?)
ElementExposed and only the methods on ElementExposed are
On 11/22/11 7:31 AM, Martin Kadlec (BS-Harou) wrote:
CSS: article div:nth-child(2) input[type=text], article div:nth-child(2)
input:not([type]), article div:nth-child(2) input[type=color];
XPath: //article/div[2]//input[@type='text' | @type='color'| not(@type)];
How about:
CSS:
article
On 11/22/11 8:05 AM, Lachlan Hunt wrote:
The current draft of Selectors 4 includes :matches(), though, which can
partially handle that case, excluding :not([type]), which would have to
be left separate.
That seems like a bug in :matches() that just needs fixing if it's meant
as a replacement
On 11/22/11 6:50 AM, Lachlan Hunt wrote:
Last time we had this discussion, you had a desire to keep the name
prefixed until the refNodes and :scope stuff was implemented [1]. What's
the status on that now?
The status is that I've given up on the :scope discussion reaching a
conclusion in
On 11/22/11 12:29 PM, Robin Berjon wrote:
d - //div[parent::*//a];
(d) can be done with the new subject indicator in the Selectors 4
draft: a! div (syntax pending, but that's the general idea)
I think that the example you show selects thea parent of adiv, notdivs that
have parents
On 11/22/11 12:57 PM, Ojan Vafai wrote:
The fewer properties that are exposed this way, the smaller the quirk
is.
I think the problem is that from web developers point of view the quirky
behavior is _not_ exposing properties. Certainly in the short term...
In the long term, since we have
On 11/23/11 10:03 AM, Aryeh Gregor wrote:
Can't browsers add instrumentation for this? You have users who have
opted in to sending anonymized data. So for each user, on a small
percentage of pages, intercept all bare-name property accesses in on*.
With enough work, this is possible. It'd
On 11/23/11 5:38 PM, Sean Hogan wrote:
- If you want to use selectors with :scope implied at the start of each
selector in the selector list (as most js libs currently do) then you
use find / findAll / matches.
I'm not sure that for matches() the :scope thing is all that relevant.
:matches()
On 12/3/11 7:55 PM, Benson Margulies wrote:
7.2.2 says that if the response is * and credentials are off, we
fail.
The text I'm looking at right now is:
If the Access-Control-Allow-Origin header value is the literal *
character and the credentials flag is false return pass and terminate
On 12/11/11 7:21 AM, Anne van Kesteren wrote:
The DOM specifications probably need to move back to using interface
rather than sequence. I was hoping sequence would define the whole
collection thing magically, but it never turned out that way. Still not
quite sure what the real use case is for
John Jensen here at Mozilla has been doing some web crawling trying to
find what barewords are used in on* attributes.
What I have so far as a result is a list of about 1.7 million barewords
used across several tens of thousands of pages. If people are
interested in the exact methodology, I
On 12/14/11 3:01 AM, Simon Pieters wrote:
What I have so far as a result is a list of about 1.7 million
barewords used across several tens of thousands of pages.
Do you have a more accurate figure for the number of pages?
57,444 unique urls, all taken from the top 21,000 domains is all the
On 12/14/11 3:54 AM, Ryosuke Niwa wrote:
This is great! Thanks for doing this. Can we also get stats. on new Node
methods like append, remove, etc...?
There seem to be no hits on append in the data I have so far.
remove is used on a bunch of pages on fdc.soufun.com but nowhere else
in this
On 12/14/11 3:15 AM, Boris Zbarsky wrote:
Yeah, understood. Working on getting that description.
Ok. It's just a simple spider that starts with the list at
http://code.google.com/p/httparchive/source/browse/trunk/lists/All.txt
and for each of those urls loads the url itself and then follows
On 12/14/11 5:41 PM, Jonas Sicking wrote:
This doesn't really tell us weather access to expandos on the
element/form is strictly needed or not, right?
Yes. The data I have does nothing to address that question
-Boris
On 12/14/11 7:55 PM, Ian Hickson wrote:
Browsers do keep them around for the lifetime of the page, in their HTTP
cache.
Browsers limit the size of the HTTP cache and evict as needed.
-Boris
On 12/14/11 4:52 PM, Boris Zbarsky wrote:
Ok. It's just a simple spider that starts with the list at
http://code.google.com/p/httparchive/source/browse/trunk/lists/All.txt
and for each of those urls loads the url itself and then follows all
same-host links from that page. So loads the front page
On 12/21/11 9:43 PM, Benson Margulies wrote:
I just made a small discovery;
Chrome 16 sends, e.g.
Access-Control-Request-Headers: Content-Type
Firefox 8.0 sends, contrastively:
Access-Control-Request-Headers: content-type
Given the requirement for case-sensitive comparison in the spec
On 12/21/11 11:28 PM, Jarred Nicholls wrote:
I'll try this again...
The spec makes it very succinct in its preflight request steps that
Access-Control-Request-Method should be sent, always. However in WebKit
and Firefox I'm observing this header only being sent when there are
author request
On 12/22/11 6:17 AM, Benson Margulies wrote:
Jarred, along the lines of my question of 'what is a user header',
what spec would one read to learn that lower-casing was correct? I
looked for it and did not find it in the CORS draft.
It's in both
On 1/6/12 11:20 AM, Glenn Maynard wrote:
Accepting content that other browsers don't will result in pages being
created that work only in WebKit. That gives the least
interoperability, not the most.
I assume Jarred was talking about interoperability with content, not
with other browsers.
On 1/6/12 12:13 PM, Jarred Nicholls wrote:
WebKit is used in many walled garden environments, so we consider these
scenarios, but as a secondary goal to our primary goal of being a
standards compliant browser engine. The point being, there will always
be content that's created solely for
On 1/11/12 11:41 AM, Aryeh Gregor wrote:
Also, while I'm at it, how about collapsing at
(document.documentElement, 0) instead of (document, 0)?
Then you have to handle the case when document.documentElement is null.
And yes, this has come up before; there are scripts out there that
remove
On 1/11/12 6:03 PM, Charles Pritchard wrote:
Is there any instance in practice where DOMString as exposed to the
scripting environment is not implemented as a unicode string?
I don't know what you mean by that.
The point is, it's trivial to construct JS strings that contain
arbitrary
On 1/13/12 2:37 AM, Simon Pieters wrote:
HTML uses this concept in lots of places, e.g.
http://www.whatwg.org/specs/web-apps/current-work/#cookie-free-document-object
A Document that has no browsing context.
Ah, that's better than using defaultView (because behavior for
defaultView on
On 1/13/12 12:18 PM, Aryeh Gregor wrote:
Actually, defaultView is defined to return the Document's browsing
context's WindowProxy object, if it has one, and null otherwise.
Hmm. I guess the spec doesn't really define what happens to the
association between a document and its browsing context
On 1/17/12 4:55 PM, Ian Hickson wrote:
On Fri, 13 Jan 2012, Boris Zbarsky wrote:
On 1/13/12 2:37 AM, Simon Pieters wrote:
HTML uses this concept in lots of places, e.g.
http://www.whatwg.org/specs/web-apps/current-work/#cookie-free-document-object
A Document that has no browsing context.
Ah
On 1/24/12 8:58 PM, Glenn Adams wrote:
2012/1/24 Ojan Vafai o...@chromium.org mailto:o...@chromium.org
Can we just compromise on the language here? I don't think we'll
find agreement on the proper way to do spec work.
How about: DOM2 is no longer updated. DOM4 is the latest
On 1/30/12 11:15 AM, Bronislav Klučka wrote:
In this case you got me... what sense does it make? If there is no
reference to original blob or any other object using that URL, why is it
kept?
Because given a string there is no way to tell whether someone has a
reference it.
Consider this:
On 2/1/12 2:39 PM, Charles Pritchard wrote:
Mozilla said they were getting rid of their enable privilege API. I
don't know that they have.
It's being removed, slowly. For example, cross-site XHR (modulo
whatever CORS allows) is no longer possible even if you enablePrivilege
in current
On 2/1/12 2:41 PM, Paul Libbrecht wrote:
Android goes somewhat in this direction with its app-security model...
With all due respect, the app-security model on Android is a joke.
Everyone just clicks through the permissions grant without even reading
what's being requested, because _every_
On 2/1/12 3:02 PM, Charles Pritchard wrote:
On 2/1/12 11:57 AM, Boris Zbarsky wrote:
On 2/1/12 2:39 PM, Charles Pritchard wrote:
Mozilla said they were getting rid of their enable privilege API. I
don't know that they have.
It's being removed, slowly. For example, cross-site XHR (modulo
On 2/3/12 8:52 PM, Kang-Hao (Kenny) Lu wrote:
# Unexpected end of style sheet. User agents must close all open
# constructs (for example: blocks, parentheses, brackets, rules,
# strings, and comments) at the end of the style sheet. For example:
...
IE9, FF9.0.1, Opera12alpha don't
On 2/4/12 10:58 AM, Kang-Hao (Kenny) Lu wrote:
Are there more inconsistency between Selectors4 and Selectors API 2?
Given that Selectors API wants to allow strings that aren't valid
selectors at all (like foo, say), I'd think so.
-Boris
On 2/7/12 2:41 PM, Dimitri Glazkov wrote:
div class=overflow
script event=click
// this is the parent div element.
// event is the current event object.
if (event.target.className != 'more')
return;
if (this.moreOpened)
On 2/7/12 3:25 PM, Dimitri Glazkov wrote:
Oh, likescript scoped or something?
No opinions on the syntax, or even on whether the element should be
called script.
this.onclick = function() { }
I think. The only thing the UA would have to do there is syntax-check the
function, which
On 2/9/12 12:04 PM, John J Barton wrote:
As far as I can tell, a cross-domain iframe contentWindow has only one
valid property, postMessage(). By no stretch of anyone's imagination
is the object a window. Calling this thing we get a contentWindow
is a mean lie to developers; it forces us into
On 2/9/12 12:43 PM, John J Barton wrote:
The drawback is that your fallback behavior in UAs without support for the
new feature is quite different. Is that a problem? Developer feedback
definitely needed there.
Extending the API on iframe would make fallback easy even though it
lacks
On 2/9/12 1:15 PM, John J Barton wrote:
This leads developers to look for events that will tell them about
'load' on iframes, and that leads them to try
iframe.contentWindow.addEventListener(). It works fine for same-domain
iframes, but fails for cross-domain.
Adding a load listener to the
On 2/14/12 2:52 PM, Glenn Maynard wrote:
I don't think this:
function() {
f1();
yieldUntil(condition);
f2();
}
is any more racy than this:
function() {
f1();
waitForCondition(function() {
f2();
});
}
Let's say the function above is called f, and
On 3/20/12 2:58 PM, Ojan Vafai wrote:
With my web developer hat on, I would expect the WebKit/IE behavior.
Keypress is fired before the DOM is modified (I tested in Gecko and
WebKit on an input element). As such, I'd expect focus changed during a
keypress event to change where the text is
On 3/20/12 10:38 PM, Bronislav Klučka wrote:
Hello,
Why there are 2 similar functionalities for selector matching?
Because you're reading two versions of the same spec and the spec
changed sometime between those versions.
http://dev.w3.org/2006/webapi/selectors-api2/#matches
boolean
The spec says:
Return the HTTP status text.
But the HTTP status text is a sequence of bytes, while the return value
for statusText is a DOMString. The conversion from one to the other
needs to be defined.
-Boris
On 3/27/12 2:46 PM, Glenn Adams wrote:
Is this really a problem?
Yes. We've run into bug reports in the past of sites sending some
pretty random bytes in the HTTP status text, then reading .statusText
from script. If we want interop here, we need to define the conversion.
HTTP defines
On 3/27/12 3:35 PM, Glenn Adams wrote:
The TEXT rule is only used for descriptive field contents and values
that are not intended to be interpreted by the message parser. Words
of *TEXT MAY contain characters from character sets other than ISO-
8859-1 [22] only when encoded
On 3/27/12 3:36 PM, Boris Zbarsky wrote:
On 3/27/12 3:35 PM, Glenn Adams wrote:
The TEXT rule is only used for descriptive field contents and values
that are not intended to be interpreted by the message parser. Words
of *TEXT MAY contain characters from character sets other than ISO-
8859-1
On 3/27/12 4:00 PM, Glenn Adams wrote:
Since there are so may places in XHR, HTML5, etc., that interact with
HTTP semantics, it would be better to define this in one place for all
uses
Sounds good to me. It just needs to be defined (and the definition
linked to from the statusText
On 3/28/12 1:33 AM, Anne van Kesteren wrote:
On Tue, 27 Mar 2012 22:23:15 +0100, Boris Zbarsky bzbar...@mit.edu wrote:
But the HTTP status text is a sequence of bytes, while the return
value for statusText is a DOMString. The conversion from one to the
other needs to be defined.
Would using
On 3/28/12 2:48 AM, Anne van Kesteren wrote:
Wow, inflating is what the specification currently requires for header
fields, for what it's worth.
Yes, Gecko has different behavior here for the status text and for
header fields. I have no idea whether that's on purpose; I suspect it's
mostly
On 3/28/12 10:42 AM, Glenn Adams wrote:
Any use of DOMString to serve as a holder for arbitrary binary data
(including inflating from UTF-8 bytes into 16-bit code units), should be
specifically marked as such.
For what it's worth, I would be reasonably happy if we had a
non-DOMString IDL type
As far as I can tell, the WebIDL specification doesn't define anything
about what really happens when a constructor is invoked, once the
arguments have been converted to the IDL types, except the conversion of
the return value from an IDL type to an ES type. It defers the exact
behavior of
On 3/30/12 9:22 PM, Brendan Eich wrote:
See the [[Scope]] internal property of function objects from ECMA-262
13.2, 10.4.3, etc.
Nothing in WebIDL or XHR says to use [[Scope]]. If it did, that would
constitute a definition of the behavior, yes.
-Boris
On 3/31/12 2:15 AM, Cameron McCormack wrote:
Boris Zbarsky:
What's the document associated with xhr? Is it w1.document,
w2.document, or window.document? The concept the Window object for
which the XMLHttpRequest interface object was created doesn't seem to
be defined anywhere
I don't have
On 4/2/12 12:58 AM, Simon Pieters wrote:
I believe some things in the HTML spec uses the entry script, at least
for the purpose of choosing origin or base URL. For instance: WebSocket,
Worker.
Yes, but what do they use for the origin of the Worker object itself?
I.e. if you create one and
On 4/2/12 1:33 AM, Simon Pieters wrote:
Yes, but what do they use for the origin of the Worker object itself?
Run a worker for the resulting absolute URL, with the script's browsing
context of the script that invoked the method as the owner browsing
context, with the script's document of the
On 4/2/12 2:50 AM, Simon Pieters wrote:
I can find:
User agents must throw a SecurityError exception whenever any
properties of a Document object are accessed by scripts whose effective
script origin is not the same as the Document's effective script origin.
On 4/2/12 5:54 PM, Ian Hickson wrote:
My understanding is that security checks are only done for members of
Document and Window objects.
That understanding certainly isn't correct as stated. For example,
security checks are done on at least some members of Location objects
(e.g. you can
And just to be clear, the discussion about security and document.domain
is somewhat orthogonal to the original issue. WebIDL requires that all
objects be associated with a particular global and that any spec
defining anything that creates an object needs to define how this
association is set
On 4/2/12 6:15 PM, Ian Hickson wrote:
Interesting. When speccing this stuff years ago, I do not recall coming
across any browser other than Opera that had any security checks on
objects other than the few that the spec talks about.
For what it's worth, I believe Gecko does the checks today
On 4/2/12 6:46 PM, Cameron McCormack wrote:
Boris Zbarsky:
And just to be clear, the discussion about security and document.domain
is somewhat orthogonal to the original issue. WebIDL requires that all
objects be associated with a particular global and that any spec
defining anything
On 4/10/12 3:35 PM, Alan Stearns wrote:
What is this group's API preference for a set of objects identified by
name?
The real question is what the use cases are, no? The NamedFlowMap
approach doesn't provide a good way to enumerate the named flows; if
that's a use case that needs
On 4/10/12 4:13 PM, Tab Atkins Jr. wrote:
According to current WebIDL spec, an object with a named property
getter exposes the list of names as own properties, so you can get
them with for-in enumeration.
1) for-in enumeration enumerates prototype properties.
2) for-in enumeration enumerates
On 4/10/12 4:23 PM, Tab Atkins Jr. wrote:
On Tue, Apr 10, 2012 at 1:16 PM, Boris Zbarskybzbar...@mit.edu wrote:
On 4/10/12 4:13 PM, Tab Atkins Jr. wrote:
According to current WebIDL spec, an object with a named property
getter exposes the list of names as own properties, so you can get
them
On 4/10/12 5:05 PM, Tab Atkins Jr. wrote:
Agreed, but ES6 is making this easier with Object.keys() and for-of iteration.
Sort of. for-of doesn't necessarily work on this stuff, as I understand.
(Off the top of my head, I can't come up with a use-case for
enumerating all flows in a page
On 4/11/12 6:57 AM, Jonas Sicking wrote:
open(DOMString method, DOMString url, optional boolean async, optional
DOMString? user, optional DOMString? password);
This means that if anything other than null is passed as value for the
user/password arguments, then the value should be stringified
On 4/11/12 12:26 PM, Boris Zbarsky wrote:
On 4/11/12 6:57 AM, Jonas Sicking wrote:
open(DOMString method, DOMString url, optional boolean async, optional
DOMString? user, optional DOMString? password);
This means that if anything other than null is passed as value for the
user/password
On 4/11/12 3:01 AM, Anne van Kesteren wrote:
How about
send(optional (ArrayBuffer or Blob or Document or DOMString or
FormData)? data = null)
I think that should be fine too, yes. I don't have a strong preference
for that over the overload version or vice versa.
-Boris
Seems like right now passing a typed array to send() requires a bit of
extra hoop-jumping to pass the .buffer instead, right? Is that desirable?
-Boris
On 4/11/12 2:53 PM, Charles Pritchard wrote:
Yes; .buffer has stable semantics across many apis.
Like what?
It does feel awkward when first using it, but the design makes sense after some
experience.
My point is that we can have overloads taking both ArrayBuffer and
ArrayBufferView. Is
301 - 400 of 759 matches
Mail list logo
