On 10/31/17 10:56 AM, Regis Kuckaertz wrote:
Indeed I find your idea more appealing and semantically clearer.
OK, good. Since it's not just me, I filed
https://github.com/whatwg/html/issues/3195 on this.
-Boris
On 10/31/17 6:23 AM, Regis Kuckaertz wrote:
formElement.onsubmit = (evt) => {
evt.preventDefault();
const button = evt.target.elements.namedItem('action');
const value = button.value
If this returned buttons, which button would you expect it to return in
various situations and why?
On 2/2/17 2:28 PM, fantasai wrote:
On 02/02/2017 01:18 PM, Boris Zbarsky wrote:
OK, so if I have a flex container with two kids, a run-in and a block,
do I get one flex item or two flex items and why? And
did that require any thought about interactions?
You get two flex items, because being
On 2/1/17 6:07 PM, fantasai wrote:
Wrt this particular issue, run-ins only run into other blocks; they
do not exist in or affect layout modes other than block-and-inline.
OK, so if I have a flex container with two kids, a run-in and a block,
do I get one flex item or two flex items and why?
On 1/25/17 10:48 PM, Florian Rivoal wrote:
Is it a general argument that adding more things to the platform always makes
it harder down the road to add more things due to having to figure out more
interactions
It's not a general argument in this case. It's a specific argument.
For example,
On 1/25/17 8:14 PM, fantasai wrote:
* a 'run-in' layout model slightly less insane than the one proposed
in CSS2.0
I like the truth in advertising there. ;)
I'd just like to reiterate my (longstanding, so unlikely to sway anyone)
opinion that run-in, even in this "less insane"
On 12/13/16 9:09 AM, Jonathan Zuckerman wrote:
Ah right.. would it be possible to compute the missing dimensions given
a mouse event with screenX/Y and clientX/Y properties?
Yes, that should be possible.
-Boris
On 12/13/16 8:46 AM, Jonathan Zuckerman wrote:
Jan, does window.screenX/screenY not meet your needs?
https://developer.mozilla.org/en-US/docs/Web/API/Window/screenX
https://developer.mozilla.org/en-US/docs/Web/API/Window/screenY
That doesn't work because it gives the screen position of the
On 12/9/16 5:57 AM, Michael A. Peters wrote:
max-height and max-width and orientation change, but device-width does
not change.
Just as a point of fact, device-width can absolutely change. The
simplest case is a two-monitor setup with the window getting dragged
from one monitor to another,
On 12/2/16 11:34 AM, Michael A. Peters wrote:
It seems that CSP behavior has radically changed since the last time I
looked at it
I can't speak to when you last looked at it, but the current state
shipping in browsers is, as far as I know, no different from what
browsers shipped initially
On 12/2/16 11:23 AM, Boris Zbarsky wrote:
(except for maybe with the new unsafe-inline option that requires
checksum in the head ???)
unsafe-inline doesn't require a checksum. See examples above.
It's also not new. Certainly the November 2012 CR of CSP 1.0 [1] has
unsafe-inline.
-Boris
On 12/2/16 11:01 AM, Michael A. Peters wrote:
Personally I love CSP but it does not allow inline scripts or inline CSS
Only if you say to not allow them. The default behavior allows them.
For example, this disallows inline scripts, because script-src is
explicitly specified without
On 12/1/16 1:41 AM, Chris Holland wrote:
I think the devil would be in implementation detail. Slapping a
"rel/noopener" attribute on a specific link is very deterministic and
straightforward from a logic standpoint Whichever window was created
from this link can't control the parent.
It's
On 11/1/16 6:36 AM, Roger Hågensen wrote:
Wait, are you saying that ContentSecurityPolicy can't be relied upon?
It depends on your threat model.
Content security policy is a tool that allows a web page to defend
itself and its users from cross-site script injection attacks and the
like. A
On 9/20/16 2:44 AM, Mats Palmgren wrote:
Which is pretty much what I said above, no?
That depends on whether the requirements around summary and legend in
the HTML spec are "box generation and layout" or not, right?
-Boris
On 9/20/16 1:46 AM, Mats Palmgren wrote:
Assuming that the above are the final DOM trees, then they should
create exactly the same CSS boxes as if the element is replaced
by its (DOM) children.
That contradicts what fantasai claimed the spec says.
Which brings me back to my claim that the
On 2/10/16 1:25 PM, Domenic Denicola wrote:
In new JavaScript-only APIs we've made the decision to move away from the
potentially-confusing HTML style crossOrigin enums in favor of the RequestCredentials
enum used by Fetch: https://fetch.spec.whatwg.org/#requestcredentials. You can see this
On 2/8/16 6:25 PM, Domenic Denicola wrote:
So I think the plan of record is: `attribute any console`, with prose describing how the
getter returns "the window's console object" which is initially set to a new
instance of Console, but the setter can change it to any value.
What was the
On 2/8/16 9:31 PM, Domenic Denicola wrote:
and Firefox used to do this but backed it out.
Just for the record, Firefox used to do it back before we had a Web IDL
implementation of console at all. At the time it was a giant
injected-into-the-page hack, and the particular way it was injected
It looks like at least the angular-animate assumes that the .timeStamp
property of animation events produces values that can be compared to
Date.now() return values. See
https://bugzilla.mozilla.org/show_bug.cgi?id=1231619#c3 for details.
-Boris
On 12/1/15 11:40 AM, Domenic Denicola wrote:
Since it has no web-visible impact
That may or may not be true. For example, it's quite likely to change,
in practice, the enumeration order for properties on the obect. Of
course there is no spec defining that enumeration order right now... but
On 10/15/15 9:58 AM, Михаил Гаврилов wrote:
I understand an option to add an attribute to manually specify a
delimiter is not considered here.
I think this is the thing that has the best chance of success: having
explicit opt-in to various different formatting behaviors based on
knowledge of
On 10/15/15 2:35 AM, Михаил Гаврилов wrote:
Let's first decide what numbers is meant by number type.
Good luck with that. Everyone seems to feel it's a different thing.
Also a special case is the number of a credit card and any number with
leading zero. Because leading zero no have
On 10/14/15 5:47 AM, Михаил Гаврилов wrote:
2015-10-14 0:41 GMT+05:00 Boris Zbarsky <bzbar...@mit.edu>:
See https://bugzilla.mozilla.org/show_bug.cgi?id=974175 for details.
I think the problem with the display of the year with the help of
far-fetched.
In what sense? People are
On 10/13/15 3:35 PM, Domenic Denicola wrote:
S ... any implementers interested in solving this problem?
Note that Gecko used to show such separators, then stopped doing that.
See https://bugzilla.mozilla.org/show_bug.cgi?id=974175 for details.
It might be worth having some way to opt in
On 9/25/15 10:48 AM, Justin Novosad wrote:
I am sharing this here in case there would be interest in standardizing
this behavior.
I personally think it's a good idea (and throwing an exception is how
Gecko handles, or at least aims to handle, this situation).
-Boris
On 7/12/15 12:47 PM, Ashley Gullen wrote:
1. Yes: statically references e.preventDefault
2. Maybe: some dynamic reference like e[str]
3: No: no dynamic references, and no static references to e.preventDefault
Assuming the maybe case is rare
Is there data supporting this assumption? I would
On 7/9/15 8:42 AM, Philip Jägenstedt wrote:
Would there be any way to feature detect support for EventListenerOptions as
the third
argument?
Yes. You call addEventListener and pass an object that has getters for
the properties you care about detecting. If those getters get invoked,
the
On 7/9/15 1:32 PM, Rick Byers wrote:
Done. How does example 2 look now?
http://rbyers.github.io/EventListenerOptions/EventListenerOptions.html#example_2
Looks like it would work. Also looks kind of ugly because of the
object-truthiness bit, but I'm not sure there's any way to avoid that
On 7/6/15 5:47 AM, Mike West wrote:
Boris, I think this is consistent with your suggestions in
https://groups.google.com/a/chromium.org/d/msg/blink-dev/wXbgxLu63Fo/F6WGG03FafAJ
and
https://groups.google.com/a/chromium.org/d/msg/blink-dev/wXbgxLu63Fo/pZZ0MXzpbKAJ.
Can you live with this
On 6/16/15 1:57 PM, Anne van Kesteren wrote:
On Tue, Jun 16, 2015 at 7:51 PM, Boris Zbarsky bzbar...@mit.edu wrote:
about: is not standardized enough across UAs to really reason about.
about and mailto are the reasons query is split out. Not so much that
you can set it (you can't)
Why can't
On 6/16/15 1:18 PM, Anne van Kesteren wrote:
On Tue, Jun 16, 2015 at 7:01 PM, Boris Zbarsky bzbar...@mit.edu wrote:
about, data, etc.
data: doesn't use query in practice. As in, any '?' that happens to be
in there is totally accidental.
about: is not standardized enough across UAs
On 6/16/15 8:06 AM, Anne van Kesteren wrote:
I also think we should change the API such that you cannot change
anything for non-relative URLs
Why would you disallow setting fragment for a non-relative URL?
-Boris
On 6/16/15 12:55 PM, Anne van Kesteren wrote:
You're right, fragments make sense. Changing path (scheme data in the
specification) or query would be painful however.
I see no particular need to support changing path.
Not sure about query; Gecko doesn't support query to start with on what
you
On 6/16/15 2:23 PM, Anne van Kesteren wrote:
Actually, it seems like you can, though that would equally affect data
URLs, but maybe that's not too bad. I guess for the API we could
special case a couple of schemes to not support reading/writing as
desired for optimizations.
What optimizations
On 6/1/15 12:17 PM, Aaron Polley (Union Square Software) wrote:
Would you happen to know where I could find this in the specs?
https://html.spec.whatwg.org/multipage/infrastructure.html#document-base-url
and
https://html.spec.whatwg.org/multipage/infrastructure.html#fallback-base-url
On 6/1/15 4:49 AM, Aaron Polley (Union Square Software) wrote:
I've recently been looking at embedding pages with the same origin however in
the latest versions of browsers any script tags inside the iframe with relative
urls are loaded relative to the parent page url rather than the iframe
On 5/18/15 6:49 PM, Domenic Denicola wrote:
Ping. We're considering implementing this in Chrome and it would be helpful to
get a sense if other vendors support this.
We (Mozilla) support having something here. Not making the error event
even more complicated than it already is makes sense.
On 5/8/15 11:56 AM, Roger Hågensen wrote:
One way to cheapen the computational cost is to have partial case
insensitive matching.
If you're walking the string at all, you have already lost in terms of
performance for this stuff.
If (character = $0041) And (character = $005A)
character
On 5/7/15 7:16 AM, Rune Lillesveen wrote:
This adds an implementation complexity to type selector matching.
What's the rationale for matching the selector case-sensitively in the
svg case?
The idea is to allow the selector match to be done case-sensitively in
all cases so it can be done as
On 5/7/15 5:07 PM, Tab Atkins Jr. wrote:
I believe the SVGWG is fine with a parsing-based approach, exactly
like what HTML does. An SVG element created with mixed casing, or
imported from an XML document, might not match a lowercase tagname
selector, but SVG written in HTML will.
Hmm. The
On 5/7/15 10:53 AM, Rune Lillesveen wrote:
So there's no author-rationale here?
Well... that depends.
The way things used to work before SVG-in-HTML existed is that selector
matching was case-sensitive in SVG and apppeared case-insensitive in
HTML. I say appeared because it wasn't,
On 4/27/15 10:00 AM, Anne van Kesteren wrote:
Currently Chrome supports data URLs inside EventSource whereas in
Firefox EventSource is restricted to http/https URLs:
https://bugzilla.mozilla.org/show_bug.cgi?id=1156137
What's the convergence we want here?
Note that per current spec,
On 4/1/15 8:27 AM, James M. Greene wrote:
We had it but browser cendors abandoned its proper behavior [for some
historical reason unbeknownst to me]
The support signal (the hasFeature() implementation) was not in any way
coupled with the actual implementation.
So you would have cases in
On 3/24/15 4:06 PM, Tetsuharu OHZEKI wrote:
But I think that, why don't CanvasRenderingContext2D use restricted
float type defined in WebIDL if these methods ignore the value when
its is not finite?
Because they want to ignore the value.
By the current WebIDL spec
On 3/20/15 8:13 AM, Jake Archibald wrote:
Almost all the pieces already exist, except a way to get the image data of
a CanvasRenderingContext2D into a format that can be read from a
url.
There's CanvasRenderingContext2D.toDataURL; I assume the problem is that
it's not async, yes? But if
On 3/20/15 8:53 AM, Kenji Baheux wrote:
I believe that toDataURL is on Canvas not CanvasRenderingContext2D.
https://html.spec.whatwg.org/multipage/scripting.html#canvasrenderingcontext2d
The CanvasRenderingContext2D.canvas being null, there is no way to use it.
Oh. Yeah, that's silly; we
On 2/27/15 9:54 AM, David Bruant wrote:
I jumped a bit to conclusions quickly, but I think the point remains. If
the iframe is loaded in parallel (different thread, different process,
anything that isn't blocking the parent), then its loading doesn't block
the parent loading.
Sure it does, to
On 2/27/15 4:43 AM, David Bruant wrote:
It is my belief that providing the sandbox attribute should be a strong
enough indicator that the iframe could be fully run in parallel (not
just loaded async'ly).
Iframes are already loaded async, obviously.
It sounds like what's wanted here is more of
On 2/27/15 10:24 AM, Anne van Kesteren wrote:
On Fri, Feb 27, 2015 at 4:15 PM, David Bruant bruan...@gmail.com wrote:
To achieve this priorization, currently, authors would use a bit of JS to
delay adding the iframe to the document. It seems like it solves all the
issues listed in the original
On 2/27/15 10:15 AM, David Bruant wrote:
But for processor timeslices, the amount of blocking seems insignificant
compared to the current situation as long as you have the hardware to
run 2 threads in parallel, no?
Until the subframe spins up a dozen workers, yes.
To achieve this
On 2/27/15 10:35 AM, Fady Samuel wrote:
I've started thinking about better iframes lately and I've been
thinking along the lines of async iframes as well. If you start adding
iframes onload, are you not forcing relayout?
You can add whenever and set src onload.
Of course the more complicated
On 2/27/15 10:06 AM, Anne van Kesteren wrote:
Yes, less important and therefore should not block the load event or
any UA notion of complete.
Hmm. Not blocking the load event is interesting. Right now, even
defer scripts and whatnot block the load event. Experimenting with an
opt-in way
On 2/27/15 2:18 PM, Tim Streater wrote:
One thing I'd like would be to be able to put content into an iframe (and thus
have it parsed), but defer any rendering or speculative download of resources
referred to in the content.
Depending on whether you care about the href of your iframe and
On 2/13/15 10:15 AM, David Sheets wrote:
I suppose currently Chrome is preventing copying hidden content but
Firefox is not and neither picks up the CSS content.
Both prevent copying hidden content, but may not have identical
definitions of hidden.
Neither picks up CSS generated content,
On 1/7/15 3:55 PM, Nicholas C. Zakas wrote:
Yeah, that works well if you're dealing with bleeding-edge browsers
only. Not so much elsewhere.
Non-bleeding-edge browsers would also have the existing
window.opener.location.href behavior, right? As in, asking for a spec
change to the way the
On 1/5/15 5:17 PM, Nicholas C. Zakas wrote:
Basically window.opener.location.href = whatever works all
the time, regardless of origin restrictions, and pretty much works that
way across all browsers.
This seems to indicate that this behavior isn't allowed:
On 1/6/15 3:10 PM, Nicholas C. Zakas wrote:
Yes, if we do it with window.open(), then it's possible to set opener to
null. However, if you click on a link with target=_blank, window.opener
is set as well.
Not if you use rel=nofollow, per spec. Browser support there is still
spotty but
On 1/6/15 3:43 PM, James M. Greene wrote:
The spec doesn't mention that `rel=nofollow` should null out
`window.opener`. That behavior is only mentioned for `rel=noreferrer`.
Er, you're right. I meant noreferrer.
-Boris
On 1/5/15 8:14 PM, Mat Carey wrote:
even when the two windows have different domains
Basically window.opener.location.href = whatever works all the time
Looks like Chrome, Firefox and Opera already differentiate between window origins
when the example is changed to
On 12/2/14, 7:46 AM, James M. Greene wrote:
1. Is there any existing way or guidance for browser vendors on how to
confirm that a plugin can be secured and thus allowed to be instantiated
within a sandboxed iframe?
As far as I know, there is not. For Gecko there definitely is not.
2. Is
On 12/2/14, 8:01 AM, James M. Greene wrote:
So, it sounds like sandboxed iframes will probably /never/ support
plugin instantiation -- even if such a plugin were hosted on the same
origin as both the iframe page /and/ top-level page.
For Gecko it depends.
For example, we plan to ship a PDF
On 11/10/14, 9:23 AM, Florian Rivoal wrote:
that authors occasionally ask for by the ability to style the label based on
the state of the labeled control
The label, or the labels?
The problem of hover the control if the label is hovered is simple:
the label already has a reference to the
On 11/10/14, 5:31 PM, Florian Rivoal wrote:
That said, the labeled control also maintains a list of references to the
associated labels, so there is no particular difficulty involved in finding
them.
The difficulty is not finding them. The difficulty is efficiently
updating hover state on
On 10/7/14, 11:39 AM, Glenn Maynard wrote:
Firefox has had a ticket open for this for about half a
decade
It's fixed and the fix is shipping in Firefox 33 in a week.
-Boris
On 10/1/14, 1:59 PM, David Dorwin wrote:
Rejection also has the advantage of providing an exception, which can
provide information (reason and message) to differentiate between
potentially multiple causes. This is not possible when resolving with null.
Providing such information would likely
On 9/12/14, 2:34 PM, Domenic Denicola wrote:
Thank you for writing this up. This is definitely an area that needs
improvement.
As usual, if one or both of these events is missing listeners, nothing will
happen.
I'm not sure that's usual.
Specifically, an observable case that's worth
On 9/12/14, 3:19 PM, Domenic Denicola wrote:
If there is no listener for either when the promise would normally fire error, but then a
listener for rejectionhandled gets added before a .catch() call on the
promise, does the listener get called?
No.
That's not compatible with the events
On 9/12/14, 3:45 PM, Domenic Denicola wrote:
var p = Promise.reject(new Error(boo));
setTimeout(() = {
window.onrejectionhandled = () = console.log(got here);
}, 100);
setTimeout(() = {
p.catch(() = {});
}, 200);
That's a good proxy for what I was envisioning...
In this case the
On 9/12/14, 4:07 PM, Domenic Denicola wrote:
To state what happens in that scenario more clearly:
- `error` is fired at time zero. Nobody is listening.
- `rejectionhandled` is fired at time 200 ms. Somebody is listening, and got
here is logged.
OK, good. We're on the same page!
-Boris
On 9/2/14, 4:34 AM, Yoav Weiss wrote:
* They're likely to add implementation complexity, since these instructions
must be read by the preloader, which at least for Blink Gecko is on the
parser thread, and cannot do JS AFAIK.
Fwiw, in Gecko it could, but it would add some overhead to that
On 8/28/14, 5:31 PM, Yoav Weiss wrote:
Wouldn't that be something that is best handled as part of HTTP? e.g.
sending a flag with the request indicating whether the resource can be
progressively decoded or not?
Can we define progressively decoded?
Firefox is moving to a setup where we will
On 8/8/14, 8:43 PM, Rik Cabanier wrote:
The problem is that a large number of drawImage calls have a lot of
overhead due to JS crossings and housekeeping.
Could we please quantify this?
I measured the JS crossings part of this, because it's easy: Just have
the C++ side of drawImage return
On 8/8/14, 9:46 PM, Justin Novosad wrote:
The way you measured the JS crossing time does not include parameter
validations if I am not mistaken.
It includes the validation Web IDL does (e.g. this is an
HTMLImageElement) but not the specific validation this method does,
correct.
If you
On 7/24/14, 2:10 AM, Jukka K. Korpela wrote:
I’m afraid the fix does not work.
Sure it does.
Testing the jsfiddle code there,
http://jsfiddle.net/tatesn/hVv72/
in the newest Firefox (31.0, on Win 7)
The newest Firefox you should be testing in for everything except
what do shipping UAs do
On 7/24/14, 3:13 PM, Jukka K. Korpela wrote:
So how have authors handled the issue in the current situation where
browsers fail to support tabindex values 32767 and do that
inconsistently?
By not using tabindex on those forms and possibly having sucky keyboard
navigation.
Having that many
On 7/24/14, 1:29 AM, Jukka K. Korpela wrote:
However, browsers actually impose an upper limit of 32767
In Chrome and Firefox, values larger than this are interpreted as 0.
In the case of Firefox, this was a bug, that was fixed a few months ago.
See
On 7/22/14, 7:46 AM, milakam wrote:
Guess it could be similar to the beforescriptexecute
So you don't care if the script data is loaded (by the preload scanner),
only whether it's executed?
-Boris
On 7/22/14, 2:01 PM, Ben Maurer wrote:
One advantage of doing this is that if there is some use case a site has
that isn't met by the dependency model they can still manually separate the
fetch of an object from its insertion into the DOM.
One issue worth considering here: there are various
On 7/22/14, 2:57 PM, Ben Maurer wrote:
Nothing prevents a website from downloading content via fetch/XHR and
simply inserting that text into the DOM.
Yes, I know that. But we're trying to develop a better API so sites
won't need/want to do that anymore, right? All I'm saying is that we
On 7/22/14, 7:07 PM, Ben Maurer wrote:
var myfetch = window.fetch('my.css', {'fetch-as': 'stylesheet'});
myfetch.then(function(resp) {
document.body.appendChild(resp.body.asStyleSheet());
});
Boris, Will -- would this setup address the concerns you have about the
problems websites that use
On 7/21/14, 12:42 PM, milakam wrote:
If the alert scripts are referenced as external js files it will alert
good.js in Chrome.
http://jsfiddle.net/59Sxf/1/ seems to disagree.
This doesn't sound too bad Safari 5.0 and later (and other WebKit-based
browsers) generates a beforeload event before
On 7/21/14, 1:13 PM, Boris Zbarsky wrote:
http://jsfiddle.net/59Sxf/1/ seems to disagree.
Er, sorry, I failed to actually test it in Chrome.
And my original fiddle with data: URIs had a quoting issue which meant
it wasn't testing the behavior.
So I agree with you about what Chrome's
On 7/21/14, 1:21 PM, Boris Zbarsky wrote:
That said, Chrome's behavior is not useful for your purposes for
script-inserted scripts, since those do prepare a script before the
mutation observer fires...
And for parser-created scripts I expect Chrome doesn't prevent the
preload, but haven't
On 7/20/14, 5:21 PM, milakam wrote:
A BeforeLoad replacement was never discussed as a target use case for
MutationObservers, therefore this message.
MutationObservers happen when the DOM is modified.
Loads geneally speaking start off the preload scanner, before the DOM is
even constructed.
On 7/14/14, 3:35 AM, Anne van Kesteren wrote:
Is this observably different from
a target=_blank rel=noreferrer
somehow?
I think for a sandboxed iframe it might be...
Which raises a separate question, by the way: should a sandboxed iframe
(without allow-popups, in case that matters) be
On 7/8/14, 10:28 AM, Brian Blakely wrote:
Thank you for this information, Boris. Did you collect this with
Firefox's own devtools?
With about:memory, to be precise.
I'd like to set up a full-view Canvas document and see how it profiles.
Please do!
FWIW, memory is one of several
On 7/2/14, 3:21 PM, Rik Cabanier wrote:
facts = 2 implementations. I certainly didn't say anything else.
You said, and I quote:
That thread concluded with a let's see how this feature is going to
be used before we commit.
Anyway, 2 implementations is a necessary condition for a REC, not
On 6/26/14, 10:39 AM, Tim Marinin wrote:
If not, then why we need link for css, only for legacy reasons?
Pretty much, yes. If style were allowed in head, we could just do
style src (and in fact Gecko had support for that at one point).
-Boris
On 6/26/14, 2:57 PM, Тимофей Маринин wrote:
Do you mean if style src were supported?
No, I mean what I said. But looks like style doesn't autoclose
head, in fact; I thought it did.
-Boris
On 6/18/14, 8:59 AM, Robert O'Callahan wrote:
For example, SVGIframeElement as specced has two
width attributes.
Which actually means the IDL will fail to be parsed with a conforming
Web IDL parser.
SVGIframeElement implements HTMLIFrameElement creates a multiple
inheritance situation that
On 6/2/14, 5:19 AM, Anne van Kesteren wrote:
This is not the case in Chrome and we'd like this to be no
longer the case in Gecko.
Note that it's not clear to me what we means in this case. For
example, I'm unconvinced we want to change Gecko behavior here.
And then it would only be set
On 6/2/14, 9:00 AM, Anne van Kesteren wrote:
You're not persuaded by the attack scenario?
Correct. I mean, the same scenario applies to srcdoc, document.write()
into an iframe, etc. Why are data urls special?
Provided we agree that it is always unset after any redirect, yes.
We agree
On 6/2/14, 10:15 AM, Anne van Kesteren wrote:
The attack is the URL. A developer has to specifically consider data
URLs and realize their implications.
Note that this is already true for javascript: URLs in @src values (but
not in location sets and the like, I agree).
-Boris
On 5/29/14, 5:13 PM, Glenn Maynard wrote:
Assembly language is inherently incompatible with the Web.
A SIMD API, however is not. Under the hood, it can be implemented in
terms of MMX, SSE, NEON, or just by forgetting about the SIMD bit and
pretending like you have separate operations. In
On 5/13/14, 10:11 AM, James Graham wrote:
I think the problem that I have with this API is the number of cores
that exist isn't obviously a good proxy for the number of cores that
are available. It I have N cores and am already using M cores for e.g.
decompressing video, N-M is probably a much
On 5/7/14, 1:51 AM, Brian Birtles wrote:
This time is measured from navigationStart
It's probably better to say that it's measured from the same 0 point as
performance.now(), since there is no navigationStart in workers but
there are events there.
-Boris
On 5/7/14, 6:43 AM, Anne van Kesteren wrote:
Is there a good reference somewhere for what the time would be relative to?
https://w3c.github.io/web-performance/specs/HighResolutionTime2/Overview.html#sec-time-origin
seems like the right thing.
-Boris
On 5/6/14, 5:30 PM, Rik Cabanier wrote:
Leaving the question of fingerprinting aside for now, what name would
people prefer?
mauve?
Failing that, maxUsefulWorkers?
-Boris
On 5/4/14, 9:49 AM, Adam Barth wrote:
Maybe navigator.hardwareConcurrency as a nod to the C++11 name?
What is the proposed behavior of this attribute on AMP (as opposed to
SMP) systems? Note that some of these are shipping in actual devices
today, and I expect that to continue.
-Boris
1 - 100 of 1308 matches
Mail list logo
