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