Custom Elements Everywhere (Polymer Summit 2017)

If you're a mid to large size company, building your UI in Web Components and sharing it across teams on different stacks sounds like a great plan. In theory, things should ""just work,"" but reality often proves otherwise. What do we need to do to make sure our components work well with all of the major frameworks and, conversely, what do the frameworks need to do to work with our components? This video explores both sides of the problem and lays out some best practices that both parties can use to ensure seamless interoperability.

[DesaraeVeit]

Next talk: how to make design systems more accessible for a full team. I believe we should be enabling designers more than developers to manage design systems. I don't mean someone who doesn't know how to code, but that they identify as a designer or creative first. I've been working on a couple projects that can automate this process and also works to integrate AI and web morphing in element creation. Your presentation was really educational. Thank you for simplifying some of these concepts. I plan to reference your work in my Thesis and would love to chat if you ever have some time.

[Gizzatful]

the camera guy thinks he's invisible

[prushforth]

Nice talk Rob, thanks for making the subject approachable. I am wondering where you stand on customizing built-in elements. I think I agree that custom elements need their own shadow root, but this doesn't seem possible with void elements, for example like input, img etc. I know there is a "whitelist" of elements that can have a customized shadow root, but that whitelist seems to be growing about as fast as customized built-ins are being implemented. I have put a lot of time into implementing a customized map element in polymer 0, and would love to move up to more recent work, but that's not possible currently. Essentially, I don't need *any* functionality from the native element, just the name and the content model. I implement my own functionality if the custom element runs. Why is this not a viable approach for other customized built-ins? The element name (potentially, if the author wants it to) acts as a fallback in case of 404s or whatever adverse conditions happen when setting up the page.

I notice that the void input element in the parsed devtools representation does appear to have an end-tag. So the parser has created a non-void normal element out of it. That is kind of perfect, as a normal element could contain a shadow root, right? Maybe when the element is being taken over by a customized implmenetation, the parser could stop there?

Anyway thanks to you and the Polymer team for being very approachable, I can see that it is not easy.

[oskarsrukmans]

Website links to actual tests are broken. Anyway, great idea and talk.

[DenisTRUFFAUT]

"Monica's cheat sheet" and "Rob's ARIA tutorials" evolved in "Polymer guide" !

[shawnnosaurus]

Is it possible to get a Polymer to work without a DOM for server side components(Not SSR)? We have native solutions that we would like to inject custom components into.

[dmitriid]

So... 6 years and multiple "WebComponents is THE SHIT AND THE FUTURE..." screams later we end up with "no reference implementations", "no one knows how to build them", and ""If we can agree on how Custom Elements should behave..."?

WTF indeed.