Re: =[xhr]

2014-08-31 Thread Brian Di Palma
I would suggest taking a look at what you can do with Generators and Promises in ES6 for example ( https://www.npmjs.org/package/co ) or if you want to try something from ES7 async functions https://github.com/lukehoban/ecmascript-asyncawait I work on applications of over 200,000K LOC and we load

Re: [HTML Imports] What is the imagined work flow?

2014-07-22 Thread Brian Di Palma
:09 PM, Ryosuke Niwa rn...@apple.com wrote: On Jul 2, 2014, at 3:57 AM, Brian Di Palma off...@gmail.com wrote: I'm happy to hear that it seems natural to trigger resource loading within a module. For example, I could imagine adding a new syntax for loading an arbitrary sub resource dependency

Re: Feedback on custom elements and virtual DOM

2014-07-19 Thread Brian Di Palma
from being standardized, implemented in browsers and used by developers. A standard will have mind share purely because it's a standard but it doesn't seem like a significant step forward. On Wed, Jul 2, 2014 at 4:18 PM, Ryosuke Niwa rn...@apple.com wrote: On Jul 2, 2014, at 3:57 AM, Brian Di Palma

Re: [HTML Imports] What is the imagined work flow?

2014-07-02 Thread Brian Di Palma
On Jun 5, 2014, at 6:07 AM, Brian Di Palma off...@gmail.com wrote: Dimitri, Thank you for your excellent reply. As you mention the dependency resolution properties are also available in ES6 modules. I feel there is a case to be made for ES6 modules being used for any resource type loading

Re: [HTML Imports] What is the imagined work flow?

2014-06-05 Thread Brian Di Palma
nicely into the imports story as well -- it's just one of dependencies. :DG On Fri, May 23, 2014 at 9:35 AM, Brian Di Palma off...@gmail.com wrote: HTML Imports seems the least crucial of the Web Components specs. Consider that all but the most trivial of Web Components will require JS. JS

Re: [HTML Imports] What is the imagined work flow?

2014-05-23 Thread Brian Di Palma
HTML Imports seems the least crucial of the Web Components specs. Consider that all but the most trivial of Web Components will require JS. JS is now getting a module system which can be used to load other resources ( e.g. https://github.com/systemjs/systemjs/#plugins ). The JS module system

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

2013-12-10 Thread Brian Di Palma
On Tue, Dec 10, 2013 at 9:23 AM, Ryosuke Niwa rn...@apple.com wrote: On Dec 7, 2013, at 8:33 PM, Rafael Weinstein rafa...@google.com wrote: On Sat, Dec 7, 2013 at 6:56 PM, Ryosuke Niwa rn...@apple.com wrote: On Dec 7, 2013, at 3:53 PM, Rafael Weinstein rafa...@google.com wrote: The

Re: [webcomponents] Binding Custom Element without Polluting Global Scope (Was Proposal for Cross Origin Use Case and Declarative Syntax)

2013-12-07 Thread Brian Di Palma
On Sat, Dec 7, 2013 at 1:01 AM, Ryosuke Niwa rn...@apple.com wrote: On Dec 6, 2013, at 1:20 AM, Brian Di Palma off...@gmail.com wrote: On Fri, Dec 6, 2013 at 3:24 AM, Ryosuke Niwa rn...@apple.com wrote: On Nov 12, 2013, at 12:45 AM, Ryosuke Niwa rn...@apple.com wrote: On Nov 12, 2013, at 8:12

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

2013-12-07 Thread Brian Di Palma
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 honestly curious as I'm not too familiar with the spec. On

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

2013-12-07 Thread Brian Di Palma
can achieve that right now without a new spec. On Sat, Dec 7, 2013 at 10:16 PM, Domenic Denicola dome...@domenicdenicola.com wrote: 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

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

2013-12-07 Thread Brian Di Palma
...@domenicdenicola.com wrote: 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

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

2013-12-07 Thread Brian Di Palma
On Sat, Dec 7, 2013 at 11:07 PM, Domenic Denicola dome...@domenicdenicola.com wrote: 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

Re: [webcomponents] Binding Custom Element without Polluting Global Scope (Was Proposal for Cross Origin Use Case and Declarative Syntax)

2013-12-06 Thread Brian Di Palma
On Fri, Dec 6, 2013 at 3:24 AM, Ryosuke Niwa rn...@apple.com wrote: On Nov 12, 2013, at 12:45 AM, Ryosuke Niwa rn...@apple.com wrote: On Nov 12, 2013, at 8:12 AM, Dimitri Glazkov dglaz...@chromium.org wrote: 1) It is not friendly to ES6 classes. In fact, you can't use class syntax and this

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

2013-12-06 Thread Brian Di Palma
On Fri, Dec 6, 2013 at 1:37 AM, Ryosuke Niwa rn...@apple.com wrote: Hi, Given that many important/natural use cases of custom elements involve shadow DOM, can we add a flag to auto-create shadow DOM for custom elements? In particular, can we add template as the third argument to

Re: Styling form control elements

2013-12-06 Thread Brian Di Palma
If UA controls are not styleable in the manner I wish them to be and I have access to custom elements + shadow DOM, I think I would just create my own controls and use them instead of UA ones. I know it sounds wasteful but I'd imagine that the best ones would end up being reused much like jQuery

Re: Styling form control elements

2013-12-06 Thread Brian Di Palma
On Fri, Dec 6, 2013 at 12:59 PM, Scott González scott.gonza...@gmail.com wrote: On Fri, Dec 6, 2013 at 5:26 AM, Brian Di Palma off...@gmail.com wrote: If UA controls are not styleable in the manner I wish them to be and I have access to custom elements + shadow DOM, I think I would just

Re: Styling form control elements

2013-12-06 Thread Brian Di Palma
On Fri, Dec 6, 2013 at 4:00 PM, Scott González scott.gonza...@gmail.com wrote: On Fri, Dec 6, 2013 at 10:53 AM, Brian Di Palma off...@gmail.com wrote: I did mention that these would probably be turned into reusable components in widget libraries. If they hope to be used by developers I see

Re: [webcomponents] HTML Imports

2013-12-04 Thread Brian Di Palma
To be fair though Web Components are bleeding edge and the vast majority of developers have had no interaction with them at all. I work in a company that should see huge benefits from Web Components as we build large scale browser applications and not one developer has had the time to investigate

Re: [webcomponents] HTML Imports

2013-12-04 Thread Brian Di Palma
: On Wed, Dec 4, 2013 at 10:37 AM, Dimitri Glazkov dglaz...@chromium.org wrote: On Wed, Dec 4, 2013 at 9:56 AM, Dimitri Glazkov dglaz...@chromium.org wrote: On Wed, Dec 4, 2013 at 4:32 AM, Anne van Kesteren ann...@annevk.nl wrote: On Wed, Dec 4, 2013 at 9:21 AM, Brian Di Palma off

Re: [HTML Imports]: what scope to run in

2013-11-20 Thread Brian Di Palma
On Tue, Nov 19, 2013 at 10:16 PM, Rick Waldron waldron.r...@gmail.com wrote: On Mon, Nov 18, 2013 at 11:26 PM, Ryosuke Niwa rn...@apple.com wrote: We share the concern Jonas expressed here as I've repeatedly mentioned on another threads. On Nov 18, 2013, at 4:14 PM, Jonas Sicking

Re: [webcomponents] Proposal for Cross Origin Use Case and Declarative Syntax

2013-11-12 Thread Brian Di Palma
I'm not sure I would want jQuery UI to pollute the window object with $, with ES6 modules around the corner it seems like a step backwards for imports to start polluting window objects with their libraries... On Tue, Nov 12, 2013 at 9:01 PM, Elliott Sprehn espr...@gmail.com wrote: On Tue, Nov

Re: HTML as application manifest format

2013-08-09 Thread Brian Di Palma
I've no experience of the previous XML manifest files but I must admit that I find the arguments for HTML quite persuasive. My default and original position would have been for JSON. I know that I for one will now be more open toward using HTML as a data definition format in my own work. On Tue,

Re: [webcomponents]: When element is having a bad time

2013-08-01 Thread Brian Di Palma
at 5:50 PM, Dimitri Glazkov dglaz...@google.com wrote: On Wed, Jul 31, 2013 at 9:23 AM, Brian Di Palma off...@gmail.com wrote: Is it not possible to have a linking stage before a compile stage? Can you help me understand this idea? I don't quite get the definitions of linking and compile when