Re: [webcomponents]: Of weird script elements and Benadryl

On 4/15/13 10:45 AM, Rick Waldron wrote: Sorry, I should've been more specific. What I meant was that: new HTMLButtonElement(); Doesn't construct an HTMLButtonElement, it throws with an "illegal constructor" in Chrome and "HTMLButtonElement is not a constructor" in Firefox (I'm sure this is the

Re: [webcomponents]: Of weird script elements and Benadryl

On 4/14/13 5:35 PM, Rick Waldron wrote: I have a better understanding of problem caused by these generated HTML*Element constructors: they aren't constructable. I'd like to understand what's meant here. I have a good understanding of how these constructors work in Gecko+SpiderMonkey, but I'm

Re: [webcomponents]: Of weird script elements and Benadryl

On 4/14/13 4:57 PM, Rick Waldron wrote: Of course, but we'd also eat scraps from the trash if that was the only edible food left on earth. document.createElement() is and has always been "the wrong way"—the numbers shown in those graphs are grossly skewed by a complete lack of any real alternativ

Re: [webcomponents]: Of weird script elements and Benadryl

On 4/14/13 3:07 PM, Allen Wirfs-Brock wrote: >> 2, 3, 4 I believe have been suggested in one form or another, but as I mentioned, were determined to be non-starters for Gecko. I don't think we've heard anything from IE team. Well #4 has been accepted for ES6 by all TC39 participants including

Re: [webcomponents]: Of weird script elements and Benadryl

On 4/14/13 1:49 PM, Scott Miles wrote: Erik Arvidsson came up with a strategy for overcoming this in Blink, but to my recollection Boris Zbarsky said this was a non-starter in Gecko. Just to be clear, the proposal there was to take an already existing function object and call some UA-provided

Re: [webcomponents]: Platonic form of custom elements declarative syntax

On 4/11/13 12:55 PM, Boris Zbarsky wrote: On 4/11/13 12:50 PM, Allen Wirfs-Brock wrote: Yes ES6 has "class-side" inheritance OK. Should we be doing that with WebIDL interface objects, perhaps? It would certainly make sense to me to do that, as long we we don't run into we

Re: [webcomponents]: Platonic form of custom elements declarative syntax

On 4/11/13 12:50 PM, Allen Wirfs-Brock wrote: Yes ES6 has "class-side" inheritance OK. Should we be doing that with WebIDL interface objects, perhaps? It would certainly make sense to me to do that, as long we we don't run into web compat issues. -Boris

Re: [PointerLock] Should there be onpointerlockchange/onpointerlockerror properties defined in the spec

On 4/11/13 1:29 PM, Anne van Kesteren wrote: On Thu, Apr 11, 2013 at 6:23 PM, Anne van Kesteren wrote: So how much can we still change fullscreen? It should really use futures. It seems Gecko and Chrome have it prefixed Isn't the thing that matters whether _sites_ have it unprefixed? -Bori

Re: [webcomponents]: Platonic form of custom elements declarative syntax

On 4/11/13 12:23 PM, Allen Wirfs-Brock wrote: So why don't you make "register" a static method on HTMLElement and then define the semantics so it automatically does: MyElement.register() This would normally invoke the inherited static method I lost track of something here. Why would it

Re: [webcomponents] self-documenting component.html files

On 4/5/13 2:57 PM, Mike Kamermans wrote: The getter/setter incur virtually no overhead, being baked into JS at the lowest possible level, compared to mutation observers, which are rather heavy hitting things for notifying non-owner objects of changes. For what it's worth, I welcome actual perfo

Re: [indexeddb] spec for keyPath attributes is underdefined

On 4/2/13 2:08 PM, Boris Zbarsky wrote: I filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=20394 to track this. Of course I meant https://www.w3.org/Bugs/Public/show_bug.cgi?id=21555 -Boris

[indexeddb] spec for keyPath attributes is underdefined

I filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=20394 to track this. Not sure whether that's enough to get it on the issues list... -Boris

Re: [webcomponents] Adjusting offsetParent, offsetTop, offsetLeft properties in Shadow DOM

On 3/28/13 12:55 PM, Elliott Sprehn wrote: and isPositioned is a bitfield check That happens to be a WebKit-specific claim, as far as I can tell. > parse the property name As is this. But yes, the general claim that the JS APIs for doing this right now are full of performance fail stands.

Re: [webcomponents] Adjusting offsetParent, offsetTop, offsetLeft properties in Shadow DOM

On 3/28/13 12:49 PM, Elliott Sprehn wrote: var rect = node.offsetParent.getBoundingClientRect(); node.style.top = computePosition(rect); node.style.left = computePosition(rect); Nothing guarantees the result of this to be sane today, unless you have extra information about the precise styles o

Re: [webcomponents] Adjusting offsetParent, offsetTop, offsetLeft properties in Shadow DOM

On 3/27/13 2:02 PM, Boris Zbarsky wrote: Note that if you're using offsetWith/Height/Top/Bottom you already lose, s/Bottom/Left/, of course. -Boris

Re: [webcomponents] Adjusting offsetParent, offsetTop, offsetLeft properties in Shadow DOM

Scott Miles wrote: > This is a thorny problem, but my initial reaction is that you > threaded the needle appropriately. I don't see how we avoid some > lossiness in this situation. Note that if you're using offsetWith/Height/Top/Bottom you already lose, because they return integers. I think w

Re: window.event and Event.srcElement

On 3/25/13 4:36 PM, David Bruant wrote: We could complicate the scoping setup for event handlers even more, of course. Would any UAs actually be willing to implement that (given that e.g. Chrome doesn't even implement the current, simpler, scoping setup sanely)? Any info on why they don't imple

Re: window.event and Event.srcElement

On 3/25/13 2:47 PM, David Bruant wrote: For the latter case, a scoping trick might work. In essence, on* code could run within a scope "located" between the code scope and the global scope. It already does: the scope is the element, with some more complications as to what's on the scope chain

Re: window.event and Event.srcElement

On 3/25/13 3:19 PM, Dave Methvin wrote: Basically, either UAs that currently implement window.event remove it or it's clearly required for web compat and hence needs to be specified so other UAs can implement it. I don't see any other sane options; do you? I'm okay with the fir

Re: [webcomponents]: Making Shadow DOM Subtrees Traversable

On 3/12/13 7:11 PM, Scott González wrote: It's been a while since I looked at this spec, what are the ways in which you can get access? You mean in the "hidden" case? For example, overriding Node.prototype.appendChild with your own function such that any time script in the component calls app

Re: [webcomponents]: Making Shadow DOM Subtrees Traversable

On 3/12/13 5:19 PM, Dimitri Glazkov wrote: However, to allow developers a degree of enforcing integrity of their shadow trees, we are going add a new mode, an equivalent of a "KEEP OUT" sign, if you will, which will makes a shadow tree non-traversable, effectively skipping over it in an element's

Re: [webcomponents]: What callbacks do custom elements need?

On 3/11/13 8:59 PM, Brian Kardell wrote: Is it very difficult to provide "here is an attribute I'm watching + a callback"? It's not super-difficult but it adds more complication to already-complicated code One big question is whether in practice the attribute that will be changing is on

Re: [webcomponents]: What callbacks do custom elements need?

On 3/11/13 5:27 PM, Daniel Buchner wrote: - I thought the concern was over the same issues that plagued mutation/events/, namely perf-crushing event bubbling sparked by frequent DOM changes. The #1 issue with mutation events is that they insanely complicated implementation and specification b

Re: [webcomponents]: What callbacks do custom elements need?

On 3/11/13 5:18 PM, Elliott Sprehn wrote: "inserted" and "removed" can probably be end of micro task, but attributeChanged definitely needs to be synchronous to model the behavior of where changing it from X to Y has an immediate effect on the APIs available (like stepUp). Hmm. That's a good

Re: [webcomponents]: What callbacks do custom elements need?

On 3/11/13 4:39 PM, Brian Kardell wrote: So does it actually need to be sync at that leve? I'm not sure why it does really. I'm not sure why it does either, honestly... -Boris

Re: [webcomponents]: What callbacks do custom elements need?

On 3/11/13 3:44 PM, Daniel Buchner wrote: Just to be clear, these are callbacks (right?), meaning synchronous executions on one specific node. That is a far cry from the old issues with mutation events and nightmarish bubbling scenarios. Where does bubbling come in? The issue with _synchronous

Re: [webcomponents]: Making Shadow DOM Subtrees Traversable

On 3/7/13 1:54 PM, Dave Methvin wrote: Another example, let's say Disqus created a webcomponent to show discussions related to content. I want to use that on my page but enhance it with a bozo/spam filter, fully understanding that it will require knowledge of Disqus webcomponent internals. But

Re: [webcomponents]: Making Shadow DOM Subtrees Traversable

On 3/7/13 1:54 PM, Scott González wrote: We're talking about a default value, not what functionality is or isn't available. We're talking about both, in general. Until this conversation started at least one implementor was planning to ship exposed-by-default with no way to not expose, as far

Re: [webcomponents]: Making Shadow DOM Subtrees Traversable

On 3/7/13 11:51 AM, Scott González wrote: I was replying in the context of jQuery, in which we expose most internals always. There is no option to have jQuery hide it's internals. Yes, but you explicitly said there are pros to exposing the internals. I'd like to understand what those pros are

Re: [webcomponents]: What callbacks do custom elements need?

On 3/6/13 5:05 PM, Dimitri Glazkov wrote: * attributeChangedCallback -- synchronously called when an attribute of an element is added, removed, or modified Synchronously in what sense? Why are mutation observers not sufficient here? * insertedCallback -- asynchronously called when an eleme

Re: [webcomponents]: Moving custom element callbacks to prototype/instance

On 3/6/13 7:13 PM, Erik Arvidsson wrote: There is no reason to walk the prototype chain from C++ (speaking from WebCore+V8/JS experience). You can invoke the method using the V8/JSC APIs. This is just as slow as walking the proto chain, in the end, because it can't benefit from the various opt

Re: [webcomponents]: Making Shadow DOM Subtrees Traversable

On 3/6/13 1:31 PM, Scott González wrote: but we feel the pros of exposing internals outweigh the cons. When you say "exposing internals" here, which one of the following do you mean: 1) Exposing internals always. 2) Exposing internals by default, with a way to opt into not exposing. 3) No

Re: The need to re-subscribe to requestAnimationFrame

On 3/2/13 6:45 AM, Lars Knudsen wrote: Imagine that you have a callback that does a lot of heavy rendering and the rAF returns AGAIN while "// do stuff". Can't happen, unless the callback calls showModalDialog or something else that spins the event loop. -Boris P.S. Note that you can make y

Re: The need to re-subscribe to requestAnimationFrame

On 3/2/13 6:03 AM, David Bruant wrote: I was wondering why it was the case. Other event-like mechanism do not require to re-subscribe after an event happened. requestAnimationFrame was designed as a way for web pages to do animations without hogging CPU like they did with setTimeout/setInterva

Re: [webcomponents]: Making Shadow DOM Subtrees Traversable

On 2/26/13 3:56 PM, Dominic Cooney wrote: One more thought occurs to me: It is easier to add public shadows in a subsequent revision of the spec than it is to take public shadows away. Yes, indeed. That's one of the main reasons I'd like it to be the initial default... I would certainly be

Re: [webcomponents]: Making Shadow DOM Subtrees Traversable

On 2/26/13 1:57 PM, Tab Atkins Jr. wrote: An argument to the contrary (which you do seem to acknowledge later in your message, if I'm reading correctly): if you make shadow private, but allow authors to make them public on an ad-hoc basis I think "ad-hoc" in this case means "per-component", not

Re: [webcomponents]: Making Shadow DOM Subtrees Traversable

On 2/25/13 2:43 PM, Scott Miles wrote: The good part is that in this forum I get to argue my own opinion, which I would say is that of a (single) web developer. Fair. ;) Ironically, I was trying to argue that these things are on a spectrum and that it is in fact not black and white. Often th

Re: [webcomponents]: Making Shadow DOM Subtrees Traversable

On 2/25/13 1:52 PM, Scott Miles wrote: Given Boris' arguments, Big Marketshare can simply always mess up his project and blame me and it's my fault. Scott, That's how it often works in the court of public opinion, yes. Your employer is not immune to this behavior. I don't accept it. That'

Re: [webcomponents]: Making Shadow DOM Subtrees Traversable

On 2/25/13 1:15 PM, Scott Miles wrote: You cannot accidentally stumble into ShadowDOM. You have to actively take that step. Sure. We all know this. I'm not sure why this strawman keeps getting argued. For one thing, I suggest that most of the time, the component code is shipping w/your ap

Re: [webcomponents]: Making Shadow DOM Subtrees Traversable

On 2/25/13 12:38 PM, Tab Atkins Jr. wrote: Still, though, the "private by default" impulse is nearly always wrong That's an interesting claim. Do you think that C++ classes should be public by default? (Binary patching that can mess even with private members notwithstanding for now) and

Re: [webcomponents]: Making Shadow DOM Subtrees Traversable

On 2/25/13 12:33 PM, Tab Atkins Jr. wrote: If a script is explicitly looking inside the shadows of unknown controls and checking their contents (and then failing when the unknown control has different contents than whatever it expected), something is *messed up* with that script. I can 100% gua

Re: [webcomponents]: Making Shadow DOM Subtrees Traversable

On 2/25/13 12:11 AM, Tab Atkins Jr. wrote: We've gone back and forth. It seems that allowing monkeypatching by default is the better choice, as most uses aren't security conscious Tab, could you please read and respond to what Blake actually wrote? He didn't mention the word "security" at al

Re: [webcomponents]: Building HTML elements with custom elements

On 2/20/13 7:26 AM, Anne van Kesteren wrote: These already cannot be just localName checks They often are in practice for extensions and web script. For browser code or better-written extensions and web script they're typically localName + namespaceURI checks. I also fail to see exactly wh

Re: [shadow-dom] Counters and list item counting

On 2/19/13 3:02 PM, Tab Atkins Jr. wrote: For example, if you intend for the component to contain a Oh, effects with components in particular. Yeah, ignoring the rearrangement done by components for purposes of counters makes sense to me. -Boris

Re: [shadow-dom] Counters and list item counting

On 2/19/13 2:43 PM, Tab Atkins Jr. wrote: There's some layer-breaching intrinsic to this. You do have to examine your styles to see if you generate a box. Well, your styles and the styles of all your ancestors in the flattened tree, yes? I wouldn't want it to rely on the box tree, though,

Re: [shadow-dom] Counters and list item counting

On 2/19/13 2:20 PM, Elliott Sprehn wrote: Currently in Webkit list item counting is done on the render tree, but we are looking at making it use the DOM instead so that ordered lists work properly in regions. Why wouldn't they work properly even if done on the render tree? Note that if you do

Re: [xhr] Appending a charset after an author added content-type

On 2/19/13 1:51 PM, Anne van Kesteren wrote: Does that include cases though where the page did set a Content-Type through setRequestHeader()? That's a good question. I don't remember anymore; I'd have to go read the relevant bugs. Because technically what Firefox does violates HTTP semanti

Re: [xhr] Appending a charset after an author added content-type

On 2/19/13 1:40 PM, Anne van Kesteren wrote: On Tue, Feb 19, 2013 at 5:51 PM, David Bruant wrote: My understanding of the spec is that the charset shouldn't be added, because: 1) the Content-Type header is in author request header 2) the value is a valid MIME-type (tell me if I'm wrong on this)

Re: Custom elements ES6/ES5 syntax compromise, was: document.register and ES6

On 2/14/13 6:03 PM, Dimitri Glazkov wrote: Since these are two separate steps, I technically don't _need_ to put HTMLButtonElement.call(this) into my element's constructor -- it's a sure bet it will just be a useless dummy. For HTMLButtonElement, perhaps. But for HTMLImageElement that's less c

Re: [webcomponents] Making the shadow root an Element

On 2/12/13 1:11 AM, Tab Atkins Jr. wrote: Not given the flattened tree construction algorithm I last saw... Am I just missing something? Right, because it's not an element yet, and thus can't appear in the tree like all the other elements do. Once it becomes an element, I presume it would.

Re: document.register and ES6

On 2/7/13 6:15 PM, Dimitri Glazkov wrote: 1) Expose the ability to override [[Construct]]. Arv tells me that he spoke with V8 peeps and they think they can do this fairly easily. How's the SpiderMonkey story looking here? Requires major surgery on how functions are implemented; not likely in t

Re: [webcomponents] Making the shadow root an Element

On 2/11/13 7:56 PM, Tab Atkins Jr. wrote: If it's an element and thus has an effect on styling, I presume it would appear in the final flattened tree. Not given the flattened tree construction algorithm I last saw... Am I just missing something? (But given the styling I suggest, it wouldn'

Re: [webcomponents] Making the shadow root an Element

On 2/11/13 6:49 PM, Tab Atkins Jr. wrote: I propose that we reify the shadow root into an element, but default it to "display: contents;" Why does this part matter? in the UA stylesheet. That way it has no layout effect by default It

Re: [webcomponents] Styling the shadow based on the host element

On 2/11/13 3:12 PM, Tab Atkins Jr. wrote: What doesn't seem possible is to use the host element's qualities (such as tagname, attributes, class, etc.) to style elements in the shadow tree. Seems like a selector akin to :scope would work fine here, no? Modulo deciding on a name for it... -Bo

Re: document.register and ES6

On 2/8/13 5:49 PM, Scott Miles wrote: In our recent debates, the general agreement is that we would support this syntax: Doesn't that allow us to have proper localName? It does, sure. I don't have a problem with that. What I want to be clearly defined is what happens with createElement("m

Re: document.register and ES6

On 2/8/13 5:11 PM, Erik Arvidsson wrote: 1. We cannot really extends anything else but HTMLElement/HTMLUnknownElement. Note that this restriction is not limited to polyfills. Extending other HTMLElements with a custom tagname seems ... highly undesirable to me. In particular, if you have an

Re: document.register and ES6

On 2/6/13 5:07 PM, Erik Arvidsson wrote: This refactoring is needed for ES6 anyway so it might be worth looking into no matter what. Well, yes, but it's a matter of timeframes. It's incredibly unlikely that a complete refactoring of how functions are implemented (which is what I was given to

Re: document.register and ES6

On 2/6/13 10:46 AM, Boris Zbarsky wrote: There is no "exposed function". In Erik's proposal the function is provided by the script and then the script keeps using it; the caller is expected to mutate the [[Construct]] I meant the _callee_ of course. ;) -Boris

Re: document.register and ES6

On 2/6/13 10:36 AM, David Bruant wrote: As a band-aid short-term type of solution, the exposed function could be a proxy to the actual function with a specific construct trap There is no "exposed function". In Erik's proposal the function is provided by the script and then the script keeps us

Re: document.register and ES6

On 2/5/13 10:28 PM, Boris Zbarsky wrote: And the point is that document.register changes the [[Construct]] of MyButton but does nothing else with it? Note that I'm still checking how feasible this is in SpiderMonkey on any sort of finite timeframe, if we do decide to do this. Functions

Re: document.register and ES6

On 2/5/13 11:01 PM, Erik Arvidsson wrote: On Tue, Feb 5, 2013 at 5:28 PM, Boris Zbarsky wrote: So in particular this allows creation of "uninitialized" instances in some sense, yes? Depends how much logic is put in the constructor vs @@create. For DOM Elements I think we want t

Re: document.register and ES6

On 2/5/13 10:12 PM, Erik Arvidsson wrote: In ES6 speak, we have split the "new Foo(...args)" expression into "Foo.call(Foo[@@create](), ...args)" which means that creating the instance has been separated from the call to the function. So in particular this allows creation of "uninitialized" ins

Re: [fullscreen-api] Allowing AJAX requests when in fullscreen mode

On 1/24/13 9:22 AM, Anne van Kesteren wrote: On Thu, Jan 24, 2013 at 3:19 PM, Boris Zbarsky wrote: That seems overly broad. For example, navigating to a named anchor should not exit fullscreen, in my opinion. Is there no sufficiently-late step in the navigate algorithm that this can hook

Re: [fullscreen-api] Allowing AJAX requests when in fullscreen mode

On 1/24/13 3:48 AM, Anne van Kesteren wrote: Ah, there is a requirement to the effect that when navigating, you exit fullscreen. That seems overly broad. For example, navigating to a named anchor should not exit fullscreen, in my opinion. Is there no sufficiently-late step in the navigate a

Re: [PointerLock] Should there be onpointerlockchange/onpointerlockerror properties defined in the spec

On 1/18/13 5:35 AM, Anne van Kesteren wrote: I'm not sure that though that all the splintering is useful long term as you lose track of what is going on. This is actually a fairly serious concern, to be honest. When I was recently working on WebIDL bindings for document, I ended up with http

Re: [PointerLock] Should there be onpointerlockchange/onpointerlockerror properties defined in the spec

On 1/10/13 2:02 PM, Vincent Scheib wrote: I'm confused why HTML should include the properties, and not the respective specifications. Other than scope creep? I am too; see the bug I linked to. -Boris

Re: [PointerLock] Should there be onpointerlockchange/onpointerlockerror properties defined in the spec

On 1/10/13 1:19 PM, Vincent Scheib wrote: The pointer lock specification intentionally mimics the fullscreen specification to provide consistency for developers, as they are similar and expected to be commonly used in the same apps. Neither specification mention event properties. But HTML5 ment

[PointerLock] Should there be onpointerlockchange/onpointerlockerror properties defined in the spec

And if so, which objects should they be on? Window? Documents? Elements? -Boris

RE: [IndexedDB] Straw man proposal for moving spec along TR track

> The other feedback we received, seems to have been agreed on by the > iplementers & WG but not documented in the spec. Did I miss some sort of agreement on the last call comment in http://lists.w3.org/Archives/Public/public-webapps/2012OctDec/0087.html and http://lists.w3.org/Archives/Public

Re: File Save As

On 1/5/13 8:35 AM, Florian Bösch wrote: > Left clicking the link auto-saves to the downloads folder with the > selected file name (no way to choose a location) That depends on that browser and user settings, fwiw. Right click Save As is even a bit more counter intuitive and the filename for th

Re: pointerLock vendor prefixes, shims and usability

On 12/24/12 12:44 PM, Florian Bösch wrote: I'm a bit concerned in doing these things to eventing because that stuff gets called a lot and what's being done isn't straightforward (allocating closures, regexing strings etc.) and that it could impact performance. OK, that's fair. For what it's wo

Re: pointerLock vendor prefixes, shims and usability

On 12/24/12 11:01 AM, Florian Bösch wrote: - vendorRequestPointerLock is on the prototype to HTMLElement which you cannot modify in Firefox You mean applying HTMLElement.prototype.mozRequestPointerLock to particular elements throws (which is not the same thing at all)? That's fixed as of 3 d

Re: [ambient light events LC] Feedback

On 12/18/12 12:09 PM, Anne van Kesteren wrote: FWIW, in the dictionary you do not need to define a default value, at least not as far as events are concerned. That's true, but it might save on the amount of prose needed to define the behavior. That said, For events you need to define a def

Re: [ambient light events LC] Feedback

On 12/18/12 11:23 AM, Tab Atkins Jr. wrote: Anne pointed out in IRC that, when all the other values are strings, it is somewhat more convenient to have the "no value" value be a string as well, and the empty string is the obvious choice for that role. Convenient for whom? For the dictionary ca

Re: [ambient light events LC] Feedback

On 12/18/12 10:47 AM, Tab Atkins Jr. wrote: Makes sense, I guess (though I'm not super happy with having to explicitly add the empty string to every enum that's supposed to be "nullable"). In that case, the IDL would be: enum LightLevel { "dim", "normal", "bright", "" }; [Constructor (DOMString

Re: [XHR] Need to define the behavior when the Window the XHR is created from does not have an associated document

On 12/14/12 2:29 PM, Anne van Kesteren wrote: Per Hixie the Document is associated with both the old and the new Window. Meaning that XMLHttpRequest will function normally even though XMLHttpRequest != window.XMLHttpRequest. I'm not sure it actually will; Olli had some concerns about event dis

Re: [XHR] Need to define the behavior when the Window the XHR is created from does not have an associated document

On 12/14/12 1:55 PM, Anne van Kesteren wrote: It seems to depend on whether or not the old Window object still has an associated document. If it still points to the active document the above "would work". If it points nowhere the above cannot work Well. It depends on whether we want to use the

Re: [XHR] Need to define the behavior when the Window the XHR is created from does not have an associated document

On 12/14/12 12:54 PM, Anne van Kesteren wrote: On Fri, Dec 14, 2012 at 6:40 PM, Boris Zbarsky wrote: Which other case? The document.open() one? In that case, there is no problem with the document per se; the only question is whether the XHR has an associated document object at all in that

Re: [XHR] Need to define the behavior when the Window the XHR is created from does not have an associated document

On 12/14/12 11:54 AM, Anne van Kesteren wrote: On Fri, Dec 14, 2012 at 5:30 PM, Boris Zbarsky wrote: But note that you can get the same effect by just navigating the a browsing context, then calling a function that was defined in the no-longer-active document, without worrying about browsers

Re: [XHR] Need to define the behavior when the Window the XHR is created from does not have an associated document

On 12/14/12 6:49 AM, Jungkee Song wrote: FWIW, document.open() does not create a new Window object Yes, it does. See http://www.whatwg.org/specs/web-apps/current-work/multipage/elements.html#dom-document-open processing steps step 14. WebKit gets this wrong, but other UAs do it right.

Re: [WebIDL] Representing functions that user code can call

On 12/9/12 10:41 PM, Cameron McCormack wrote: OK. For Document.register, the Function object that is returned is not going to do anything with its arguments, so I don't think we gain much in this case compared to (to make the IDL valid) replacing "Function" with "object". It needs to do specia

Re: [WebIDL] Representing functions that user code can call

On 12/8/12 7:07 PM, Cameron McCormack wrote: Is this for partial interface Document { Function register(DOMString name, optional Options options); }; Yes. ? Despite the name "callback function", I think they could be used here. I don't think there's anything in the spec that pre

[WebIDL] Representing functions that user code can call

We have a way to represent user functions that platform objects can call: callbacks. But I don't think there's really a good way to represent functions that are not hanging off any particular object that user code can call. Or can callbacks be used for that too? Note that right now the web

Re: [selectors-api] Matching of :scope in document.querySelector(All)

On 12/3/12 7:33 AM, Lachlan Hunt wrote: So it seems the current spec ended up treating these in the same way by matching nothing: document.querySelector(":scope") document.findAll(":scope") document.findAll(":scope", null) document.findAll(":scope", []) That's how I read it, yes. I can chan

[selectors-api] Matching of :scope in document.querySelector(All)

When implementing :scope support, I discovered that as things stand this call: document.querySelector(":scope") is specified to return null. In particular http://dev.w3.org/2006/webapi/selectors-api2/#queryselector step 1 calls http://dev.w3.org/2006/webapi/selectors-api2/#determine-contex

[pointer-lock] pointerLockElement should be nullable in the IDL

The IDL at http://dvcs.w3.org/hg/pointerlock/raw-file/default/index.html#extensions-to-the-document-interface says: readonly attribute Element pointerLockElement; but the attribute can return null, so the type should be "Element?". -Boris

Re: random numbers API

On 11/16/12 7:13 AM, Florian Bösch wrote: 4) Alternative implementations in JS suffer even in the presence of sophisticated JITing VMs from the fact that mathematics is done in doubles (in the case of addition, subtraction, division and multiplication) and by converting double -> int -> double (i

Re: Two years on and still no sensible web storage solutions exist

On 11/12/12 2:59 PM, Florian Bösch wrote: A-ha. Filled payload with random. Now it's FF 4.4s put, 5.5s get. In line with chromes perf. Hmm. This I can't reproduce. I tried filling the array with randoms, and the times end up about 30% higher, but not 20x higher, for me. -Boris

Re: Two years on and still no sensible web storage solutions exist

On 11/12/12 1:56 PM, Florian Bösch wrote: In FF 16.0.2 on linux, 50mb put takes about 100ms and get takes about 500ms. For what it's worth, I did some measuring, and the main performance cost centers for the write (the CPU-intensive ones, not the disk access) seem to be: 1) Making a copy o

Re: Two years on and still no sensible web storage solutions exist

On 11/12/12 12:31 PM, Florian Bösch wrote: Care to paste that one? I'll test it in firefox. http://pastebin.mozilla.org/1937689 -Boris

Re: Two years on and still no sensible web storage solutions exist

On 11/12/12 8:17 AM, Florian Bösch wrote: This testsite: http://codeflow.org/issues/indexeddb.html Putting 50mb takes between 2.5 to 8 seconds. Getting it between 2 to 4 seconds. Putting 100mb doesn't work in Chrome at all and throws an exception on the put after half a second. After fixing you

Re: [webcomponents]: Making Shadow DOM Subtrees Traversable

On 11/8/12 9:28 AM, Elliott Sprehn wrote: If you're worried about malicious attacks on your widget, shadows being private is not enough. You need a whole new scripting context. Er... yes, you do. Do widgets not get that? If not, that's pretty broken... Google Feedback is an HTML rendering

Re: [webcomponents]: Making Shadow DOM Subtrees Traversable

On 11/8/12 1:45 AM, Elliott Sprehn wrote: That means that I doubt you'll get widgets being broken as Boris suggests because people aren't going to accidentally modify the inside of your widget. The problems start when people _maliciously_ modify the inside of your widget. Again, with XBL you

[WebIDL] Typo in platform array object [[GetOwnProperty]] method

Step 3 substep 3 says: Let value be the result of converting the indexth element of the IDL array that A represents to an IDL value of type T. Presumably it should say: Let value be the result of converting the indexth element of the IDL array that A represents to an ECMAScript value.

Re: [webcomponents]: Making Shadow DOM Subtrees Traversable

On 11/1/12 7:41 AM, Tab Atkins Jr. wrote: There was no good *reason* to be private by default Yes, there was. It makes it much simpler to author non-buggy components. Most component authors don't really contemplate how their code will behave if someone violates the invariants they're depend

Re: [selectors-api] Updated Testsuite

On 10/22/12 6:10 AM, Lachlan Hunt wrote: * hasFeature() returns false Just as a note, this is a pretty pointless test, and the language about it should be removed from this spec, assuming http://dom.spec.whatwg.org/#dom-domimplementation-hasfeature stays the way it is. * :link and :visite

Re: [XHR] Open issue: allow setting User-Agent?

On 10/17/12 4:57 AM, Aryeh Gregor wrote: In terms of correctness, yes, but that will make them useless as caches. If a moderate number of users with an assortment of browsers are using the same caching proxy, it's entirely possible that no two of them have the same exact User-Agent string. Vary

Re: [XHR] Open issue: allow setting User-Agent?

On 10/17/12 4:34 AM, Hallvord Reiar Michaelsen Steen wrote: I guess UAs *could* add a Cache-control: no-cache request header when getting a resource that was previously retrieved with a different UA string - this is getting very "fiddly" though. Hmm. In similar vein, UAs could Cache-control:

Re: [XHR] Open issue: allow setting User-Agent?

On 10/17/12 3:36 AM, Jungkee Song wrote: But my concern was even if browser acts as such, intermediary caches would still return forged content in its cache rather than trying to make a fresh request to origin server. That is, authors would expect that they are free from cache poisoning threat

Re: [XHR] Open issue: allow setting User-Agent?

On 10/17/12 12:17 AM, Jungkee Song wrote: Yes, that could solve the issue, but it seems we cannot avoid the intermediary caching proxy problem unless server actually put "Vary: User-Agent" in every response. I'm wondering if it's still worth to put it into spec. Again, any intermediary proxy th

<    1   2   3   4   5   6   7   8   9   >