On 12/18/15 3:53 AM, Simon Pieters wrote:
Note that it requires liveness. Does that work for a frozen array?
No. You'd have to create a new array object at the point when you want
to update the set of values in the array.
Maybe this particular API should be a method instead that returns a
On 11/30/15 8:31 AM, Xiaoqian Wu wrote:
The latest [TEST RESULTS] of Web Workers indicate that Dedicated Workers have
been widely implemented by the major browser vendors.
Compatibly? Last I checked, for example, Blink doesn't support
Dedicated Workers inside workers, only inside Window. I
On 11/6/15 3:44 PM, Olli Pettay wrote:
You need to override addEventListener on EventTarget, and also relevant
onfoo EventHandler setters on Window and Document and *Element prototypes
Are we trying to just do this best-effort, or reliably? Because this:
var ifr =
On 7/17/15 12:05 PM, Anne van Kesteren wrote:
True, but either way this doesn't seem like a problem. You can create
a DocumentFragment, insert a new img, and then let it be GC'd,
today.
Sure. In practice it won't get GC'd until the load completes, which is
sucky, but that's life.
-Boris
On 7/17/15 10:38 AM, Anne van Kesteren wrote:
If I look at update the image data step 6 it seems it might be
fetched at a later point?
Yes, but in practice the fetch will go ahead, no? There's nothing to
prevent it from happening, so it's going to happen once you reach a
stable state...
On 7/17/15 2:03 PM, Travis Leithead wrote:
Something magical happens here. The use of super() is supposed to call
the constructor of the HTMLElement class—but that’s not a normal JS
class. It doesn’t have a defined constructor() method
Sure, but neither does Array. What super() actually does
On 7/16/15 12:02 PM, cha...@yandex-team.ru wrote:
But would just abandoning T[] break anything elsewhere?
It's hard to break something that never worked. No browser ever
implemented anything for T[] to my knowledge.
-Boris
On 7/16/15 11:45 AM, Travis Leithead wrote:
Now that WebIDL has added FrozenArray and dropped T[], it’s time to
switch over! On the other hand, there are a number of specs that have
already gone to Rec that used the old syntax.
Note that since the old syntax was never supported by any UA in
On 6/26/15 4:07 AM, Ashley Gullen wrote:
I don't think we should extend HTMLImageElement because it is not
available in workers. Adding the conversion methods to ImageBitmap
allows workers to perform conversions using Blob (compressed image data)
in the place of HTMLImageElement.
Maybe I
On 6/24/15 1:28 PM, Ashley Gullen wrote:
I'm new to specs and WebIDL, my intent was to say those are new methods
on ImageBitmap. Is partial interface ImageBitmap the correct way to
say that?
Yes, it is.
The wording of undue latency in the ImageBitmap spec does not appear
to rule out
On 6/19/15 5:43 AM, Ashley Gullen wrote:
I've not done this before, so I've no idea if this is the right/useful
approach, but I drafted a spec for it here:
https://www.scirra.com/labs/specs/imagedata-blob-extensions.html
Let me know if you have any feedback on this.
Ashley,
I assume the
On 6/11/15 4:32 PM, Dimitri Glazkov wrote:
I noticed that the CSS Color Module Level 4 actually does this, and it
seems pretty nice:
http://dev.w3.org/csswg/css-color/#dom-rgbcolor-rgbcolorcolor
I should note that the ES code there produces semantics that don't match
the IDL in this spec (or
On 5/9/15 12:40 PM, Anne van Kesteren wrote:
So that seems clearly wrong (in the specification)... Are descendants
notified in tree order?
In Gecko, yes.
Note that running script during these insert/remove notifications is not
OK, so anything that needs to run script has to do it later (for
On 5/8/15 1:42 AM, Elliott Sprehn wrote:
That actually seems pretty similar to what we have, ours is in the form of:
Node#insertedInto(Node insertionPoint)
Node#removedFrom(Node insertionPoint)
To be clear, ours is also in the form of two methods
(BindToTree/UnbindFromTree) that take various
On 5/7/15 3:43 AM, Anne van Kesteren wrote:
On Wed, May 6, 2015 at 11:01 PM, Justin Fagnani
justinfagn...@google.com wrote:
How are you supposed to tell if one of your ancestors was removed?
Is that a hook builtin elements have today?
In Gecko, yes. The set of hooks Gecko builtin elements
On 4/29/15 12:23 AM, Glen Huang wrote:
because of the proxy machinery involved on the JS engine side
Do you mean the cost introduced by passing a C++ object into ecmascript world?
No, it's the cost introduced by needing custom property behavior for
integer-named properties on lists (and in
On 4/28/15 2:44 AM, Glen Huang wrote:
But If I do getElementsByClass()[0], and LiveNodeList is immediately
garbage collectable
Then it will only be collected the next time GC happens. Which might
not be for a while.
-Boris
On 4/28/15 1:58 AM, Glen Huang wrote:
Just a quick follow up question to quench my curiosity: if I do list[1] and no one has
ever asked the list for any element, Gecko will find the first two matching elements, and store
them in the list, if I then immediately do list[0], the first element is
On 4/28/15 2:13 AM, Glen Huang wrote:
On second thought, if the list returned by getElementsByClass() is lazy
populated as Boris says, it shouldn't be a problem. The list is only
updated when you access that list again.
Mutations have to check whether the list is marked dirty already or not.
On 4/28/15 2:59 AM, Glen Huang wrote:
Looking at the microbenchmark again, for Gecko, getElementById is around 300x
faster than querySelector('#id'), and even getElementsByClassName is faster
than it.
This is why one should not write microbenchmarks. ;) Or at least if
one does, examine
On 4/27/15 11:27 PM, Glen Huang wrote:
When you say var node = list[0]; walks the DOM until the first item is found,
do you mean it only happens under the condition that some previous code has changed the
DOM structure?
Or that no one has ever asked the list for its [0] element before, yes.
On 4/23/15 9:31 PM, Kyle Huey wrote:
Today it's not demanding, it's not even possible. e.g. how do you
duplicate a FileList object?
Ah, there we go. I figured there was something that would fail the
ways of cloning them all test in the platform today... ;)
We should make it possible to
On 4/23/15 6:34 PM, Elliott Sprehn wrote:
Have you benchmarked this? I think you're better off just writing your
own clone library.
That requires having a list of all objects browsers consider clonable
and having ways of cloning them all, right? Maintaining such a library
is likely to be a
On 4/17/15 2:44 AM, Mike West wrote:
Consider Geolocation, for instance: users can disable the API entirely
in Chrome (and, I assume, other browsers). Should we remove the API in
these cases as well?
There's no user-facing UI to disable geolocation in Firefox, but there
is a preference that
On 4/17/15 2:52 AM, Boris Zbarsky wrote:
If that preference is toggled, we in fact remove the API entirely, so
that 'geolocation' in navigator tests false.
Oh, I meant to mention: this is more web-compatible than having the API
entrypoints throw, because it can be object-detected. Of course
On 4/17/15 3:38 AM, Elliott Sprehn wrote:
It's preferable not to do that for us because you can then create a
static heap snapshot at compile time and memcpy to start JS contexts faster.
For this specific case, where there are only two possibilities
(privileged or not) it seems like you can
On 4/17/15 2:44 AM, Mike West wrote:
Either way, expressing the constraint via IDL seems totally reasonable.
OK, so let's say we do the API is still present but fails somehow
thing. How would one express that constraint via IDL? What would the
normative language be? It seems like the best
On 4/17/15 7:58 AM, Ashley Gullen wrote:
I think the existence of the API functions should indicate the browser
has the capability, and then the API returns an error if it's not
allowed to be used in the current context. I think this would improve
the quality of messages seen by users, since for
On 4/17/15 11:13 AM, Anne van Kesteren wrote:
A bunch of the new non-legacy APIs (that is geolocation doesn't count)
have some kind of promise thing you need to get past before things
start working. For those APIs we could have something with normative
language. I don't see how we could make
On 4/16/15 12:37 AM, Travis Leithead wrote:
Was an imperative form of HTML imports already considered? E.g., the
following springs to mind:
PromiseDocument importDocument(DOMString url);
How is this different from a promise-ified version of XHR, exactly?
(Not that there's anything wrong
On 4/14/15 8:22 AM, Yves Lafon wrote:
I remember ArrayClass removed from NodeList for the reason of lack of
implementations, and even plans for implementation
It was removed because as things stand it's not web-compatible. Once
@@isConcatSpreadable exists in implementations, we could and
On 4/2/15 8:15 AM, Simon Pieters wrote:
http://www.w3c-test.org/websockets/keeping-connection-open/001.html --
the test is wrong. Passing undefined means the argument is not
present per Web IDL, so this should not throw.
I assume you mean some other test since that test doesn't use undefined.
On 4/1/15 12:50 PM, Domenic Denicola wrote:
Do you think it's acceptable for browser to experiment with e.g. auto-granting
permission if the requested remoteAddress is equal to the IP address of the
origin executing the API?
This particular example sets of alarm bells for me because of
On 3/26/15 10:51 AM, Arthur Barstow wrote:
If anyone is willing to help with the failure analysis, that would be
very much appreciated.
Taking a brief look at some of the failures in Firefox, in addition to
the ones Olli already posted about:
On 3/26/15 10:51 AM, Arthur Barstow wrote:
* All results http://w3c.github.io/test-results/websockets/all.html
* 2 passes http://w3c.github.io/test-results/websockets/less-than-2.html
Overall these results are pretty good: 97% of the 495 tests have two or
more passes.
Arthur,
It looks like
On 3/26/15 1:02 PM, Boris Zbarsky wrote:
It looks like the tests that are failed with an Error as opposed to a
Fail are not being counted in the 2 passes list?
And the for
http://www.w3c-test.org/websockets/keeping-connection-open/001.html
which is all-Timeout.
-Boris
On 2/23/15 4:27 AM, Anne van Kesteren wrote:
1) If we run the constructor synchronously, even during cloning. If
the constructor did something unexpected, is that actually
problematic? It is not immediately clear to me what invariants we
might want to preserve. Possibly it's just that the code
On 2/11/15 3:04 PM, Brendan Eich wrote:
If you want multi-threaded DOM access, then again based on all that I
know about the three open source browser engines in the field, I do not
see any implementor taking the huge bug-risk and opportunity-cost and
(mainly) performance-regression hit of
On 2/11/15 9:45 PM, Marc Fawzi wrote:
this backward compatibility stuff is making me think that the web is
built upon the axiom that we will never start over and we must keep
piling up new features and principles on top of the old ones
Pretty much, yep.
this has worked so far, miraculously
On 2/10/15 12:28 PM, Marc Fawzi wrote:
Launch an async xhr and monitor its readyState in a while loop and don't exit
the loop till it has finished.
Per spec (and in implementations last I checked), the readyState isn't
allowed to change during the loop. So all that will happen is you will
On 1/21/15 3:52 AM, Simon Pieters wrote:
This jsperf might be interesting:
http://jsperf.com/appendchild-vs-documentfragment-vs-innerhtml/81
Or misleading.
Again, in real life what matters most here is what else is on the page,
which the jsperf doesn't capture. The other thing that really
On 1/20/15 6:45 PM, Glen Huang wrote:
I vaguely remember document fragment is introduced just to reduce
reflows. Looks like this best practice is obsolete now?
You don't have to use a document fragment to reduce reflows, as long as
you don't query layout information between your DOM
On 1/14/15 9:45 AM, Anne van Kesteren wrote:
* No subclassing of normal elements for now.
You mean subclassing anything more specific than HTMLElement/SVGElement,
yes? Presumably we still want subclassing of HTMLElement and maybe
SVGElement?
* Parsing of declarative syntax invokes the
On 1/14/15 8:28 AM, Anne van Kesteren wrote:
On Wed, Jan 14, 2015 at 2:00 PM, Boris Zbarsky bzbar...@mit.edu wrote:
Wanting things like custom buttons is _very_ common. What is your proposal
for addressing this use case?
I have no good answer. appearance:button seems to work okayish
I
On 1/14/15 11:52 AM, Dimitri Glazkov wrote:
Would like to point out that we're not talking about a general case
here. The actual proto munging in custom elements spec is minimized to a
pretty small set.
Pretty small set of which? Possible mutations, elements, something else.
Given that most
On 1/14/15 7:51 AM, Anne van Kesteren wrote:
I would rather we gave up on subclassing normal elements
Wanting things like custom buttons is _very_ common. What is your
proposal for addressing this use case?
-Boris
On 1/13/15 12:06 PM, Gabor Krizsanits wrote:
I think this part of the spec was largely written before ES6 class stuff
stabilized, fwiw. Which is not hard, since it's still not stabilized. ;)
Isn't there a chance to consider our use-case in ES6 spec. then?
I suspect not in time for ES6.
On 1/13/15 12:05 PM, Domenic Denicola wrote:
From: Boris Zbarsky [mailto:bzbar...@mit.edu]
var x = new Element(a, http://www.w3.org/1999/xhtml;)
The idea is that your above example throws, preserving the invariant.
That sounds annoying
Presumably this means
On 1/13/15 1:18 PM, Ryosuke Niwa wrote:
I agree. It's unusual for a constructor of a super class to automatically
instantiate an arbitrary subclass based on its arguments. And we usually solve
that convenience problem by introducing a factory class/function.
While true, I do think there's a
On 1/13/15 12:50 PM, Domenic Denicola wrote:
Agreed. That needs to be done with img is=my-img, IMO. (Assuming the
upgrading design doesn't get switched to DOM mutation, of course.)
Although! Briefly yesterday Arv mentioned that for Blink's DOM implementation there's no real
difference in
On 1/13/15 12:10 PM, Domenic Denicola wrote:
Hmm. So given the current direction whereby ES6 constructors may not even be
[[Call]]-able at all, I'm not sure we have any great options here. :(
Basically, ES6 is moving toward coupling allocation and initialization but the
upgrade scenario
On 1/13/15 1:33 PM, Ryosuke Niwa wrote:
Shouldn't we throw in this case because the concert type of somename is
HTMLUnknownElement?
Oh, hmm.
Yes, I guess so. That's very non-obvious to an author.
Even less obvious because for some tag names using the HTMLElement
constructor is in fact
On 1/13/15 2:43 PM, Domenic Denicola wrote:
Why is the tree data structure embodied by the DOM any different?
The issue is not the tree structure but rather 1) what it means to have
a certain document as your ownerDocument and 2) Whether there are
footguns here that make it too easy for
On 1/12/15 1:56 PM, Olivier Forget wrote:
Unfortunately
multiple range selections are not a nice to have. All real editors
(MS Word, Google Docs, etc..) support selecting multiple ranges
Precisely. This is why Gecko ended up supporting it: it was needed for
the editor that was part of the
On 1/12/15 12:20 PM, Tab Atkins Jr. wrote:
Proto munging isn't even that big of a deal.
That really depends.
For example, dynamically changing __proto__ on something somewhat
permanently deoptimizes that object in at least some JS engines.
Whether that's a big deal depends on what you do
On 1/11/15 2:33 PM, Domenic Denicola wrote:
Terminology: In what follows I use 'own-instances of X' to mean objects where
obj.constructor === X,
That doesn't make much sense to me as a useful test, since it's pretty
simple to produce, say, an HTMLParagraphElement instance on the web that
On 1/11/15 3:13 PM, Domenic Denicola wrote:
So, at least as a thought experiment: what if we got rid of all the local name checks
in implementations and the spec. I think then `my-q` could work, as long as
it was done *after* `document.registerElement` calls.
Yes.
However, I don't
On 1/12/15 7:24 PM, Domenic Denicola wrote:
One crazy idea for solving B is to make every DOM element (or at least, every one
generated via parsing a hyphenated or is= element) into a proxy whose target
can switch from e.g. `new HTMLUnknownElement()` to `new MyEl()` after upgrading. Like
On 1/9/15 8:01 PM, Domenic Denicola wrote:
I was writing up my ideas in an email but it kind of snowballed into something
bigger so now it's a repo: https://github.com/domenic/element-constructors
Domenic, thanks for putting this together.
Caveat: I won't get a chance to read through this
On 1/9/15 9:33 AM, Anne van Kesteren wrote:
On Fri, Jan 9, 2015 at 3:09 PM, Boris Zbarsky bzbar...@mit.edu wrote:
In any case, the fact that we're even _having_ this discussion and that it
needs careful reading of the HTML spec is my point.
It does seem however we could define this in a way
On 1/9/15 8:46 AM, Anne van Kesteren wrote:
As far as I can tell from the specification, when the value IDL
attribute is in the filename mode, any values that might be stored in
internal slots are ignored.
Hmm... That was not obvious to me, but OK. I guess it uses the list
of selected files
On 1/9/15 7:14 AM, Anne van Kesteren wrote:
Both parent and input need to be cloned in this case. While parent's
callback runs it changes the type of input, at which point input's
callback runs. So, yes.
OK. So just to be clear, the type will be set before the input's
cloning callback runs,
On 1/9/15 4:28 AM, Anne van Kesteren wrote:
On Thu, Jan 8, 2015 at 5:54 PM, Boris Zbarsky bzbar...@mit.edu wrote:
var input = document.createElement(input);
input.value = file:///etc/passwd;
var newInput = input.cloneNode();
newInput.type = file;
Note that in the above example
On 1/8/15 10:56 AM, Anne van Kesteren wrote:
2) For normal elements we act directly when they are cloned or
adopted. How much interest is there in delaying what happens for
normal elements to align them with custom elements?
Which things are we talking about delaying?
I'm pretty sure the
On 1/7/15 6:17 AM, Anne van Kesteren wrote:
The main tricky thing here I think is whether it is acceptable to have
an element whose name is a, namespace is the HTML namespace, and
interface is Element.
That depends on what you mean by interface is Element.
If you mean that it has all the
On 1/7/15 9:51 AM, Anne van Kesteren wrote:
That is what I meant. Otherwise in order to support new Element()
you'd have to support an ever growing set of more specific objects as
well and layering is out of the window.
Do you mean layering of implementations or specifications? For
On 12/15/14, 1:10 PM, Ashley Gullen wrote:
Why would modules affect the decision to ship HTML imports?
Because the interaction of the various import systems with each other
needs to be specified, for one thing.
But more to the point, we're not shipping imports because we've gotten
feedback
On 12/15/14, 3:09 PM, Arthur Barstow wrote:
Does [Bugzilla] capture all of Mozilla's Imports concerns (or at least
the higher priority issues)?
Not yet. We've just gotten things sorted out on our end.
If not, who should I contact to request
capturing your concerns?
I think Anne's email
On 12/3/14, 6:02 AM, Yves Lafon wrote:
Pretty much like refactoring XHR using Fetch or not. Most
implementations will most probably move to the latest version, but the
external interface will be the same.
External interface being the IDL syntax in this case, not the
resulting web-exposed
On 12/1/14, 1:49 PM, Travis Leithead wrote:
I believe so; this will give many specs a baseline WebIDL document to point to
in their references at the very least. Many specs don't rely on the more
advanced feature set being defined in WebIDL Second Edition.
Here's the problem.
As of today,
On 10/17/14, 8:19 PM, Hallvord R. M. Steen wrote:
a) Ship a TR based on the spec just *before* the big Fetch refactoring.
If we want to publish something at all, I think this is the most
reasonable option, frankly. I have no strong opinions on whether this
is done REC-track or as a Note, I
On 9/11/14, 12:52 PM, Mark Baker wrote:
On Thu, Sep 11, 2014 at 12:13 PM, Anne van Kesteren ann...@annevk.nl wrote:
In which case the WHATWG version wouldn't be canonical anymore anyway.
It would be for implementers.
Only those implementers that can afford to staff a team to keep up
with a
On 9/10/14, 6:14 PM, Glenn Adams wrote:
and they do not follow a consensus process.
Glenn, with all due respect, neither do many W3C specifications. Case
in point is http://www.w3.org/TR/navigation-timing/ which managed to get
to REC while ignoring feedback that pointed out that not a
On 9/2/14, 9:51 AM, Mounir Lamouri wrote:
required PermissionName name;
Glad to see required being put to good use. ;)
interface PermissionManager {
IDL nit: This needs Exposed=(Window,Worker)
[NoInterfaceObject, Exposed=Window,Worker]
And parens.
-Boris
On 8/27/14, 4:50 PM, Daniel Appelquist wrote:
with a few minimal editorial changes.
What are the changes, specifically?
-Boris
On 8/1/14, 9:39 AM, nmork_consult...@cusa.canon.com wrote:
All tabs, menus, etc. must be frozen.
Sync XHR doesn't do that.
-Boris
In http://w3c.github.io/webcomponents/spec/imports/#fetching-import the
spec says:
Fetch a resource from LOCATION with request's origin set to the
origin of the master document, the mode to CORS and the omit
credentials mode to CORS.
There is no omit credentials mode in the current Fetch
On 7/2/14, 11:07 AM, Adam Barth wrote:
I've studied the XBL implementation of marquee in Gecko, and it does
leak some implementation details.
Absolutely. The point of the XBL implementation was to provide the
functionality (back before there was a spec for it, note) at minimal
cost and core
On 7/1/14, 9:16 PM, Ryosuke Niwa wrote:
I would love to hear from Mozillians if they have gotten enough developer
feedbacks
Our implementation is currently at a stage that can best be described as
not usable yet, which is most of the feedback we've gotten thus far. ;)
-Boris
On 7/1/14, 9:13 PM, Brendan Eich wrote:
Are you sure? Because Gecko has used XBL (1) to implement, e.g., input
type=file, or so my aging memory says.
We use XBL to implement marquee.
We do not use XBL to implement input type=file, though there was
once a project to do that sort of thing.
On 7/1/14, 11:20 PM, Brendan Eich wrote:
XBL can expose anonymous content via special API:
https://developer.mozilla.org/en-US/docs/XBL/XBL_1.0_Reference/DOM_Interfaces#getAnonymousNodes
https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XUL/Tutorial/XBL_Example
On 7/2/14, 12:15 AM, Brendan Eich wrote:
Boris Zbarsky wrote:
On 7/1/14, 9:13 PM, Brendan Eich wrote:
Are you sure? Because Gecko has used XBL (1) to implement, e.g., input
type=file, or so my aging memory says.
We use XBL to implement marquee.
Also video playback controls, per your next
On 6/30/14, 4:40 AM, Anne van Kesteren wrote:
Are stack overflow exceptions even a thing per standards?
No.
However, they come up pretty regularly in practice. In fact, some sites
depend on them for proper functioning. :(
-Boris
On 6/24/14, 6:56 AM, Charles McCathie Nevile wrote:
While nobody is offering an editor who can get the work
done, this argument is in any case academic (unless the editor's
availability is predicated on the outcome, in which case it would be mere
political machinations).
I strongly disagree
On 6/24/14, 1:05 PM, Glenn Adams wrote:
Such device certification regimes cannot work unless the referenced
specifications are locked down and clearly implementable.
I see.
So this is not about actual spec implementations or spec authors but
effectively about a QA cycle that compares the
On 6/24/14, 1:46 PM, Glenn Adams wrote:
The primary goal of the W3C is to produce Technical Reports that reach a
stable level of maturity.
The Technical Reports are not an end in themselves. They're a means to
an end. This is why we don't produce Technical Reports that just say
do whatever
On 6/3/14, 12:48 PM, Hajime Morrita wrote:
HTML Imports are a bit more strict. They see CORS header and decline if
there is none for cross origin imports.
Also, requests for imports don't send any credentials to other origins.
These two measures prevent attacks on other origins via imports.
On 6/2/14, 8:54 AM, James M Snell wrote:
So long as they're handled with the same policy and restrictions as the
script tag, it shouldn't be any worse.
It's worse for sites that have some sort of filtering on user-provided
content but don't catch this case right now, no?
-Boris
On 6/2/14, 9:22 AM, James M Snell wrote:
Yes, that's true. Content filters are likely to miss the links
themselves. Hopefully, the imported documents themselves get filtered
By what, exactly? I mean, CSP will apply to them, but not website
content filters...
One assumption we can possibly
On 6/2/14, 9:54 AM, James M Snell wrote:
Im not saying it's perfect. Not by any stretch. I'm saying it shouldn't
be worse.
I don't understand why you think it's not worse.
and content filters will need to evolve.
And until they do, we may have vulnerable pages, right? How is that not
On 6/2/14, 4:21 PM, Giorgio Maone wrote:
I do hope any filter already blocked out link elements, as CSS has
been a XSS vector for a long time
link elements without stylesheet in rel don't load CSS, though.
Hence the worries about blacklist vs whitelist...
-Boris
On 6/2/14, 11:17 PM, Eduardo' Vela Nava wrote:
Now, I'm not sure how many have tried to implement an HTML sanitizers.
I've reviewed Gecko's implementation of one, if that counts...
1. You have to write a parser OR You have to use a third-party parser.
Wasn't an issue for us obviously.
On 6/1/14, 2:06 AM, Domenic Denicola wrote:
- Named constructors scare me (I can't figure out how to make them work in
JavaScript without breaking at least one of the normal invariants). I think a
static factory method would make more sense for RedirectResponse.
Or just a constructor
On 5/16/14, 10:11 AM, Anne van Kesteren wrote:
What exactly is wrong with the data URL model that we have today
The fact that some UAs don't want to implement it?
and how do we plan on fixing it?
We don't have a plan yet.
But I guess this is a scenario you explicitly want to outlaw,
even
On 5/16/14, 10:39 AM, Anne van Kesteren wrote:
The fact that some UAs don't want to implement it?
Do we know why?
They think it's a security problem.
-Boris
On 5/16/14, 11:08 AM, Anne van Kesteren wrote:
Not tainting canvas? Same-origin iframe? Doesn't matter?
The same-origin iframe bit. I think everyone is on board with not
tainting canvas for data: things.
-Boris
On 5/13/14, 1:20 AM, Frederik Braun wrote:
On 12.05.2014 18:41, Jonas Sicking wrote:
(new URL(url)).origin should work, no?
It does not work for blob URIs in Firefox.
It can't work, given how URL.origin is currently defined... It's
possible that definition should change, though.
-Boris
On 5/13/14, 7:31 AM, Dimitri Glazkov wrote:
Sole had the idea of providing hooks for attributes so a component can
say it handles them rather than the user agent. That makes a lot of
sense to me. That way you can grab any name, even existing ones.
3 this idea, would love to hear more. It's
On 5/12/14, 5:28 AM, Anne van Kesteren wrote:
so blob:https://origin:42/uuid would be fine.
I'd really rather we didn't make web pages parse these strings to get
the origin. A static method on Blob that takes a valid blob: URI and
returns its origin seems like it should be pretty easy for
On 5/12/14, 7:46 AM, Anne van Kesteren wrote:
I thought the idea was to associate the origin of
URL.createObjectURL() with the Blob object (which might be different
from the Blob object's origin).
Er, right, these URLs come from URL.createObjectURL. So we'd want a
URL.getObjectURLOrigin() or
1 - 100 of 759 matches
Mail list logo
