Re: Proposal for changes to manage Shadow DOM content distribution

2015-04-22 Thread Erik Bryn
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. jackalm...@gmail.com 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
 justinfagn...@google.com javascript:; 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 javascript:;
  wrote:
 
 
 
  On Tue, Apr 21, 2015 at 10:40 PM, Ryosuke Niwa rn...@apple.com
 javascript:; wrote:
 
 
   On Apr 21, 2015, at 10:23 PM, Justin Fagnani 
 justinfagn...@google.com javascript:;
   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
   content select=[content-slot=name] 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:
 
  template
content select=.header/content
content select=:not(.footer)/content
content select=.footer/content
  /template
 
  Cheers,
Justin
 
 
 
 
  - R. Niwa
 
 
 




Re: Minimum viable custom elements

2015-02-05 Thread Erik Bryn
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 chrisb...@gmail.com 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 input:
 http://jsbin.com/mevemu/1/edit?html,output

 And the version with an input 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 rn...@apple.com wrote:


  On Feb 4, 2015, at 11:11 AM, Chris Bateman chrisb...@gmail.com 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

2014-04-22 Thread Erik Bryn
*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 dglaz...@chromium.orgwrote:

 BTW, here's a jsbin that implements yield/transclude using existing Shadow
 DOM plumbing:

 http://jsbin.com/pacim/1/edit

 :DG



Decoupling style scoped from Shadow DOM

2014-02-20 Thread Erik Bryn
Hi everyone,

First time caller, long time listener.

From what I understand, the browser vendors seem to be bundling style
scoped with the Shadow DOM spec. I'd like to start a discussion around
decoupling the two and asking that vendors prioritize shipping style
scoped over Shadow DOM as a whole. As a web developer and JS framework
author, the single most important feature that I could use immediately and
I believe is totally uncontroversial is style scoped.

Thoughts?

Thanks,
- Erik


Re: [webcomponents] Imperative API for Insertion Points

2014-02-18 Thread Erik Bryn
On Mon, Feb 17, 2014 at 11:03 AM, Edward O'Connor eocon...@apple.comwrote:

 I think Ryosuke's content.add/remove are a better base layer than
 content select. In fact, content select is straightforwardly
 implementable / explainable on top of MO + content.add/remove, but
 there are several use cases that content.add/remove address that are
 difficult or impossible with content select (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 content select was even a thing.

- Erik