Re: Art steps down - thank you for everything

+1 :DG< On Thu, Jan 28, 2016 at 7:45 AM, Chaals McCathie Nevile < cha...@yandex-team.ru> wrote: > Hi folks, > > as you may have noticed, Art has resigned as a co-chair of the Web > Platform group. He began chairing the Web Application Formats group about a > decade ago, became the leading

Re: [Web Components] proposing a f2f...

I am available on all of those days. Will also be happy to help with logistics. :DG<

Re: [Web Components] proposing a f2f...

ry date so as to allow me to arrange travel. >> Otherwise, I’m happy to attend remotely anytime. >> >> >> >> *From:* Dimitri Glazkov [mailto:dglaz...@google.com] >> *Sent:* Thursday, October 29, 2015 2:52 AM >> *To:* Olli Pettay <o...@pettay.fi> >> *

Re: TPAC Topic: Using ES2015 Modules in HTML

Also keenly interested in moving this forward. :DG< On Fri, Oct 16, 2015 at 2:45 AM, Anne van Kesteren wrote: > On Fri, Oct 16, 2015 at 5:39 AM, Ryosuke Niwa wrote: > > Can we discuss how we can integrate ES2015 modules into HTML on Tuesday, > > October 27th

Shadow DOM Styling Meeting on September 18, 2015

Folks, Now that the Shadow DOM v1 implementations had started in a few browsers, we need a quick get-together to iron out implementation specifics around Shadow DOM styling and reconcile any remaining shifts (if any) in CSS Scoping spec due to Shadow DOM v1. To do this, we're going to meet on

Re: Components F2F

Hi folks! I just updated the meeting wiki [1] with the meeting location information. tl;dr: it's the same room that we had in April. [1]: https://www.w3.org/wiki/Webapps/WebComponentsJuly2015Meeting :DG On Thu, Jul 2, 2015 at 6:01 AM, cha...@yandex-team.ru wrote: Google had offered to host

Re: Custom Elements: is=

Folks, I agree with Anne that we've been having a somewhat circular re-discovery of the pros/cons here. I believe that the best way to address this is to capture all of these points in one doc -- this would be a just a little extra work for the current participants, but super awesome for the

Writing spec algorithms in ES6?

Folks, Many specs nowadays opt for a more imperative method of expressing normative requirements, and using algorithms. For example, both HTML and DOM spec do the run following steps list that looks a lot like pseudocode, and the Web components specs use their own flavor of prose-pseudo-code. I

Re: Custom Elements: is=

On Tue, Jun 9, 2015 at 8:13 AM, Anne van Kesteren ann...@annevk.nl wrote: - v1 sets the stage for people to develop habits and expectations about how custom elements work. New features tend to be slowly adopted, by both browser vendors and (partly as a consequence) developers, so even if

Re: [components] Isolated Imports and Foreign Custom Elements

On Sun, May 17, 2015 at 1:54 AM, Maciej Stachowiak m...@apple.com wrote: (Replying to slightly old thread.) Another thing that might be nice is that if these elements are that much isolated, perhaps we can consider allowing them to be renamed them as well, similar to what module

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

:DG -Original Message- From: Anne van Kesteren [mailto:ann...@annevk.nl] Sent: Wednesday, May 20, 2015 9:10 PM To: Dimitri Glazkov Cc: Scott Miles; Ryosuke Niwa; Edward O'Connor; Travis Leithead; Maciej Stachowiak; Arron Eicholz; public-webapps Subject: Re: [webcomponents] How

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

On Tue, May 19, 2015 at 10:09 AM, Domenic Denicola d...@domenic.me wrote: I think this model you cite Polymer using is different from what HTML normally does, which is why it was confusing to me. In HTML the insertion point tags (e.g. summary or li or option) act as dumb containers. This was

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

On Fri, May 15, 2015 at 4:58 PM, Scott Miles sjmi...@google.com wrote: Polymer really wants Shadow DOM natively, and we think the `slot` proposal can work, so maybe let's avoid blocking on design of an imperative API (which we still should make in the long run). As our entire stack is built

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

On Mon, May 18, 2015 at 6:48 PM, Hayato Ito hay...@chromium.org wrote: My preference in v1: 1. select (strongly preferred). okay to rename it if we have a better name. e.g. content select=xxx == slot select=xxx 2. select + content-slot 3. content-slot I was assuming that content-slot is

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

On Mon, May 18, 2015 at 8:18 PM, Hayato Ito hay...@chromium.org wrote: Thank you! I'm afraid that we don't have enough discussion about the pros and cons between select nodes using a selector and select nodes by a fixed id using attribute. BTW, here's one bit of research I'd done:

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

On Fri, May 15, 2015 at 5:45 PM, Scott Miles sjmi...@google.com wrote: How does it work for redistribution We've done some investigation and think it can work. Note that distributions work just fine with slots. The only thing that doesn't is partial redistributions, and we haven't been able

Re: Shadow DOM: state of the distribution API

I did a quick experiment around distribution timing: https://github.com/w3c/webcomponents/blob/gh-pages/proposals/Distribution-Timing-Experiment.md. Hope you find it helpful. :DG

Re: Shadow DOM: state of the distribution API

On Wed, May 6, 2015 at 2:05 AM, Anne van Kesteren ann...@annevk.nl wrote: It seems we have three contenders for the distribution API. 1) Synchronous, no flattening of content. A host element's shadow tree has a set of slots each exposed as a single content element to the outside. Host

Re: Custom Elements: insert/remove callbacks

On Wed, May 6, 2015 at 6:45 AM, Anne van Kesteren ann...@annevk.nl wrote: Open issues are kept track of here: https://wiki.whatwg.org/wiki/Custom_Elements This has come up before, but it came up again at the Extensible Web Summit so raising hopefully for the last time. The DOM has

Re: Custom Elements: is=

It might be good to document these on the wiki? Would be lost otherwise. :DG On Wed, May 6, 2015 at 11:53 AM, Elliott Sprehn espr...@chromium.org wrote: Removing this breaks several use cases of which there's no alternative currently:

[webcomponents]: Minutae -- moved proposals from wiki to /proposals

Folks, To alleviate the limitations of the github wiki (can't submit PRs easily, etc.), we are moving to a slightly different, more streamlined (awesomer!) model: the /proposal directory: https://github.com/w3c/webcomponents/blob/gh-pages/proposals/ It's basically the same as the wiki, but now

Re: Custom Elements: Upgrade et al

On Wed, May 6, 2015 at 7:50 AM, Domenic Denicola d...@domenic.me wrote: Can you explain how you envision cloning to work a bit more? Somehow there will be instances of these elements which are not created by their constructors? Also, how is it in any way similar to how canvas or input work?

Re: Shadow DOM Imperative API proposal #1 vs content select/slot

Thanks Wilson and Anne! One interesting thing I noticed is that the algo relies on candidate.distributedNodes already being correctly populated by the nesting shadow tree. Does that mean that we'd need to ensure the correct order of invoking distribution among the nesting trees? Or maybe mutation

Re: Nice version Re: Minutes of Shadow DOM meeting

Will do. :DG On Sun, Apr 26, 2015 at 2:08 AM, cha...@yandex-team.ru wrote: Attached here is a clean version, which will be archived. Note that there was a lot of sidechat in IRC it is unclear how much of that everyone in the room was aware of. I hope the minutes are a pretty accurate

Re: Imperative API for Node Distribution in Shadow DOM (Revisited)

On Mon, Apr 27, 2015 at 8:48 PM, Ryosuke Niwa rn...@apple.com wrote: One thing that worries me about the `distribute` callback approach (a.k.a. Anne's approach) is that it bakes distribution algorithm into the platform without us having thoroughly studied how subclassing will be done upfront.

Re: Imperative API for Node Distribution in Shadow DOM (Revisited)

On Tue, Apr 28, 2015 at 1:52 PM, Ryosuke Niwa rn...@apple.com wrote: I've updated the gist to reflect the discussion so far: https://gist.github.com/rniwa/2f14588926e1a11c65d3 Please leave a comment if I missed anything. Thank you for doing this. There are a couple of unescaped tags in

Re: Imperative API for Node Distribution in Shadow DOM (Revisited)

On Wed, Apr 29, 2015 at 5:59 PM, Ryosuke Niwa rn...@apple.com wrote: On Apr 29, 2015, at 4:16 PM, Dimitri Glazkov dglaz...@google.com wrote: On Tue, Apr 28, 2015 at 1:52 PM, Ryosuke Niwa rn...@apple.com wrote: I've updated the gist to reflect the discussion so far: https

Re: [components] Apple's consolidated feedback on Web Components

Thank you for writing this up, Maciej. Looking forward to the F2F. :DG On Wed, Apr 22, 2015 at 11:19 PM, Maciej Stachowiak m...@apple.com wrote: On Apr 22, 2015, at 11:10 PM, Maciej Stachowiak m...@apple.com wrote: Hi everyone, In preparation for Fridays’ face-to-face, a number of

Re: Proposal for changes to manage Shadow DOM content distribution

FWIW, I can see the appeal of a slot-based approach in Ryosuke/Ted/Jan proposal. It reduces the implementation complexity: all of the selector-checking logic in http://w3c.github.io/webcomponents/spec/shadow/#satisfying-matching-criteria is replaced with (what effectively is) a map lookup. While

Re: Proposal for changes to manage Shadow DOM content distribution

On Tue, Apr 21, 2015 at 9:43 PM, Daniel Freedman dfre...@google.com wrote: Hi Ryosuke, I want to start by thanking you, Ted, and Jan for taking the time to make this proposal. I read through the proposal, and had a quick question about how redistribution should work with this slot concept.

Re: [webcomponents]: Let's reach consensus on Shadow DOM

On Sun, Feb 8, 2015 at 10:17 AM, Ryosuke Niwa rn...@apple.com wrote: One more thing. I think it's nice to have a new comprehensive list of use cases participants have come up over the years on the same document since the wiki page is quite outdated. I spent the last couple of weeks working

Re: Mozilla and the Shadow DOM

On Thu, Apr 16, 2015 at 7:07 AM, Wilson Page wilsonp...@me.com wrote: This is an interesting approach that didn't occur to me! Similar to Anne's concerns, this would require you to have more knowledge of the internals of the super-class component. If you own both components then this is fine.

Re: Mozilla and the Shadow DOM

Updated https://www.w3.org/Bugs/Public/show_bug.cgi?id=28446 with the latest, to keep the history in bug. :DG On Thu, Apr 16, 2015 at 7:52 AM, Dimitri Glazkov dglaz...@google.com wrote: On Thu, Apr 16, 2015 at 7:07 AM, Wilson Page wilsonp...@me.com wrote: This is an interesting approach

Re: [Imports] Considering imperative HTML imports?

https://www.w3.org/Bugs/Public/show_bug.cgi?id=25319 On Thu, Apr 16, 2015 at 12:55 AM, Elliott Sprehn espr...@chromium.org wrote: On Wed, Apr 15, 2015 at 9:37 PM, Travis Leithead travis.leith...@microsoft.com wrote: Was an imperative form of HTML imports already considered? E.g., the

Re: [Imports] Considering imperative HTML imports?

Imports bug tree: https://www.w3.org/Bugs/Public/showdependencytree.cgi?id=20683hide_resolved=1 On Thu, Apr 16, 2015 at 7:27 AM, Dimitri Glazkov dglaz...@google.com wrote: https://www.w3.org/Bugs/Public/show_bug.cgi?id=25319 On Thu, Apr 16, 2015 at 12:55 AM, Elliott Sprehn espr

Re: Mozilla and the Shadow DOM

On Tue, Apr 14, 2015 at 5:38 AM, Anne van Kesteren ann...@annevk.nl wrote: On Wed, Apr 8, 2015 at 6:11 PM, Dimitri Glazkov dglaz...@google.com wrote: Thanks for the feedback! While the iron is hot I went ahead and created/updated bugs in the tracker. A problem I have with this approach

Re: Are web components *seriously* not namespaced?

On Thu, Apr 9, 2015 at 9:04 AM, Rahly hungry.ra...@gmail.com wrote: On Thu, Feb 5, 2015 at 4:12 PM, Kurt Cagle kurt.ca...@gmail.com wrote: Tab, I spend the vast majority of my time anymore in RDF-land, where namespaces actually make sense (I'm not going to argue on the XML use of

Re: [Shadow] URL-based shadows?

On Wed, Mar 18, 2015 at 2:35 PM, Travis Leithead travis.leith...@microsoft.com wrote: I think ‘Worker’ threw me off at first J. My original use case was to make the current model of loading components more “local”, as AFAIK, these components can only presently be loaded by code you

Re: [Shadow] URL-based shadows?

On Mon, Mar 16, 2015 at 3:55 AM, Anne van Kesteren ann...@annevk.nl wrote: On Fri, Mar 13, 2015 at 6:44 PM, Dimitri Glazkov dglaz...@google.com wrote: https://docs.google.com/document/d/1V7ci1-lBTY6AJxgN99aCMwjZKCjKv1v3y_7WLtcgM00/edit?pli=1 That seems really cool. I'm not sure worker

Re: [Shadow] URL-based shadows?

... found it: https://docs.google.com/document/d/1V7ci1-lBTY6AJxgN99aCMwjZKCjKv1v3y_7WLtcgM00/edit?pli=1 :DG On Thu, Mar 12, 2015 at 6:05 PM, Dimitri Glazkov dglaz...@google.com wrote: Yep. Elliott (cc'd) had a proposal like this a while back. It was coolly received (can't remember

Re: [Shadow] URL-based shadows?

On Fri, Mar 13, 2015 at 12:57 PM, Travis Leithead travis.leith...@microsoft.com wrote: Ah, thanks Dimitri. After reading that, I'm also receiving it rather coolly. It's a very interesting idea, but as it relates to web components, its errs strongly on the side of isolation to the degree

Re: template namespace attribute proposal

On Thu, Mar 12, 2015 at 4:13 AM, Robin Berjon ro...@w3.org wrote: On 12/03/2015 11:07 , Anne van Kesteren wrote: On Thu, Mar 12, 2015 at 4:32 AM, Benjamin Lesh bl...@netflix.com wrote: What are your thoughts on this idea? I think it would be more natural (HTML-parser-wise) if we

Re: [Shadow] URL-based shadows?

Yep. Elliott (cc'd) had a proposal like this a while back. It was coolly received (can't remember the details). :DG On Thu, Mar 12, 2015 at 5:46 PM, Travis Leithead travis.leith...@microsoft.com wrote: Dimitri et al., Has the idea of loading/parsing a Shadow DOM directly from a URL

Re: Extending HTMLCanvasElement in Custom Element issue

There could be more details there, but here's the summary of the problem: https://wiki.whatwg.org/wiki/Custom_Elements#Subclassing_existing_elements :DG On Wed, Mar 11, 2015 at 7:17 AM, Халитов Кирилл voro...@gmail.com wrote: Hello. My issue is described there

Re: Custom elements: synchronous constructors and cloning

On Tue, Feb 24, 2015 at 12:14 AM, Anne van Kesteren ann...@annevk.nl wrote: On Mon, Feb 23, 2015 at 11:58 PM, Ryosuke Niwa rn...@apple.com wrote: In that regard, perhaps what we need another option (although 4 might be a developer friendly superset of this): 5) Don't do anything. Custom

Re: Custom elements: synchronous constructors and cloning

Filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=28092 to add more data to the informative content around the normative statement that makes this happen. On Tue, Feb 24, 2015 at 7:39 AM, Dimitri Glazkov dglaz...@google.com wrote: On Tue, Feb 24, 2015 at 7:37 AM, Anne van Kesteren ann

Re: Custom elements: synchronous constructors and cloning

On Tue, Feb 24, 2015 at 7:37 AM, Anne van Kesteren ann...@annevk.nl wrote: On Tue, Feb 24, 2015 at 4:35 PM, Dimitri Glazkov dglaz...@google.com wrote: Wait, what do you mean by that is what custom elements provide for today.. The entire pattern of template-stamping depends on the fact

Re: Web Components F2F in April 2015

On Fri, Feb 20, 2015 at 1:08 PM, Dimitri Glazkov dglaz...@google.com wrote: Working on it now. Will report back shortly. The location at the Google Mountain View campus. Will update as soon as I have the room/building info. Location: Google Mountain View Campus. Sorry grammar bad

Re: Web Components F2F in April 2015

On Thu, Feb 19, 2015 at 5:28 AM, Arthur Barstow art.bars...@gmail.com wrote: When will you be able to confirm the location? Regardless, I think we should consider the meeting as confirmed. Working on it now. Will report back shortly. :DG

Web Components F2F in April 2015

Folks, Following Art's suggestion [1], I propose a Web Components-specific F2F with with the primary goal of reaching consensus on the Shadow DOM contentious bits [2]. When: Friday, April 24, 2015 Where: Google San Francisco or Mountain View (to be confirmed) What: a one-day meeting Tentative

Re: Showing dialog from HTML import

Can you file a spec bug? https://www.w3.org/Bugs/Public/enter_bug.cgi?comment=blocked=20683short_desc=%5Bimports%5D%3A%20product=WebAppsWGimport=import%20Model :DG On Wed, Feb 18, 2015 at 5:18 AM, Ashley Gullen ash...@scirra.com wrote: I filed crbug.com/458799 for Chrome recently since

Re: Base Template (Was Re: Minimum viable custom elements)

Ryosuke, Jan, It might be useful for you two folks to work through Jan's Shadow DOM composition/inheritance insight (use cases?) together and see how they could be resolved without having multiple shadow roots per element. I would love to take advantage of all the work you both have done thinking

[webcomponents]: Let's reach consensus on Shadow DOM

Folks, I wrote a long email, replying to each point where I agreed/differed with Ryosuke, and then deleted it, realizing I wasn't being productive. So instead, I decided to start summarizing the contentious bits of the current Shadow DOM spec:

Re: Are web components *seriously* not namespaced?

On Fri, Feb 6, 2015 at 4:05 AM, Arthur Barstow art.bars...@gmail.com wrote: Dimitri - if someone wants to provide input (f.ex. requirements ) for this API, should they add them to the above bug (or do you recommend else)? Yep. That's a good place. :DG

Re: Shadow tree style isolation primitive

On Thu, Feb 5, 2015 at 10:11 AM, Dimitri Glazkov dglaz...@google.com wrote: ... Hanging but?! Oh lordy. Oooh, let me turn this into a contemplative sidebar opportunity. Shadow DOM and Web Components seem to have what I call the Unicorn Syndrome. There's a set of specs that works, proven

Re: Shadow tree style isolation primitive

On Thu, Feb 5, 2015 at 10:52 AM, Marc Fawzi marc.fa...@gmail.com wrote: Following this thread because there is real need for what is being discussed. However, until that need is satisfied, here is what we're thinking to achieve style encapsulation, using current-world technologies, and I'm

Re: Shadow tree style isolation primitive

On Thu, Feb 5, 2015 at 5:46 AM, Olli Pettay o...@pettay.fi wrote: On 02/05/2015 02:24 AM, Dimitri Glazkov wrote: However, I would like to first understand if that is the problem that the group wants to solve. It is unclear from this conversation. Yes. The marketing speech for shadow DOM

Re: Shadow tree style isolation primitive

On Thu, Feb 5, 2015 at 9:41 AM, Dimitri Glazkov dglaz...@google.com wrote: On Thu, Feb 5, 2015 at 5:46 AM, Olli Pettay o...@pettay.fi wrote: On 02/05/2015 02:24 AM, Dimitri Glazkov wrote: However, I would like to first understand if that is the problem that the group wants to solve

Re: Shadow tree style isolation primitive

On Wed, Feb 4, 2015 at 3:56 PM, Ryosuke Niwa rn...@apple.com wrote: On Feb 4, 2015, at 3:20 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Wed, Feb 4, 2015 at 11:56 PM, Olli Pettay o...@pettay.fi wrote: Why do we need shadow DOM (or something similar) at all if we expose it easily

Re: Shadow tree style isolation primitive

Not trying to barge in, just sprinkling data... On Tue, Feb 3, 2015 at 6:22 AM, Brian Kardell bkard...@gmail.com wrote: On Tue, Feb 3, 2015 at 8:06 AM, Olli Pettay o...@pettay.fi wrote: On 02/02/2015 09:22 PM, Dimitri Glazkov wrote: Brian recently posted what looks like an excellent

Re: Shadow tree style isolation primitive

Brian recently posted what looks like an excellent framing of the composition problem: https://briankardell.wordpress.com/2015/01/14/friendly-fire-the-fog-of-dom/ This is the problem we solved with Shadow DOM and the problem I would like to see solved with the primitive being discussed on this

Re: Minimum viable custom elements

One additional point, unrelated to accessibility: is also enables piggybacking to special parser behavior of existing elements. For example, I can extend template or link. Here are some examples: http://jsbin.com/xuheb/3/edit?html,output

Re: Minimum viable custom elements

On Fri, Jan 16, 2015 at 1:14 PM, Ryosuke Niwa rn...@apple.com wrote: On Jan 15, 2015, at 7:25 PM, Dimitri Glazkov dglaz...@google.com wrote: On Thu, Jan 15, 2015 at 6:43 PM, Ryosuke Niwa rn...@apple.com wrote: When an author imports a ES6 module, we don't create a fake object which gets

Re: Custom element design with ES6 classes and Element constructors

I'm sympathetic to this but I think it is fine that DOM continues to define new string based property names. Anytime we add a new property to an existing class we run into this issue and I don't think we want to give up on the superior usability of string based property names. I agree,

Re: Minimum viable custom elements

No argument that callbacks are also a useful new addition. :DG

Re: Custom element design with ES6 classes and Element constructors

On Thu, Jan 15, 2015 at 2:37 AM, Anne van Kesteren ann...@annevk.nl wrote: On Thu, Jan 15, 2015 at 5:11 AM, Yehuda Katz wyc...@gmail.com wrote: Can you say more about why same-identity upgrading is critical to the design (as opposed to dom-mutation upgrading)? I asked up-thread but didn't

Re: Custom element design with ES6 classes and Element constructors

We're already doing some crude namespacing with *Callback. I'd expect that as soon as the first iteration of Custom Elements is out, people will copy the *Callback style in user code. This is a powerful point that I definitely agree with. I would not be terribly surprised to find some

Re: Minimum viable custom elements

On Thu, Jan 15, 2015 at 8:03 AM, Anne van Kesteren ann...@annevk.nl wrote: * I think we could iterate towards a v2 that has an aspect of upgrading but perhaps works a bit differently from the current setup. E.g. a way to include an entire subtree of custom elements with a fallback mechanism

Re: Minimum viable custom elements

FWIW, I think that element upgrade is sort of fundamental to the usefulness of custom elements. In a world where most scripts are non-blocking (that's hopefully the modern world we should aim for), I'll effectively expect to walk the tree anyway. And if I walk the tree anyway, what's the point of

Re: Minimum viable custom elements

https://www.w3.org/Bugs/Public/show_bug.cgi?id=24579 On Wed, Jan 14, 2015 at 11:11 AM, Domenic Denicola d...@domenic.me wrote: 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

Re: Custom element design with ES6 classes and Element constructors

On Mon, Jan 12, 2015 at 9:11 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 1/12/15 12:20 PM, Tab Atkins Jr. wrote: Proto munging isn't even that big of a deal. That really depends. For example, dynamically changing __proto__ on something somewhat permanently deoptimizes that object in at

Re: Shadow tree style isolation primitive

For the record, I am a huge fan of exploring this. I tried a couple of times, but was unable to extract this primitive from Shadow DOM in a clean way. I talked with Tab late last year about restarting this effort, so this is timely. :DG On Fri, Jan 9, 2015 at 7:49 AM, Anne van Kesteren

Re: Shadow tree style isolation primitive

=sharing :DG On Fri, Jan 9, 2015 at 7:54 AM, Dimitri Glazkov dglaz...@google.com wrote: For the record, I am a huge fan of exploring this. I tried a couple of times, but was unable to extract this primitive from Shadow DOM in a clean way. I talked with Tab late last year about restarting

Re: Custom element lifecycle callbacks

On Thu, Jan 8, 2015 at 7:56 AM, Anne van Kesteren ann...@annevk.nl wrote: 1) Can we use symbols to identify these instead? That gives us a guarantee they won't be used for other things and makes it somewhat safer to put them where they are located now. cc'ing a few folks I heard expressing

Re: ES6 and upgrading custom elements

On Tue, Jan 6, 2015 at 10:38 AM, Anne van Kesteren ann...@annevk.nl wrote: On Tue, Jan 6, 2015 at 7:06 PM, Dimitri Glazkov dglaz...@google.com wrote: Yes to the first question. I wasn't planning on doing anything different there. It seems simple prototype munging but not actually changing

Re: ES6 and upgrading custom elements

On Tue, Jan 6, 2015 at 10:59 AM, Anne van Kesteren ann...@annevk.nl wrote: On Tue, Jan 6, 2015 at 7:54 PM, Dimitri Glazkov dglaz...@google.com wrote: Right, that's why to create a valid custom element that subclasses HTMLInputElement, you should use type extensions. With type extensions

Re: pull request on custom elements spec

Thanks! Merged. :DG On Tue, Jan 6, 2015 at 1:46 AM, Steve Faulkner faulkner.st...@gmail.com wrote: Hi Dimitri, made quite a few tweaks to the custom element semantics section after feedback. Appreciate a review of the PR https://github.com/w3c/webcomponents/pull/31 when you get a

Re: ES6 and upgrading custom elements

On Tue, Jan 6, 2015 at 9:56 AM, Anne van Kesteren ann...@annevk.nl wrote: On Tue, Jan 6, 2015 at 6:13 PM, Dimitri Glazkov dglaz...@google.com wrote: That section needs to be updated, because the ES6 spec had shifted a little bit with regard to @@create. Filed https://www.w3.org/Bugs

Re: ES6 and upgrading custom elements

That section needs to be updated, because the ES6 spec had shifted a little bit with regard to @@create. Filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=27769. Conceptually, when I wrote it I'd imagined that the constructor will be called only when you explicitly invoke it (new

Re: [custom-elements] Re: web developer conformance requirements and advice in custom elements spec

On Sat, Dec 6, 2014 at 7:34 AM, Arthur Barstow art.bars...@gmail.com wrote: On 12/6/14 4:21 AM, Steve Faulkner wrote: Hi all, looking at the custom elements spec http://w3c.github.io/ webcomponents/spec/custom/ i realized it includes no defined requirements or advice for web developers on

Re: Bringing APIs for experimental hardware/software to the Web

On Sun, Nov 16, 2014 at 8:30 PM, Robert O'Callahan rob...@ocallahan.org wrote: On Sun, Nov 16, 2014 at 5:35 PM, Dimitri Glazkov dglaz...@google.com wrote: On Wed, Nov 12, 2014 at 8:44 PM, Robert O'Callahan rob...@ocallahan.org wrote: On Wed, Nov 12, 2014 at 12:36 PM, Dimitri Glazkov dglaz

Re: New approach to activities/intents

On Mon, Nov 10, 2014 at 8:14 PM, Brendan Eich bren...@secure.meer.net wrote: Dimitri Glazkov wrote: Domenic's question still needs addressing separately, but just a quick response here -- the API roc described there is different. Tubes are just like talking to a worker or any MessagePort

Re: New approach to activities/intents

On Tue, Nov 11, 2014 at 12:28 PM, Robert O'Callahan rob...@ocallahan.org wrote: I still don't see how exposing an API via MessagePorts is in any way better than exposing an API via WebIDL. Can you describe with concrete examples how this makes life better for implementors or authors? I've read

Re: Bringing APIs for experimental hardware/software to the Web

On Tue, Nov 11, 2014 at 3:01 PM, Robert O'Callahan rob...@ocallahan.org wrote: On Wed, Nov 12, 2014 at 6:24 AM, Dimitri Glazkov dglaz...@google.com wrote: Given any capability on a modern computing device and a developer who wants to use it, what is a) the acceptable delay between when

Re: New approach to activities/intents

On Mon, Nov 10, 2014 at 9:57 AM, Boris Zbarsky bzbar...@mit.edu wrote: On 11/10/14, 12:45 PM, Dimitri Glazkov wrote: FWIW, it is perfectly reasonable for us to admit that we as a platform aim to always be years behind other platforms. But then we should make this clear and communicate

Re: New approach to activities/intents

to virtual service workers that implement proprietary string-based APIs using URLs that only work in certain browsers. I don't understand how these are connected... Hope you can help me out there :) Dimitri Glazkov mailto:dglaz...@google.com November 10, 2014 at 12:45 PM On Mon, Nov 10, 2014 at 1

Re: New approach to activities/intents

On Mon, Nov 10, 2014 at 3:14 PM, Domenic Denicola d...@domenic.me wrote: From: Dimitri Glazkov [mailto:dglaz...@google.com] It's still not clear to me what the advantage is of creating a framework for designing proprietary APIs. If we don't do something like this as a platform, we'd

Re: New approach to activities/intents

FWIW, I think we should be concentrating on something like the Tubes (aka navigator.connect): https://github.com/dglazkov/tubes It is hard to impossible to get these types APIs right on the first try. That's why we need to create a clearinghouse for capability experiments and be data-driven in

Re: [WebComponents] Seeking status and plans [Was: [TPAC2014] Creating focused agenda]

Here's an update on Custom Elements Spec. Since the last TPAC: * Added informative ES6 section: http://w3c.github.io/webcomponents/spec/custom/#es6 * Minor bug fixes Next 6 months: * P1: fix bugs, identified by Mozilla folks when implementing Custom Elements:

[webcomponents]: Telcon on as-needed basis from now on

Howdy, Web Appey folks! Last week's telcon was super-exciting. I was the only participant. If not for Hayato-san who stayed up late and tried to keep up my spirits, it would've been a total tree falling in the forest. I think it might be best to flip the regular bit to off for now, and only use

[webcomponents]: Semi-regular telcon tomorrow

We will be having our second Web Components telcon tomorrow (June 3). If you'd like to suggest specific agenda items, please reply to this mail. Potential agenda items: * Understanding Shadow DOM theming problem, brainstorming primitives, maybe even filing bugs (who knows!). * Reduce the

Re: [webcomponents]: Next weeks telcon agenda

Since we had no topic suggestions, let's cancel the call this week. :DG On Fri, May 23, 2014 at 12:36 PM, Dimitri Glazkov dglaz...@google.com wrote: As a reminder, we have our standing meeting next week: https://www.w3.org/wiki/WebComponents/ Please reply to this mail with your agenda topics

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

Brian, I believe Scott enumerated all these in his initial reply, but here's my take (I wrote parts of this in another email, my apologies to that email's recipient for repeating myself :) HTML Imports are primarily about dependency resolution. They allow the web developer to think locally in

[webcomponents]: Next weeks telcon agenda

As a reminder, we have our standing meeting next week: https://www.w3.org/wiki/WebComponents/ Please reply to this mail with your agenda topics. I haven't had a chance to work on specs this week, so I don't have any topics. :DG

Re: [webcomponents]: Inaugural telcon tomorrow

I also made a wiki: https://www.w3.org/wiki/WebComponents/ :DG On Mon, May 19, 2014 at 8:50 AM, Dimitri Glazkov dglaz...@google.com wrote: Hell, We will be having our first Web Components telcon tomorrow (May 20). If you'd like to suggest specific agenda items, please reply

Re: Custom Elements: 'data-' attributes

On Tue, May 13, 2014 at 2:37 AM, Anne van Kesteren ann...@annevk.nl wrote: Sole had the idea of providing hooks for attributes so a component can say it handles them rather than the user agent. That makes a lot of sense to me. That way you can grab any name, even existing ones. 3 this idea,

Re: [webcomponents]: Regular Conference Call Survey

with more details) next Monday morning. :DG On Thu, May 1, 2014 at 11:44 AM, Dimitri Glazkov dglaz...@google.com wrote: Greetings, WebApp-ateurs! At the last F2F, there was some positive sentiment toward setting up a regular conference call to discuss Web Components-related topics. On Art's

[webcomponents]: Informal Shadow DOM Survey

Howdy, Web-Appa-rishi, Last week, I was looking at the Shadow DOM bugs and, sort of impulsively, put together a quick top 10 survey that I then promptly twittered here: https://twitter.com/dglazkov/status/462319811326791680 I thought it might be interesting for y'alls to see the results so far:

Re: NetAwards 2014: The winner of Best New Technology 2014 is Web Components

Yay team!! On Fri, May 9, 2014 at 8:26 AM, Coralie Mercier cora...@w3.org wrote: Hi Team, DKA, public-webapps, A quick follow-up that the NetAwards winner for Best New Technology 2014 is Web Components. Dan Appelquist is representing the W3C in London right now and got the award on our

[webcomponents]: Regular Conference Call Survey

Greetings, WebApp-ateurs! At the last F2F, there was some positive sentiment toward setting up a regular conference call to discuss Web Components-related topics. On Art's advice, I thereby present this lovely survey that seeks to find a good time slot for such a conference call:

  1   2   3   4   >