Re: Minimum viable custom elements

So a web page author would write
<x-slider min="-100" ... etc.>

and then the custom element would sprout an <input type="range" ...etc>
with the attribute values copied across? Then the web page author knows
nothing about the <input> element, so if they want to programmatically the
value of the custom element, they'd modify an attribute on it, rather than
the <input>, right? So you'd have to keep them in sync regardless.

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

>
> 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> 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?
>
>
> 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
>
>