On 8/5/15 10:53 AM, Takeshi Yoshino wrote:
+domenic
We've recently finished the ReadableStream part of the spec and
experimenting integration with the Fetch API. Most of the spec is
still unstable. I don't have bandwidth to maintain W3C version of the
spec even briefly currently...
Hi
On 8/4/15 2:21 PM, Tab Atkins Jr. wrote:
On Thu, Jul 30, 2015 at 7:29 AM, Arthur Barstow art.bars...@gmail.com wrote:
Hi All,
This is heads-up re the intent to publish a Working Draft of WebIDL Level
1 (on or around August 4) using Yves' document as the basis and a new
shortname of WebIDL-1:
On Fri, Aug 7, 2015 at 2:45 PM, Arthur Barstow art.bars...@gmail.com wrote:
The L2 version (by Cameron and Boris) has not been published as a TR
and if there no objections to proceeding as above, I will start working on
making this all happen.
I still don't understand why L1 is even published.
On Fri, Aug 7, 2015 at 1:56 PM, Arthur Barstow art.bars...@gmail.com wrote:
Given this status, and in the absence of other feedback, I think the Streams
API should remain in WebApps' charter (at least for now). Then later, the
work may proceed (if there is still agreement an additional API
According to Art
https://dvcs.w3.org/hg/xhr/raw-file/default/Overview.html is no longer
maintained. It should redirect to https://xhr.spec.whatwg.org/
therefore.
According to Art the plan of record is to still pursue
https://dvcs.w3.org/hg/xhr/raw-file/default/xhr-1/Overview.html but
that was
This assumes you'll match
That's a good point. I agree for most APIs it's probably better to simply use
polyfill code for all browsers. But some APIs have some extra benefits that
might not be polyfillable. For example, the native version of web animations
happen in a compositor thread, so
On Thu, Aug 6, 2015 at 6:50 PM, Glen Huang curvedm...@gmail.com wrote:
@William @Matthew
Ah, thanks. Now I think prollyfill is prolly a good name. :)
@Brian
Actually, I had this pattern in mind:
When no browsers ship the API:
```
if (HTMLElement.prototype.foo) {
@William @Matthew
Ah, thanks. Now I think prollyfill is prolly a good name. :)
@Brian
Actually, I had this pattern in mind:
When no browsers ship the API:
```
if (HTMLElement.prototype.foo) {
HTMLElement.prototype._foo = HTMLElement.prototype.foo;
} else {
HTMLElement.prototype._foo =
On Tue, Aug 4, 2015 at 11:31 PM, Hallvord Reiar Michaelsen Steen
hst...@mozilla.com wrote:
so I hit a bit of an issue: I've written some parts of the clipboard spec
with the assumption that it will be invoked from a
document.execCommand('copy'/'cut'/'paste') call (although 'paste' would
On Thu, Aug 6, 2015 at 9:09 AM, Anne van Kesteren ann...@annevk.nl wrote:
On Tue, Aug 4, 2015 at 11:31 PM, Hallvord Reiar Michaelsen Steen
hst...@mozilla.com wrote:
so I hit a bit of an issue: I've written some parts of the clipboard spec
with the assumption that it will be invoked from a
On Thu, Aug 6, 2015 at 9:15 AM, Anne van Kesteren ann...@annevk.nl wrote:
According to Art
https://dvcs.w3.org/hg/xhr/raw-file/default/Overview.html is no longer
maintained. It should redirect to https://xhr.spec.whatwg.org/
therefore.
Well, I don't think he said exactly it's not maintained
On Wed, Aug 5, 2015 at 2:34 AM, MOHAN ARUN mar...@gmail.com wrote:
Would implementors want to support (writing stuff to the clipboard)?
Yes, we really, really want to allow that - at least for simple cases.
There are plenty of complex questions - for example what formats is it
safe to let JS
Hi Hallvord,
I don't have a specific opinion on where what should be done, speaking
personally I certainly don't have an issue with XHR being at the WHATWG,
but just some notes below in case it helps.
On 06/08/2015 14:07 , Hallvord Reiar Michaelsen Steen wrote:
And that is mostly my fault.
'Prolly' is a slang term for probably... At least in the US it is.
On Aug 5, 2015 11:00 PM, Glen Huang curvedm...@gmail.com wrote:
Thanks for the detailed explanation.
The only thing I'm not sure I understand is the pattern you described:
```
HTMLElement.prototype.foo =
On 8/6/15 3:15 AM, Anne van Kesteren wrote:
According to Art
https://dvcs.w3.org/hg/xhr/raw-file/default/Overview.html is no longer
maintained.
WebApps agreed to stop work on the above (aka XHR L2) and published a WG
Note in November 2014 [1].
It should redirect to
Question all,
Is web remoting web socket built in HTML 5 and above/
Why do we need XMLHttpRequest at all?
Pls. enlighten me.
I am not sure if we should be bothering about
XMLHttpRequest.
L.Mohan Arun
@cintanotes2
I want to write/proofread from home.
On Thu, Aug 6, 2015 at 5:49 PM, Matthew Robb
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.
Because it will probably become a real polyfill.
Em Thu, Aug 6, 2015 às 4:00 AM, Glen Huang curvedm...@gmail.com escreveu:
Thanks for the detailed explanation.
The only thing I'm not sure I understand is the pattern you described:
```
HTMLElement.prototype.foo = HTMLElement.prototype._foo;
Hi,
Sorry if I might be out of scope, I am quite new in this mailing list.
The clipboard is aimed to exchange any? data between any apps running on
your computer. It is not a browser stuff, it is an OS stuff that any app,
including a browser, may use. I would like to use it in such a way I
Thanks for the detailed explanation.
The only thing I'm not sure I understand is the pattern you described:
```
HTMLElement.prototype.foo = HTMLElement.prototype._foo;
```
I had this pattern in mind when you talked about prollyfills:
```
HTMLElement.prototype._foo = function() {
if
+domenic
We've recently finished the ReadableStream part of the spec and
experimenting integration with the Fetch API. Most of the spec is still
unstable. I don't have bandwidth to maintain W3C version of the spec even
briefly currently...
Takeshi
On Tue, Aug 4, 2015 at 11:13 PM, Arthur Barstow
Would implementors want to support (writing stuff to the clipboard)?
Actually, no - The Simpsons already did it.
Lets not think about windows clipboard. Those are Windows.
We are browser.
I feel clipboard is something that contains copy of
contenteditable items of the same web page.
We seem to
Do polyfills like WebReflection's DOM4 look promising?
No. Lets choose to not spoil a text-based markup language by trying to
emulate geometry. etc. There are other tools for geometry. HTML not suited
for geometry.
'I feel it's more sustainable to bet on spec APIs.'
No. I prefer lets Focus on
On 7/30/15 8:46 AM, Arthur Barstow wrote:
http://w3c.github.io/charter-html/group-charter.html
The WebApps + HTML WG draft charter says the following about WebApps'
Streams API:
[[
Streams API https://w3c.github.io/streams-api/
An API for representing a stream of data in web
Hi,
I proposed some changes to the cascade order in the CSS Scoping spec
on www-style[1] a while back. I've had positive feedback from Google,
but I thought I'd notify WebApps, as some Web Components people might
not be on www-style.
I've sent a github pull request for adding the proposal[2] to
On Tue, Aug 4, 2015 at 8:22 PM, Glen Huang curvedm...@gmail.com wrote:
There's actually a lot of questions in here, so let me take them one
at a time...
On second thought, what's the difference between prollyfills and libraries
A major difference is that it's hard to translate libraries into
Hi,
so I hit a bit of an issue: I've written some parts of the clipboard spec
with the assumption that it will be invoked from a
document.execCommand('copy'/'cut'/'paste') call (although 'paste' would
require some extra permission work which no UA but IE has attempted so far).
Meanwhile, the
On second thought, what's the difference between prollyfills and libraries
exposed web APIs in a functional style (e.g., node1._replaceWith(node2) vs
replaceWith(node2, node1)? Or in a wrapper style like jquery does? Prefixing
APIs doesn't seem to be that different from using custom APIs? You
Thanks. I merged the pull request,
https://github.com/w3c/webcomponents/pull/292.
Now the proposal is at
https://github.com/w3c/webcomponents/blob/gh-pages/proposals/Shadow-DOM-Cascade-Order.md
On Tue, Aug 4, 2015 at 11:41 PM Rune Lillesveen r...@opera.com wrote:
Hi,
I proposed some changes
On Thu, Jul 30, 2015 at 7:29 AM, Arthur Barstow art.bars...@gmail.com wrote:
Hi All,
This is heads-up re the intent to publish a Working Draft of WebIDL Level
1 (on or around August 4) using Yves' document as the basis and a new
shortname of WebIDL-1:
Brian,
prollyfills seems pragmatic. But what about when the logic of an API changes,
but not the name? The node.replaceWith() API for example is about to be
revamped to cover some edge cases. If the prollyfills exposed
node._replaceWith(), what should it do when the new node.replaceWith()
On Mon, Aug 3, 2015 at 9:07 PM, Glen Huang curvedm...@gmail.com wrote:
Brian,
prollyfills seems pragmatic. But what about when the logic of an API changes,
but not the name? The node.replaceWith() API for example is about to be
revamped to cover some edge cases. If the prollyfills exposed
(Dang, just realized I forgot to include WebApps on this joint deliverable.)
Members of WebApps, please note the below Call for Consensus on proposed
non-normative updates to the CORS recommendation and comment on
public-webapp...@w3.org by Monday, August 10, 2015.
Thank you,
Brad Hill
I'm pretty obsessed with all kinds of web specs, and invest heavily in tools
based on future specs. I was discussing with Tab the other day about whether he
thinks using a css preprocessor that desugars future css is a good idea. His
answer was surprisingly (at least to me) negative, and
On Sun, Aug 2, 2015 at 9:39 PM, Glen Huang curvedm...@gmail.com wrote:
I'm pretty obsessed with all kinds of web specs, and invest heavily in tools
based on future specs. I was discussing with Tab the other day about whether
he thinks using a css preprocessor that desugars future css is a
I am pleased to announce Arun is nowan Invited Expert in this group (he
is no longer a member of WebApps on behalf of Mozilla).
Thanks Arun!
-AB
Hi All,
The proposal to merge the WebApps WG and the HTML WG has started a
formal review period that ends September 10:
http://w3c.github.io/charter-html/group-charter.html
If you have any comments about the proposal, please reply to this e-mail
or [Github] before September 10.
Note
Hi folks,
Thanks to PLH (Who was a bit quicker than me to publish the work) there
are combined minutes of nearly everything from the webapps face to face
meeting at http://www.w3.org/2015/07/21-webapps-minutes.html
Unfortunately, about the only things that got missed were the action items
https://www.w3.org/Bugs/Public/show_bug.cgi?id=27674
Bug 27674 depends on bug 26440, which changed state.
Bug 26440 Summary: Allow fullscreenchange events to be synchronized with
animation frames
https://www.w3.org/Bugs/Public/show_bug.cgi?id=26440
What|Removed
https://www.w3.org/Bugs/Public/show_bug.cgi?id=28614
Bug 28614 depends on bug 26440, which changed state.
Bug 26440 Summary: Allow fullscreenchange events to be synchronized with
animation frames
https://www.w3.org/Bugs/Public/show_bug.cgi?id=26440
What|Removed
https://www.w3.org/Bugs/Public/show_bug.cgi?id=16502
Anne ann...@annevk.nl changed:
What|Removed |Added
Status|NEW |RESOLVED
https://www.w3.org/Bugs/Public/show_bug.cgi?id=26516
Bug 26516 depends on bug 26440, which changed state.
Bug 26440 Summary: Allow fullscreenchange events to be synchronized with
animation frames
https://www.w3.org/Bugs/Public/show_bug.cgi?id=26440
What|Removed
https://www.w3.org/Bugs/Public/show_bug.cgi?id=26440
Anne ann...@annevk.nl changed:
What|Removed |Added
Status|NEW |RESOLVED
On Tue, 28 Jul 2015 08:24:17 -0400, Hallvord Reiar Michaelsen Steen
hst...@mozilla.com wrote:
On Tue, Jul 28, 2015 at 1:08 PM, Chaals McCathie Nevile
cha...@yandex-team.ru wrote:
I'm just thinking out loud here, but this problem is similar to one
already faced by email clients, especially
I'm just thinking out loud here, but this problem is similar to one
already faced by email clients, especially those which are web-based...
On Mon, 27 Jul 2015 15:03:40 -0400, Hallvord Reiar Michaelsen Steen
hst...@mozilla.com wrote:
On Tue, Jun 9, 2015 at 8:39 PM, Daniel Cheng
On Tue, Jul 28, 2015 at 1:08 PM, Chaals McCathie Nevile
cha...@yandex-team.ru wrote:
I'm just thinking out loud here, but this problem is similar to one
already faced by email clients, especially those which are web-based...
On Mon, 27 Jul 2015 15:03:40 -0400, Hallvord Reiar Michaelsen Steen
On Tue, Jun 9, 2015 at 8:39 PM, Daniel Cheng dch...@google.com wrote:
Currently, the Clipboard API [1] mandates support for a number of formats.
Unfortunately, we do not believe it is possible to safely support writing a
number of formats to the clipboard:
- image/png
- image/jpg, image/jpeg
My 2c inline below:
On 27 July 2015 at 12:03, Hallvord Reiar Michaelsen Steen
hst...@mozilla.com wrote:
On Tue, Jun 9, 2015 at 8:39 PM, Daniel Cheng dch...@google.com wrote:
Currently, the Clipboard API [1] mandates support for a number of
formats. Unfortunately, we do not believe it is
https://www.w3.org/Bugs/Public/show_bug.cgi?id=28460
Anne ann...@annevk.nl changed:
What|Removed |Added
Status|NEW |RESOLVED
On Wed, Jul 22, 2015 at 12:27 PM Hallvord Reiar Michaelsen Steen
hst...@mozilla.com wrote:
Hi,
there's an interesting proposal here
https://github.com/w3c/clipboard-apis/issues/9
for solving our what about clipboard data from various native
applications? conundrum. The proposal is to let a
Hi,
there's an interesting proposal here
https://github.com/w3c/clipboard-apis/issues/9
for solving our what about clipboard data from various native
applications? conundrum. The proposal is to let a page indicate what
native clipboard identifiers it is interested in handling:
WebApps-ACTION-757: Collect the various minutes and make them as coherent as
the reality of the meeting.
http://www.w3.org/2008/webapps/track/actions/757
Assigned to: Charles McCathie Nevile
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
https://www.w3.org/Bugs/Public/show_bug.cgi?id=28967
Bug ID: 28967
Summary: Legacy appendices should be normative
Product: WebAppsWG
Version: unspecified
Hardware: All
OS: All
Status: NEW
Severity: normal
A while back we sent a consolidated pile of feedback on the Web Components
family of specs. In preparation for tomorrow's F2F, here is an update on our
positions. We've also changed the bugzilla links to point to relevant github
issues instead.
We're only covering Custom Elements (the main
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
On Jul 20, 2015, at 10:29 PM, Domenic Denicola d...@domenic.me wrote:
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
I’m re-sending the following message from Maciej because I received a
report that some members of the list didn’t receive it when he sent it
However, note that it did reach the list, because it’s already archived at
https://lists.w3.org/Archives/Public/public-webapps/2015JulSep/0204.html
-
https://www.w3.org/Bugs/Public/show_bug.cgi?id=27674
Anne ann...@annevk.nl changed:
What|Removed |Added
Status|NEW |RESOLVED
https://www.w3.org/Bugs/Public/show_bug.cgi?id=28459
Anne ann...@annevk.nl changed:
What|Removed |Added
Status|NEW |RESOLVED
https://www.w3.org/Bugs/Public/show_bug.cgi?id=26676
Anne ann...@annevk.nl changed:
What|Removed |Added
Status|NEW |RESOLVED
If the main draw of wanting custom constructors is to be able to interface with
other custom elements that may not have been upgraded, maybe we could skip the
custom constructor and all of its attached concerns altogether by adding some
sort of 'elementUpgraded' event to the document that is
On Fri, Jul 17, 2015 at 4:15 PM, Domenic Denicola d...@domenic.me wrote:
From: Anne van Kesteren [mailto:ann...@annevk.nl]
It fails atomically, based on the definition of innerHTML.
What if that 512 KiB of HTML contains img src=foo.png? Following
definitions, I assume we fire off the network
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
https://www.w3.org/Bugs/Public/show_bug.cgi?id=27162
Anne ann...@annevk.nl changed:
What|Removed |Added
Status|NEW |RESOLVED
https://www.w3.org/Bugs/Public/show_bug.cgi?id=28614
Anne ann...@annevk.nl changed:
What|Removed |Added
Status|NEW |RESOLVED
On Fri, Jul 17, 2015 at 5:47 PM, Boris Zbarsky bzbar...@mit.edu wrote:
On 7/17/15 10:38 AM, Anne van Kesteren wrote:
If I look at update the image data step 6 it seems it might be
fetched at a later point?
Yes, but in practice the fetch will go ahead, no? There's nothing to
prevent it from
Thanks everyone! Started a draft agenda page here; please pile in!
https://github.com/slightlyoff/ServiceWorker/wiki/july_20_2015_meeting_agenda
On Wed, Jul 15, 2015 at 10:38 PM, Benjamin Kelly bke...@mozilla.com wrote:
On Sat, Jul 4, 2015 at 7:26 AM, Alex Russell slightly...@google.com
On Thu, Jul 16, 2015 at 10:36 PM, Domenic Denicola d...@domenic.me wrote:
I have a related question: what happens if the constructor throws?
Right, this is the kind of thing we need to figure out.
!DOCTYPE html
script
use strict;
window.throwingMode = true;
class XFoo extends
On 7/17/15 12:05 PM, Anne van Kesteren wrote:
True, but either way this doesn't seem like a problem. You can create
a DocumentFragment, insert a new img, and then let it be GC'd,
today.
Sure. In practice it won't get GC'd until the load completes, which is
sucky, but that's life.
-Boris
On 7/17/15 10:38 AM, Anne van Kesteren wrote:
If I look at update the image data step 6 it seems it might be
fetched at a later point?
Yes, but in practice the fetch will go ahead, no? There's nothing to
prevent it from happening, so it's going to happen once you reach a
stable state...
OK, after reading Dominic's proposal [1], I'm a little confused. I thought that
I understood how constructors should work, but there's some magic going on that
I can't follow... I'm sure you folks can help.
```
class CustomElement extends HTMLElement {
constructor() {
super();
}
}
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
On 7/17/15 2:03 PM, Travis Leithead wrote:
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
Sure, but neither does Array. What super() actually does
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].
On Jul 17, 2015, at 1:14 PM, Travis Leithead travis.leith...@microsoft.com
wrote:
From: Domenic Denicola [mailto:d...@domenic.me]
window.XFoo = document.registerElement(‘x-foo’, XFooStartup);
Why is XFoo different from XFooStartup? If I define a method in XFooStartup,
does it exist
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
From: Domenic Denicola [mailto:d...@domenic.me]
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
On 16 July 2015 at 09:36, Domenic Denicola d...@domenic.me wrote:
- https://w3c.github.io/webrtc-pc/
Specifically:
https://w3c.github.io/webrtc-pc/#rtctrackevent - should be OK
https://github.com/w3c/webrtc-pc/issues/251
On 07/16/2015 08:30 AM, Domenic Denicola wrote:
From: Travis Leithead [mailto:travis.leith...@microsoft.com]
I've discussed this issue with some of Edge's key parser developers.
Awesome; thank you for doing that!
I believe to be the most straightforward approach that most closely matches
Hey folks,
Now that WebIDL has added FrozenArray and dropped T[], it's time to switch
over! On the other hand, there are a number of specs that have already gone to
Rec that used the old syntax.
Recommendations:
*HTML5
*Web Messaging
Other references:
*CSS OM
*
On Thu, Jul 16, 2015 at 6:49 PM, Domenic Denicola d...@domenic.me wrote:
Even if it can be specced/implemented, should it? I.e., why would this be OK
where MutationEvents are not?
Apart from the verbosity and performance issues with mutation events,
I think the main problem with mutation
WebApps has been asked to review the Tracking Protection group's July 14
Last Call Working Draft of T/racking Compliance and Scope/:
http://www.w3.org/TR/2015/WD-tracking-compliance-20150714/
If anyone in WebApps wants to propose an official group response, please
do so ASAP, in reply to
On Thu, Jul 16, 2015 at 6:03 PM, Domenic Denicola d...@domenic.me wrote:
Ah OK, thanks. Is there any way to get a consensus from Mozilla as a whole,
preferably ahead of the F2F?
I think the problem is that nobody has yet tried to figure out what
invariants that would break and how we could
On 7/16/15 12:02 PM, cha...@yandex-team.ru wrote:
But would just abandoning T[] break anything elsewhere?
It's hard to break something that never worked. No browser ever
implemented anything for T[] to my knowledge.
-Boris
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)].
On 7/16/15 11:45 AM, Travis Leithead wrote:
Now that WebIDL has added FrozenArray and dropped T[], it’s time to
switch over! On the other hand, there are a number of specs that have
already gone to Rec that used the old syntax.
Note that since the old syntax was never supported by any UA in
On Thu, Jul 16, 2015 at 5:45 PM, Travis Leithead
travis.leith...@microsoft.com wrote:
Should we consider keeping T[] in WebIDL, but having it map to FrozenArray?
We should just update the relevant specifications. We'll continue to
hit this as IDL still needs to evolve quite a bit.
--
16.07.2015, 17:59, Anne van Kesteren ann...@annevk.nl:
On Thu, Jul 16, 2015 at 5:45 PM, Travis Leithead
travis.leith...@microsoft.com wrote:
Should we consider keeping T[] in WebIDL, but having it map to
FrozenArray?
We should just update the relevant specifications.
That seems a rational
On Thu, Jul 16, 2015 at 6:02 PM, cha...@yandex-team.ru wrote:
But would just abandoning T[] break anything elsewhere? Is there any value in
having it mapped and deprecated?
If specifications were written by a team the size of a browser that
might be reasonable, but it really seems like more
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
I have a related question: what happens if the constructor throws? Example:
!DOCTYPE html
script
use strict;
window.throwingMode = true;
class XFoo extends HTMLElement {
constructor() {
if (window.throwingMode) {
throw new Error(uh-oh!);
}
}
}
On Thu, Jul 16, 2015 at 8:45 AM, Travis Leithead
travis.leith...@microsoft.com wrote:
Recommendations:
·HTML5
·Web Messaging
Other references:
·CSS OM
·Web Sockets
·WebRTC
Note that in practice I would think that most implementations return
objects
On Thu, Jul 16, 2015 at 9:49 AM, Domenic Denicola d...@domenic.me wrote:
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
I'm glad to hear that somebody has been working on this issue!
After read your proposal and previous dicussion, I realized that such
locking mechanism doesn't have to be tied to specific storage mechanism,
and a promise-based API
is more general than a synchronous API.
在 2015年07月16日 01:12,
On Thu, Jul 16, 2015 at 12:16 PM, Domenic Denicola d...@domenic.me wrote:
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,
I've discussed this issue with some of Edge's key parser developers. From a
technical ground, we do not have a problem with stopping the parser to callout
to author code in order to run a constructor, either during parsing or cloning.
For example, in parsing, I would expect that the callout
On 07/16/2015 03:45 AM, Domenic Denicola wrote:
Hi all,
Ahead of next week's F2F, I'm trying to pull together some clarifying and
stage-setting materials, proposals, lists of open issues, etc. In the
end, they all get blocked on one key question:
**Is it OK to run author code during
801 - 900 of 27344 matches
Mail list logo
