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? A
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" incarnation,
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 top/
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, b
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 for
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
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 unsafe-in
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 f
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 spe
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
in
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
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 outcome
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 significa
On 10/14/15 5:47 AM, Михаил Гаврилов wrote:
2015-10-14 0:41 GMT+05:00 Boris Zbarsky :
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 doing it right now, and
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 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
whi
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 bro
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 naming/beh
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 a
On 6/16/15 1:57 PM, Anne van Kesteren wrote:
On Tue, Jun 16, 2015 at 7:51 PM, Boris Zbarsky 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 you
On 6/16/15 1:18 PM, Anne van Kesteren wrote:
On Tue, Jun 16, 2015 at 7:01 PM, Boris Zbarsky 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 to real
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 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/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
-Boris
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 url
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)
characte
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 mai
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, actually
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 equ
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, EventS
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/31/15 2:18 AM, Roger Hågensen wrote:
What type of iframes would benefit from this?
Ads, from a user point of view.
Now getting them to opt in to being throttled...
-Boris
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
(http://heycam.github.io/we
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 shou
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 you'r
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 whet
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:24 AM, Anne van Kesteren wrote:
On Fri, Feb 27, 2015 at 4:15 PM, David Bruant 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 message (load UI, l
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 wa
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 priorization
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 t
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 o
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, b
On 2/9/15 8:45 PM, Domenic Denicola wrote:
- Queue a task that occurs after all other tasks
On many web pages, this would effectively mean "never" because they post
tasks all the time...
-Boris
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 hre
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/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 impro
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
window.opener.location.hr
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:
https://html.spec.whatwg.org/#allowed
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 vie
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. I
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 t
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 t
On 10/15/14, 10:15 AM, Mike West wrote:
`FormData` objects created from forms including these writeonly elements
would be "opaque". You could use them to submit an XHR request, but you
couldn't read the values directly from script.
If you're at the point where you can run script on the page, ca
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 make
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/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 t
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 a
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 co
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 th
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 pr
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 ha
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 i
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, 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 d
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 https://bugzilla.mozilla.org/show_bug
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 XH
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
shou
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 sit
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/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
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 Chr
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 befo
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
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 able to do this?
-Boris
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 optimizat
On 7/7/14, 6:58 PM, Brian M. Blakely wrote:
I am not a browser developer, I am a Web developer, but it stands to reason
that (as stated in the OP) there may at least be a fruitful memory savings
I just measured in Firefox 30, and a bare-bones document (about:blank)
uses approximately 550KB of
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 7/1/14, 10:18 PM, Ryosuke Niwa wrote:
Could you point me to a specific test case that demonstrates the difference?
http://fiddle.jshell.net/t4sgd/show/
Chrome and Firefox alert "true"; IE alerts "false". The spec says
"false" should be alerted.
-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
On 6/26/14, 10:39 AM, Tim Marinin wrote:
If not, then why we need for css, only for legacy reasons?
Pretty much, yes. If
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 t
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 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
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 f
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 pa
1 - 100 of 1380 matches
Mail list logo