RE: Quick update on WebIDL "Level 1"

From: Travis Leithead [mailto:travis.leith...@microsoft.com] > The purpose of the “Level 1” document is to serve as a stable reference for > W3C specs that link to WebIDL. It contains a subset of the WebIDL syntax that > is considered stable (as verified by interoperable tests). Implementations

RE: [gamepad] New feature proposals: pose, touchpad, vibration

From: Brandon Jones [mailto:bajo...@google.com] > readonly attribute Float32Array? position; Just as a quick API surface comment, Float32Array? is not a very good way of representing a vector (or quaternion). You want either separate x/y/z/w properties, or to use a DOMPoint(ReadOnly). Web VR

RE: [Custom Elements] They are globals.

I think you are being misled by a superficial similarity with React's JSX. JSX's `` desugars to `React.createElement(Foo)`, which creates a `` element with some of its behavior derived from the `Foo` class, found in JavaScript lexical scope. The `Foo` token has no impact on the DOM tree. Custom

RE: [Web Components] Editor for Custom Elements

From: Philippe Le Hegaret [mailto:p...@w3.org] > But I hope you realize that coming in the W3C community, working with them > for while, and then take things away to continue the work elsewhere is > received as not working in good faith with the W3C community. This is not a > judgment of wheth

RE: [Web Components] Editor for Custom Elements

From: Léonie Watson [mailto:t...@tink.uk] > Domenic Denicola briefly stepped into the role, but regretfully he has since > declined to work within the W3C community [2]. That is not at all an accurate description of what has happened. I've very much enjoyed working with the W3C commu

RE: Telecon / meeting on first week of April for Web Components

From: Jan Miksovsky [mailto:jan@component.kitchen] > As a reminder: the proposed agenda for the meeting is to go through the > “needs consensus” items posted at  > https://github.com/w3c/webcomponents/issues?q=is:issue+is:open+label:"needs+consensus";. > It sounds like it would be good to resol

RE: [XHR]

From: Gomer Thomas [mailto:go...@gomert-consulting.com] > [GT] It would be good to say this in the specification, and > reference > some sample source APIs. (This is an example of what I meant when I said it > is very difficult to read the specification unless one already knows how

RE: [XHR]

From: Elliott Sprehn [mailto:espr...@chromium.org] > Can we get an idl definition too? You shouldn't need to read the algorithm to > know the return types. Streams, like promises/maps/sets, are not specced or implemented using the IDL type system. (Regardless, the Web IDL's return types are on

RE: [XHR]

From: Gomer Thomas [mailto:go...@gomert-consulting.com] > I looked at the Streams specification, and it seems pretty immature and > underspecified. I’m not sure it is usable by someone who doesn’t already know > how it is supposed to work before reading the specification. How many of the > maj

RE: Custom elements contentious bits

From: Brian Kardell [mailto:bkard...@gmail.com] > I'd really like to understand where things really are with async/sync/almost > sync - does anyone have more notes or would they be willing to provide more > exlpanation?  I've read the linked contentious bit and I'm still not sure > that I unde

RE: [WebIDL] T[] migration

From: Simon Pieters [mailto:sim...@opera.com] > Note that it requires liveness. Does that work for a frozen array? Frozen array instances are frozen and cannot change. However, you can have the property that returns them start returning a new frozen array. The spec needs to track when these ne

RE: Meeting date, january

From: Chaals McCathie Nevile [mailto:cha...@yandex-team.ru] > Yes, likewise for me. Anne, Olli specifically called you out as someone we > should ask. I am assuming most people are OK either way, having heard no > loud screaming except for Elliot... I would be pretty heartbroken if we met without

RE: Callback when an event handler has been added to a custom element

From: Mitar [mailto:mmi...@gmail.com] > Hm, but message port API itself has such a side-effect: I think that is just a very bad API. The platform is unfortunately full of bad APIs :). In particular, a difference between two different ways of adding event listeners is not something authors ever

RE: Callback when an event handler has been added to a custom element

In general I would be cautious about this kind of API. Events are not expected to have side effects, and adding listeners should not cause an (observable) action. See e.g. https://dom.spec.whatwg.org/#action-versus-occurance which tries to explain this in some detail. A better design in your cas

RE: [web-animations] Should computedTiming return a live object?

Anne's questions are interesting and worth answering. For example, which of these properties are typically held in memory already, versus which would require some kind of computation---the former usually are better as properties, and the latter as methods. But setting aside the deeper issues he

RE: Indexed DB + Promises

This seems ... reasonable, and quite possibly the best we can do. It has a several notable rough edges: - The need to remember to use .promise, instead of just having functions whose return values you can await directly - The two-stage error paths (exceptions + rejections), necessitating async/

RE: Normative references to Workers.

From: Xiaoqian Wu [mailto:xiaoq...@w3.org] > If the spec is still changing frequently, indeed it isn't a good idea to > publish another CR… but the WebApps WG needs to clearly tell the community > that the 2012 CR should be considered obsolete. > > I’d suggest that we publish a WD for Workers,

RE: PSA: publish WD of "WebIDL Level 1"

From: Ryosuke Niwa [mailto:rn...@apple.com] > For our internal documentation purposes, I'd refer having a perm link to a > document that never changes. > > Let's say we implement some feature based on Web IDL published as of > today. I'm going to refer that in my source code commit message. Fut

RE: Custom elements "Constructor-Dmitry" baseline proposal

From: Maciej Stachowiak [mailto:m...@apple.com] > On Aug 17, 2015, at 3:19 PM, Domenic Denicola wrote: > > > - Parser-created custom elements and upgraded custom elements will > have their constructor and attributeChange callbacks called at a time when all > their children

Custom elements "Constructor-Dmitry" baseline proposal

In https://github.com/w3c/webcomponents/blob/gh-pages/proposals/Constructor-Dmitry.md I’ve written up in some detail what I consider to be the current state-of-the-art in custom elements proposals. That is, if we take the current spec, and modify it in ways that everyone agrees are good ideas,

RE: W3C's version of XMLHttpRequest should be abandoned

From: Hallvord Reiar Michaelsen Steen [mailto:hst...@mozilla.com] > I still like the idea of having a "stable" spec documenting the interoperable > behaviour of XHR by a given point in time - but I haven't been able to > prioritise it and neither, apparently, have the other two editors. Thankf

RE: Apple's updated feedback on Custom Elements and Shadow DOM

From: Maciej Stachowiak [mailto:m...@apple.com] > Does that sound right to you? > > If so, it is not much more appealing than "prototype swizzling" to us, since > our biggest concern is allowing natural use of ES6 classes. Got it, thanks. So it really does sound like it comes down to class XFo

RE: Apple's updated feedback on Custom Elements and Shadow DOM

Thanks very much for your feedback Maciej! I know we'll be talking a lot more tomorrow, but one point in particular confused me: From: Maciej Stachowiak [mailto:m...@apple.com] > 4. Specifically, we don't really like the "Optional Upgrades, Optional > Constructors" proposal (seems like it's th

RE: alternate view on constructors for custom elements

From: Travis Leithead [mailto:travis.leith...@microsoft.com] > if super() is absolutely required for a constructor in a class > that extends something, is there a requirement about when in the > constructor method it be invoked? Must it always be the first call? Can it be > later on, say at the en

Two new custom elements ideas

Hi all, Over the last few days I’ve worked on two new potential ideas for custom elements, hoping to shake things up with new possibilities. These are both largely geared around how we react to the key custom elements question [1]. https://github.com/w3c/webcomponents/blob/gh-pages/proposals/Op

RE: alternate view on constructors for custom elements

From: Travis Leithead [mailto:travis.leith...@microsoft.com] > Something magical happens here. The use of super() is supposed to call the > constructor of the HTMLElement class—but that’s not a normal JS class. It > doesn’t have a defined constructor() method [yet?]. Yep. We'd need to define o

RE: The key custom elements question: custom constructors?

From: Anne van Kesteren [mailto:ann...@annevk.nl] >> // What about >> document.body.innerHTML = "[512 KiB of normal HTML] "; >> // ? does the HTML make it in, or does the operation fail atomically, or >> something else? > > It fails atomically, based on the definition of innerHTML. What if tha

RE: The key custom elements question: custom constructors?

wingMode = true; el.cloneNode(true); // this will throw, presumably... // ... but does the XBar constructor run or not? // ... if so, how many times? > -Original Message- > From: Domenic Denicola [mailto:d...@domenic.me] > Sent: Wednesday, July 15, 2015 20:45 > To: public-weba

RE: The key custom elements question: custom constructors?

From: Jonas Sicking [mailto:jo...@sicking.cc] > Like Anne says, if it was better defined when the callbacks should happen, > and that it was defined that they all happen after all internal datastructures > had been updated, but before the API call returns, then that would have > been much easier t

RE: The key custom elements question: custom constructors?

From: Anne van Kesteren [mailto:ann...@annevk.nl] > I think the problem is that nobody has yet tried to figure out what invariants > that would break and how we could solve them. I'm not too worried about > the parser as it already has script synchronization, but cloneNode(), ranges, > and editing

RE: [WebIDL] T[] migration

So in terms of concrete updates, we'd need to fix - https://html.spec.whatwg.org/ - https://w3c.github.io/webrtc-pc/ - http://dev.w3.org/csswg/cssom/ (sigh, still no https?) The other documents mentioned are either obsolete or forks of (sections of) the first. Once the LS/EDs are fixed, then we

RE: The key custom elements question: custom constructors?

From: Olli Pettay [mailto:o...@pettay.fi] > That is too strongly said, at least if you refer to my email (where I > expressed > my opinions, but as usually, others from Mozilla may have different opinions). > I said "I'd prefer if we could avoid that [Running author code during > cloneNode(true)]

RE: URL bugs and next steps

[+Sebastian] From: Anne van Kesteren [mailto:ann...@annevk.nl] > the state of the specification and testsuite. Worth pointing out, since I guess it hasn't been publicized beyond IRC: as part of the jsdom project [1] (which is a hobby of mine), Sebastian has been working on a reference implemen

RE: Writing spec algorithms in ES6?

Some previous discussion: [1] especiallly [2] In general I think this is a reasonable thing, but it requires a decent bit more infrastructure to do things “safely”. For example, consider the definition [3]. It's generic in its arguments, which I think is nice (but does not fit with Web IDL---wh

RE: [webcomponents] How about let's go with slots?

From: Dimitri Glazkov [mailto:dglaz...@google.com] > Not sure what you mean by "Polymer model". I was referring to Elliot's "This is identical to the common usage today in polymer apps where you annotate your own element with classes." > When we have custom elements, the assumption of dumb con

RE: [webcomponents] How about let's go with slots?

From: Elliott Sprehn [mailto:espr...@chromium.org] > Given the widget that expects a ui-collapsible-header in the > content model, with slots I can write: > > >  ... > > > >  ... > > > within the same application. It also means the library can ship with an > implementation of the heade

RE: [webcomponents] How about let's go with slots?

From: Justin Fagnani [mailto:justinfagn...@google.com] > They're not equivalent, because any element can have the right content-slot > value, but with tag names, only one (or maybe N) names would be supported. Hmm, I don't understand, and fear we might be talking past each other. Can you give

Re: [webcomponents] How about let's go with slots?

t disagree. But it wasn't clear. From: Elliott Sprehn Sent: Monday, May 18, 21:03 Subject: Re: [webcomponents] How about let's go with slots? To: Justin Fagnani Cc: Philip Walton, Domenic Denicola, Daniel Freedman, Dimitri Glazkov, Scott Miles, Ryosuke Niwa, Edward O'Connor, Anne

RE: [webcomponents] How about let's go with slots?

I was thinking opposed. I don’t see any reason to invent two ways to do the same thing. If we do support content-slot then I think we should allow .. and a few others.

RE: [webcomponents] How about let's go with slots?

From: Dimitri Glazkov [mailto:dglaz...@google.com] > What do you think, folks? Was there a writeup that explained how slots did not have the same performance/timing problems as select=""? I remember Alex and I were pretty convinced they did at the F2F, but I think you became convinced they did

RE: Custom Elements: is=""

From: Travis Leithead [mailto:travis.leith...@microsoft.com] > It always seemed weird to me that 'prototype' of ElementRegistrationOptions > can inherit from anything (including null), and be completely disassociated > from the localName provided in 'extends'. Yes, the current spec is complete

Re: Making ARIA and native HTML play better together

From: Anne van Kesteren > On Thu, May 7, 2015 at 9:02 AM, Steve Faulkner > wrote: >> Currently ARIA does not do this stuff AFAIK. > > Correct. ARIA only exposes strings to AT. We could maybe make it do more, > once we understand what more means, which is basically figuring out HTML as > Custo

RE: [components] Isolated Imports and Foreign Custom Elements

> alert(weirdArray.__proto__ == localArray.__proto__) This alerts false in IE, Firefox, and Chrome.

RE: Proposal for changes to manage Shadow DOM content distribution

Between content-slot-specified slots, attribute-specified slots, element-named slots, and everything-else-slots, we're now in a weird place where we've reinvented a micro-language with some, but not all, of the power of CSS selectors. Is adding a new micro-language to the web platform worth help

RE: [W3C TCP and UDP Socket API]: Status and home for this specification

From: Boris Zbarsky [mailto:bzbar...@mit.edu] > This particular example sets of alarm bells for me because of virtual hosting. Eek! Yeah, OK, I think it's best I refrain from trying to come up with specific examples. Let's forget I said anything... > As in, this seems like precisely the sort of

RE: [W3C TCP and UDP Socket API]: Status and home for this specification

From: Jonas Sicking [mailto:jo...@sicking.cc] > I agree with Anne. What Domenic describes sounds like something similar to > CORS. I.e. a network protocol which lets a server indicate that it trusts a > given > party. I think my point would have been stronger without the /.well-known protocol t

RE: [W3C TCP and UDP Socket API]: Status and home for this specification

I think it's OK for different browsers to experiment with different non-interoperable conditions under which they fulfill or reject the permissions promise. That's already true for most permissions grants today.

RE: [W3C TCP and UDP Socket API]: Status and home for this specification

in to play. -Original Message- From: Nilsson, Claes1 [mailto:claes1.nils...@sonymobile.com] Sent: Wednesday, April 1, 2015 09:58 To: 'Anne van Kesteren' Cc: public-sysa...@w3.org; public-webapps; Device APIs Working Group; Domenic Denicola; slightly...@chromium.org; yass...

RE: Minimum viable custom elements

I hope others can address the question of why custom element callbacks are useful, and meet the bar of being a feature we should add to the web platform (with all the UA-coordination that requires). I just wanted to interject into this discussion. In IRC Anne and I were briefly discussing how

RE: Custom element design with ES6 classes and Element constructors

From: Elliott Sprehn [mailto:espr...@google.com] > Perhaps, but that logically boils down to "never use string properties ever" > just in case some library conflicts with a different meaning. We'd have > $[jQuery.find](...) and so on for plugins. Nah, it boils down to "don't use string propert

RE: Custom element design with ES6 classes and Element constructors

It does. If a framework says “use clonedCallback and we will implementing cloning for you,” we cannot add a clonedCallback with our own semantics. Whereas, if a framework says “use [Framework.cloned] and we will implement cloning for you,” we’re in the clear. Better yet! If a framework is a bad

RE: Better focus support for Shadow DOM

enthused as I am :) From: Takayoshi Kochi (河内 隆仁) [mailto:ko...@google.com] Sent: Wednesday, January 21, 2015 02:41 To: public-webapps Subject: Re: Better focus support for Shadow DOM Hi, After conversation with Domenic Denicola, I changed the title and the whole story of solving this issue

RE: Defining a constructor for Element and friends

From: Anne van Kesteren [mailto:ann...@annevk.nl] > How can that work if the custom element constructor needs to look in the > registry to find its name? Pick a name at random? Nah, it just automatically starts acting like HTMLQuoteElement: the localName option becomes required. See https://

RE: Minimum viable custom elements

From: Ryosuke Niwa [mailto:rn...@apple.com] > However, nobody has suggested a design that satisfies both of our > requirements: using ES6 constructor for element initialization Hi Ryosuke, Could you say more about why this is a requirement? In particular, why you require that developers type

RE: Minimum viable custom elements

Steve's concerns are best illustrated with a more complicated element like . He did a great pull request to the custom elements spec that contrasts all the work you have to do with vs. : https://w3c.github.io/webcomponents/spec/custom/#custom-tag-example vs. https://w3c.github.io/webcomponents

RE: Defining a constructor for Element and friends

part of the class author than writing a class that corresponds to a single name, and is painless to use for consumers. -Original Message----- From: Domenic Denicola [mailto:d...@domenic.me] Sent: Friday, January 9, 2015 20:01 To: Anne van Kesteren; WebApps WG; www-...@w3.org Subject: RE: D

RE: Minimum viable custom elements

From: Ryosuke Niwa [mailto:rn...@apple.com] > Unfortunately for developers, native syntax for inheritance in Stink 2.0 > cannot be used to subclass views in Odour. The native syntax for inheritance can definitely be used! You just can't override the constructor, since constructing a view is a

RE: Minimum viable custom elements

From: Dimitri Glazkov [mailto:dglaz...@google.com] > Why is "Not having identity at creation-time is currently a mismatch with the > rest of the platform" a problem? Why does it all have to be consistent across > the board? Are there any other platform objects that are created by HTML > parser

RE: Custom element design with ES6 classes and Element constructors

Just to clarify, this argument for symbols is not dependent on modules. Restated, the comparison is between: ```js class MyButton extends HTMLElement { createdCallback() {} } ``` vs. ```js class MyButton extends HTMLElement { [Element.create]() {} } ``` > We're already doing some crude nam

RE: Custom element design with ES6 classes and Element constructors

I had a chat with Dmitry Lomov (V8 team/TC39, helped shape the new ES6 classes design, CC'ed). His perspective was helpful. He suggested a way of evolving the current createdCallback design that I think makes it more palatable, and allows us to avoid all of the teeth-gnashing we've been doing in

RE: Minimum viable custom elements

From: Ryosuke Niwa [mailto:rn...@apple.com] > Let me restate the problem using an example. Suppose we're parsing > . > > Once the HTML is parsed, the DOM tree is constructed with two DOM elements. > Now we call the constructors on those elements. Without loss of generality, > let's assume w

RE: Minimum viable custom elements

From: Erik Arvidsson [mailto:a...@google.com] > I'm not sure how that is speced but in Blink we have an extended IDL > attribute called CustomElementCallbacks which means that we are going to call > the pending callbacks after the method/setter. If I recall this is how Anne and others were say

RE: Minimum viable custom elements

From: Ryosuke Niwa [mailto:rn...@apple.com] > See Boris' responses in another thread [1] and [2]. Jonas outlined how this > could work in the same thread [3] Thanks for the references. But avoiding this problem is exactly what Arv and I were talking about. The mechanism that createdCallback

RE: Minimum viable custom elements

From: Anne van Kesteren [mailto:ann...@annevk.nl] > Could you explain how this works in more detail? I haven't checked, but my impression was we could just use the same processing model the current spec uses for createdCallback, and use the constructor instead.

RE: Adopting a Custom Element into Another Document

From: Anne van Kesteren [mailto:ann...@annevk.nl] > Because it's very easy to move nodes from one tree to another and this > happens quite a bit through and such. If the then goes away > it would be a shame to have to leak it forever. This is all discussed to > great extent in the aforementi

RE: Defining a constructor for Element and friends

From: Bjoern Hoehrmann [mailto:derhoe...@gmx.net] > I know that this a major concern to you, but my impression is that few if any > other people regard that as anything more than "nice to have", especially if > you equate "explaining" with having a public API for it. How do you propose having

RE: Adopting a Custom Element into Another Document

I imagine this has all been discussed before, but why do __proto__-munging when adopting cross document? That seems bizarre, and causes exactly these problems. When you put an object in a Map from another realm, it doesn't __proto__-munge it to that other realm's Object.prototype. Why is the tre

RE: Defining a constructor for Element and friends

From: Ryosuke Niwa [mailto:rn...@apple.com] > Or, we could always throw an exception in the constructor of > HTMLUnknownElement so that nobody could do it. It would mean that libraries > and frameworks that do support custom elements without "-" would have to use > document.createElement but

RE: Defining a constructor for Element and friends

From: Ryosuke Niwa [mailto:rn...@apple.com] > Shouldn't we throw in this case because the concert type of "somename" is > HTMLUnknownElement? Yes, that's exactly the current design. Hidden a bit: https://github.com/domenic/element-constructors/blob/master/element-constructors.js#L4 This still

RE: Custom element design with ES6 classes and Element constructors

From: Boris Zbarsky [mailto:bzbar...@mit.edu] > Just to be clear, this still didn't allow you to upgrade a to be a > subclass of , because that required a change in allocation, right? Agreed. That needs to be done with , IMO. (Assuming the upgrading design doesn't get switched to DOM mutation

RE: Defining a constructor for Element and friends

From: Boris Zbarsky [mailto:bzbar...@mit.edu] > But it also means that user-space code that has to create an HTML element > generically now has to go through document.createElement instead of being > able to do |new HTMLElement("a")|, right? That seems totally fine to me though. The idea of a

RE: Custom element design with ES6 classes and Element constructors

From: Gabor Krizsanits [mailto:gkrizsan...@mozilla.com] > Isn't there a chance to consider our use-case in ES6 spec. then? I kind of feel like I and others dropped the ball on this one. Until this thread I didn't realize how important the dual-stage allocation + initialization was, for upgradi

RE: Custom element design with ES6 classes and Element constructors

From: Boris Zbarsky [mailto:bzbar...@mit.edu] > Hmm. So given the current direction whereby ES6 constructors may not even be > [[Call]]-able at all, I'm not sure we have any great options here. :( > Basically, ES6 is moving toward coupling allocation and initialization but > the upgrade sce

RE: Defining a constructor for Element and friends

From: Boris Zbarsky [mailto:bzbar...@mit.edu] >> "Terminology: In what follows I use 'own-instances of X' to mean objects >> where obj.constructor === X, > > That doesn't make much sense to me as a useful test, since it's pretty simple > to produce, say, an HTMLParagraphElement instance on the

RE: Custom element design with ES6 classes and Element constructors

From: Ryosuke Niwa [mailto:rn...@apple.com] > There's no brilliant solution here. I'm suggesting to introduce something > akin to sync script element. > In this particular example, my-el will remain HTMLUnknownElement since it had > already appeared when the script element to load the module

RE: Custom element design with ES6 classes and Element constructors

From: Ryosuke Niwa [mailto:rn...@apple.com] > In that case, we can either delay the instantiation of those unknown elements > with "-" in their names until pending module loads are finished Could you explain this in a bit more detail? I'm hoping there's some brilliant solution hidden here that

RE: Custom element design with ES6 classes and Element constructors

From: Domenic Denicola [mailto:d...@domenic.me] > In other words, in an ES6 modules world, all custom elements are upgraded > elements. Should be, "In other words, in an ES6 modules world, all custom elements __that appear in the initially-downloaded .html file__ are upgraded elements."

RE: Custom element design with ES6 classes and Element constructors

From: Ryosuke Niwa [mailto:rn...@apple.com] > As we have repeatedly stated elsewhere in the mailing list, we support option > 1 since authors and frameworks can trivially implement 2 or choose to set > "prototype" without us baking the feature into the platform. At first I was sympathetic towa

RE: Custom element design with ES6 classes and Element constructors

From: Tab Atkins Jr. [mailto:jackalm...@gmail.com] > Proto munging isn't even that big of a deal. It's the back-end stuff that's > kinda-proto but doesn't munge that's the problem. This is potentially > fixable if we can migrate more elements out into JS space. It really isn't though, at leas

RE: Custom element design with ES6 classes and Element constructors

using user-authored constructors. Instead, we essentially have to re-invent the @@create/constructor split in user-space as constructor/createdCallback. That's a shame. -Original Message----- From: Domenic Denicola [mailto:d...@domenic.me] Sent: Sunday, January 11, 2015 15:13 To: WebApps W

Custom element design with ES6 classes and Element constructors

This is a spinoff from the thread "Defining a constructor for Element and friends" at http://lists.w3.org/Archives/Public/public-webapps/2015JanMar/0038.html, focused specifically on the design of custom elements in that world. >> The logical extension of this, then, is that if after that >> `

RE: Defining a constructor for Element and friends

From: Boris Zbarsky [mailto:bzbar...@mit.edu] > That said, I do have one question already: what does the term "own-instances" > mean in that document? Explained at the top: "Terminology: In what follows I use 'own-instances of X' to mean objects where obj.constructor === X, as distance from '

RE: Defining a constructor for Element and friends

OK, so I've thought about this a lot, and there was some discussion on an unfortunately-TC39-private thread that I want to put out in the open. In [1] I outlined some initial thoughts, but that was actually a thread on a different topic, and my thinking has evolved. [1]: http://lists.w3.org/Ar

RE: Custom element lifecycle callbacks

From: annevankeste...@gmail.com [mailto:annevankeste...@gmail.com] On Behalf Of Anne van Kesteren > On Fri, Jan 9, 2015 at 3:30 AM, Adam Klein wrote: >> Do you have a proposal for where these symbols would be vended? > > My idea was to put them on Node or Element as statics, similar to the Symbo

RE: ES6 and upgrading custom elements

From: annevankeste...@gmail.com [mailto:annevankeste...@gmail.com] On Behalf Of Anne van Kesteren > That's why I tried to scope this thread to upgrading and not the script side. > > The main question is how you tie MyInputElement to something like > and have that actually work. It seems Dimitri

RE: ES6 and upgrading custom elements

This is all intimately tied to the still-ongoing how-to-subclass-builtins discussion that is unfortunately happening on a private TC39 thread. The essential idea, however, is that as long as you do ```js class MyInputElement extends HTMLInputElement { constructor() { super(); // this is ke

RE: Publishing working draft of URL spec

From: cha...@yandex-team.ru [mailto:cha...@yandex-team.ru] > There is no need for a CfC, per our Working Mode documents, so this is > announcement that we intend to publish a new Public Working Draft of the URL > spec, whose technical content will be based on what is found at > https://specs.w

RE: URL Spec WorkMode (was: PSA: Sam Ruby is co-Editor of URL spec)

What we really need to do is get some popular library or website to take a dependency on mobile Chrome or mobile Safari's file URL parsing. *Then* we'd get interoperability, and quite quickly I'd imagine. From: Jonas Sicking Sent: ‎2014-‎1

RE: =[xhr]

From: Rui Prior [mailto:rpr...@dcc.fc.up.pt] > If you absolutely need to stream content whose length is unknown beforehand > to a server not supporting ckunked encoding, construct your web service so > that it supports multiple POSTs (or whatever), one per piece of data to > upload. Unfortuna

RE: =[xhr]

From: Rui Prior [mailto:rpr...@dcc.fc.up.pt] > IMO, exposing such degree of (low level) control should be avoided. I disagree on principle :). If we want true webapps we need to not be afraid to give them capabilities (like POSTing data to S3) that native apps have. > In cases where the size o

RE: =[xhr]

From: annevankeste...@gmail.com [mailto:annevankeste...@gmail.com] On Behalf Of Anne van Kesteren > On Tue, Nov 18, 2014 at 12:50 PM, Takeshi Yoshino wrote: >> How about padding the remaining bytes forcefully with e.g. 0x20 if the >> WritableStream doesn't provide enough bytes to us? > > How wo

RE: =[xhr]

From: annevankeste...@gmail.com [mailto:annevankeste...@gmail.com] On Behalf Of Anne van Kesteren > The only way I could imagine us doing this is by setting the Content-Length > header value through an option (not through Headers) and by having the > browser enforce the specified length somehow

RE: =[xhr]

From: Takeshi Yoshino [mailto:tyosh...@google.com] > On Tue, Nov 18, 2014 at 12:11 AM, Anne van Kesteren wrote: >> On Mon, Nov 17, 2014 at 3:50 PM, Domenic Denicola wrote: >>> What do we think of that kind of behavior for fetch requests? > >> I'm not sure we

RE: =[xhr]

If I recall how Node.js does this, if you don’t provide a `Content-Length` header, it automatically sets `Transfer-Encoding: chunked` the moment you start writing to the body. What do we think of that kind of behavior for fetch requests? My opinion is that it’s pretty convenient, but I am not s

RE: New approach to activities/intents

From: Dimitri Glazkov [mailto:dglaz...@google.com] >> It's still not clear to me what the advantage is of creating a framework for >> designing proprietary APIs. > > If we don't do something like this as a platform, we'd be always lagging > behind. Many new ideas start as proprietary. It takes

RE: CfC: publish WG Note of XHR Level 2; deadline November 14

From: cha...@yandex-team.ru [mailto:cha...@yandex-team.ru] > That doesn't work with the way W3C manages its work and paper trails. I guess I was just inspired by Mike Smith earlier saying something along the lines of "don't let past practice constrain your thinking as to what can be done in th

RE: CfC: publish a WG Note of Fullscreen; deadline November 14

From: Arthur Barstow [mailto:art.bars...@gmail.com] > OK, so I just checked in a patch that sets the Latest Editor's Draft points > to Anne's document > . I think it would be ideal to change the label to e.g. "See Instead" or "Mainta

Re: CfC: publish WG Note of XHR Level 2; deadline November 14

> On Nov 7, 2014, at 17:55, Anne van Kesteren wrote: > >> On Fri, Nov 7, 2014 at 5:46 PM, Arthur Barstow wrote: >> https://dvcs.w3.org/hg/xhr/raw-file/default/TR/XHRL2-Note-2014-Nov.html > > Should this not include a reference to https://xhr.spec.whatwg.org/? Or better yet, just be a redir

RE: [streams] Seeking status and plans [Was: [TPAC2014] Creating focused agenda]

From: Arthur Barstow [mailto:art.bars...@gmail.com] > I think recent threads about Streams provided some useful information about > the status and plans for Streams. I also think it could be useful if some set > of you were available to answer questions raised at the meeting. Can any of > you

RE: Push API and Service Workers

From: annevankeste...@gmail.com [mailto:annevankeste...@gmail.com] On Behalf Of Anne van Kesteren > On Tue, Oct 21, 2014 at 5:53 PM, Shijun Sun wrote: >> One of the most typical scenarios is > > [citation needed] Let's expand on this point. You're not going to be able to provide a citation, be

  1   2   3   >