Re: Minimum viable custom elements

On Wed, Feb 4, 2015 at 10:36 AM, Ryosuke Niwa <rniwa@apple.com> wrote:

>
> On Feb 4, 2015, at 10:12 AM, Brian Kardell <bkardell@gmail.com> wrote:
>
> On Wed, Feb 4, 2015 at 12:41 PM, Chris Bateman <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?