Re: Proposal for changes to manage Shadow DOM content distribution
FWIW, we're working to implement what we call named blocks in Ember.js and believe this proposal aligns very closely to what our users have been asking us to build for them. - Erik On Wednesday, April 22, 2015, Tab Atkins Jr. wrote: > This is literally reinventing Selectors at this point. The solution > to "we don't think it's worth implementing *all* of Selectors" is to > define a subset of supported Selectors, not to define a brand new > mechanism that's equivalent to selectors but with a new syntax. > > On Wed, Apr 22, 2015 at 10:21 AM, Justin Fagnani > > wrote: > > Another technique I've seen used is compound selectors, which could be > used > > to migrate from one selector to another while preserving backwards > > compatibility, or to provide some nice default distributions that are > also > > accessible via a class or attribute (ie, select="header, .header"). > > > > Could slots have multiple names to support something like this? > > > > On Wed, Apr 22, 2015 at 10:16 AM, Justin Fagnani < > justinfagn...@google.com > > > wrote: > >> > >> > >> > >> On Tue, Apr 21, 2015 at 10:40 PM, Ryosuke Niwa > wrote: > >>> > >>> > >>> > On Apr 21, 2015, at 10:23 PM, Justin Fagnani < > justinfagn...@google.com > > >>> > wrote: > >>> > > >>> > I do want the ability to redirect distributed nodes into a holes in > the > >>> > base template, so that part is welcome to me. However, my first > reaction to > >>> > the slot idea is that forcing users to add the content-slot > attribute on > >>> > children significantly impairs the DOM API surface area of custom > elements. > >>> > > >>> > For the single-level distribution case, how is this different from > >>> > except that content select can > >>> > distribute based on features of the children that might already > exist, like > >>> > tag names or an attribute? > >>> > >>> At the conceptual level, they're equivalent. However, we didn't find > the > >>> extra flexibility of using CSS selectors compelling as we mentioned in > our > >>> proposal [1]. > >> > >> > >> I personally would like to see more power, especially positional > >> selectors. Some components would be better off selecting their first > child, > >> rather than requiring a class. > >>> > >>> > >>> [1] See points 3 and 4 in > >>> > https://github.com/w3c/webcomponents/wiki/Proposal-for-changes-to-manage-Shadow-DOM-content-distribution#some-issues-with-the-current-shadow-dom-spec > >> > >> > >> Point 4 is interesting, because unless I'm missing something (which > could > >> be!) it's incorrect. You can create selectors with :not() that exclude > the > >> content selectors that come after in document order. I would rewrite the > >> example as: > >> > >> > >> > >> > >> > >> > >> > >> Cheers, > >> Justin > >> > >>> > >>> > >>> > >>> - R. Niwa > >>> > >> > > > >
Re: Minimum viable custom elements
Thanks for the mentioning the Ember issue Chris :) I've filed it here: https://github.com/tildeio/htmlbars/issues/288 On Thu, Feb 5, 2015 at 7:13 AM, Chris Bateman wrote: > As an example I made a simple input-based Custom Element which prevents > alphabetic input, and dropped it in an very simple Ember app. > > Here's the version with a subclassed : > http://jsbin.com/mevemu/1/edit?html,output > > And the version with an nested in a custom > element:http://jsbin.com/hepuvif/1/edit?html,output. The custom element adds > an input if one wasn't provided in the markup. > > Click the "Show" button to inject the CE. The CE is registered at the top, > and the template (where it's included) is at the bottom. > > Note that the 2nd version isn't completely functional because Ember isn't > expecting to update a value based on an attribute - but this is something > that Ember can solve (they've stated intent to support Web Components). > > > So - it was extra code to map the input's value to the custom element (and I > didn't do a very robust job of it) - but I'll let you draw your own > conclusions. In my opinion - it's definitely not as ideal as the subclass - > but maybe it's not prohibitive either. > > > ** Bonus issue - I didn't know this, but Chrome doesn't upgrade when you add > the is= attribute to an element that's already been created. Ember builds up > its templates into document fragments - so the input failed to upgrade in > Chrome. This doesn't happen with the polyfill, however, so I got around the > issue by forcing the polyfill to override the native > document.registerElement. > > > Chris > > > > On Wed, Feb 4, 2015 at 1:15 PM, Ryosuke Niwa wrote: >> >> >> > On Feb 4, 2015, at 11:11 AM, Chris Bateman wrote: >> > >> > Ugh, I forgot about that. Without subclassing - terseness is a very >> > minor drawback, but remapping the interface is a big pain. >> >> Could you give us a concrete use case in which remapping the interface is >> necessary or hard/impossible to do? >> >> - R. Niwa >> >> >
Re: Separating Transclusion Mechanisms for Inheritance and Data Binding
*claps for sharing JSBin* Would love to see more of this on public-webapps when possible :) On Tue, Apr 22, 2014 at 10:46 AM, Dimitri Glazkov wrote: > BTW, here's a jsbin that implements yield/transclude using existing Shadow > DOM plumbing: > > http://jsbin.com/pacim/1/edit > > :DG< >
Re: Starting work on Indexed DB v2 spec - feedback wanted
In my mind, promisifying the IndexedDB API would be the highest value thing to end users. After using a very early version of localForage ( https://github.com/mozilla/localForage), I started toying with a lower level, promise-based, API wrapper with my EasyIndexedDB library. Here's some example usage: https://github.com/ebryn/EasyIndexedDB/blob/master/test/basics_test.js#L42 I'd be happy to help provide continual feedback from a framework developer (Ember.js) & end users perspective. - Erik On Wed, Apr 16, 2014 at 11:49 AM, Joshua Bell wrote: > At the April 2014 WebApps WG F2F [1] there was general agreement that > moving forward with an Indexed Database "v2" spec was a good idea. Ali > Alabbas (Microsoft) has volunteered to co-edit the spec with me. > Maintaining compatibility is the highest priority; this will not break the > existing API. > > We've been tracking additional features for quite some time now, both on > the wiki [2] and bug tracker [3]. Several are very straightforward > (continuePrimaryKey, batch gets, binary keys, ...) and have already been > implemented in some user agents, and it will be helpful to document these. > Others proposals (URLs, Promises, full text search, ...) are much more > complex and will require additional implementation feedback; we plan to add > features to the v2 spec based on implementer acceptance. > > This is an informal call for feedback to implementers on what is missing > from v1: > > * What features and functionality do you see as important to include? > * How would you prioritize the features? > > If there's anything you think is missing from the wiki [2], or want to > comment on the importance of a particular feature, please call it out - > replying here is great. This will help implementers decide what work to > prioritize, which will drive the spec work. We'd also like to keep the v2 > cycle shorter than the v1 cycle was, so timely feedback is appreciated - > there's always room for a "v3". > > [1] http://www.w3.org/2014/04/10-webapps-minutes.html > [2] http://www.w3.org/2008/webapps/wiki/IndexedDatabaseFeatures > [3] > https://www.w3.org/Bugs/Public/buglist.cgi?bug_status=RESOLVED&component=Indexed%20Database%20API&list_id=34841&product=WebAppsWG&query_format=advanced&resolution=LATER > > PS: Big thanks to Zhiqiang Zhang for his Indexed DB implementation report, > also presented at the F2F. >
Decoupling
Hi everyone, First time caller, long time listener. >From what I understand, the browser vendors seem to be bundling
Re: [webcomponents] Imperative API for Insertion Points
On Mon, Feb 17, 2014 at 11:03 AM, Edward O'Connor wrote: > I think Ryosuke's .add/remove are a better base layer than > . In fact, is straightforwardly > implementable / explainable on top of MO + .add/remove, but > there are several use cases that .add/remove address that are > difficult or impossible with (as described in Maciej's > recent email on this thread). > I agree. As a contributor to a major JS framework, I was shocked by the lack of an imperative API and that was even a thing. - Erik
