(Native) Custom element samples

[Addy Osmani]

A question we regularly get asked is where devs can find high-quality examples of custom elements that don't necessarily use Polymer or Brick.

Some of the use-cases tend to be:

• I'd like to try this out natively for educational purposes
• I want to compare a native implementation to what it would be with a library or framework
• I need this for presentations and they don't exist, so we have to roll our own.

Is there value in us trying to put some time into creating some samples that could live on WebComponents.org?

[Rob Dodson]

Would it make sense to port some of our more successful Polymer elements to vanilla custom elements? Maybe start small with something like polymer-ui-tabs and polymer-ui-collapsible? We could also give polymer-ajax or polymer-flexbox a shot. Those are all pretty popular items I think.

--
You received this message because you are subscribed to the Google Groups "Web Components Organisation" group.
To unsubscribe from this group and stop receiving emails from it, send an email to webcomponent...@googlegroups.com.
To post to this group, send email to webcom...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/webcomponents/bef0d69b-5bc1-4b5a-808b-1ac20e2e0dc3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Jonathan Dodd]

Just my two-cents worth, as a highly interested (non-professional) observer of the Web Component pre-revolution:

 

Ever since Rob and Eric introduced Web Components in the amazing CSS-Tricks and HTML5Rocks articles, I have been reworking and tinkering with every demo and example, in order to produce usable, plain vanilla components. While I am in awe of all that is being done by the Polymer team... I really am more interested in seeing the "Platform" polyfill progress to the point where (at least) vanilla custom elements can be used reliably over  the modern browsers.

 

All of the 'opinionated' additions and facilities being developed in Polymer will be amazing and wonderful, and I certainly want Polymer to flourish and rapidly develop, but I believe that the basic goal of Web Components being used on real, everyday sites is still not realized.  As an example, I re-worked Rob's "slider" component from the CSS-Tricks article so that multiple sliders, each with differing numbers of images, can be placed on a page.  In my Windows 7 "test/development" environment -- Node-webkit (a Chromium-browser runtime) on the desktop -- this works perfectly.  As re-worked, the code represents a minimal, vanilla component: It is included via a single HTML Import, uses Templating and Shadow Dom , registers the custom element(s) via createCallback and is encapsulated -- CSS via Shadow Dom and JS through IIFE and namespacing.  As of today, this works on both Chrome and Canary.  However, with "platform.js" included, at this moment, it works on Chrome, but the Shadow Dom fails on Canary.  And as yet, I have had no success with Firefox, Safari, or IE, at all.  Naturally, I understand everything is in a state of flux, but clearly the Platform polyfill is not yet ready, even with a basic vanilla Web Component, to be utilized on an actual live site.

 

I think we need many more full, working examples of vanilla custom elements in order to bring Web Components into viability for real Websites.  Not until the Polyfill achieves jQuery-like reliability in its basic mission -- providing (modern) cross-browser functioning for the 4 pillars (Imports, Templates, Custom Elements and Shadow Dom), can all of the additional sugar of Polymer be evaluated and utilized. 

 

So, DL;TL  :  + 1  YES, more high-quality examples of vanilla custom elements would be great.

 

 

 

[Eric Bidelman]

Hi Johnathan, 

Teaching web devs the underlying technologies is high priority. It's important for the growth of web development and the next generation of apps and frameworks to be built. Apart from the basic articles on h5r, what are some other things you'd be interested in seeing?

If the platform.js polyfills are not fully working for the vanilla cases, we've failed. Can you provide a jsbin of the things that don't work?  As you've pointed out, there are still a lot of pieces in flux and there may be required tweaks. For example, there are numerous slide decks and blog posts on the web that are grossly out of date...and they're only months old :\ This will all settle down very soon. I promise!

FWIW, brokenness may be a combination of flags not being set (in Chrome Canary) and/or differences between the polyfills and native. The SD polyfill in particular tries its hardest to do the RightThing, but it's not 100% perfect.

--

You received this message because you are subscribed to the Google Groups "Web Components Organisation" group.
To unsubscribe from this group and stop receiving emails from it, send an email to webcomponent...@googlegroups.com.
To post to this group, send email to webcom...@googlegroups.com.

To view this discussion on the web, visit https://groups.google.com/d/msgid/webcomponents/5a39a768-962f-42db-9ada-aa384298b686%40googlegroups.com.

[Jonathan Dodd]

Hi Eric:

 

Thank you for your response.  I will try to  produce a jsBin of the slider code I mentioned, but I am a newbie ... (How do you show the HTML (page) file, as well as a "import.html" file? ). 

 

In the meantime, since you asked (and focusing on the polyfill) --  I would be very interested in having a "curated chart"  showing implementation details for the four basic API's.  For Imports, Templates, Custom Elements and Shadow Dom, the chart would list every method actually implemented, with any differences from the (working) standards.  For example, it would show if "document.register" or "document.registerElement" was implemented,  whether ^ & ^^  OR  /shadow/ & /shadow-deep/  (or /shadow-all/, /shadow-child/....etc.) was implemented, and so forth.  In addition, for each of the "modern browser" versions, it would  record which (if any) of these "Big 4 API's" would be utilizing native code when platform.js is present, which would be successfully polyfilled (with any required "switches"), and which have neither native implementations nor will be successfully polyfilled.  I have seen such charts presented with no version distinctions, no details as to what constitutes compliance, and no "curation," by which I mean continuous updating and correction of information on at least a weekly (if not almost daily) basis.

 

I realize this would be a considerable undertaking, but currently I (and no doubt many others) spend many hours each week pouring over all the developer-postings, comments, tweets, working group documents, stackoverflow and google+  in order to try and piece together this information.  At the current juncture, I believe that accurate and unvarnished documentation of the state of the polyfill with regard to the modern ("evergreen") browsers for the four required API's  is a critical need.  In  my (limited) experience,  just these four API's, reliably polyfilled for modern browsers -- encompassing encapsulated CSS (and js), imports, and templates -- would open the floodgates of widespread adoption.  Mutation observers, pointer APIs, animation, additional event management, and all the other "sugar" of Polymer will be essentially unusable until "plain vanilla" web components can be adopted with knowable effect.

 

Sorry to bend your ear.....   but you did ask !!

 

Thanks for listening,

Jonathan

[Rob Dodson]

Maybe something like the ECMAScript compatibility table?

--

You received this message because you are subscribed to the Google Groups "Web Components Organisation" group.
To unsubscribe from this group and stop receiving emails from it, send an email to webcomponent...@googlegroups.com.
To post to this group, send email to webcom...@googlegroups.com.

To view this discussion on the web, visit https://groups.google.com/d/msgid/webcomponents/2c8f7d51-832f-4b4d-9b48-8dd1428b6606%40googlegroups.com.

[Jonathan Dodd]

 

Hi Rob:

 

Yes, that has the right feel.  With this kind of information, it would be possible to provide consistent fall-back functionality and rendering within web-components themselves.  Or, for example, a "modernizr-like" addition within the Platform.js polyfill, itself, could dynamically provide this implementation information (for the current browser) so that any web-component could access/react to whatever browser it found itself in.  Or, a VERY plain vanilla Web Component (or js "shim"), with no visible rendering, and utilizing only (name-spaced) JavaScript could provide this information via JS globals.  With this information constantly changing  (as must be expected for years to come)  but not being succinctly and accurately available,  how can Web Components be utilized on "live" web sites??

 

Custom Web Components, in my opinion, should be usable (via fall-backs with known characteristics) in virtually any browser (with at least JS and basic HTML/CSS), just like "regular" HTML elements.

 

Does this make any sense....   coming from the viewpoint of a beginner?

 

Thanks, Jonathan

[Rob Dodson]

Yeah that makes total sense. To be honest, I often get tripped up knowing what's in and what's out since things move so fast and there are varying levels of support. webcomponents.org sounds like a good place to house such a thing. anyone disagree?

--

You received this message because you are subscribed to the Google Groups "Web Components Organisation" group.
To unsubscribe from this group and stop receiving emails from it, send an email to webcomponent...@googlegroups.com.
To post to this group, send email to webcom...@googlegroups.com.

To view this discussion on the web, visit https://groups.google.com/d/msgid/webcomponents/423c3e94-41c6-4ca9-8e31-17893f24f685%40googlegroups.com.

[Eric Bidelman]

> Thank you for your response.  I will try to  produce a jsBin of the slider code I mentioned, but I am a newbie ... (How do you show the HTML (page) file, as well as a "import.html" file? ). 

 

You could inline everything into the same page if it makes things easier.

> I would be very interested in having a "curated chart"  showing implementation details for the four basic API's.  For example, it would show if "document.register" or "document.registerElement" was implemented,  whether ^ & ^^  OR  /shadow/ & /shadow-deep/  (or /shadow-all/, /shadow-child/....etc.) was implemented, and so forth. 

There are a few resources, though not in this amount of detail:

http://jonrimmer.github.io/are-we-componentized-yet/

http://www.polymer-project.org/resources/compatibility.html

 

IMHO, I'm not sure the detailed view is really practical right now until 1.) multiple vendors have an implementation (out from behind a flag) and b.) the specs settle down.

Personally, it's been a daunting task to constantly update Polymer documentation, html5rocks articles, presentations. And that's my full time job :) 

There is still a lot of churn at the standards level. You can effectively forget about things like document.register and ^ && ^^. They're gone and there's no reason we should ever talk about them again. Other things like /shadow-*/ and hot are still hot off the press. Literally, the ink is still wet! Documentation on MDN and webplatform.org is only a matter of time, but it will eventually happen.

On Wed, Mar 12, 2014 at 8:00 AM, Rob Dodson <robd...@google.com> wrote:

Yeah that makes total sense. To be honest, I often get tripped up knowing what's in and what's out since things move so fast and there are varying levels of support. webcomponents.org sounds like a good place to house such a thing. anyone disagree?

It would be great if wc.org became a type of caniuse for webcomponents.

 

On Tue, Mar 11, 2014 at 10:35 PM, Jonathan Dodd <nw.e...@gmail.com> wrote:

 

Hi Rob:

 

Yes, that has the right feel.  With this kind of information, it would be possible to provide consistent fall-back functionality and rendering within web-components themselves.  Or, for example, a "modernizr-like" addition within the Platform.js polyfill, itself, could dynamically provide this implementation information (for the current browser) so that any web-component could access/react to whatever browser it found itself in.  Or, a VERY plain vanilla Web Component (or js "shim"), with no visible rendering, and utilizing only (name-spaced) JavaScript could provide this information via JS globals.  With this information constantly changing  (as must be expected for years to come)  but not being succinctly and accurately available,  how can Web Components be utilized on "live" web sites??

An implicit goal of the polyfills is that you should not have to feature detect. They choose the fast path for you and shim support for missing features. Drop in platform.js and you get a browser from 2015.

 

 

Custom Web Components, in my opinion, should be usable (via fall-backs with known characteristics) in virtually any browser (with at least JS and basic HTML/CSS), just like "regular" HTML elements.

 

Does this make any sense....   coming from the viewpoint of a beginner?

 

Thanks, Jonathan

--
You received this message because you are subscribed to the Google Groups "Web Components Organisation" group.
To unsubscribe from this group and stop receiving emails from it, send an email to webcomponent...@googlegroups.com.
To post to this group, send email to webcom...@googlegroups.com.

To view this discussion on the web, visit https://groups.google.com/d/msgid/webcomponents/423c3e94-41c6-4ca9-8e31-17893f24f685%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Web Components Organisation" group.
To unsubscribe from this group and stop receiving emails from it, send an email to webcomponent...@googlegroups.com.
To post to this group, send email to webcom...@googlegroups.com.

To view this discussion on the web, visit https://groups.google.com/d/msgid/webcomponents/CAJj5OwAk7Yuw-xX2EP85ngTt01yq4q7XVcaPJkgHwzg6Wkjuig%40mail.gmail.com.

[Jonathan Dodd]

Rob and Eric:

 

Wow!  Thank you both for taking the time to respond to my  "shoot-from-the-hip, perhaps-not-fully-baked" comments.  It was not my intent to hijack this thread and take it so far from the original question posed:  Would  "high-quality examples of custom elements that don't necessarily use Polymer or Brick" be useful?  Again, I would personally be grateful for such a resource.

 

Eric:

> You can effectively forget about things like document.register and ^ && ^^.  (and)  An implicit goal of the polyfills is that you should not have to feature detect

Ideally, I agree.  However, I might point out that ^ and ^^ remain in stable chrome, have been replaced in Canary, and from the resources you mention ( http://jonrimmer.github.io/are-we-componentized-yet/
 and http://www.polymer-project.org/resources/compatibility.html) it is not obvious what the state of the polyfill is -- for this or any other feature.

 

>... it's been a daunting task to constantly update Polymer documentation, html5rocks articles, presentations. And that's my full time job :)

Believe me, we lurkers/followers appreciate all your efforts!

 

>  Drop in platform.js and you get a browser from 2015 

This is precisely where my whole ramble started. Basically, the entire web browser universe -- including Chrome and Canary, unless users have set the correct flags -- falls into this case.  So, it is important to assess it dispassionately. If a suite of "plain vanilla" web components (which fully utilize the important underlying APIs) existed, could they be dropped into modern versions of IE, Safari, Chrome, FireFox and so forth -- with platform.js -- and  1) behave consistently or 2) fall back gracefully?  From my own experimentation, I would say the polyfill is not yet up to this level of reliability/usefulness. When it is

 

>  Literally, the ink is still wet! Documentation on MDN and webplatform.org is only a matter of time, but it will eventually happen.

I look forward to it!

 

 

Thanks, again

Jonathan

 

 

 

 

 

 

 

[Eric Bidelman]

On Wed, Mar 12, 2014 at 11:03 AM, Jonathan Dodd <nw.e...@gmail.com> wrote:

Rob and Eric:

 

Wow!  Thank you both for taking the time to respond to my  "shoot-from-the-hip, perhaps-not-fully-baked" comments.  It was not my intent to hijack this thread and take it so far from the original question posed:  Would  "high-quality examples of custom elements that don't necessarily use Polymer or Brick" be useful?  Again, I would personally be grateful for such a resource.

 

Eric:

> You can effectively forget about things like document.register and ^ && ^^.  (and)  An implicit goal of the polyfills is that you should not have to feature detect

Ideally, I agree.  However, I might point out that ^ and ^^ remain in stable chrome, have been replaced in Canary, and from the resources you mention ( http://jonrimmer.github.io/are-we-componentized-yet/
 and http://www.polymer-project.org/resources/compatibility.html) it is not obvious what the state of the polyfill is -- for this or any other feature.

^ and ^^ only exist if the web platform flag on in canary. I'm not 100% sure if they work in stable with the same flag on. 

Polyfill support is in for the new combinator names is in. The old ones are still supported for backwards compat, but they'll eventually be removed. This stuff was only renamed a few weeks ago so bare with :0

 

 

>... it's been a daunting task to constantly update Polymer documentation, html5rocks articles, presentations. And that's my full time job :)

Believe me, we lurkers/followers appreciate all your efforts!

Thanks!

 

 

>  Drop in platform.js and you get a browser from 2015 

This is precisely where my whole ramble started. Basically, the entire web browser universe -- including Chrome and Canary, unless users have set the correct flags -- falls into this case.  So, it is important to assess it dispassionately. If a suite of "plain vanilla" web components (which fully utilize the important underlying APIs) existed, could they be dropped into modern versions of IE, Safari, Chrome, FireFox and so forth -- with platform.js -- and  1) behave consistently or 2) fall back gracefully?  From my own experimentation, I would say the polyfill is not yet up to this level of reliability/usefulness. When it is

Yes, they should work. For example Mozilla's x-tags/Brick project uses parts of platform.js. 

If things don't work, they're probably bugs. Please let us know on polymer-dev where things fail or file bugs.

 

 

>  Literally, the ink is still wet! Documentation on MDN and webplatform.org is only a matter of time, but it will eventually happen.

I look forward to it!

 

 

Thanks, again

Jonathan

 

 

 

 

 

 

 

--

You received this message because you are subscribed to the Google Groups "Web Components Organisation" group.
To unsubscribe from this group and stop receiving emails from it, send an email to webcomponent...@googlegroups.com.
To post to this group, send email to webcom...@googlegroups.com.

To view this discussion on the web, visit https://groups.google.com/d/msgid/webcomponents/55adfdb7-4b37-4767-ad8a-b132de04b37c%40googlegroups.com.

[Addy Osmani]

So on the topic of samples: if we're happy to proceed with them living on the WebComponents GitHub repo, I'd be happy to create a samples repo where we could start accepting PRs for additions. 

Off the top of my head, places we can look at for inspiration include:

• CustomElements polyfill unit tests
• Rob's webcomponents sketchbook

I've been checking other repos on GitHub out for good samples but so far a lot are either heavily out of date, use Polymer/X-Tag or Dart. Suggestions welcome!

[Rob Dodson]

I should sit down and update the sketchbook and related blog posts. I've been avoiding that for a while because I know there's a lot there :D

Would these examples live in the sandbox on WC.org?

--

You received this message because you are subscribed to the Google Groups "Web Components Organisation" group.
To unsubscribe from this group and stop receiving emails from it, send an email to webcomponent...@googlegroups.com.
To post to this group, send email to webcom...@googlegroups.com.

To view this discussion on the web, visit https://groups.google.com/d/msgid/webcomponents/6dc2a87c-7f90-4325-94e1-0423290ffda3%40googlegroups.com.

[Addy Osmani]

It depends on the type of sample, but yes they could. Alternatively, we could have a samples repo on the org where any miscellaneous code snippets could live.