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
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.
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
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 com
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
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
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
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
>
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
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
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
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
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
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
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
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
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.
From: Maciej Stachowiak [mailto:m...@apple.com]
On Aug 17, 2015, at 3:19 PM, Domenic Denicola d...@domenic.me wrote:
- Parser-created custom elements and upgraded custom elements will
have their constructor and attributeChange callbacks called at a time when all
their children
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,
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.
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 XFoo
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 the
From: Anne van Kesteren [mailto:ann...@annevk.nl]
// What about
document.body.innerHTML = [512 KiB of normal HTML] x-foo/x-foo;
// ? 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
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
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].
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 end
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
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,
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)].
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 to
-
From: Domenic Denicola [mailto:d...@domenic.me]
Sent: Wednesday, July 15, 2015 20:45
To: public-webapps
Subject: The key custom elements question: custom constructors?
Hi all,
Ahead of next week's F2F, I'm trying to pull together some clarifying and
stage-setting materials, proposals
[+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
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
From: Elliott Sprehn [mailto:espr...@chromium.org]
Given the widget ui-collapsible that expects a ui-collapsible-header in the
content model, with slots I can write:
ui-collapsible
my-header-v1 slot=ui-collapsible-header ... /...
/ui-collapsible
ui-collapsible
my-header-v2
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
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
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 detailsdiv
content-slot=summary.../div.../details and a few others.
. 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 van Kesteren, Travis Leithead
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 completely
From: Anne van Kesteren ann...@annevk.nl
On Thu, May 7, 2015 at 9:02 AM, Steve Faulkner faulkner.st...@gmail.com
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
alert(weirdArray.__proto__ == localArray.__proto__)
This alerts false in IE, Firefox, and Chrome.
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
such techniques to come 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
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.
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
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
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 input discussion.
In IRC Anne and I were briefly
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 properties
stuff!
I hope others are as 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
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
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
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
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 or a
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
Steve's concerns are best illustrated with a more complicated element like
button. He did a great pull request to the custom elements spec that
contrasts all the work you have to do with taco-button vs. button
is=tequila-button:
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: Defining a constructor
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
From: Ryosuke Niwa [mailto:rn...@apple.com]
Let me restate the problem using an example. Suppose we're parsing
my-element/my-elementmy-other-element/my-other-element.
Once the HTML is parsed, the DOM tree is constructed with two DOM elements.
Now we call the constructors on those
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
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 iframe and such. If the iframe then goes away
it would be a shame to have to leak it forever. This is all discussed to
great extent in the
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.
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
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 a
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
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
From: Boris Zbarsky [mailto:bzbar...@mit.edu]
Just to be clear, this still didn't allow you to upgrade a my-img to be a
subclass of img, because that required a change in allocation, right?
Agreed. That needs to be done with img is=my-img, IMO. (Assuming the
upgrading design doesn't get
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 web
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
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
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
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 that
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 toward
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.
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 I
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 least,
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
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
-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 WG
Subject
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]:
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 ad...@chromium.org 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,
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 my-input
and have that actually work. It seems
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
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
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 Sickingmailto:jo...@sicking.cc
Sent:
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 of
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.
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.
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 tyosh...@google.com wrote:
How about padding the remaining bytes forcefully with e.g. 0x20 if the
WritableStream doesn't provide enough bytes to
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
From: Takeshi Yoshino [mailto:tyosh...@google.com]
On Tue, Nov 18, 2014 at 12:11 AM, Anne van Kesteren ann...@annevk.nl wrote:
On Mon, Nov 17, 2014 at 3:50 PM, Domenic Denicola d...@domenic.me wrote:
What do we think of that kind of behavior for fetch requests?
I'm not sure we want to give
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
https://dvcs.w3.org/hg/fullscreen/raw-file/default/TR.html.
I think it would be ideal to change the label to e.g. See Instead or
Maintained
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
On Nov 7, 2014, at 17:55, Anne van Kesteren ann...@annevk.nl wrote:
On Fri, Nov 7, 2014 at 5:46 PM, Arthur Barstow art.bars...@gmail.com 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/?
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
I just remembered another similar situation that occurred recently, and in my
opinion was handled perfectly:
When it became clear that the WHATWG DOM Parsing and Serialization Standard was
not being actively worked on, whereas the W3C version was, a redirect was
installed so that going to
No need to make this a vs.; we're all friends here :).
FWIW previous specs which have needed to become abandoned because they were
superceded by another spec have been re-published as NOTEs pointing to the
source material. That is what I would advise for this case.
Examples:
-
From: Paul Cotton [mailto:paul.cot...@microsoft.com]
Would it be feasible to resurrect this interface as a layer on top of [1] so
that W3C specifications like MSE that have a dependency on the Streams
interface are not broken?
The decision we came to in web apps some months ago was that
I'm not an expert either, but it seems to me that push without service workers
(or some other means of background processing) is basically just server-sent
events. That is, you could send push notifications to an active webpage over
a server-sent events channel (or web socket, or
From: annevankeste...@gmail.com [mailto:annevankeste...@gmail.com] On Behalf Of
Anne van Kesteren
On Mon, Oct 13, 2014 at 10:00 PM, Paul Cotton paul.cot...@microsoft.com
wrote:
MSE is in CR and there are shipping implementations.
Yes, but the Stream object is not shipping. Unless Microsoft
From: Domenic Denicola [mailto:dome...@domenicdenicola.com]
The more interesting question is whether BufferSource is shipping
(unprefixed), since ideally we would make BufferSource a WritableStream.
Sorry, SourceBuffer, not BufferSource---both in this message and the previous
one.
1 - 100 of 190 matches
Mail list logo
