Re: [whatwg] RadioNodeList and buttons
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
Re: [whatwg] RadioNodeList and buttons
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?
Here is my question: if the UA handles this situation without a glitch,
wouldn't you expect the corresponding DOM API to expose the same behaviour?
I just checked one UA (Firefox), and the way it handles this situation
is that it stores the "submitter" (in the sense of the argument to
) on the
"submit" event itself. Exposing it as a property on that event would
make a lot of sense to me.
-Boris
Re: [whatwg] [csswg][css-display] Updated WD of CSS Display L3
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 in a flex container overrides the outer display type of an element: https://www.w3.org/TR/css-flexbox-1/#flex-items In other words, the run-in/inline/block distinction is ignored within a flex container. Sure, but my point wasn't whether the behavior is _defined_. It's that defining it requires thinking about the various cases, and having run-in makes for more cases to think about. -Boris
Re: [whatwg] [csswg][css-display] Updated WD of CSS Display L3
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? And did that require any thought about interactions? -Boris
Re: [whatwg] [csswg][css-display] Updated WD of CSS Display L3
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, adding any new display type has to consider how it interacts with run-in. Adding anything that rearranges things in terms of layout (e.g. shadow DOM, flexbox, grid, etc) has to consider how it interacts with run-in and whether the result makes any sense. Adding any structural pseudo-elements, have to consider run-in (note that the run-in spec already has to specify interactions with ::marker and ::before). That's on the specification side. On the implementation side, run-in makes all sorts of element insertion/removal either slow or complicated or both, because you have to deal with it affecting the run-in situation. Who knows. Some of us are new enough to this discussion that we may not know of all the arguments that had been presented against it in the past. Anyway, what I suggest is writing _very_ thorough run-in tests, including all the dynamic mutation cases. Something akin to what you see in https://bugzilla.mozilla.org/attachment.cgi?id=421975 but targeting the current spec. I should note that at the point when I wrote those tests, they mostly failed in all implementations; a bunch of them crashed in various implementations. I'd hope the new text is at least easier to implement sanely, but I'm not holding my breath too hard on it... -Boris
Re: [whatwg] [csswg][css-display] Updated WD of CSS Display L3
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, introduces an amount of complexity to both specification and implementation that is wholly disproportionate to its value as a feature. It will complicate attempts to add other, much higher value, features to CSS, again both in terms of specification and implementation. I think we would be better off not adding this feature. -Boris P.S. I don't see much point filing this as a github issue, since this really isn't the sort of comment that lends itself to discussion on github. And again, I don't expect this mail to actually change anything. But I felt like I had to try one last time...
Re: [whatwg] window.innerScreenX and window.innerScreenY
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
Re: [whatwg] window.innerScreenX and window.innerScreenY
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/left edge of the browser window, not of the content are the web page is rendered into. So if you have a screen coordinate and you want to translate it into page-relative coordinates, this won't do what you want: you'll be off by the size of the window decorations and the browser chrome. -Boris
Re: [whatwg] Media query for bandwidth ??
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, but similar things can happen when things are docked/undocked, monitors are plugged in or removed, etc. -Boris
Re: [whatwg] window.opener security issues (Was: WhatWG is broken)
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 purposes of this discussion. At least historically, the on* attributes were not allowed, the style attributes were not allowed, and any script nodes in the body were not allowed. If you specify script-src and style-src and don't include 'unsafe-inline', sure. If CSP now allows them by default then I am not very happy about that CSP allows the things you don't issue directives for. If you don't issue any script-src directives (or default-src directives), then there won't be any limitations on scripts. -Boris
Re: [whatwg] window.opener security issues (Was: WhatWG is broken)
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 [1] https://www.w3.org/TR/2012/CR-CSP-20121115/
Re: [whatwg] window.opener security issues (Was: WhatWG is broken)
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-inline, but does nothing about
inline CSS:
body { color: green; }
This is green
alert("I am not alerted")
I believe there now are CSP parameters that relax those prohibitions but
from I understand they are only relaxed when a hash of the inline
scripts / CSS is declared in the head.
That's ... not correct. Simple example; compare it to the previous one:
body { color: green; }
This is green
alert("I am alerted")
and that too isn't
compatible with CSP where the scripts need to be defined in the head
Uh... No, they do not. Neither of my examples above has a
Re: [whatwg] window.opener security issues (Was: WhatWG is broken)
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 a much stronger guarantee. The guarantee is that the parent and the created window have no way to see each other at all. Neither one can read any state from the other, or even know the other one exists. In particular, the idea is that rel="noopener" allows the new window to be opened in a separate process, or even a separate browser if desired. The only difference between it and the user copying the link and then pasting it into some other tab or other program is that a referrer header is sent. Note that this guarantee makes for fairly simple implementation. Having a header that opts in all links targeted at anything other than _parent, _self, and _top have the noopener behavior would be doable. Having a header that opts in some links based on the origin of the link href or something would probably be doable. Having a header that tries to add some sort of new mode wherein the two windows _can_ see each other but can't do some things that they can normally do would be a snake pit of complexity that is best avoided. -Boris
Re: [whatwg] How can a server or serverside script identify if a request is from a page, iframe or xhr?
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 fundamental assumption here is that the user is NOT the attacker, and hence the user's browser is cooperating with the web page to protect the user. It's a perfectly fine tool for the "user and page author are cooperating" threat model. If, on the other hand, your threat model includes attacks by the _user_ on your server, you absolutely can't rely on CSP to defend against that. Most simply, the user can use a browser that doesn't support CSP. For addressing this class of attacks, you _have_ to rely on a completely server-side solution, because by assumption the client (the browser) is the attacker in this situation. -Boris
Re: [whatwg] [css-display] CSS Display Review
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
Re: [whatwg] [css-display] CSS Display Review
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 spec is not clear enough: one of you two is wrong, which isn't really a situation that should arise with a clear spec. -Boris
Re: [whatwg] Reviving ImageBitmap options: Intend to spec and implement
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 e.g. https://github.com/whatwg/html/pull/608 where I chose the same initial crossOrigin design and Anne convinced me to move to credentials. I imagine we'll continue to use crossorigin="" and corresponding reflected crossOrigin IDL attributes for any HTML elements, but for JS-only APIs RequestCredentials is the way to go. That's not _quite_ the same thing. The HTML setup basically lets you specify one of: 1) No CORS (attr not set). 2) CORS, RequestCredentials == "include" (crossrigin="use-credentials") 3) CORS, RequestCredentials == "same-origin" (any other attr value) Note that in the pull request you reference your default was not actually any of those situations, as far as I can tell, so I agree that using "crossOrigin" there was not a good fit. But for the ImageBitmap case, we do want to support case 1 above, at least assuming tainted ImageBitmap is a thing. If it's not, then I agree that just a RequestCredentials value is probably sufficient and all the loads involved should use CORS. That said, the actual phrasing around "crossOrigin" in https://wiki.whatwg.org/wiki/ImageBitmap_Options doesn't make much sense (e.g. it in fact is not a "CORS settings attribute" because it's not a markup attribute at all). But we can wordsmith it better once we agree on what we actually want it to do. -Boris
Re: [whatwg] Opinions on window.console = "foo", and other oddities of window.console
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 of the discussions about possibly having "interface console" and having all the methods be statics? If we don't want to go that route, then we should do the [Replaceable] thing instead, imo. -Boris
Re: [whatwg] Opinions on window.console = "foo", and other oddities of window.console
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 happened to work the way it did. This should not be construed as me arguing against changing the behavior; just a note that it's not as simple as flipping a switch back to something we already had at some point. But I also don't think it would be super-difficult to do... just a bit time-consuming. So the hard part will be finding someone with the time to do it. -Boris
[whatwg] Using time-origin-relative times for the .timeStamp property of animation events is not web-compatible
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
Re: [whatwg] Splitting CanvasRenderingContext2D
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 in practice I believe UAs mostly do it in the IDL order. Normally I wouldn't worry about it, but there is known content out there that depends on the enumeration order of _some_ things on this particular interface. See https://bugzilla.mozilla.org/show_bug.cgi?id=631117 and https://bugzilla.mozilla.org/show_bug.cgi?id=623437 (note that these are about different URLs, though caused by the same underlying issue). In practice I expect that an interface split that keeps arc() and arcTo() together in this case will be OK. I just want to point out that the risk here is sadly nonzero. -Boris
Re: [whatwg] Proposal for showing thousand separator in form controls.
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 what sort of "number" you're showing. -Boris
Re: [whatwg] Proposal for showing thousand separator in form controls.
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 significance and will always be clipped in numbers. For such cases, it is necessary always use text or masked text. And yet people consistently try to use for these. For credit card numbers it's silly, but for hours/minutes it's not unreasonable, if only to get the little up/down spinners. Yes, the fact that people are trying to shoehorn a wide variety of quite different use cases into is unfortunate. -Boris
Re: [whatwg] Proposal for showing thousand separator in form controls.
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 doing it right now, and people do not expect to see "2,015" as the year. They just don't. Sooner or later year will be five-digit and more You mean "later", right? ;) Seriously, I expect the computer interaction modalities to be quite different by then, assuming the concept even makes sense at that point. And in general I think for selecting date should be used for special types of input: type="month" type="year". That's great, and I agree, but that's not what people are doing in practice. -Boris
Re: [whatwg] Proposal for showing thousand separator in form controls.
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 to this sort of formatting, but the issues raised regarding editing in that bug report would still need to be sorted out... -Boris
Re: [whatwg] Handling out of memory issues with getImageData/createImageData
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
Re: [whatwg] DOM Events Proposal: EventListenerOptions 'mayCancel' for improved scroll performance
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 expect that in practice in the cases that matter the maybe case is the common one. In particular, I expect that the maybe case includes the following situations: 1) someObject[someName].call(event); 2) someFunctionThatIsNotInlined(event); 3) event[someName](); Of these, I expect #2 to be the most common, then #1, then #3... and I expect #2 to be _very_ common. A simple way to determine the no case could be to identify handlers with no parameters at all, e.g: Are these common in the case of the events we're talking about here? (Also, that's assuming window.event doesn't exist, and while that assumption is kinda ok today if you're writing cross-browser code that may cease being the case in the near future if Gecko ends up having to implement window.event.) -Boris
Re: [whatwg] DOM Events Proposal: EventListenerOptions 'mayCancel' for improved scroll performance
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 browser knows about those dictionary properties. Also, I think that this would make good sense as part of DOM itself, This spec requires changes to DOM anyway, because the spec as written is not valid IDL: It's creating two overloads that can both be called with two arguments. So we'll need to remove the optional annotation from the boolean arg that's already in DOM when we add this new overload. That doesn't seem like a problem. -Boris
Re: [whatwg] DOM Events Proposal: EventListenerOptions 'mayCancel' for improved scroll performance
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 while keeping the overload a boolean and dictionary setup. -Boris
Re: [whatwg] Proposal: Two changes to iframe@sandbox
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/behavior? I personally can probably can... I can't promise anything about how people will respond to an intent to implement for such a thing. -Boris
Re: [whatwg] Relative URL plan
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 you? If it's something you want to reason about as a separate entity, why doesn't it make sense to set it as a separate entity? -Boris
Re: [whatwg] Relative URL plan
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 to really reason about. Hence my question: which schemes are not special, widespread, and actually use '?' to mean something? Specific use cases for this would make it clearer whether mutating the query is a meaningful operation. -Boris
Re: [whatwg] Relative URL plan
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
Re: [whatwg] Relative URL plan
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 describe as non-relative URIs (as in, it's considered part of scheme data for our purposes and we don't parse that at all) so I'm not sure what use cases there might be for it. What are examples of non-relative URIs that use query? mailto:, I guess? -Boris
Re: [whatwg] Relative URL plan
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 are we talking about here, specifically? Note that my general view for how URL objects should work internally in Gecko is that we should have an immutable backing store and mutators that clone-with-modifications (basically copy on write). Of course in terms of the web-exposed behavior we'd just have the web-exposed URL change which internal object it points to on mutation, so we can expose whatever mutators we want. -Boris
Re: [whatwg] same origin iframe relative paths
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
Re: [whatwg] same origin iframe relative paths
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. That sounds quite odd, and doesn't match the behavior of any browser I'm aware of. Do you happen to have a link to a page that shows the behavior you're describing? Does anyone know what the correct behaviour of the iframe should be in these circumstances? The correct behavior is that relative URLs in an iframe use the base URL of the iframe, which is the document URL of the iframe unless there's a base tag or the document URL is about:srcdoc or about:blank or javascript:something (and possibly some complexity around iframes whose content was generated via document.open/write/close). -Boris
Re: [whatwg] An API for unhandled promise rejections
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. Presumably whatever the new events are would also get propagated from worker global scope to worker? Event names in the web platform are typically lowercase, not camelCase. It's hard to say what this you're talking about implementing in Chrome in terms of the task-queueing behavior. Is that something you just haven't decided on yet? Past that, I'm not sure we have any particular thoughts on the details here so far... -Boris
Re: [whatwg] Case-sensitivity of CSS type selectors in HTML
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 = (character | $0020) EndIf Yes, this is basically the algorithm that would be considered expensive case-insensitive matching in this context. In optimized C or or ASM this should perform really well compared to calling a Unicode function to normalize and lower case the text. No one is even remotely considering anything Unicode here. -Boris
Re: [whatwg] Case-sensitivity of CSS type selectors in HTML
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 equality comparison on interned string representations instead of needing expensive case-insensitive matching on hot paths in the style system. Should we change the spec in this regard? To what, exactly? What is your proposed behavior here? -Boris
Re: [whatwg] Case-sensitivity of CSS type selectors in HTML
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 main problem here is for scripts that create SVG elements in an HTML document, since those have to use createElementNS and pass the mixed-case names (e.g. for foreignObject). -Boris
Re: [whatwg] Case-sensitivity of CSS type selectors in HTML
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: if you created an
HTML element with local name Foo (e.g. via createElementNS or
importNode from an XHTML document) then the selector foo would not
match it in at least some implementations.
When we were trying to design how this should work in a document with
mixed HTML and SVG, we aimed to preserve the existing behaviors of HTML
and SVG while also not forcing UAs into doing any actual
case-insensitive matching at selector-matching time, which allows much
faster compares on pre-interned strings.
The depends part is whether you consider aimed to preserve the
existing behaviors of HTML and SVG as author rationale or not.
Note that at least for textArea this matters, in that you could
suddenly have selectors that are not meant to match it start matching it.
You mean case-sensitively in the implementation? Type selectors are
case-insensitive for html elements.
style
* { color: green }
foo { color: red }
/style
script
var e = document.createElementNS(http://www.w3.org/1999/xhtml;, Foo);
e.textContent = Is this red?;
document.documentElement.appendChild(e);
script
If the matching were actually case-insensitive, the text would be red.
It's not.
The WebKit implementation represents each type selector with two
strings, one lowered and one with original case, when the type
selector is not lower-cased in the source. What does Gecko do?
Exactly the same thing.
To always match type selectors case-insensitively in html documents.
I don't think that's acceptable to at least Gecko from a performance
standpoint. Not if it means we have to end up with red text in my
testcase above.
-Boris
Re: [whatwg] EventSource and data URLs
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, EventSource is supposed to support whatever fetch supports. I haven't tested whether Chrome in fact does that (e.g. whether it supports EventSource over FTP or blob: or whatnot). -Boris
Re: [whatwg] Supporting feature tests of untestable features
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 which hasFeature() claimed false even though the browser supported the feature, cases in which hasFeature() claimed true even though the browser didn't support the feature, and cases in which the browser had somewhat rudimentary support for the feature but hasFeature() claimed true because of various market pressures. This was especially driven by the coarse nature of the features involved -- you could at best ask questions like is this spec supported?, not is this particular piece of functionality supported?. That works OK for small targeted specs, but the W3C wasn't so much in the business of doing those. The upshot was that in any sort of interesting case hasFeature was useless at best and misleading at worst. We are running into the exact same issues with the HTML Clipboard API being unreliably detectable. Even more troubling, this is especially true because it is already partially supported (paste events) in some browsers (e.g. Chrome), not at all supported in others, and fully supported in none. So let's consider this case. How would a hasFeature deal with this situation? At what point would you expect it to start returning true for the clipboard API? -Boris P.S. Looking over the clipboard API, it seems like it really has the following bits: 1) The various before* events, which would be detectable if the spec added the corresponding onbefore* attributes to someplace, and 2) The copy/paste/etc events, which could likewise be detectable with on* attributes. Am I missing something else that is not detectable for fundamental reasons?
Re: [whatwg] Why CanvasRenderingContext2D uses WebIDL unrestricted float type?
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/webidl/#es-double), restricted values, 'float' 'double', will raise TypeError in conversion phase under ECMAScript environment if the passed value is a NaN or +-Infinity. Exactly. That's not the same thing as ignoring the value. For the purpose to ignore non-restricted values, I feel that it's more better to restrict by IDL type. Not if you want to actually _ignore_ the value (as opposed to throwing an exception). -Boris
Re: [whatwg] Canvas image to blob/dataurl within Worker
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're inside a worker anyway, do you care? -Boris
Re: [whatwg] Canvas image to blob/dataurl within Worker
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 should add something to do this. -Boris
Re: [whatwg] iframe async
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 the extent that there is congestion on the TCP level, contention over processor timeslices, etc. I mean, it's not blocking in the sense that the parent can't finish until the iframe does, but it _can_ slow down the parent in various ways. I don't understand the concern with the shared net connection. Does the spec mandates the order of resource loading between parent and iframe? No, it does not. UAs use various heuristics for it right now. What's being proposed, afaict, is a way of providing a hint to those heuristics to deprioritize the iframe in question. If not, then browsers have enough liberty today to prioritize parent's resource loading over iframe without the need of an opt-in from devs, maybe? They have the liberty, but they don't always have enough information to know when to prioritize what. Please define async loading in the context of your question? What I meant was loading that doesn't block parent's loading. Loading iframes never blocks the parent's loading in the sense that you seem to be thinking of it. -Boris
Re: [whatwg] iframe async
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 a load this at lowest priority, which has nothing to do with whether it's running in the same thread (what I assume you mean by parallel) or not: either way the net connection is shared, right? Can async loading be retroffited into sandboxed iframes? Please define async loading in the context of your question? -Boris
Re: [whatwg] iframe async
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 message (load UI, load event, fast back). Delay until what point? onload, if you don't want it to block onload. -Boris
Re: [whatwg] iframe async
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, currently, authors would use a bit of JS to delay adding the iframe to the document. ... What is the significant benefit to adding an HTML attribute to solve this problem? This is a good question, yes. -Boris
Re: [whatwg] iframe async
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 the setup gets, the more desirable it is to have sugar for it. ;) In an iframe async world, you can compute the layout of the top level frame before beginning to load the content of the iframe. Modulo seamless iframes we have so many moving parts. -Boris
Re: [whatwg] iframe async
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 to not block it for iframes could be exciting. yes. -Boris
Re: [whatwg] iframe async
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 whether you want it sandboxed and so forth: var parsedThing = new DOMParser().parseFromString(myString, text/html); // Process parsedThing however you want. myIframe.contentDocument.replaceChild( parsedThing.documentElement, myIframe.contentDocument.documentElement ); -Boris
Re: [whatwg] Unicode - ASCII copy/paste fallback
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, because both represent selections in terms of DOM ranges, and DOM ranges can't represent CSS generated content... -Boris
Re: [whatwg] Clarification for window.opener.location.href
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 href setter works to work around lack of support for another part of the spec (rel=noreferrer) is only useful if you assume browsers would implement the change to the setter faster than they'll implement support for rel=noreferrer. I personally don' find that very likely, since rel=noreferrer is already shipping in at least Chrome and Firefox and doesn't require nearly the amount of web compat testing that the other change would. Or is the above just a general complaint, as opposed to a reason to change the behavior of the href setter? -Boris
Re: [whatwg] Clarification for window.opener.location.href
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-to-navigate Why not? Stepping through the allowed to navigate algorithm for this case, assuming window.opener is a toplevel browsing context: 1) B is a toplevel browsing context, so this item does not apply. 2) A is not sandboxed so this item does not apply. 3) A is not sandboxed so this item does not apply. 4) We allow the navigation. Am I just missing something? If B _isn't_ a toplevel browsing context, then we'd still skip step 1 because A is not sandboxed... This issue is pretty big for sites that host user-generated content, as it's easy to create an attack, such as: 1. Go to a UGC site that allows uploading files with embedded links. 2. Upload a file containing a link to an attacker's page. 3. When someone clicks the link So where in this process is the popup window opened? Is that done under the control of the file containing a link to an attacker's page or of the UGC site? Because the current spec mitigation for the problem you describe is that when a site opens a popup it can set its .opener to null to prevent it reaching back into the site that opened it, precisely because of the issue you described. So my question is: is the spec incorrect in that it should reflect reality? Or are browsers incorrect and we should be hounding them to fix this behavior? As far as I can tell, either you're just misreading the spec or I am. -Boris
Re: [whatwg] Clarification for window.opener.location.href
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 improving. Of course that affects more than just window.opener (e.g. affects whether a referrer is sent) -Boris
Re: [whatwg] Clarification for window.opener.location.href
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
Re: [whatwg] Clarification for window.opener.location.href
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.href=javascript:alert(‘Gotcha');” - if they’re on the same origin the alert is displayed, if they’re on different origins it’s not. This is a totally different issue. This case basically does an eval in window.opener, and has to be blocked if the setter is not same-origin to prevent cross-site scripting exploits. You can see this in the spec in https://html.spec.whatwg.org/multipage/browsers.html#navigating-across-documents step 15 the javascript: case, substep 1, which says: If the origin of the source browsing context is not the same origin as the origin of the active document of the browsing context being navigated, then act as if the result of evaluating the script was the void value, and jump to the step labeled process results below. Importantly, this is absolutely required to prevent XSS, as I said, and all browsers already do this and have since time immemorial, so no sites depend on this working. I guess it’s a logical that the existing restriction should be applied more widely. The wider application doesn't resolve immediate XSS issues, and is very likely to cause web compat problems. It's worth thinking about, but data on how serious the web compat issues are is key. And as noted sites have a way to opt in to more protection here already; the only thing we're discussing is the default behavior. -Boris
Re: [whatwg] Seeking clarification on sandboxed iframes and plugins (Flash, etc.)
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 there any existing way or guidance for library/plugin developers on how to provide appropriate metadata to the browser in order to allow a plugin to be considered secured and thus allowed to be instantiated within a sandboxed iframe? Again, as far as I know there is not. 3. Is this really just confusing/misleading text that may never actually correlate to a real implementation? The text is intended to allow people to develop such systems if they want to. I don't think any current UAs particularly want to. Note that making sure something with the API surface of Flash is secured would be quite an undertaking... -Boris
Re: [whatwg] Seeking clarification on sandboxed iframes and plugins (Flash, etc.)
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 viewer plugin (based on pdf.js) that we may decide to allow in sandboxed iframes. Will need to audit it a bit. For third-party plug-ins, I suspect the never answer is a good assumption for now. This mostly makes sense to me as you would only infrequently want to sandbox an iframe of your own site Actually, sandboxing iframes of your own site is one of the main sandbox use cases: it allows limited user upload of content without creating security holes, in theory. -Boris
Re: [whatwg] relationship between labeled control and label for :active and :hover pseudos
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 control it's labeling; when an element enters hover state you at worst have to deal with one other element (plus their ancestors) entering hover state. And even that gets a bit complicated given the ancestors thing. The backreference, however, is a one-to-many relationship, which makes things quite complicated, or fairly slow, or both, when multiple labels label the same form control. So I would be a bit careful here. -Boris
Re: [whatwg] relationship between labeled control and label for :active and :hover pseudos
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 the set of ancestors of all the nodes involved, some of which might still be in hover state when the control ceases to be. and when they do merge Detecting that things merge is ... not that fast. Not if you have to do it in realtime as the mouse moves, and have to do it pairwise on a bunch of nodes at once. All in all, while I agree this is potentially slower, I don’t think it will be significantly different in anything but pathological cases. Unfortunately, browsers have to be fast on pathological cases too, in practice. :( -Boris
Re: [whatwg] getting rid of anonymizing redirects
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
Re: [whatwg] Notifications: making requestPermission() return a promise
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 development and debugging easier. If you were designing a sync API, would not the same arguments apply? So you'd want to throw different kinds of exceptions to indicate not supported? -Boris
Re: [whatwg] An API for unhandled promise rejections
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 considering: if there is no listener for error but there is a listener for rejectionhandled, does the latter get called? 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? It seems to me like from a spec point of view if this sort of thing is done the events should fire unconditionally instead of depending on whether listeners exist, like other events in the platform. If there really are no listeners, such that UA shenanigans are not observable, UAs are free to perform those shenanigans, whatever they are. We would add a new event to the global, named `rejectionhandled`, along with a `RejectionHandledEvent` class that contains only a `promise` member. Worker globals too, right? What is the resulting interaction with onerror on the worker object itself? Would we grow an onrejectionhandled attribute on AbstractWorker as well? * When a promise is rejected, if it has no handlers, we would queue a task to potentially-fire-an-error. This presumably implies keeping the promise alive and not allowing the garbage collector to collect it until that task executes, right? -Boris P.S. I'm torn on whether to reuse existing onerror mechanisms for this or not...
Re: [whatwg] An API for unhandled promise rejections
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 always get fired, afaict Are we talking about different situations here somehow? This presumably implies keeping the promise alive and not allowing the garbage collector to collect it until that task executes, right? Interesting. This seems OK since it would only be until the queued task executes, which should be very soon. There's no obvious guarantee of that, especially in workers. But if this complicates implementations undesirably, we could fall back to integer IDs or something. The only important thing IMO is being able to match up `error` and `rejectionhandled` occurrences, and to me the promise itself was a good key. The promise itself can't be shipped out of the worker scope to the onerror on the Worker itself; that's why I was asking what we want to do with workers. If we want a unique key thing there we need some non-object (or at least structured clonable) key. -Boris
Re: [whatwg] An API for unhandled promise rejections
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 event would be fired
By the event do you mean the error event or the rejectionhandled event?
but no listener would be present at that time, so got here would not be
logged.
In my mental model based on your initial mail here, the rejectionhandled
event would get fired at the point when catch() is called, which is
after window.onrejectionhandled is set.
The promise itself can't be shipped out of the worker scope to the onerror on
the Worker itself; that's why I was asking what we want to do with workers. If
we want a unique key thing there we need some non-object (or at least
structured clonable) key.
Oh, hmm, I didn't realize you could listen to worker errors via
`workerInstance.onerror = ...` in the creating script; I thought you were
referring to `self.onerror = ...` inside the worker.
We have both. self.onerror gets first dibs at the error, and if it
doesn't do anything to prevent the error propagating, then
workerInstance gets an error event fired at it.
More reason for an integer key, I guess. (Call it promiseId, presumably?) The
alternative would be not letting you catch such errors via
`workerInstance.onerror`, but I assume that would just complicate things and
fit poorly with any telemetry frameworks that try to collect errors from both
the window and any spawned workers.
Yeah, I have no good insights into what, if anything, telemetry
frameworks do with error events on workers.
-Boris
Re: [whatwg] An API for unhandled promise rejections
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
Re: [whatwg] Preloading and deferred loading of scripts and other resources
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 thread (instantiating a JS runtime on it)... -Boris
Re: [whatwg] Preloading and deferred loading of scripts and other resources
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 progressively parse scripts, and possibly progressively bytecode-compile, and possibly progressively native-code-compile in the cases when we do AOT compilation, but obviously not progressively execute. -Boris
Re: [whatwg] [2D Canvas] Proposal: batch variants of drawImage
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 immediately. What I see if I do that
is that a drawImage call that passes an HTMLImageElement and two
integers takes about 17ns on my hardware in a current Firefox nightly on
Mac.
For scale, a full-up drawImage call that actually does something takes
the following amounts of time in various browsers I have [1]:
Firefox nightly: ~9500ns/call
Chrome dev: ~4300ns/call
Safari 7.0.5 and WebKit nightly: ~3000ns/call
all with noise (when averaged across 10 calls) that's way more than
17ns.
So I'm not sure JS crossings is a significant performance cost here.
I'd be interested in which parts of housekeeping would be shareable
across the multiple images in the proposal and how much time those take
in practice.
-Boris
[1] The specific testcase I used:
!DOCTYPE html
img src=http://www.mozilla.org/images/mozilla-banner.gif;
script
onload = function() {
var c = document.createElement(canvas).getContext(2d);
var count = 100;
var img = document.querySelector(img);
var start = new Date;
for (var i = 0; i count; ++i) c.drawImage(img, 0, 0);
var stop = new Date;
console.log((stop - start) / count * 1e6 + ns per call);
}
/script
Re: [whatwg] [2D Canvas] Proposal: batch variants of drawImage
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 have 1000 sprite draws that draw from the same sprite sheet, that is 1000 times you are verifying the same image parameter (verifying that the image is complete, that its security origin does not taint the canvas, fetch the decoded image data, etc.), even tough most of this stuff is cached, it is being looked up N times instead of just once. True. I just tested this in a Firefox nightly: I put the early return after we have looked up the decoded image data in our internal cache, or gotten it from the image if not cached, but before we've started doing anything with the position passed to drawImage. The internal cache lookup already includes checks for things like tainting, completeness verification, etc, since there is nothing in the cache if the image is not complete and the canvas is already tainted as needed if we have cached decoded data for this (image,canvas) pair. This version of drawImage takes about 47ns per call when averaged over 1e5 calls (of which, recall, 17ns is the JS call overhead; the other 30ns is the cache lookup, which hits). That's starting to creep up into the 1.5% range of the time I see drawImage taking in the fastest drawImage implementation I have on hand. I will prototype this and come back with some hard data. That would be awesome! -Boris
Re: [whatwg] Maximum value needed for tabindex
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 in this legacy situation? is the one you get from http://nightly.mozilla.org, just like you should be testing WebKit nightlies and Chrome canary (or dev, worst-case) builds. Firefox 31 is based on code that was feature-frozen 3 months ago, so if something is fixed a few months ago chances are it's not in 31. This particular fix is in Firefox 32. Are there any use cases for tabindex values greater than 32767? We've seen use cases for forms with that many form controls (large forms parts of which get conditionally shown/hiden based on values filled in for some of the controls), so I would think so, yes. -Boris
Re: [whatwg] Maximum value needed for tabindex
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 controls is rather exceptional, but there's more: tabindex attributes are needed only when you need to make the order of controls in source different from the tabbing order. Sure. -Boris
Re: [whatwg] Maximum value needed for tabindex
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.cgi?id=996095 1) Keep tabindex unlimited and try to make browsers implement this. This is what we should do, in my totally biased opinion. -Boris
Re: [whatwg] MutationObserver Spec for AddedNodes Timing network requests
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
Re: [whatwg] Fetch Objects and scripts/stylesheets
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 situations (CSP, extension) in which a browser would like to know what sort of resource is being loaded, or more precisely how it will be consumed, before loading it. From that point of view, adding a way to customize fetch paramaters on link rel=stylesheet or some other mechanism that tells the UA up front what is being fetched is vastly preferable to taking an existing fetch and synthesizing a stylesheet from it, because it provides a lot more control to the user agent and user's extensions. -Boris
Re: [whatwg] Fetch Objects and scripts/stylesheets
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 should make the new API play nicer with CSP and extensions than the XHR and stick it in approach does. This won't stop _malicious_ sites, obviously, but it'll help with user control for normal sites who actually want to play nice with the user's settings. This API seems strictly better than a site that fetches text and just inserts it into the DOM. Sure. Also, it seems like CSP or extensions could still hook into this API, maybe not as early as before. For example, CSP would still know the URL of the resource that had been loaded as a script / stylesheet. While it wouldn't be able to block the loading, it could block the document from being turned into a script or stylesheet element. Again, sure. One could also imagine a flag passed to fetch saying fetch this document as if it were the src of a script tag. Right, exactly. That would actually simplify things for UAs as well; for example they have to do different kinds of sniffing on different request types, so knowing ahead of time what sort of thing you're requesting is quite helpful. -Boris
Re: [whatwg] Fetch Objects and scripts/stylesheets
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 XHR to load resources encounter?
It would. So would some API on top of fetch (as Domenic and Ian propose).
-Boris
Re: [whatwg] MutationObserver Spec for AddedNodes Timing network requests
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 loading each subresource belonging to a webpage. The beforeload event is generated before loading every script, iframe, image, or style sheet specified in the webpage, for example. from https://developer.apple.com/library/safari/documentation/Tools/Conceptual/SafariExtensionGuide/MessagesandProxies/MessagesandProxies.html#//apple_ref/doc/uid/TP40009977-CH14-SW9 Anyone knows why this never made it into the spec? How would this interact with a preload scanner, exactly? Or are there alternatives? Are we talking about web pages here, or browser extensions? -Boris
Re: [whatwg] MutationObserver Spec for AddedNodes Timing network requests
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 behavior is. 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... -Boris
Re: [whatwg] MutationObserver Spec for AddedNodes Timing network requests
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 tested that. -Boris
Re: [whatwg] MutationObserver Spec for AddedNodes Timing network requests
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.
So you can't really use a MutationObserver to prevent loads, as you
discovered.
Obviously some UAs in some circumstances may delay some loads to after
the mutation observer is fired. That shouldn't be relied on.
I think this is great solution
and it would be fantastic if it can be standardized.
I think it would be terrible if registering a MutationObserver is forced
to disable the preload scan (especially because you never know whether
the MutationObserver will get registered at all until you start running
scripts, at which point your preload scan is already going along), so I
disagree with this being a great solution.
My own usecase / testcase I created:
script type=text/javascript
MutationObserver = window.MutationObserver;
var observer = new MutationObserver(function(mutations) {
mutations.forEach(function(mutation) {
var addedNodes = mutation.addedNodes;
for (var i = 0; i addedNodes.length; i++) {
if (addedNodes[i].nodeName == 'SCRIPT') {
addedNodes[i].src = 'good.js';
}
}
});
});
observer.observe(document, {childList: true, subtree: true});
/script
script type=text/javascript src=evil.js/script
In chrome this works out of the box and good.js is called directly
(without sending any network requests beforehand
Uh... That would be a clear spec violation. Toggling the src of a
script _after_ it has been inserted into a document (which is when
that MutationObserver fires) is a no-op per spec.
That said, I can't reproduce the behavior you claim.
http://jsfiddle.net/59Sxf/ alerts evil for me in Chrome.
The source is updated within DOM afterwards, but there's no network request or
parsing of the
updated script (apart from the DOM change it has no effect).
Right, as the spec clearly requires.
-Boris
Re: [whatwg] Proposal: navigator.launchURL
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 able to do this? -Boris
Re: [whatwg] Canvas-Only Document Type
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 optimizations one could conjure, and it is the culmination of these that (in concept) creates a more polished experience. For example, if a user changes their device orientation, the application could perhaps respond in a more jank-free fashion since the UA can skip refreshing the layout tree. Refreshing a layout tree with three boxes in it doesn't take very long. -Boris
Re: [whatwg] Proposal: navigator.cores
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 a sufficient one. -Boris
Re: [whatwg] Proposal: defining script as link rel=script href=actualwaytoscript
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
Re: [whatwg] Proposal: defining script as link rel=script href=actualwaytoscript
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
Re: [whatwg] SVG cloning elements from HTML5
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 I don't think any engine would really want to implement, even if it made sense, which I don't think it does. For what it's worth, all that line means is copy all the methods/properties from HTMLIframeElement.prototype and its ancestors to SVGIframeElement.prototype. No multiple inheritance involved per se. Of course in this case both HTMLIframeElement and SVGIframeElement ultimately inherit from Element and Node, but as WebIDL is currently written I believe all that implements statement will do is also copy all the Node and Element stuff onto SVGIframeElement.prototype. This will, of course, greatly confuse authors who try to hook things on Element.prototype and discover it works for every element except SVGIframeElement... In any case, whether the implementations of those methods/properties make sense after the copying is done depends on exactly how they're written. I strongly doubt the HTMLIframeElement ones are all written in a generic enough way, so this would definitely need coordination with the HTML editor. Fully agreed on the rest of your mail about this not being the way to go, if that wasn't clear. ;) And I strongly recommend running any draft IDL through an actual conforming IDL parser and not publishing any drafts with invalid IDL. -Boris
Re: [whatwg] Stricter data URL policy
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 for the initial fetch, not after the iframe has been navigated. More precisely, it would be set for loads due to the iframe's src changing but not ones due to link clicks and location changes? Or do you really mean only for the initial fetch and not later changes to @src? I'll be updating Fetch shortly with this new policy This seems fine, since we want it no matter what; the only disagreement is about when that flag should be set, right? -Boris
Re: [whatwg] Stricter data URL policy
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 that. -Boris
Re: [whatwg] Stricter data URL policy
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
Re: [whatwg] Proposal: toDataURL “image/png” compression control
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 particular, you could have a SIMD API that desugars to plain JS as the default implementation in browsers but that JITs can recognize and vectorize as they desire. This sort of API will happen, for sure. No opinion on the PNG encoder thing. -Boris
Re: [whatwg] Proposal: navigator.cores
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 better estimate of the available resources than N. One thing along those lines that came up in discussion of this proposal at Mozilla: this proposal seems to assume that the UA itself is using a very few cores. This is a valid-ish assumption for current UAs: as long as you have only one tab open, the UA will typically use only one core (ignoring things like parallel JIT compilation, parallel GC, etc; I did say valid-ish). But I suspect that for future UAs this will be an outright bad assumption. Certainly for Servo it is. -Boris
Re: [whatwg] Proposal: Event.creationTime
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
Re: [whatwg] Proposal: Event.creationTime
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
Re: [whatwg] Proposal: navigator.cores
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
Re: [whatwg] Proposal: navigator.cores
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
