Check if frameworks are able to recognize the special meaning of the is=""-attribute, and that it cannot be handled like a traditional attribute when it comes to dynamic element creation.

On registry https://registry.npmjs.org/, the "latest" version (v6.24.1) of dependency babel-preset-es2015 has the following deprecation notice:

🙌 Thanks for using Babel: we recommend using babel-preset-env now: please read babeljs.io/env to update!

Marking the latest version of an npm package as deprecated results in the entire package being considered deprecated, so contact the package author you think this is a mistake.

Affected package file(s): libraries/__shared__/webcomponents/package.json, libraries/angular/package.json, libraries/angularjs/package.json, libraries/canjs/package.json, libraries/dio/package.json, libraries/dojo2/package.json, libraries/hybrids/package.json, libraries/hyperhtml/package.json, libraries/litelement/package.json, libraries/mithril/package.json, libraries/polymer/package.json, libraries/preact/package.json, libraries/react/package.json, libraries/skate/package.json, libraries/surplus/package.json, libraries/svelte/package.json, libraries/vue/package.json

If you don't care about this, you can close this issue and not be warned about babel-preset-es2015's deprecation again. If you would like to completely disable all future deprecation warnings then add the following to your config:

"suppressNotifications": ["deprecationWarningIssues"]

It'd be rad if a bot could compare the before/after results of every PR and sound the alarm if a library's scores have changed. On a few occasions I've seen libraries go to 0 either because of them shipping an upgrade that breaks the tests, or they themselves have actually shipped a bug and the tests caught it for them. Currently I manually check before each deploy but that's inefficient :P

It seems to me that libraries do not always appropriately handle camelCase property names the same way.

When using Vue and Svelte together, for example, I'm finding the only way to reliably pass properties is to use a single lowercase value such as textcolor instead of textColor.

However when using only Vue, it seems to pass and accept camelCased properties without issue.

Could this behavior be standardized?

For example, there are problems if you'd like to use a iron-list in a angualar component (I've not tried but my colleague had the issue).

see also: https://stackoverflow.com/questions/33790738/how-to-use-iron-list-with-angular-2-0

ist it possible that you also test if this works?

Right now primitive values are allowed to be set as either an attribute or a property. Since properties and attributes are two separate APIs, custom elements could require that a value is passed in via one API or the other. I do think it's fairly common that there are properties not set from corresponding attributes.

There should be tests that set a property to a boolean|number|string|null|undefined and requires that the property is set, not the attribute.

https://github.com/Tencent/omi

I love the utility that custom-elements-everywhere.com provides to web developers, but the biggest issue with the test data is that it only shows the current versions of each framework.

Not all developers are fortunate enough to be using the latest releases of each framework, so it would be extremely useful to be able to view test results for older versions.

It wouldn't need to be exhaustive, but it would need to at least have results for compatibility milestones (last failing vs first passing).

I just released an adapted version of the interactive react lifecycle methods diagram for custom element reactions:
https://andyogo.github.io/custom-element-reactions-diagram/

If you have time, I would appreciate your feedback very much.

As per @WebReflection's comment here: WebReflection/hyperHTML#138 (comment)

the currently used hyperHTML version in the test is broken.

I'm working on a project where we integrate web components into a web application using the preact framework. For the most part, the issues this site have raised have proven applicable and been very helpful in steering the way we design the application.

One aspect that took me by surprise, though, is that there may be an issue when a custom element uses template tags in the light children area. In particular, I encountered issues with the Vaadin Grid, which uses inner templates to define the columns. Something seemed to go wrong in the way the JSX/h engine generated these teplate tags.

It's a little hard to explain what I was seeing. It was like the template tags weren't quite inert, and the inside of the template turned into strings. Or something. I do think there's an issue here.

This is really cool! Thanks for the detailed write ups!

That being said...

I would expect to see which version of React was tested in the test results.

For example, React 15.6.1

Otherwise the results will become stale and no one will know.

ef.js is an intuitive framework that works perfectly with custom elements.

• Repo
• Website

I have created a pull request in order to add the smart-elements framework to this repository: #462. Locally, the basic test passes, but Travis CI fails with a message regarding GITHUB_TOKEN: https://travis-ci.org/webcomponents/custom-elements-everywhere/builds/510811429?utm_source=github_status&utm_medium=notification.

Could someone, please, clarify how this issue can be addressed?

It'd be nice if Travis or whatever could rebuild and deploy the site once a day.

I've been successfully using Aurelia with custom elements for some time now. I would like to attempt a PR for adding Aurelia. Would that be something that is wanted?

It would be great to cover Saleforce "Lightning Web Components", which are claimed to be based on web standards but in practice completely fail all interoperability criteria, if for no other reason than to shame Salesforce.

It looks like mjackson's expect library is now part of jest (https://github.com/mjackson/expect#notice) but since we're not using jest I think it'd be worthwhile to move to something else like chai expect.

While listing which libraries work with custom elements is extremely useful, I'd also like to know which frameworks can produce custom elements. Would this be a useful advanced test?

Adding complexity is that some frameworks have third party libraries that do this, (example: convert react to web components), should something like this be included?

If there's support, I'd be interested in helping write the tests, etc. Thanks!

I'm the maintainer of a large private custom element library at work and we we're very excited to see Svelte move to 100% passing tests recently. Several pilot projects had been done with Svelte and finally we adopted it for use in official applications based in part on the fantastic information in this repository.

A few weeks after adoption we discovered Svelte isn't fully compatible with custom elements because of a conflicting "named slot" implementation. We have worked around the issue temporarily, but since slot (or "content projection" in framework nomenclature) is a major function of both custom elements and frameworks I thought a test for would be good to add here.

A related Svelte issue has already been reported by @therealnicksaunders here:

sveltejs/svelte#1689

On the site https://custom-elements-everywhere.com/ there is a typo:

imporant / important

Couldn't find the repo anywhere so I'm submitting it here :)

Hey, thanks for the awesome site! This has been super useful for some web components research I've been doing!

I noticed one issue that could potentially make the site difficult to navigate for screen reader users (or search engine crawlers).

Screen reader users can navigate the page by jumping to headings (h1, h2, h3, etc.) For example, in VoiceOver you can use the "rotor" feature to get a list of all headings on the page and then jump to a specific heading based on it's text. This can be a very quick way to navigate the page.

For example imagine a screen reader user was interested in compatibility between React and web components. They hit the home page, open the rotor, and search for a heading containing the text "React." This is the heading structure they see instead:

H1 — Custom Elements Everywhere 
H2 — Making sure frameworks and custom elements can be BFFs 🍻 
H2 — What's this? 
H4 — Handling data 
H4 — Handling events 
H3 — Related Issues 
H4 — Yay! No open issues! 
H4 — Handling data 
H4 — Handling events 
H3 — Related Issues 
H4 — Yay! No open issues! 
H4 — Handling data 
H4 — Handling events 
H3 — Related Issues 
H4 — Handling data 
H4 — Handling events 
H3 — Related Issues 
H4 — Yay! No open issues! 
H4 — Handling data 
H4 — Handling events 
H3 — Related Issues 
H4 — Yay! No open issues! 
H4 — Handling data 
H4 — Handling events 
H3 — Related Issues 
H4 — Yay! No open issues! 
H4 — Handling data 
H4 — Handling events 
H3 — Related Issues 
H4 — Yay! No open issues! 
H4 — Handling data 
H4 — Handling events 
H3 — Related Issues 
H4 — Handling data 
H4 — Handling events 
H3 — Related Issues 
H4 — Handling data 
H4 — Handling events 
H3 — Related Issues 
H4 — Handling data 
H4 — Handling events 
H3 — Related Issues 
H4 — Handling data 
H4 — Handling events 
H3 — Related Issues 
H4 — Yay! No open issues! 
H4 — Handling data 
H4 — Handling events 
H3 — Related Issues 
H4 — Handling data 
H4 — Handling events 
H3 — Related Issues 
H4 — Yay! No open issues! 
H4 — Handling data 
H4 — Handling events 
H3 — Related Issues 
H4 — Yay! No open issues! 
H4 — Handling data 
H4 — Handling events 
H3 — Related Issues 
H4 — Yay! No open issues! 
H4 — Handling data 
H4 — Handling events 
H3 — Related Issues 
H4 — Yay! No open issues! 
H2 — Frequently Asked Questions 
H3 — What are these custom element things? 
H3 — Are you testing that libraries let you author custom elements? 
H3 — Why is each test counted twice? 
H3 — How are the libraries scored? 
H3 — How are basic and advanced tests different? 
H3 — I thought the whole point of Polymer was to write custom elements. Why doesn't it get a 100%? 
H3 — If a library is missing a feature, like declarative event or property bindings, does it automatically fail those tests? 
H3 — Why don't you have tests for _____ library? 
H3 — I want to write some tests for _____ library. Do you accept pull requests? 

This was output by running this snippet on the home page:

[...document.querySelectorAll('h1, h2, h3, h4, h5, h6')].forEach(heading => {
  console.log(`${heading.tagName} — ${heading.innerText}`)
});

As you can see, it would be difficult to find information about React using the rotor heading navigation strategy. Instead they'd need to search the page for a string containing "react" or read through the full document.

Similarly search engines use headings to determine and catalogue page content. If the headings do not describe the content well it can be difficult for search engines to understand the content.

I think each framework section should likely have a heading structure like this instead:

H3 — React
H4 — Handling data 
H4 — Handling events 
H4 — Related Issues 

Ideally this change would be made without any visual changes by using CSS to maintain the current styles and layout.

Let me know what you think. I could spend some time putting together a PR if this is something you're interested in.

Thanks!

@WebReflection The site displays the library version under test:

However, with hyperhtml we're actually entirely using hyperhtml-element now, instead of hyperhtml itself. Would you rather show the hyperhtml version or the hyperhtml-element version?

There is a known issue with Angular and material-components-web: material-components/material-components-web#4221

Angular template syntax uses colon as a special behavior and event with colon in the name do not work.
This naming convention is pretty common and goes back to jQueryUI custom events names.

I believe it is important enough to be reflected in the test cases

Should there be a test that covers upgrading elements? Just wondering if the custom element is defined after the framework/library renders the output how

It appears that this currently does not work for Preact props and might be an issue for others.

This issue provides visibility into Renovate updates and their statuses. Learn more

Awaiting Schedule

These updates are awaiting their schedule. Click on a checkbox to get an update now.

• Pin dependencies (@babel/core, @babel/preset-env, @babel/preset-react, @webcomponents/webcomponentsjs, babel-loader, chai, copy-webpack-plugin, karma, karma-chrome-launcher, karma-firefox-launcher, karma-webpack, preact, react, react-dom, webpack)
• Update babel monorepo (@babel/core, @babel/plugin-transform-runtime, @babel/preset-env, @babel/preset-react, babel-loader)
• Update dependency rxjs to v7.5.1

Other Branches

These updates are pending. To force PRs open, click the checkbox below.

• Update dependency https-proxy-agent to 2.2.3 [SECURITY]
• Update dependency node-fetch to 2.6.1 [SECURITY]
• Update dependency trim-newlines to 3.0.1 [SECURITY]

Ignored or Blocked

These are blocked by an existing closed PR and will not be recreated unless you click a checkbox below.

• Update dependency ansi-regex to 5.0.1 [SECURITY]
• Update dependency glob-parent to 5.1.2 [SECURITY]
• Update dependency minimist to 0.2.1 [SECURITY]
• Update dependency nth-check to 2.0.1 [SECURITY]
• Update dependency chai to v4.3.4
• Update dependency copy-webpack-plugin to v10.2.0
• Update dependency mocha to v8.4.0
• Update dependency webpack to v4.46.0
• Update react monorepo to v0.14.10 (react, react-dom)
• Update dependency babel-loader to v8
• Update dependency cross-env to v7.0.3
• Update dependency hybrids to v7
• Update dependency karma-webpack to v5
• Update dependency marked to v4
• Update dependency mocha to v9
• Update dependency ora to v6
• Update dependency preact to v10
• Update dependency riot to v6
• Update dependency typescript to v4.5.4
• Update dependency webpack to v5
• Update dependency xmlbuilder to v15
• Update react monorepo to v17 (major) (react, react-dom)

• Check this box to trigger a request for Renovate to run again on this repository

Smart HTML Elements for building Custom Elements: https://www.htmlelements.com/

Svelte 1.37 now supports Custom Elements!
sveltejs/svelte#797

It was released a long time ago and I think we are at 2.2.1 now.

There is an error with this repository's Renovate configuration that needs to be fixed. As a precaution, Renovate will stop PRs until it is resolved.

Error type: Cannot find preset's package (github>whitesource/merge-confidence:beta)

I think it would be fair and rewarding to see frameworks ordered by their overall score rather than their name. What do you think?

I'm currently encountering a problem with svelte and I think it could be interesting to know if other framework has this caveat.

The goal of the test is to see if a custom element produced by a framework can emit a CustomEvent.

<my-element></my-element>
<script>
document.querySelector('my-element').addEventListener('myevent', function (e) {

});
</script>

The sentence would be

• The library/framework should be able to dispatch DOM events from a custom element. These DOM events could be listened from the outside.

LitElement will pass data to an element as properties, as long as the property is defined on the element's prototype. Otherwise it will fallback to passing data as attributes.

I just asked on the LitElement slack and this is not true. lit-html uses attributes by default and has an alternate syntax to explicitly pass a property instead, just like Vue.

P.S. Historically, this one the other way around (properties by default and special syntax to explicitly specify attributes). This was changed in lit-html 0.11 via lit/lit#398

I think it would be useful to test that libraries supporting custom elements include the ability to listen for events from either the capture or the bubble phase.

We recently ran into an issue where the Angular Framework can only listen to bubble events while Angular Elements can only emit capture phase events. In this case the Angular Framework was not able to easily consume arbitrary custom elements (created by Angular Framework).

Glimmer.js, a component-based library that powers components in Ember.js, is able to output web components.

Maybe there's some obvious reason why it isn't needed, but it isn't obvious to me due to my murky understanding -- would it make sense to also test preact with the preact-compat react compatibility layer?

I mean as a separate test. Testing without it is probably more useful. But would be good to know if anything negative happens when the compatibility layer is needed.

Similar to #12, stenciljs outputs custom elements now so let's see if they comply with the tests. We'd be looking to check how they handle attributes and properties, events, etc. We know stencil doesn't use shadow dom so there would be a few test failures there I think, but good to identify and track all of this stuff, especially as stencil evolves.

Going through the tests, it seemed like there were some (small) disparities between some of the libraries. This dojo test in particular caught my eye.

If the tests were shared, it would give a level of consistency across the tests. It would also make it easier to add new tests/fix tests (if necessary) and to add new libraries to the repo. It might even be useful to export the tests so that libraries could add them to their own test suites.

I'm thinking providing a light adaptor for each framework would be enough.

Take a look at this example for Preact:
https://gist.github.com/mlrawlings/1a14ddf446ca9787da7e378bc80f9a0c
conceptually, it should work, but I haven't actually run the code

Thoughts?

Setting value as property on a custom element fails. It gets passed as a string [Object Object] instead.

<custom-element :value.prop="message"></custom-element>

new Vue({
  el: '#app',
  data: {
       message: {'hello': 'world'}
  }
})

Codepen to reproduce: https://codepen.io/tornadoalert/pen/rNjVzbd

I'd love to see JSDom's support on the page.

for example: https://custom-elements-everywhere.com/libraries/angular/results/results.html

did the deployed site go away? I was just reading it 40 minutes ago and now it's gone.

https://custom-elements-everywhere.com/ -- Site Not Found (Firebase)

Several libraries are outputting the following during npm install:

npm WARN deprecated [email protected]: 🙌 Thanks for using Babel: we recommend using babel-preset-env now: please read babeljs.io/env to update!

Each project should be updated to remove this recommendation warning.

Preact X (10) is out, seems like it has fixed some issues in compatibility.

Maybe it is worth to update the version?

I can do it, if you are not against

@WebReflection I tried updating to 2.0.6 but noticed all the tests failed because

import {hyper} from 'hyperhtml'

no longer works. The docs mention that hyper is still an exported function so I must be doing something wrong with my use of modules. Any ideas?

I've been doing some work with Ember + WebComponents lately and support, in the latest version, is actually pretty good. I would love to get this reflected in your site! I can look into making a PR that adds tests for Ember, but it may be tricky since Ember is tightly coupled to its own build tools.

Now that React 17 is released, this should be updated to run on it.

It'd be good to link to the primer and the best practices docs.

On registry https://registry.npmjs.org/, the "latest" version (v0.2.1) of dependency @dojo/interfaces has the following deprecation notice:

@dojo/interfaces is deprecated

Marking the latest version of an npm package as deprecated results in the entire package being considered deprecated, so contact the package author you think this is a mistake.

Affected package file(s): libraries/dojo2/package.json

If you don't care about this, you can close this issue and not be warned about @dojo/interfaces's deprecation again. If you would like to completely disable all future deprecation warnings then add the following to your config:

"suppressNotifications": ["deprecationWarningIssues"]

As of version 10 of the library, the name of this library has been updated from DIO to Dyo:

https://github.com/dyo/dyo/blob/master/CHANGELOG.md#1000-unreleased