RE: [DOM4] Short and Efficent DOM Traversal

2013-07-27 Thread Domenic Denicola
Both of these seem very like the ES6 iterator interface. Can you just use that instead of minting a new iterable/iterator interface, viz. `.iterator()`/`.next()` or `.nextNode()`? The resulting code would be ```js var tw = document.createTreeWalker(document.body, ul.menu li); for (var node of

RE: [DOM4] Short and Efficent DOM Traversal

2013-07-28 Thread Domenic Denicola
From: François REMY [mailto:francois.remy@outlook.com] If I'm not mistaken, all it takes for this to work is to add an .iterator() function on the TreeWalker/NodeIterator interface `.iterator()` is a nonstandard Mozilla-ism; the spec calls for a field named by the well-known unique

Re: Overlap between StreamReader and FileReader

2013-07-31 Thread Domenic Denicola
Hey all, I was directed here by Anne helpfully posting to public-script-coord and es-discuss. I would love it if a summary of what proposal is currently under discussion: is it [1]? Or maybe some form of [2]? [1]: https://rawgithub.com/tyoshino/stream/master/streams.html [2]:

RE: Overlap between StreamReader and FileReader

2013-07-31 Thread Domenic Denicola
From: Anne van Kesteren [ann...@annevk.nl] Stream.prototype.readType takes an enumerated string value which is arraybuffer (default) or text. Stream.prototype.read returns a promise fulfilled with the type of value requested. I believe this is somewhat similar to how Node streams have

RE: Overlap between StreamReader and FileReader

2013-07-31 Thread Domenic Denicola
From: Anne van Kesteren [ann...@annevk.nl] It seems though that if you can change the way bytes are consumed while reading a stream you will end up with problematic scenarios. E.g. you consume 2 bytes of a 4-byte utf-8 sequence. Then switch to reading code points... Instantiating a

RE: Overlap between StreamReader and FileReader

2013-08-08 Thread Domenic Denicola
From: Takeshi Yoshino [mailto:tyosh...@google.com] On Thu, Aug 1, 2013 at 12:54 AM, Domenic Denicola dome...@domenicdenicola.com wrote: Hey all, I was directed here by Anne helpfully posting to public-script-coord and es-discuss. I would love it if a summary of what proposal is currently

RE: Overlap between StreamReader and FileReader

2013-08-08 Thread Domenic Denicola
From: Takeshi Yoshino [tyosh...@google.com] Sorry, which one? stream.Readable's readable event and read method? Exactly. I agree flow control is an issue not addressed well yet and needs to be fixed. I would definitely suggest thinking about it as soon as possible, since it will likely have

RE: Overlap between StreamReader and FileReader

2013-08-09 Thread Domenic Denicola
Isaac has essentially explained what I was getting at earlier, except much more clearly. When I said this allows better pipelining and backpressure down to the network and file descriptor layer, I was essentially saying implementing read or write operations as cancellable and incremental does

RE: Selectors: name find method and find signature

2013-09-11 Thread Domenic Denicola
From: Tab Atkins Jr. [mailto:jackalm...@gmail.com] That helps when you've *already* run findAll() once, and need to run it again on the results, but it doesn't help at all when you're starting with a set of elements, unless we perhaps make a constructable NodeList and force people to pass

RE: Selectors: name find method and find signature

2013-09-12 Thread Domenic Denicola
And in particular, the spec as written now doesn't clearly define the behavior of query() or queryAll(). Presumably they would be defined in some generic way (such that they can run with any object as this), but it's not obvious what that generic way is in this case. This seems like a

RE: Selectors: name find method and find signature

2013-09-12 Thread Domenic Denicola
From: Boris Zbarsky [mailto:bzbar...@mit.edu] I think it depends on what the internal properties bit is and how flexible it's supposed to be. For example, if in this case the basic operation would be to check for a C++ Element instance and then call some C++ method with that instance,

RE: Selectors: name find method and find signature

2013-09-12 Thread Domenic Denicola
From: Boris Zbarsky [mailto:bzbar...@mit.edu] Why is that needed? If we just want this to be generic and all, it seems simplest to say that they just get the length of this, then run a counter from 0 to length, for each value [[Get]] that property, then [[Invoke]] querySelectorAll on it.

RE: Selectors: name find method and find signature

2013-09-13 Thread Domenic Denicola
From: Boris Zbarsky [mailto:bzbar...@mit.edu] TC39 and like-minded people are pushing in the direction of the platform being mostly a JavaScript library which would indeed give you exactly those problems... Why? There is no reason we can't have macros for commonly used ES-style patterns

RE: Selectors: name find method and find signature

2013-09-13 Thread Domenic Denicola
From: Boris Zbarsky [mailto:bzbar...@mit.edu] None of those affect the common pitfalls people run into. Really? Argument defaulting and destructuring, at the very least, seems like something that's historically been done many different and un-ESey ways. As has been defining classes with

RE: Selectors: name find method and find signature

2013-09-13 Thread Domenic Denicola
Thanks Boris, this is indeed all very helpful. I just wanted to point out that what you are calling dictionaries is largely covered by what I called destructuring, on the input side at least. E.g. Furthermore, privileged code should never be working with raw page-provided ES objects, because

RE: Selectors: name find method and find signature

2013-09-13 Thread Domenic Denicola
From: Boris Zbarsky [mailto:bzbar...@mit.edu] Consider this IDL: dictionary Dict1 { long a = 5; }; dictionary Dict2 { sequenceDict1 dicts; } void foo(optional Dict2 arg); How would you express eqivalent semantics with destructuring? ```js function foo({ dicts:

Re: [webcomponents] Per-type ready event for Custom Elements

2013-09-26 Thread Domenic Denicola
I am not sure I entirely understand the problem, but generally ready events should be promises instead, since they allow you to subscribe even after the promise has been fulfilled and then still get called back. That sounds like it would be helpful for those users. I believe the new font load

RE: [webcomponents] Per-type ready event for Custom Elements

2013-09-27 Thread Domenic Denicola
From: daniel...@gmail.com [daniel...@gmail.com] on behalf of Daniel Buchner [dan...@mozilla.com] Surely then we should remove all events defined by the Web Component specs in favor of Promises, right? I don't think anyone's suggesting that; let's not stuff strawmen here. What's being

RE: publish WD of Streams API; deadline Nov 3

2013-10-30 Thread Domenic Denicola
From: Arthur Barstow [mailto:art.bars...@nokia.com] If you have any comments or concerns about this proposal, please reply to this e-mail by November 3 at the latest. I have some concerns about this proposal, and do not think it is solving the problem at hand in an appropriate fashion. I

RE: CfC: publish WD of Streams API; deadline Nov 3

2013-11-04 Thread Domenic Denicola
From: Arthur Barstow [mailto:art.bars...@nokia.com] Domenic - Mike Smith mentioned you have worked on a related spec. What is the URL? We are working on a streams specification which addresses the appropriate requirements at https://github.com/whatwg/streams. It is still a work in progress,

RE: [screen-orientation] screen orientation angle

2013-11-26 Thread Domenic Denicola
It would be a shame to continue the trend of verbose web APIs. lockOrientation is nice. If it fails, the promise is rejected. Many operations can fail; this is not an argument for prefixing them with request. Just lock the orientation. If there's a problem locking it, we'll deal with it :)

RE: Browser search API

2013-12-02 Thread Domenic Denicola
I really appreciate Mitar's desire to not hijack the browser's native UI, and instead intercept it and supply it with more helpful information. That seems definitely better than preventDefault()ing the normal search UI. From: Mitar mmi...@gmail.com Sent:

RE: Styling form control elements

2013-12-05 Thread Domenic Denicola
From: Jonas Sicking [mailto:jo...@sicking.cc] The tricky part is finding a set of pseudo elements that work across different UAs, and that give authors enough control that they can integrate the control with the look-and-feel of their website. I am wondering if we put forward the following

RE: Styling form control elements

2013-12-06 Thread Domenic Denicola
From: Jonas Sicking [mailto:jo...@sicking.cc] The control that you see by default can simply be targetted with select, no? Hmm, I suppose so. Although I have been unable to get rid of the arrow (which I consider part of that control) with CSS. And, I have found that styles applied to the

RE: Styling form control elements

2013-12-07 Thread Domenic Denicola
From: Boris Zbarsky [mailto:bzbar...@mit.edu] You can, but if it doesn't match the scrollbar width in cases when there is a scrollbar the result looks pretty terrible when the popup is opened... And scrollbar widths are user-configurable. Ah! Right. Well, styling scrollbars would also be

RE: [webcomponents] Auto-creating shadow DOM for custom elements

2013-12-07 Thread Domenic Denicola
From: Ryosuke Niwa [mailto:rn...@apple.com] Also, I'd like to hear opinions and perspectives of people who are not affiliated with either Apple or Google since the discussion is not going anywhere between us. In that case, web developer here. I feel that keeping them separate is much

RE: [webcomponents] Auto-creating shadow DOM for custom elements

2013-12-07 Thread Domenic Denicola
From: Brendan Eich [mailto:bren...@secure.meer.net] Requiring this kind of boilerplate out of the gave is not: this.createShadowRoot().appendChild(document.importNode(template.contents)); Wanting to avoid this kind of boilerplate is not a stab in the dark. Why can't we avoid it, even

RE: [webcomponents] Auto-creating shadow DOM for custom elements

2013-12-07 Thread Domenic Denicola
From: Brian Di Palma [mailto:off...@gmail.com] I'm just wondering what benefit is there in using custom elements if you don't use shadow dom or templates? If all we had was the custom elements spec would there be any appreciable gain for web developers without the other specs? I'm

RE: [webcomponents] Auto-creating shadow DOM for custom elements

2013-12-07 Thread Domenic Denicola
From: Brian Di Palma [mailto:off...@gmail.com] Are they appreciatively more powerful then just building Angular directives though? Do they enable any functionality that you could not access without the custom elements spec? Yes. There are at least two major benefits that I can see: 1)

RE: [webcomponents] Auto-creating shadow DOM for custom elements

2013-12-07 Thread Domenic Denicola
From: Brian Di Palma [mailto:off...@gmail.com] From your email it seems you can still achieve everything you can with custom elements when not using them, it would just involve more code/boilerplate. I don't see how you can draw that conclusion from my email, except perhaps the trivial

RE: [webcomponents] Inheritance in Custom Elements (Was Proposal for Cross Origin Use Case and Declarative Syntax)

2013-12-07 Thread Domenic Denicola
From: Dominic Cooney [mailto:domin...@google.com] If someone were to make proposals about adding more hooks to the web platform to enable more subtyping use cases (for example, a protocol for participating in form submission) I would look forward to working with them on those proposals.

RE: [webcomponents] Inheritance in Custom Elements (Was Proposal for Cross Origin Use Case and Declarative Syntax)

2013-12-10 Thread Domenic Denicola
From: a...@google.com a...@google.com on behalf of Erik Arvidsson a...@chromium.org On Tue, Dec 10, 2013 at 10:34 AM, Anne van Kesteren ann...@annevk.nl wrote: I think Ryosuke has a point here though. ES6 brings subclassing to the platform, but are not even close to reimagining the

RE: Styling form control elements

2013-12-10 Thread Domenic Denicola
From: Jonas Sicking jo...@sicking.cc Actually, I think our mental models are surprisingly aligned. Which is great! More below. Sweet! So dropping the arrowthingy element seems fine. I'm not opposed to it, just trying to come up with something minimal. option:hover should just work, no?

RE: [testing] Common way to manage test bugs?

2013-12-19 Thread Domenic Denicola
I would encourage use of GitHub for greater developer involvement. I think elsewhere in the thread it's been covered how to adapt GitHub issues to solve the potential problems you mention, so hopefully it's sufficient technically for your needs. Just wanted to give a voice to that perspective,

RE: [promises] Guidance on the usage of promises for API developers

2014-01-14 Thread Domenic Denicola
I like your way of phrasing it, because it does not explicitly queue a needless task. But I am not sure how generally it applies. What did you think of the addBookmark example? https://github.com/domenic/promises-unwrapping/blob/master/docs/writing-specifications-with-promises.md#addbookmark--

RE: [promises] Guidance on the usage of promises for API developers

2014-01-14 Thread Domenic Denicola
From: Boris Zbarsky bzbar...@mit.edu On 1/14/14 9:22 AM, Domenic Denicola wrote: Do you think it would be improved by nesting step 5 under These steps will be run asynchronously? Yes. Otherwise if there is another method that allows synchronously checking whether a bookmark has been

RE: [promises] Guidance on the usage of promises for API developers

2014-01-16 Thread Domenic Denicola
From: Boris Zbarsky bzbar...@mit.edu All the terms in the Creating Promises are implicitly assuming operation in a particular realm [1]. Same for the ones in Aggregating Promises and the definition of Transforming p with onFulfilled and onRejected. Same thing for the Promise Arguments

RE: CFCs for ordinary drafts, was CFC for Re: W3C XHR, was Re: [admin] Draft of updated charter available for review

2014-01-27 Thread Domenic Denicola
This sounds great. It would be cool if editors ping the relevant list as working drafts get updated, just so everyone can use the lists as an ambient feed of what's going on. But an actual CFC process seems unnecessary. From: Jonas Sicking jo...@sicking.cc

RE: [quota-api] Heads-up: TAG review started

2014-01-29 Thread Domenic Denicola
Hi guys! Just so you know my review notes are very preliminary and I wanted to run them by other TAG members before presenting them in any official capacity; don't take them too seriously yet :)

RE: [promises] Guidance on the usage of promises for API developers

2014-01-29 Thread Domenic Denicola
2014 22:50:19 + Resent-From:www-...@w3.org Date: Mon, 13 Jan 2014 22:49:30 + From: ext Domenic Denicola dome...@domenicdenicola.com To: www-...@w3.org www-...@w3.org In the past, the TAG has discussed producing a document on how to use promises in spec text. There's even

RE: Officially deprecating main-thread synchronous XHR?

2014-02-07 Thread Domenic Denicola
From: Olli Pettay olli.pet...@helsinki.fi And at least we'd improve responsiveness of those websites which stop using sync XHR because of the warning. I think this is a great point that makes such an effort worthwhile even if it ends up not leading to euthanizing sync XHR.

RE: Form submission participation (was Re: Goals for Shadow DOM review)

2014-02-20 Thread Domenic Denicola
From: Jonas Sicking jo...@sicking.cc I'm not sure if we should return a dictionary or an array. Keep in mind that a form control can have multiple values. This is something used by both input multiple and select multiple. Also keep in mind that order matters as many servers are sensitive

RE: Form submission participation (was Re: Goals for Shadow DOM review)

2014-02-21 Thread Domenic Denicola
From: Ryosuke Niwa rn...@apple.com What if we added formparticipant boolean content attribute and fired formdata event during form submission to serialize data? I don't understand the virtue of this inverted model, where controls are responsible for listening to their containing form and

RE: [Editing] Splitting Selection API Into a Separate Specification

2014-03-13 Thread Domenic Denicola
From: Ryosuke Niwa [mailto:rn...@apple.com] Any thoughts and opinions? Have there been indications from vendors that they would have more resources to devote to implementing or critiquing the selection API if it were isolated into a smaller document? Is the idea that the surrounding text

RE: Push API - use parameterized Promise types

2014-03-20 Thread Domenic Denicola
From: Michael van Ouwerkerk mvanouwerk...@google.com It reads much better and the prose can be simplified. I am curious about the prose simplifications you mention? From talking to heycam, the value in the angle-brackets has no impact when used on the return type of a method, so I can't

RE: Push API - use parameterized Promise types

2014-03-20 Thread Domenic Denicola
From: Michael van Ouwerkerk mvanouwerk...@google.com Ah I didn't know it has no effect on return values. Why not? Well, I believe it's the same with all WebIDL method return values. If you return something that doesn't match the declared return value, that's a spec bug, but it has no impact

RE: Push API - use parameterized Promise types

2014-03-20 Thread Domenic Denicola
to be normative. Thanks, Michael On Thu, Mar 20, 2014 at 3:39 PM, Domenic Denicola dome...@domenicdenicola.commailto:dome...@domenicdenicola.com wrote: From: Michael van Ouwerkerk mvanouwerk...@google.commailto:mvanouwerk...@google.com Ah I didn't know it has no effect on return values. Why

RE: Push API - use parameterized Promise types

2014-03-20 Thread Domenic Denicola
Ouwerkerk mvanouwerk...@google.com Sent: Thursday, March 20, 2014 11:59 To: Domenic Denicola Cc: public-webapps Subject: Re: Push API - use parameterized Promise types Well, I interpreted your comment that way (it has no impact on anything). Maybe normative vs informative is not what you meant

RE: [custom-elements] :unresolved and :psych

2014-03-25 Thread Domenic Denicola
Do custom elements present any new challenges in comparison to non-custom elements here? I feel like you have the same issue with filling a select with data from a remote source. From: Brian Kardell bkard...@gmail.com Sent: Tuesday, March 25, 2014 17:31 To:

RE: [custom-elements] :unresolved and :psych

2014-03-25 Thread Domenic Denicola
It seems to me you probably should have just not included :unresolved in your very small subset. In reality, it seems, :unresolved for existing elements is just { display: none; }. That is, if you do `selectoptiona/option/select` you don't see the unstyled string a on the page, only later

[quota-api] TAG review feedback

2014-03-26 Thread Domenic Denicola
Hi everyone, The TAG recently spent some time looking at the current Quota API draft at [1], based on some early discussions between Alex and Kinuko. We believe that the topic of quotas and storage management has important architectural implications for expanding the capabilities of the web

RE: [Editing] Splitting Selection API Into a Separate Specification

2014-04-11 Thread Domenic Denicola
From: Ryosuke Niwa [mailto:rn...@apple.com] Given defining innerText is completely outside the scope of the selection API specification, we might need to defer this part to a level 2 specification since the only alternative is to wait for someone to write a innerText spec. I don't know all

RE: [Gamepad] Liveness of Gamepad objects

2014-04-29 Thread Domenic Denicola
From: Ted Mielczarek t...@mozilla.com Does anyone have any feedback on which of these seems more natural? Is there any precedent in the web platform to prefer one approach over the other? If the snapshot approach is chosen, I think it would be best to rename the Gamepad interface to

RE: Progress on Push API

2014-05-02 Thread Domenic Denicola
Regarding promise idiomaticness, the two proposals I've seen that look most reasonable would be: - isRegistered() + register(). But, this doesn't allow notification that you need to re-register, from what I can tell. - A variant on registrationNeeded, where---since it can return a different

RE: It doesn't make sense to use [MapClass] for the CacheList interface

2014-05-08 Thread Domenic Denicola
Agreed, this was odd to me. As an aside, I filed https://github.com/heycam/webidl/issues/11 regarding [MapClass]. -Original Message- From: Boris Zbarsky [mailto:bzbar...@mozilla.com] Sent: Thursday, May 8, 2014 23:15 To: public-webapps Subject: It doesn't make sense to use [MapClass]

RE: It doesn't make sense to use [MapClass] for the CacheList interface

2014-05-08 Thread Domenic Denicola
From: Jungkee Song [mailto:jungk...@gmail.com] Right. We're defining an AsyncMap interface [1] which Cache interface and CacheList interface are based off of. AsyncMap isn't spec'd yet in any place than in the .ts file. A difficulty encountered is we don't have any IDL construct for this

RE: [clipboard events] implicitly prevent default event action?

2014-05-19 Thread Domenic Denicola
From: annevankeste...@gmail.com annevankeste...@gmail.com on behalf of Anne van Kesteren ann...@annevk.nl Can you sanely explain those using a JavaScript implementation or would that be some kind of weird stack-inspecting feature? My impression was that it would be something like: if (data)

RE: Last Call for CSS Font Loading Module Level 3

2014-05-27 Thread Domenic Denicola
I strongly agree on the SetClass matter. A conventional set of method names is fine, but that should not necessitate a misleading subclass relationship. From: Jonas Sickingmailto:jo...@sicking.cc Sent: ‎2014-‎05-‎27 04:22 To: Daniel

RE: Fetch API

2014-06-01 Thread Domenic Denicola
Overall it looks really solid. Only a few things I could think of: - Named constructors scare me (I can't figure out how to make them work in JavaScript without breaking at least one of the normal invariants). I think a static factory method would make more sense for RedirectResponse. -

RE: Fetch API

2014-06-01 Thread Domenic Denicola
From: Tab Atkins Jr. [mailto:jackalm...@gmail.com] Using NamedConstructor is identical to doing: ```js class Foo { ... } let Bar = Foo; // now I can do new Foo() or new Bar(), to the same effect. ``` Not true, since the constructors take different arguments. Instead it is equivalent to

RE: Fetch API

2014-06-01 Thread Domenic Denicola
From: Tab Atkins Jr. [mailto:jackalm...@gmail.com] Out of curiosity, would you be okay with it if it was just an override? That is, if new Response(...) took either set of arguments for the ... part? It sounds like you would be. Yeah, I mean, I think in this case it would be kind of

RE: Fetch API

2014-06-03 Thread Domenic Denicola
From: Jake Archibald [mailto:jaffathec...@gmail.com] Agreed. So Response.redirect(url, status)? LGTM

RE: Fetch API

2014-06-06 Thread Domenic Denicola
4, 2014 00:50 To: Domenic Denicola Cc: public-script-coord; Joshua Bell; Jungkee Song; Yehuda Katz; Alex Russell; Jonas Sicking; Jake Archibald; Tobie Langel; WebApps WG Subject: Re: Fetch API On Sun, Jun 1, 2014 at 8:06 AM, Domenic Denicola dome...@domenicdenicola.com wrote: - HeaderMap should

RE: Fetch API

2014-06-06 Thread Domenic Denicola
For those who were not subscribed to public-webapps when that thread went down, here is the most convincing message: http://lists.w3.org/Archives/Public/public-webapps/2012AprJun/0150.html I was previously in favor of keeping things simpler by just doing ArrayBuffer, as it feels more right to

RE: Fetch API

2014-06-06 Thread Domenic Denicola
: Friday, June 6, 2014 17:31 To: Jonas Sicking Cc: Domenic Denicola; public-script-coord; Joshua Bell; Jungkee Song; Yehuda Katz; Alex Russell; Jake Archibald; Tobie Langel; WebApps WG Subject: Re: Fetch API On Fri, Jun 6, 2014 at 10:26 AM, Jonas Sicking jo...@sicking.cc wrote: I'm still arguing

RE: publish new WD of Shadow DOM on June 12

2014-06-06 Thread Domenic Denicola
I am a big fan of the giant warning at the bottom of the document. Will it be maintained in the published version? That would be ideal. -Original Message- From: Arthur Barstow [mailto:art.bars...@gmail.com] Sent: Friday, June 6, 2014 20:18 To: public-webapps Subject: PSA: publish new WD

RE: publish new WD of Shadow DOM on June 12

2014-06-06 Thread Domenic Denicola
From: Arthur Barstow [mailto:art.bars...@gmail.com] Could you live with those short qualifications/clarifications? Definitely; I see the concern and am glad you caught that.

RE: Indexed DB Transactions vs. Microtasks

2014-06-18 Thread Domenic Denicola
[+Yehuda, +Raf] From: Jonas Sicking [mailto:jo...@sicking.cc] On Thu, Jun 19, 2014 at 8:44 AM, Adam Klein ad...@google.com wrote: While I agree that the original microtask intent would suggest we change this, and I concur that it seems unlikely to break content, I worry about the spec and

RE: Indexed DB Transactions vs. Microtasks

2014-06-18 Thread Domenic Denicola
From: ad...@google.com [mailto:ad...@google.com] On Behalf Of Adam Klein This seems orthogonal to bucketing. The IDB transaction deactivation step isn't a sort of work that we'd want to bucket (as I argued in my previous message, treating this IDB work as a task leads down some bad roads)

RE: Fallout of non-encapsulated shadow trees

2014-07-01 Thread Domenic Denicola
From: Maciej Stachowiak m...@apple.com Web Components as currently designed cannot explain the behavior of any built-in elements (except maybe those which can be explained with CSS alone). Unfortunately this is a hard problem that nobody has even sketched a solution to. From what I

RE: Fallout of non-encapsulated shadow trees

2014-07-01 Thread Domenic Denicola
From: Edward O'Connor [mailto:eocon...@apple.com] But soft encapsulation is just as useless for explaining the platform as no encapsulation at all. I think just as useless overstates your case. Type 2 allows you to hide implementation details of your component from authors better than

RE: Fallout of non-encapsulated shadow trees

2014-07-01 Thread Domenic Denicola
From: Brendan Eich [mailto:bren...@secure.meer.net] That is a false idol if it means no intermediate steps that explain some but not all of the platform. Sure. But I don't think the proposed type 2 encapsulation explains any of the platform at all. (Just as per Maciej's email from Monday,

RE: Fallout of non-encapsulated shadow trees

2014-07-01 Thread Domenic Denicola
From: Brendan Eich [mailto:bren...@secure.meer.net] I don't even know what 3 means. Is it well defined, or just some utopia? I think it is as well defined as 2 is. Both are really in terms of vague requirements: 2. Widget libraries should be implementable without leaking implementation

RE: WebIDL Spec Status

2014-07-02 Thread Domenic Denicola
From: Ryosuke Niwa rn...@apple.com Snapshotting a specification is valuable for implementors as well. If I refer to a living standard page, then fragment ID or terminology used in the specification may change in 5-10 years, and I would have no idea what kind of specification the person

RE: WebIDL Spec Status

2014-07-02 Thread Domenic Denicola
From: Ian Hickson i...@hixie.ch I've been reluctant to do so to avoid people ending up on obsolete versions (e.g. by following links from old source code) and not realising what's going on. This is the danger, but I think an appropriately-annoying danger sign mitigates it significantly. I

RE: File API: reading a Blob

2014-07-02 Thread Domenic Denicola
of Anne van Kesteren ann...@annevk.nl Sent: Wednesday, July 02, 2014 10:28 To: WebApps WG; Arun Ranganathan Cc: Domenic Denicola Subject: File API: reading a Blob I tried to work out Fetch/Blob integration today. What I actually want is that reading a Blob is basically pushing the IO bytes

RE: Blocking message passing for Workers

2014-08-12 Thread Domenic Denicola
One thing that I haven't seen anyone explicitly state on this thread, in response to David's points, is that the semantics are observably and crucially different between fs.readFileSync(file.txt); console.log(read it!); and await fs.readFile(file.txt); console.log(read it!);

RE: [streams-api] Seeking status of the Streams API spec

2014-08-20 Thread Domenic Denicola
, August 18, 2014 14:28 To: Takeshi Yoshino; Feras Moussa; Domenic Denicola Cc: public-webapps; team-html-cha...@w3.org Subject: [streams-api] Seeking status of the Streams API spec Hi All, The HTML WG would like to know the status of the Streams API and if the February plan from Feras (see below

RE: [Custom] Custom elements and ARIA

2014-08-28 Thread Domenic Denicola
Hi Steve, thanks greatly for your help. It's clear now that I should have reached out to you for your expertise directly before being very wrong on a public mailing list :) From: Steve Faulkner faulkner.st...@gmail.com It appears (please correct me) you have made the assumption that 'strong

RE: [Custom] Custom elements and ARIA

2014-08-28 Thread Domenic Denicola
From: Nick Krempel ndkrem...@google.com Have you considered allowing ARIA attributes to be set on a shadow root. The semantics would be that the browser uses the value of an ARIA attribute on the (most recent) shadow root for an element, and only if it's not set there will it fall back to

RE: [Custom] Custom elements and ARIA

2014-08-28 Thread Domenic Denicola
to use. Would love to hear what others think. [1]: https://gist.github.com/domenic/ae2331ee72b3847ce7f5 [2]: https://gist.github.com/domenic/bc8a36d9608d65bd7fa9 -Original Message- From: Domenic Denicola [mailto:dome...@domenicdenicola.com] Sent: Wednesday, August 27, 2014 19:43 To: public

RE: =[xhr]

2014-09-05 Thread Domenic Denicola
FWIW I do not think ES6 modules are a good solution for your problem. Since they are not in browsers, you would effectively be adding a layer of indirection (the “transpilation” James discusses) that serves no purpose besides to beta-test a future platform feature for us. There are much more

RE: publishing new WD of URL spec

2014-09-10 Thread Domenic Denicola
This is a formal objection to the publication of this specification. My arguments against publishing this specification include that copying the spec from the WHATWG is an unnecessarily combative way of working with another standards body, especially with regard to the URL Standard wherein

RE: Service worker popup (rich notification)

2014-10-06 Thread Domenic Denicola
From: annevankeste...@gmail.com [mailto:annevankeste...@gmail.com] On Behalf Of Anne van Kesteren Constructing an object as a means of opening a new window seems really weird. Is that the pattern common JavaScript widget libraries adopt? Says the creator of `new Notification({...})` ;) But,

RE: test coverage data for XHR spec

2014-10-06 Thread Domenic Denicola
Very cool work Hallvord! This is exactly the kind of stuff that we need more of for today's specs, IMO. From: annevankeste...@gmail.com [mailto:annevankeste...@gmail.com] On Behalf Of Anne van Kesteren On Mon, Oct 6, 2014 at 3:04 PM, Hallvord R. M. Steen hst...@mozilla.com wrote: If you do

RE: [streams-api] Seeking status of the Streams API spec

2014-10-09 Thread Domenic Denicola
From: Paul Cotton [mailto:paul.cot...@microsoft.com] Was this Aug goal achieved? Yes: https://streams.spec.whatwg.org/

RE: [streams-api] Seeking status of the Streams API spec

2014-10-13 Thread Domenic Denicola
To: Domenic Denicola Cc: public-webapps; Arthur Barstow; Takeshi Yoshino; Feras Moussa Subject: RE: [streams-api] Seeking status of the Streams API spec The previous W3C WD [1] identified a large number of specifications that were stream producers and consumers. Is there any kind of mapping

RE: [streams-api] Seeking status of the Streams API spec

2014-10-13 Thread Domenic Denicola
From: Paul Cotton [mailto:paul.cot...@microsoft.com] MSE [1] simply used the Stream object directly from the previous W3C WD [2]. Since this object no longer is available in [3], what you do recommend that MSE should do? OK, down to the fun stuff :). Here's my take based on some brief

RE: [streams-api] Seeking status of the Streams API spec

2014-10-14 Thread Domenic Denicola
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

RE: [streams-api] Seeking status of the Streams API spec

2014-10-14 Thread Domenic Denicola
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.

RE: [streams-api] Seeking status of the Streams API spec

2014-10-14 Thread Domenic Denicola
From: Aaron Colwell [mailto:acolw...@google.com] Yes SourceBuffer is shipping and has been for quite some time in Chrome and IE. Hmm, window.SourceBuffer is undefined in Chrome. I am NOT going to rework it all to be a WritableStream. That's a shame, but completely understandable that you

RE: [streams-api] Seeking status of the Streams API spec

2014-10-14 Thread Domenic Denicola
From: Aaron Colwell [mailto:acolw...@google.com] MSE is just too far along, has already gone through a fair amount of churn, and has major customers like YouTube and Netflix that I just don't want to break or force to migrate...again. Totally understandable. I haven't spent much time

RE: [streams-api] Seeking status of the Streams API spec

2014-10-15 Thread Domenic Denicola
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

RE: Push API and Service Workers

2014-10-15 Thread Domenic Denicola
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

RE: Questions on the future of the XHR spec, W3C snapshot

2014-10-17 Thread Domenic Denicola
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: -

RE: Questions on the future of the XHR spec, W3C snapshot

2014-10-19 Thread Domenic Denicola
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

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

2014-10-23 Thread Domenic Denicola
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: CfC: publish WG Note of XHR Level 2; deadline November 14

2014-11-07 Thread Domenic Denicola
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/?

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

2014-11-08 Thread Domenic Denicola
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

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

2014-11-08 Thread Domenic Denicola
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

  1   2   >