I was looking for a quick markdown editor on https://www.webcomponents.org/ so that I can make posting to this blog easier and I stumbled across a neat set of components by github. I knew that they had the <time-element> but I didn’t know they had a such a nice and simple set of useful elements.
Jake and the team built this rather awesome custom element for managing pinch zooming on any set of HTML outside of the browser’s own pinch-zoom dynamics (think mobile viewport zooming). The element was one of the central components that we needed for the squoosh app that we built and released at Chrome Dev Summit (… I say ‘released at Chrome Dev Summit’ - Jake was showing it to everyone at the China Google Developer Day even though the rest of the team were under embargo ;) … )
I couldn't find an easier way, so I built it myself
Custom Elements need clear and parsable API documentation.
My adventures in creating resuable web components around sharing.
Within the last 6 months, it felt like a good time to get on board properly with Web Components so I’ve been toying around with bits and pieces. I’ve been thinking about the ecosystem as a whole and I’ve also recently been creating a few elements. One thing that is really unclear to me is that there is no defined best practice for how to include styles and templates (HTML) with your custom element which means as a consumer of Custom elements you are at the mercy of what the component developer thinks is best.
I like Web Components. It has taken a long time to get here but things are moving in the correct direction with Safari shipping Shadow DOM and now landing support for Custom Elements. I’ve been thinking a lot recently about Web Components, that is custom elements, template, Shadow DOM and CSS variables, specifically I have been focusing some of my thoughts on custom element space and how this can play out on the web in the future because I believe there are lots of interesting possibilities with how the usage of them will evolve over time.