This is Part 2 of a 3-part series.<\/p>\r\n
In Part 1 we learned how to code pure Web Components. But of course, adopting new web technologies is rarely painless, and Web Components are especially complicated. In this post, we’ll look at the current state of browsers, polyfills, performance, accessibility, progressive enhancement, and options for practical implementations.<\/p>\r\n\r\n\r\n\r\n
For the latest status, check out Are We Componentized Yet<\/a> and caniuse<\/a>. But here’s the overall situation as of December 2014:<\/p>\r\n All browsers (except for IE) have implemented HTML Templates. For the remaining specs:<\/p>\r\n Chrome<\/strong> completed and shipped all specs (enabled by default) by Chrome 36. Opera<\/strong> too.<\/p>\r\n<\/li>\r\n Firefox<\/strong> has implemented Custom Elements and Shadow DOM to some degree, but they are disabled by default behind the Firefox will be shipping Custom Elements and Shadow DOM when they’re satisfied and confident in the specs. They will not<\/strong> be shipping HTML Imports, as they want to see what the landscape looks like after ES6 modules are shipped and utilized (12\/15\/2014<\/a>).<\/p>\r\n<\/li>\r\n<\/ul>\r\n\r\n\r\n Safari<\/strong> removed Google’s Web Components code (in 2\/2014) leftover from before Blink forked, and has yet to begin any new implementations. While not opposed to implementing something in the future, they’re clearly not satisfied with the current specs.<\/p>\r\n “There is no way I’m implementing the version [of Custom Elements] that’s incompatible with ES6 classes” (11\/1\/2014<\/a>)<\/p>\r\n<\/blockquote>\r\n<\/li>\r\n Internet Explorer<\/strong>‘s status for all specs<\/a> has been “under consideration” for about 6 months (as of 12\/2014). They’ve been pulling out some great stuff for Spartan<\/a>, but so far it seems safe to say that Web Components won’t be there. However – they have said that they’re keeping it in mind as they build Spartan, which is pretty encouraging.<\/p>\r\n<\/li>\r\n<\/ul>\r\n When Chrome shipped Web Components \u2013 without a flag \u2013 they<\/a> kind<\/a> of<\/a> ticked<\/a> off<\/a> all the other browser makers, who felt that the specs weren’t done baking yet and that their feedback hadn’t been fully considered. They’re fairly diplomatic about the Chrome situation \u2013 routinely saying things like, “mail me privately for my feelings on the matter,” because their feelings probably involve a number of expletives.<\/p>\r\n So Firefox and Safari aren’t shipping until they see the adjustments to the spec they want. Will those adjustments be possible when Chrome has already shipped? Will everyone get on the same page anytime soon? How’s it all going to end? I wish I had answers to these questions. Web standards are complicated things. Tune in next year (or the next) to find out!<\/p>\r\n In Part 1<\/a>, we looked at an example of a pure, native Web Component. If you were hoping that you could write code like that, plug in a polyfill, and be good to go \u2013 you better sit down, because I’ve got some bad news for you:<\/p>\r\n It ain’t gonna happen. Some parts of Web Components simply aren’t possible\/reasonable to polyfill.<\/p>\r\n But let’s examine each spec individually.<\/p>\r\n webcomponents.js<\/a> (which was previously part of Polymer<\/a> as platform.js) is definitely the biggest game in town when it comes to polyfills, so that’s mainly what we’ll be talking about.<\/p>\r\n Custom Elements is relatively easy to polyfill \u2013 down to IE 9 and Android 2.2, if you use document-register-element<\/a> for the polyfill (and it’s only 3KB gzipped too!). The webcomponents.js polyfill works down to Android 4.1.<\/p>\r\n Caveat<\/strong>: No support for the The webcomponents.js polyfill works down to IE 9 and Android 2 (and isn’t needed in other modern browsers).<\/p>\r\n Caveat<\/strong>: Polyfilled templates aren’t truly inert \u2013 resources like images will still download.<\/p>\r\n The webcomponents.js polyfill works down to IE 9 and Android 4.4 (some things like CSS references work down to Android 4.1, but there’s other bugginess), and in other modern browsers.<\/p>\r\n Caveat #1<\/strong>: Polyfilled imports load asynchronously, even if you didn’t add the Caveat #2<\/strong>: They load via XHR \u2013 which isn’t great for performance.<\/p>\r\n Caveat #3<\/strong>: It is not reasonable\/possible to polyfill Shadow DOM, thanks to its fancy encapsulation features. You just can’t fake the behavior of a shadow root.<\/p>\r\n The webcomponents.js code attempts<\/em> to shim some<\/em> of the encapsulation features by way of rewriting your CSS. It polyfills Shadow DOM’s JavaScript API, querySelector and other DOM APIs to behave (hopefully) as they should, and it moves elements selected with the Caveats:<\/strong><\/p>\r\n webcomponents.js includes a “lite” file which includes Custom Elements, Templates, and Imports at 9KB, gzipped.<\/p>\r\n Adding Shadow DOM brings the polyfill total up to 30KB, gzipped (it’s 103KB minified, without gzipping, by the way. TJ VanToll has written about why it’s so large<\/a>).<\/p>\r\n An HTML Import for a component contains individual links to all of the component’s dependencies. This really isn’t consistent with today’s practice of concatenating JS and CSS files, to keep the number of HTTP requests down.<\/p>\r\n Imports were designed with HTTP\/2 in mind (which basically makes it fine to skip concatenation by way of multiplexing). Unfortunately, not every hosting provider, CDN, or server supports it yet. Browser support for SPDY (the predecessor to HTTP\/2’s multiplexing) isn’t too shabby<\/a>, but there are still some issues (mostly older IE, and IE 11 on Windows 7-). If you’re ready to go all HTTP\/2 \u2013 you’re in good shape to use HTML Imports.<\/p>\r\n If not \u2013 Polymer does have a tool called Vulcanize<\/a> that concatenates Import files \u2013 but there are some gotchas:<\/p>\r\n Bottom line:<\/strong> The general point of Imports is to give you an easy<\/em> way to get a component’s dependencies on a page. If you already have a solution for that \u2013 then you can just stick with it. You won’t have a good place to store HTML Templates, but that’s okay because ES6 template strings<\/a> will make templates in JS much less painful.<\/p>\r\n Accessibility with Web Components really isn’t any different than accessibility with any other kind of UI components. <\/p>\r\n Yes, Web Components can make it convenient to reimplement native elements, but you certainly don’t have<\/em> to, and people already do that without “Web Components” when the native element doesn’t provide the flexibility they want. We’ve seen custom dropdowns, range sliders, radios, checkboxes, buttons, and more. Some accessible, and some not so much.<\/p>\r\n The same principle applies, whether it’s a “Web Component” or not: You must add the appropriate accessibility features to anything you build (whether you’re reimplementing a native element or not).<\/strong> And that often means more work<\/a> than just adding an ARIA role. Here’s a handy checklist<\/a>, courtesy of Steve Faulkner.<\/p>\r\n And don’t forget \u2013 while Custom Elements lets you create new elements:<\/p>\r\n It also allows you to extend native elements \u2013 saving you the trouble of reimplementing built-in accessibility features:<\/p>\r\n Update 4\/2015:<\/strong> Extending with Bottom line:<\/strong> if you can write an accessible regular component, then you can write an accessible Web Component. Whatever you’re doing \u2013 make it accessible!<\/p>\r\n If you haven’t noticed yet \u2013 Web Components rely on JavaScript. Substantially. Imports is the only part that really works without JS. There are differing opinions on progressive enhancement, but let’s just examine a couple approaches from a high level, so that you can make the best decision for your situation:<\/p>\r\n This is kind of the assumed default with Web Components.<\/p>\r\n Good:<\/strong> <\/p>\r\n Bad:<\/strong> <\/p>\r\n This still lets you take advantage of Custom Elements’ lifecycle callbacks and element functions, while maintaining progressive enhancement.<\/p>\r\n Good:<\/strong><\/p>\r\n Bad:<\/strong> <\/p>\r\n First off – the lack of consensus between the browser makers is concerning, all-around. Firefox and Safari (and probably IE) want to see changes made before they ship – but we don’t know what those changes will look like.<\/p>\r\n Having said that, here are my overall conclusions:<\/p>\r\n So I’m left with Custom Elements (this was TJ’s conclusion<\/a> as well). It’s the only spec that’s polyfillable on all the older platforms I’d like to support (IE 9, Android 4.3 and below, etc.) and I love the public API, the lifecycle callbacks, and the “semantic” and clean way you use them on a page.<\/p>\r\n My suggestion is to give Custom Elements a try, and see if they make life easier for you. However, if you’re going to put Custom Elements into production – be sure to use a wrapper around the native API so that you can easily make changes if they become necessary. And it’s probably best to avoid extending native elements (using the To learn about using Custom Elements in JS frameworks, head over to Part 3<\/a>.<\/p>\r\n\r\n Libaries like Polymer<\/a> were developed to solve a number of common tasks related to Custom Elements (and the other specs). Things like easy attribute binding, smarter templating, and events.<\/p>\r\n However, they almost seem to violate one of the objectives of Web Components, which is reusability. If you want to build a component that can be reused in a variety of environments, keeping your dependencies to a minimum is usually a good thing. I’m not sure I’m comfortable with forcing another largeish (Polymer is ~37KB, gzipped) dependency on everyone who might want to use my component. <\/p>\r\n But if you want to develop components to be used in environments that you<\/em> control, I’d feel much better about a library like Polymer – and it’d probably be fairly helpful. X-Tag<\/a> is another alternative which provides a neat wrapper for creating Custom Elements (and they don’t even bother with Shadow DOM, which is fine by me). And if you really want to start writing CSS for Shadow DOM, you might want to take a look at Bosonic<\/a>, which transpiles your CSS on the server (rather than in the browser, as Polymer does).<\/p>\r\n\r\n Meta:<\/strong> If I’ve gotten anything flat-out wrong, missed something, or if you have any suggestions, please leave a comment or let me know on Twitter!<\/p>\r\n\r\n Update 2\/2015:<\/strong> Browser makers are having a hard time coming to an agreement on how Custom Elements should work under the hood. Particularly around the extension of native elements (using the This is Part 2 of a 3-part series. Part 1: The Specs Part 2: Practical Use (Browser Support and Other Challenges) Part 3: Web Components in Angular, Ember, and React Introduction In Part 1 we learned how to code pure Web Components. But of course, adopting new web technologies is rarely painless, and Web Components are especially complicated. In this…<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-1456","post","type-post","status-publish","format-standard","hentry","category-uncategorized"],"_links":{"self":[{"href":"https:\/\/cbateman.com\/blog\/wp-json\/wp\/v2\/posts\/1456"}],"collection":[{"href":"https:\/\/cbateman.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/cbateman.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/cbateman.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/cbateman.com\/blog\/wp-json\/wp\/v2\/comments?post=1456"}],"version-history":[{"count":40,"href":"https:\/\/cbateman.com\/blog\/wp-json\/wp\/v2\/posts\/1456\/revisions"}],"predecessor-version":[{"id":1578,"href":"https:\/\/cbateman.com\/blog\/wp-json\/wp\/v2\/posts\/1456\/revisions\/1578"}],"wp:attachment":[{"href":"https:\/\/cbateman.com\/blog\/wp-json\/wp\/v2\/media?parent=1456"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/cbateman.com\/blog\/wp-json\/wp\/v2\/categories?post=1456"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/cbateman.com\/blog\/wp-json\/wp\/v2\/tags?post=1456"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}\r\n
dom.webcomponents.enabled<\/code> flag.<\/p>\r\n\r\n
\r\n
What’s going on here?<\/h3>\r\n
Polyfills<\/h2>\r\n
Custom Elements (native support<\/a>)<\/h3>\r\n
:unresolved<\/code> pseudo class.<\/p>\r\nHTML Templates (native support<\/a>)<\/h3>\r\n
HTML Imports (native support<\/a>)<\/h3>\r\n
async<\/code> attribute. <\/p>\r\ndocument.currentScript<\/code>, which is needed in the import to access templates (or other elements) in the import, can’t be polyfilled. It is, however, shimmed with _currentScript<\/code>. So, to write code that works in both supported and polyfilled browsers, you must do this:<\/p>\r\ndocument._currentScript || document.currentScript;<\/code><\/pre>\r\nShadow DOM (native support<\/a>)<\/h3>\r\n
<content><\/code> tag to where the shadow root would be.<\/p>\r\n\r\n
\/deep\/<\/code>.<\/li>\r\n::shadow<\/code> and \/deep\/<\/code> CSS rules in the page, you must add the shim-shadowdom<\/code> attribute to the <style><\/code> or <link><\/code>.\r\n
::shadow<\/code> rules will behave like \/deep\/<\/code> rules anyhow.<\/li>\r\n<\/ul>\r\n<\/li>\r\n\r\n
::content<\/code> rules in the shadow root will apply to everything in the shadow root \u2013 not just children of <content><\/code> elements.<\/li>\r\n<content><\/code>, DOM hierchy will be different in polyfilled browsers. Normally, elements selected by <content><\/code> would be children of the root element, but in polyfilled browsers they will be children of the <content><\/code>‘s parent. You can certainly work around this \u2013 but it’s an additional thing to keep in mind as you write your component’s JS.<\/li>\r\n<\/ul>\r\nPolyfill Sizes<\/h3>\r\n
Performance & HTML Imports<\/h2>\r\n
\r\n
document.currentScript.ownerDocument<\/code> will point to the importing page’s document, rather than the (original) import document.<\/li>\r\nAccessibility<\/h2>\r\n
<ul>\r\n <crazy-li role=\"listitem\">First<\/crazy-li>\r\n<\/ul><\/code><\/pre>\r\n<ul>\r\n <li is=\"crazy-li\">First<\/li>\r\n<\/ul><\/code><\/pre>\r\nis=<\/code> will most likely be removed<\/a> from the spec. It may return in a different form, in a future version.<\/p>\r\nProgressive Enhancement<\/h2>\r\n
Component renders its own internal HTML.<\/h3>\r\n
\r\n
\r\n
<head><\/code>) will slow down the page’s initial render time<\/li>\r\nServer includes the component’s internal markup.<\/h3>\r\n
\r\n
\r\n
<head><\/code>, of course. So if you’re using an Import, it’ll need to be synchronous (and maybe load its JS asynchronously<\/em>, for performance).\r\n
What to Do?<\/h2>\r\n
\r\n
is<\/code> attribute).<\/p>\r\n\r\nA note on frameworks\/libraries<\/h3>\r\n
is=<\/code> attribute). It’s possible that they may decide to remove that feature so that they can ship a spec they all agree on. Anne van Kesteren warns<\/a> that the updates “will likely be incompatible with what is out there today.” See here<\/a> for more details. There’s also been a lot of Shadow DOM discussion and not a ton of agreement – here’s the current status<\/a>.<\/p>","protected":false},"excerpt":{"rendered":"