Re: Minimum viable custom elements

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'

-- 
Brian Kardell :: @briankardell :: hitchjs.com

Received on Wednesday, 4 February 2015 19:02:07 UTC