On 3/13/13 11:14 AM, Anne van Kesteren wrote:
However, if all data is typically available during state 3, developers
might rely on that. Not queuing a special task that triggers state 3
for data: URLs does not preclude asynchronous loading at all.
I'm not sure I follow.
State 3 is LOADING.
On 3/13/13 11:36 AM, Anne van Kesteren wrote:
On Wed, Mar 13, 2013 at 3:32 PM, Boris Zbarsky bzbar...@mit.edu wrote:
What exact behavior are you proposing for the XHR implementation when it
gets the callbacks described above? It sure sounds to me like you're
presupposing that the some data
On 3/13/13 4:02 PM, Julian Reschke wrote:
On 2013-03-13 18:38, pocci...@gmail.com wrote:
jar:http://example.com/jar?x=1!/com/example/Foo.class
is parsed in the URI standards as:
scheme - jar
scheme-specific part - http://example.com/jar?x=1!/com/example/Foo.class
I have no idea what you're
On 3/13/13 4:23 PM, Julian Reschke wrote:
Under RFC 3986, it would resolve to
jar:http://example.com/Bar.class
If you assume that this is a hierarchical scheme and that the hierarchy
is in some particular place, no? Why is that assumption being made?
Looks like a broken scheme to me.
On 3/13/13 4:43 PM, Bjoern Hoehrmann wrote:
Turning relative references into absolute ones is a generic operation
that works the same for all schemes, as far as RFC 1808 (published in
1995) and its successors are concerned.
Yes, I realize that. The point is that these RFCs don't match
On 3/14/13 4:12 AM, Julian Reschke wrote:
Is it used outside Java applet scenarios?
It's certainly used all over in Firefox chrome.
BTW: this shows why formal registration and review of URI schemes is a
*feature*.
Indeed.
-Boris
On 3/14/13 10:34 AM, Stephen White wrote:
can we create a
interface Canvas2DContextAttributes {
attribute boolean alpha;
}
which has no relation to WebGLContextAttributes?
Yes.
Then we get at least the duck typing such that
ctx = canvas.getContext('2d', {alpha: false });
and
ctx =
On 3/18/13 5:31 AM, Markus Ernst wrote:
- Opera and Safari hide it when the field gets focus
The behavior of Safari here is platform-dependent or possibly
version-dependent. Safari 6 on Mac doesn't hide the placeholder until
you start typing.
...when the element's value is the empty
On 3/19/13 11:18 AM, Brian Kardell wrote:
Section 4.2.4 of the HTML Standard[1] contains a note:
Note: If the rel attribute is used, the element is restricted to the
head element. When used with the itemprop attribute, the element can
be used both in the head element and in the body of the page,
On 3/20/13 6:27 AM, Benjamin Stürmer wrote:
I've been thinking about this exact thing for the last few weeks,
because I have a use case in which it would be beneficial to use an
in-body link to include CSS files, especially if link could be
updated to support the scoped attribute with the same
The spec for document.referrer says:
The referrer attribute must return the document's referrer.
The document's referrer is not really defined anywhere in a useful way
that I can find.
This then follows with a non-normative note:
Note: In the case of HTTP, the referrer IDL attribute
On 3/21/13 2:22 PM, Ian Hickson wrote:
On Wed, 20 Mar 2013, Boris Zbarsky wrote:
The document's referrer is not really defined anywhere in a useful way
that I can find.
Yikes, I apparently forgot to fill that in. Sorry about that. Try now.
Much better, thanks. I haven't dug through
On 3/21/13 7:01 AM, Anne van Kesteren wrote:
On Wed, Mar 20, 2013 at 10:46 PM, Boris Zbarsky bzbar...@mit.edu wrote:
My ongoing assumption has been that we want to serialize to punycode
always in the API
Hmm. That _does_ suck if you want to show location stuff to the user,
though
On 3/21/13 2:40 PM, Anne van Kesteren wrote:
You mean the decision as to when exactly to use the Unicode and when to use
ACE? In what way is it a UI decision (apart from browser URL bars having
anti-phishing logic that falls back to ACE when they detect weird chars in
the URI)?
E.g. Chrome
The way iframe srcdoc is defined, the document URI does not in any way
encode the document contents.
Unfortunately, that breaks user-agent and extension features like open
frame in new window, show only this frame, open frame in new tab, etc.
I just tried this in the two UAs I have that
On 4/5/13 1:15 AM, Tab Atkins Jr. wrote:
Are you asking to switch back to data urls instead of srcdoc, or are
you asking for a way to generate an equivalent data url from the
contents?
I don't have a proposed solution so far. I just have a problem. The
problem is that UAs that implement
The session history algorithm in the spec navigates to urls. As far as
I can tell, on the face of it, this means that this testcase:
iframe name=x srcdoc=aaa/iframe
a target=x href=http://web.mit.edu;
Click me, then later hit back
/a
should fail to go back.
The good news is that at
On 4/5/13 11:52 AM, Robin Berjon wrote:
Is there any reason not to use a Blob URL for this
Would be fine by me, personally. Though note that the processing model
for srcdoc and blob is somewhat different (e.g. srcdoc documents are
always standards mode, though this is hacked in such that it
On 4/7/13 9:52 PM, Ian Hickson wrote:
The way iframe srcdoc is defined, the document URI does not in any way
encode the document contents.
This is the same as HTTP URLs where the server returns different content
each time
No, because browsers have these things called caches and are known to
On 4/8/13 1:20 AM, Ian Hickson wrote:
If a browser can cache the data for a frame based on which frame it is
rather than just its URL
In Gecko's case, say, it's cached based on URL and a sequence number (to
handle POST).
If it can be made to work for POST, I don't see why srcdoc= would be
On 4/8/13 6:57 PM, Ian Hickson wrote:
Why does the test I posted fail, then?
http://damowmow.com/playground/demos/ui/001.html
Right-click either frame, and make it display the frame elsewhere (new
tab, only-this-frame
Those don't do the right thing; they just use the URI.
even
On 4/10/13 2:12 AM, Simon Pieters wrote:
I'm not aware of such a list.
We should solve this problem. At this point we have some interface and
prototype objects that should only appear on Window, some that should
only appear in Workers and some that should appear both places I
wonder
On 4/19/13 9:51 AM, Justin Novosad wrote:
That sounds OK. However, I would find it unfortunate to re-specify the
behavior of the property in the canvas 2d context spec, when we could just
spec it like 'font' by saying that it is interpreted the same way as the
corresponding CSS property. I think
On 4/25/13 1:43 PM, Christian Biesinger wrote:
Where should the button be positioned relative to the input field (or
if you prefer, the baseline of the block)?
The question you are really asking is where is the baseline of the
button?, right?
Chrome dev, IE and Opera
put the bottom of the
On 4/25/13 1:58 PM, Christian Biesinger wrote:
Gecko puts the baseline of the button at the baseline of the button's text,
and if the button is not auto-height the extra height is added (or removed)
equally from above and below the text.
Hm, but I don't think that's completely correct, because
On 4/25/13 3:10 PM, Christian Biesinger wrote:
From the top of the content box? Maybe I'm using the term wrong - I
mean the border-box minus borders and padding, which is a slightly
different definition than you used above.
That's the content box, yes.
Ah, I see. It's not entirely clear to
On 4/29/13 6:50 AM, James Graham wrote:
So far we have kept the model where the load event is auomatically
managed by the UA, rather than giving the developer direct control of it.
Developers already have direct control over the load event to the extent
being proposed, as far as I can tell.
On 5/1/13 12:36 PM, Darin Adler wrote:
No, I believe this was already like this before srcset was added; you can see
that in the w3.org draft which does not have srcset.
Interesting. Certainly at the point when Gecko implemented the current
behavior I recall it matching the spec...
-Boris
On 5/3/13 7:07 PM, Christian Biesinger wrote:
fantasai pointed out that CSS does specify this:
If the box does not have a baseline, align the bottom margin edge
with the parent's baseline.
(http://www.w3.org/TR/CSS2/visudet.html#propdef-vertical-align)
Yes, but that _if_ the box does not have
On 5/7/13 5:54 PM, Gordon P. Hemsley wrote:
A @download attribute with a value would override both factors, like so:
(1) Download it.
(2) A.txt
Why?
You say this as if it were obvious, but it's not obvious to me at all...
What's the reasoning that makes this the desirable behavior?
I
On 5/8/13 6:53 AM, Gordon P. Hemsley wrote:
It's not clear to me which of the two factors you take issue with.
The question of which filename takes priority.
I interpret that first sentence to mean that the file should be
downloaded (disposition type = attachment) rather than displayed
On 5/8/13 10:45 AM, Gordon P. Hemsley wrote:
I still think @download takes priority.
The Content-Disposition header says, Nevermind what filename the URL
shows; this is really file B.txt.
The @download attribute says, Nevermind what filename this link would
normally be; let's just consider it
On 5/8/13 12:15 PM, Gordon P. Hemsley wrote:
Perhaps. But maybe I'm not clear on what exactly the alternate
proposal is. Are you suggesting not supporting the @download
attribute? Or just ignoring it when Content-Disposition specifies a
filename? (I would suggest that neither is the appropriate
On 5/8/13 12:37 PM, Gordon P. Hemsley wrote:
I understand now the motivation for this, but I would think that it
would remove a lot of the usefulness of the @download attribute
You're right, but we haven't found another mitigation for our security
concerns.
If you have the same origin, you
On 5/13/13 11:32 PM, Kyle Simpson wrote:
First: https://gist.github.com/getify/5130304
`requestEachAnimationFrame(..)` and `cancelEachAnimationFrame(..)`
This is the analog to `setInterval(..)`
which was explicitly considered and rejected when requestAnimationFrame
was designed, based on
On 5/21/13 6:31 AM, Marta Pawlowska wrote:
[PutForwards=value] readonly attribute
Note the PutForwards bit.
I've prepared TC where I change sandbox value and it can be changes with
most browsers.
Yes, because of the PutForwards.
Though note that at least Gecko implements this as a
On 5/21/13 9:12 AM, Marta Pawlowska wrote:
Do you know any place/list/ling where such a concept readonly +
PutForwards is described?
Sure. See http://dev.w3.org/2006/webapi/WebIDL/#PutForwards and
http://dev.w3.org/2006/webapi/WebIDL/#dfn-attribute-setter step 3 substep 6.
-Boris
On 5/23/13 5:48 AM, Matt Falkenhagen wrote:
1. For an inert element, what happens on element.click() or
element.dispatchEvent(new Event('click'))?
What would make the most sense to me is to have these work as normal but
for the node to not have any default activation behavior.
-Boris
On 5/29/13 12:55 AM, Brady Eidson wrote:
This expectation was always wrong: events can be dispatched by script at any
time to pages in the page cache.
I'm sorry, who's page cache are you talking about?
Gecko's, which initially defined the pagehide/pageshow events. ;)
Page caches are
On 5/29/13 2:25 PM, Brady Eidson wrote:
So what happens when script calls dispatchEvent on a node that's in a
document that's in your page cache?
I believe the design is “nothing.”
That's a spec violation, then: there are no provisions in any DOM spec
for dispatchEvent on an EventTarget not
On 5/29/13 4:27 PM, Brady Eidson wrote:
Does Mozilla have a test for this that I could explore in WebKit?
It's pretty trivial to create a testcase. Something simple like this:
test1.html:
div onclick=window.test2 = window.open('test2.html')Click me to open
a window, then follow the
On 5/29/13 4:30 PM, Brady Eidson wrote:
I see in the HTML spec that the step *before* firing pagehide is “set
the Document’s page showing flag to false,” but I can’t find language
that says pagehide fires *before* the page is actually hidden, and
unload fires *after* the page is actually hidden.
Let's actually back up a second.
What problem are you really trying to solve by changing the ordering?
As I see it, right now the situation is as follows (in implementations,
if not in the spec):
1) pagehide fires, with a boolean indicating whether at this point the
UA plans to place the
On 5/29/13 11:08 PM, Michael Day wrote:
For example, setting an attribute will create a property with the same
name as the attribute:
div = document.createElement(div);
div.setAttribute(foo, bar);
alert(div.attributes.foo); // [Object Attr]
The DOM spec as written right now
On 5/30/13 12:06 AM, Michael Day wrote:
This part still seems inconsistent with current browsers:
4) Setting a property name that is currently exposed does a Reject
(which means throw in strict mode, silently do nothing in
non-strict mode). Unless there is a named setter, of
On 5/30/13 12:41 PM, Brady Eidson wrote:
pageshow is a history traversal event, and not a visibility event. I
don’t see a guarantee in any spec that “pageshow” comes after the
document is actually visible.
It comes after it's visible in terms of document.visibilityState, for
pages not in
On 5/30/13 1:04 PM, Brady Eidson wrote:
Correct. Of course note that pages that have been placed in the page
cache that are evicted have no visibility that the eviction occurred (at
least in WebKit)
I believe this is also true in Gecko.
Let me ask you this - Are there any (reasonable) pages
On 5/30/13 1:04 PM, Brady Eidson wrote:
The long standing design goals and implementation of our page cache
prevents us from delivering these events to a page that was just sent
“pagehide with persisted set to true”.
Actually, let me try to clarify this a bit.
The way I would imagine logic
On 5/30/13 2:24 PM, Brady Eidson wrote:
In WebKit, if you have an unload handler, you don’t go into the page cache.
This is also true in Gecko; I was talking about the events we dispatch,
not necessarily what a page can see.
-Boris
On 5/30/13 2:26 PM, Brady Eidson wrote:
So how does your setup differ in a way that actually makes this
impossible to implement?
The design is that after pagehide returns, if the traversal is still
taking place and the page is going into the cache, no further events
take place.
Yes, you said
On 6/7/13 7:08 PM, Ian Hickson wrote:
If browsers align on the above text the HTML spec indeed would no longer
need to worry about this, since there'd no longer be any cross-origin
fonts. Has this occurred?
No, though they have all in principle agreed that they plan to when they
didn't object
On 6/17/13 6:05 AM, Simon Pieters wrote:
What's in CSSOM now is tainting.
Sort of. I think of tainting as you can write to it but read from it,
but what's in CSSOM is you can't touch it. I guess the point is that
whether you can touch or not is detected statically at load time?
There
On 6/17/13 7:38 AM, Anne van Kesteren wrote:
On Fri, Nov 30, 2012 at 11:47 AM, Boris Zbarsky bzbar...@mit.edu wrote:
Right. My point was that cross-origin for the case of stylesheet at least
in Gecko depends on the origin of the script that tries to modify them, not
on the origin
On 6/19/13 2:17 PM, Benoit Jacob wrote:
The closest thing that I could find being discussed, was use cases by JS
frameworks or libraries that already expose similar feature-detection APIs.
However, that only shifts the question to: what is the reason for them to
expose such APIs?
I _think_ the
On 6/19/13 3:43 PM, Kenneth Russell wrote:
Accurate feature detection in libraries like Modernizr was mentioned
as a key use case:
http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2012-September/037249.html
Right, this is the use case that's not really making sense to me. The
fact
On 6/19/13 3:34 PM, Tab Atkins Jr. wrote:
This is missing the point. You don't want to wait until it's actually
time to create the context. Unless you torture your code flow, by the
time you're creating a context you should already know that the
context is supported. The knowledge of which
On 6/19/13 4:22 PM, Brandon Benvie wrote:
The point of using Modernizr or something like it is to detect
availability of features on page load, and then conditionally load
polyfills/alternate fallback implementations. It specifically does need
to do eager detection to be useful. It can't wait
On 6/19/13 5:27 PM, Paul Irish wrote:
I agree that supportsContext is only useful if it's more accurate that
!!window.WebGLRenderingContext.
So that's an interesting question. Should UAs simply not have
window.WebGLRenderingContext in situations in which supportsContext
would return false?
On 6/19/13 6:04 PM, Kenneth Russell wrote:
supportsContext() can give a much more accurate answer than
!!window.WebGLRenderingContext. I can only speak for Chromium, but in
that browser, it can take into account factors such as whether the GPU
sub-process was able to start, whether WebGL is
On 6/20/13 9:40 PM, Glenn Maynard wrote:
I've suggested that in the past, and the response was that it's harder
to do (don't recall in which engine, probably WebKit). It would seem
pretty weird if the interface appears and disappears from window over
the life of the page, as WebGL support comes
On 6/23/13 1:15 AM, Adam Barth wrote:
One tricky case here is what happens if you modify the srcdoc attribute:
Ah, indeed.
iframe id=foo srcdoc=aaa/iframe
script
[...] // Wait for the iframe to finish loading.
document.getElementById(foo).srcdoc = bbb;
[...] // Wait for the iframe to finish
On 6/23/13 12:57 PM, Adam Barth wrote:
I guess it depends on what you mean by rely.
I mean act just as if @srcdoc were syntactic sugar for
@src=data:whatever, which is what it is conceptually.
We just treat the
about:srcdoc URL as something that, when fetched, retrieves the value
currently
On 6/27/13 5:42 PM, Steve Hoeksema wrote:
I built a form and tested it in Firefox, which honours the maxlength attribute,
and then found that Chrome did not.
Note that I assume you tested this in a version of Firefox which does
not support type=number... so it was treated as type=text.
On 6/28/13 5:06 PM, Tab Atkins Jr. wrote:
getElementById(foo) is just querySelector(#foo)
This is actually false. For example, getElementById(foo:bar) is just
querySelector(#foo\\:bar), which is ... nonobvious.
It gets worse if you don't control the id that's passed in, because
On 6/28/13 6:51 PM, Tab Atkins Jr. wrote:
querySelector is simply a more powerful querying function than the old DOM
methods,
And somewhat slower as a result, note.
-Boris
On 6/28/13 8:32 PM, Zirak A wrote:
The point here is that document fragments are documents
Actually, no. They are not. getElementById on a document fragment, for
example, would almost certainly be slower than on a document (which
typically has a hashtable mapping ids to lists of elements).
On 7/3/13 12:42 AM, Dirk Schulze wrote:
The methods addText() and addPathByStrokingText() [1] take the
NoInterfaceObject CanvasDrawingStyle [2] as argument.
[NoInterfaceObject] just means that window.CanvasDrawingStyle is
undefined, basically. It doesn't affect anything else.
addText, as
On 7/3/13 3:58 AM, Mikko Rantalainen wrote:
Boris Zbarsky, 2013-06-29 05:02 (Europe/Helsinki):
On 6/28/13 6:51 PM, Tab Atkins Jr. wrote:
querySelector is simply a more powerful querying function than the old
DOM methods,
And somewhat slower as a result, note.
If that's true, I would
On 7/12/13 1:57 PM, Ian Hickson wrote:
Having not heard any interest from anyone else, I haven't done anything.
That's because other UAs are just silently ignoring the spec as
currently written, for the most part...
-Boris
On 7/12/13 2:15 PM, Ian Hickson wrote:
What's not useful about the way it's defined? It's set to a specific
string.
I couldn't find where it was normatively set to anything.
In cases when the hostname is non-ASCII, the Referer header will have it
encoded in punycode.
Is that defined
On 7/12/13 2:40 PM, Adam Barth wrote:
Why not change Firefox to use punycode in window.location?
If nothing else because that seems user-hostile (both to web developers
examining location values and users who are shown document.URL or
location.href in web pages).
-Boris
On 7/12/13 3:39 PM, Ian Hickson wrote:
That wasn't the intent. I've tried to clarify it.
Hmm. It might help to make it clearer in
http://www.whatwg.org/specs/web-apps/current-work/multipage/history.html#navigate
that new resource does not mean URL. Maybe have some explicit thing
that
On 7/12/13 4:08 PM, Ian Hickson wrote:
The HTML spec is pretty explicit about it not being:
# When the button binding applies to a button element, the element is
# expected to render as an 'inline-block' box rendered as a button whose
# contents are the contents of the element.
--
On 7/15/13 3:42 AM, Bruno Racineux wrote:
Wouldn't browsers be able to store pre-parsed/compiled' scripts in a
separate byte code cache,
You mean like https://bugzilla.mozilla.org/show_bug.cgi?id=679942 ?
There's some discussion in there about whether this is a worthwhile
optimization with
On 7/15/13 4:44 PM, Ian Hickson wrote:
I've tried to spec something that's close to what you describe and what
other vendors have described to me.
Thank you. I'll try to find time to review it, but I can't give you an
ETA. :(
Can't they just resize the window or scroll it?
It depends.
On 7/15/13 7:28 PM, Bruno Racineux wrote:
The outline there suggest: - When compiling a lazy script with no inner
functions, do a table lookup for a script with the same source location
(filename, lineno, column, source begin/end
So just to be clear: that bug is talking about script in the
On 7/18/13 5:18 PM, Rik Cabanier wrote:
Does the JS VM know about the image bits?
For what it's worth, at least in Firefox it would; we already tell the
JS VM about all sort of other large C++-side allocations owned by JS
objects.
-Boris
On 7/24/13 5:51 PM, James Greene wrote:
While I'm not familiar with the spec for DocumentFragments, I've always
consider them to be more equivalent to a detached element node than a
document node.
Fwiw, Element has a getElementsByClassName and getElementsByTagName.
And SVGElement has
On 7/24/13 5:39 PM, Ryosuke Niwa wrote:
Indeed. Note that querySelector implementations in WebKit and Blink optimize
#foo, .foo, etc... so that they're equally if not faster than getElementsById,
getElementsByClassName, etc...
I have a hard time reconciling that claim with either
On 7/24/13 10:42 PM, Jussi Kalliokoski wrote:
Argh, I had forgotten about live NodeLists. OK, this is a reason that
resonates with me and justifies calling these methods obsolete. Too bad
these methods are so badly flawed
Fwiw, I think the performance impact of live NodeLists is ... unclear.
On 7/27/13 10:58 AM, Ojan Vafai wrote:
var iterator = document.querySelectorAll('div').iterator(); --- does
some magic to not precompute the whole list
Well, so... not precompute but make it some sort of live, or not
precompute but represent a frozen set of nodes?
What should happen with
On 8/2/13 6:44 PM, David Bruant wrote:
And apparently @sandbox doesn't help here if there is allow-same-origin.
So here is an idea: make the document.domain setter throw inside an
iframe@sandbox, *regardless* of allow-same-origin. That solves the
mail.google.com VS calendar.google.com case.
On 8/2/13 6:55 PM, Ian Hickson wrote:
How does it solve it? (What _is_ the mail.google.com vs
calendar.google.com case?)
The case is when mail.google.com tries to attack calendar.google.com,
and they can't be in different processes as mitigation because you never
know when they'll both set
On 8/2/13 10:35 PM, Ian Hickson wrote:
Honestly, though, at the point
where you're able to trick a similar-origin site into changing
document.domain so you can attack it
document.domain was not involved in any way in the cross-site issues
I've pointed out to you recently.
-Boris
On 8/3/13 9:48 AM, David Bruant wrote:
a.example.org can sandbox the iframe to b.example.org and process
isolation becomes possible again
Yes, agreed. This might be a good idea. It just has nothing to do with
protecting one from attacks by the other in general, because they can
use
On 8/5/13 9:15 PM, Chang Shu wrote:
I think the atob implementation is able to enlarge the buffer size
from c++ side if necessary.
No, it's not. ArrayBuffer sizes are immutable.
the algorithm first decodes base64 string into a binary string and
casts/copies it into the desired type based on
On 8/6/13 2:30 PM, Ian Hickson wrote:
I think there are other invariants that make them equivalent that are
relevant here. In particular:
D) When a Window is a script's global object, that script is always going
to be same-origin with the Window
Ah, yes. Yes, that one is important too.
On 8/6/13 5:58 PM, Ian Hickson wrote:
One could imagine an implementation strategy where the cloning is done on
the sending side, or even on a third thread altogether
The cloning needs to run to completion (in the sense of capturing an
immutable representation) before anyone can change the
On 8/7/13 5:18 PM, Ian Hickson wrote:
We could indeed move the indexed properties to WindowProxy, while leaving
the security checks (which apply to non-indexed properties only) on
Window. This would still address my concern, which is that if we move the
security checks to WindowProxy, and then
On 8/8/13 2:11 AM, Ian Hickson wrote:
I would imagine most languages other than JavaScript would break that
invariant.
Why are we suddenly worrying about languages other than JavaScript?
What other problems would it break?
Let me think about this; it's been a while...
Because the current
On 8/8/13 7:22 AM, Boris Zbarsky wrote:
On 8/8/13 2:11 AM, Ian Hickson wrote:
I would imagine most languages other than JavaScript would break that
invariant.
Why are we suddenly worrying about languages other than JavaScript?
Let me try that with less snark.
I believe that WindowProxy
On 8/8/13 2:50 PM, Ian Hickson wrote:
I'd go further -- I wouldn't expose WindowProxy to other languages at all
Yes, I thought that was more or less what I said.
You still need an object to represent navigation contexts, of course.
My point is that either way, if we do this, that means all
On 8/8/13 2:48 PM, Ian Hickson wrote:
The current spec calls for the Window to be a proxy-like object, because
that's the only way to implement the spec's indexed getter behavior.
I don't understand what you mean. What's different about Window's indexed
getter behaviour than the indexed getter
On 8/8/13 5:05 PM, Ian Hickson wrote:
I think the problem is that I have no idea what these ES6 terms are or
what they mean.
OK. Which terms, exactly?
Was all this a problem in previous revisions of JavaScript? Or is it some
new problem caused by some new JavaScript feature?
It's a
On 8/13/13 4:34 PM, Ian Hickson wrote:
I see that this is a requirement in the JS spec, but I don't understand
why, other than providing a sane API
That's why, basically. Providing something that guarantees at least
_some_ invariants that things that want to enforce other invariants can
On 8/19/13 7:40 PM, Ryosuke Niwa wrote:
Also,
http://www.whatwg.org/specs/web-apps/current-work/multipage/common-input-element-attributes.html#the-maxlength-attribute
says if the input element has a maximum allowed value length, then the code-unit
length of the value of the element's value
On 8/8/13 5:35 PM, Ian Hickson wrote:
I'm certainly open to the idea of making document.domain not work in
sandboxed iframes. Any objections? Who is ready to implement this?
There seems to be general support for this amongst the Mozilla DOM
peers, so I filed
On 8/22/13 9:01 AM, Charles McCathie Nevile wrote:
The basic question is whether a validator should flag input
maxlength=2 value=abc as a conformance error or not. It seems to
me like it should.
Why? It seems that it generally works in browsers, and has for a long time.
Sort of. It gets
On 8/23/13 12:33 PM, Tab Atkins Jr. wrote:
If a function currently takes a callback argument and returns void,
it's trivial to upgrade it to instead make the callback optional and
return a promise when it's not passed.
And null if a callback is passed?
If we want to continue returning void
On 8/23/13 1:23 PM, Tab Atkins Jr. wrote:
On Fri, Aug 23, 2013 at 10:22 AM, Anne van Kesteren ann...@annevk.nl wrote:
On Fri, Aug 23, 2013 at 6:09 PM, Boris Zbarsky bzbar...@mit.edu wrote:
If we want to continue returning void when a callback is passed, we need to
add some webidl magic
1001 - 1100 of 1308 matches
Mail list logo
