Re: Minimum viable custom elements

On Wed, Feb 4, 2015 at 11:01 AM, Brian Kardell <bkardell@gmail.com> wrote:

>
>
> On Wed, Feb 4, 2015 at 1:54 PM, Alice Boxhall <aboxhall@google.com> wrote:
>
>> 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?
>>
>
> 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?