Re: Minimum viable custom elements

> On Feb 4, 2015, at 11:05 AM, Alice Boxhall <aboxhall@google.com> wrote:
> 
> On Wed, Feb 4, 2015 at 11:01 AM, Brian Kardell <bkardell@gmail.com <mailto:bkardell@gmail.com>> wrote:
> 
> On Wed, Feb 4, 2015 at 1:54 PM, Alice Boxhall <aboxhall@google.com <mailto:aboxhall@google.com>> wrote:
> On Wed, Feb 4, 2015 at 10:36 AM, Ryosuke Niwa <rniwa@apple.com <mailto:rniwa@apple.com>> wrote:
> 
>> On Feb 4, 2015, at 10:12 AM, Brian Kardell <bkardell@gmail.com <mailto:bkardell@gmail.com>> wrote:
>> 
>> On Wed, Feb 4, 2015 at 12:41 PM, Chris Bateman <chrisb808@gmail.com <mailto:chrisb808@gmail.com>> wrote:
>> Yeah, I had noted in that post that wrapping a native element with a custom element was an option - only drawback is that the markup isn't as terse (which is generally advertised as one of the selling points of Custom Elements). But that doesn't seem like a deal breaker to me, if subclassing needs to be postponed.
>> 
>> Chris
>> 
>>  
>> As I pointed out ealier:
>>  
>> <input is="x-foo">
>> 
>> <x-foo><input></x-foo>
>> 
>> seems like barely a ternseness savings worth discussing.
> 
> Indeed.  Also, authors are used to the idea of including a fallback content inside an element after canvas and object elements and this fits well with their mental model.
> 
> I'm just trying to get my head around this pattern. In this example, does the web page author or the custom element developer embed the input? And who is responsible for syncing the relevant attributes across? In reality, isn't this going to look more like
> 
> <x-checkbox checked="true">
>     <input type="checkbox" checked="true">
> </x-checkbox>
> 
> or as a slightly contrived example,
> 
> <x-slider min="-100" max="100" value="0" step="5">
>     <input type="range" min="-100" max="100" value="0" step="5">
> </x-slider>
> 
> Or does the custom element get its state from the embedded element?
> 
> the custom element uses its contents as input and, in the simplest sense, just moves it or maps it during creation... In a more complicated world with something more like shadow dom (a separate topic) it might be 'projected'
> 
> It seems like it would have to be in the light DOM for things like labels, forms etc to work. So then how do we treat it as "fallback content" i.e. un-rendered, while allowing it to be accessible to to the AT layer?


Since it's a fallback content, it would certainly be in the regular DOM even if we had shadow DOM.  FYI, this whole thread doesn't assume or preclude the existence of shadow DOM.  It is the responsibility for custom form elements users to put regular input elements inside them.

- R. Niwa