From @tomalec on January 10, 2018 16:10

Description

Shadow DOM styles are not scoped for vanilla JS Custom Elements and shadow DOM content does not get style-scope my-element class when element is cloned and stamped after CE definition

Live Demo

http://jsbin.com/sekilom/edit?html,output

Steps to Reproduce

1. Create a template with <my-element>
2. Define my-element in the way it attaches open shadow root in constructor or attributeChangedCallback, the shadow root that contains styles and elements.
3. Clone the template, stamp it to the main document

Expected Results

1. Styles should get scoped,
2. Elements should get style-scope my-element class

Actual Results

1. Styles are not scoped,
2. Elements didn't get style-scope my-element class

Browsers Affected

• Chrome
• Firefox
• Edge
• [?] Safari 9
• [?] Safari 8
• [?] IE 11

Versions

• webcomponents: v1.0.22

Investigation

When element is created:

• before upgrade, or
• added after upgrade with .innerHTML, or
• stamped from a template created after upgrade

elements get style-scope ... class, so are at least scopeable

I tried ShadyCSS.styleElement with no luck.
I suspect ShadyCSS assumes every custom element instance should have the same shadow root what is not true per spec and in my case. https://github.com/webcomponents/shadycss/blob/master/src/scoping-shim.js#L233 early returns early, even though my element has shadowRoot.

Copied from original issue: webcomponents/webcomponentsjs#883

Hey,

I am having the following issue, my custom elements shadow dom is like this:

    <slot></slot>
    <div class="material-toggle__switch">
        <div class="material-toggle__knob" draggable="true"></div>
    </div>

Into the slot I put:

<label>
<input type="checkbox" autofocus style="position: absolute; opacity: 0; pointer-events: none;" />
</label>

The autofocus is actually added via script if the custom element has an autofocus (and it is remove from the custom element).

Expected: Element is focused.
Actual result: Element is focused in Safari and Chrome but not in firefox.

However focusing the element via tab works. I added a log to the focus event, however it is not triggered in firefox. (It is in Chrome and Safari).

Am I doing something wrong, or is this a bug? A normal checkbox (not within slot) with autofocus gets the focus just fine in firefox.

Here's an example of what I've found when styling in Polymer, although I assume the problem is with shady polyfill itself

I have a container element with a slot and default style for all slotted elements. It's important that I select the slotted element by id

<dom-module id="my-container">
   <template>
      <style>
         section#sn :slotted(*) {
            color: red;
         }
      </style>
      <section id="sn" class="sn">
         <slot></slot>
      </section>
   </template>
</dom-module>

In another element I distribute a node and apply same rule in Light DOM

<dom-module>
   <template>
      <style>
         p {
            color: green;
         }
      </style>
      <my-container>
         <p>Green text</p>
      </my-container>
   </template>
</dom-module>

Expected behaviour

The paragraph should be green

Actual behaviour

In browsers using polyfill it will be red.

Attached is the above example

my-app.html.zip

Workaround

When selecting the slotted element one has to be very careful not be too specific. Above even if changed to using class section.slot ::slotted(*) alone won't help without making the selector in my-app more specific like.

my-container p { 
   color: green;
}

Otherwise the naked p selector will still be too little specific.

Pretty much #48 again.

The PR did not fix the issue entirely, it seems mixins are still broken because of this:
http://jsbin.com/pekebeyezi/edit?html,output

Any mixin like such:

--foo: {
  background: url('data:image/png;base64,blah');
}

Will mistakingly terminate the mixin after the semicolon.

From @Jeff17Robbins on September 8, 2017 22:29

Using the V1 polyfill, I created an ES5 babel transpilation of the <x-product> example found at MDN.

The custom element's constructor essentially wraps an <img> element. The salient code is:

                var img = document.createElement('img');
                img.alt = _this.getAttribute('data-name');
                img.src = _this.getAttribute('data-img');
                img.width = '150';
                img.height = '150';
                img.className = 'product-img';
                //_this.appendChild(img);  // this works
                _this.innerHTML = img.outerHTML;  // this creates a recursive loop in the polyfill

As shown, if instead of appending the <img> I instead assign to .innerHTML, the assignment causes a loop back into constructing <x-product>. And so on until stack crash.

This crash reproduces on Chrome, MS Edge, IE11, and Firefox.

I don't understand why the polyfill's .innerHTML apparently re-triggers the upgrade process on the element, but if you are encapsulating a 3rd party library and need to construct something in your constructor, obviously you can't control if the 3rd party chooses to use .innerHTML.

Also, a native version of this same page does not crash.

Copied from original issue: webcomponents/webcomponentsjs#841

This should provide better integration with [lit-html'(https://github.com/Polymer/lit-html)s shady-render functionality. Currently, @apply will not correctly track properties when prepareTemplate is called multiple times, losing the previously tracked properties for a given mixin.

Doesn't appear implement the DocumentOrShadowRoot interface - or only activeElement property seems to be implemented. Particularly for dealing with selections and ranges this is needed. I'm trying to use Prosemirror inside a component but this causes it to break - any chance some, if not all this interface will get implemented?

The following syntax is allowed in the Web Component v1 specification and currently works correctly on Chrome and Safari:

<template id="element-template">
  <link rel="stylesheet" href=style.css">
  <div>...</div>
</template>

At the moment, this polyfill only seems to support inline style tags.
Is support for link tags in the pipeline, or will it remain unsupported?

Styling of the form --a: var(--a); will infinite loop in StyleProperties.valueForProperty because the props will keep evaluating itself instead of checking for shadowed values

According to this JSBin: http://jsbin.com/wopofuc/edit?html,output, a variable referencing itself seems to just drop the definition, so it should be pretty simple to fix this and keep correct behavior.

When writing an attribute selector with a string literal with a colon in it, shadycss puts the scoped-style rules INSIDE THE STRING LITERAL right after the colon. e.g.

iron-icon[icon="emerson-icons:onhold"]

should get rewritten as

iron-icon[icon="emerson-icons:onhold"]:not([style-scope]):not(.style-scope)

but instead becomes

iron-icon[icon="emerson-icons:not([style-scope]):not(.style-scope):onhold"]

I was able to work around the issue by using the CSS character code for the colon char

iron-icon[icon="emerson-icons\003Aonhold"]

is rewritten as

iron-icon[icon="emerson-icons\003Aonhold"]:not([style-scope]):not(.style-scope)

I tried to write a test for this but the tests seem to be broken, see my other ticket webcomponents/shadycss#118

Currently name on <slot> can only be set via the attribute but it should also be supported by setting the name property.

See for example, http://jsbin.com/sadifij/1/edit?html,output. This works on Chrome but not Firefox since Firefox does not have property reflection for <slot>.name.

Description

During tests preparation for adding hybrids to custom-elements-everywhere I've found a bug, which disallow to use properly document.importNode. The custom element created for tests uses a constructor to create shadowRoot and its content.

Live Demo

https://stackblitz.com/edit/shadydom-import-node-bug

Steps to Reproduce

1. Create a custom element, which creates shadowRoot and set childNodes in constructor method.

Then document.importNode is broken. In that case, slotted elements are distributed in wrong way, MutationObserver returns wrong mutations and events on children elements are not properly propagated.

The worst scenario is when the element has no <slot> element in shadowRoot and you want to observe light dom children of the element.

Expected Results

Live demo (Chrome):

Custom element content renders once, and constructor called once.

Actual Results

Live demo (Firefox):

Custom element content broken (created twice, with wrong slot distribution), constructor called twice (you can see console log).

Browsers Affected

• Chrome
• Firefox
• Edge
• Safari 9 (didn't check)
• Safari 8 (didn't check)
• IE 11

Versions

• webcomponents: v2.0.0

Running a Selenium test on Firefox and trying to click on an element inside a shadow root, causes the click command to fail with

WebDriverException: e.elementFromPoint is not a function

This originates in https://github.com/SeleniumHQ/selenium/blob/77d2ac91eb7c709275b67d9dc4fd0563a2aaab64/javascript/firefox-driver/js/utils.js#L703 where Selenium assumes that every shadowRoot has an elementFromPoint function. As you can see in http://jsbin.com/potatudafa/edit?html,console, a Shady shadowRoot does not have such a function

This is happening with Firefox (not tested with others browsers that need this polyfill and of course in Chrome this works well) and with the 1.0.0-rc.1 version.
So if you add a custom element with Element.outerHTML, the custom element seems to not be "recognized" (the constructor is not called).

I wrote a simple test page where you can see the bug: http://vrac.pwet.fr/customelement_outerhtml.html

Here is a reproduction of the issue: https://codepen.io/bendavis78/pen/VrZWdR?editors=1000

The text should be red.

From @mercmobily on July 1, 2016 2:19

If you have a simple file test.html:

<!DOCTYPE html>
  <html>
    <head>

      <script>
        window.Polymer = { lazyRegister: true, dom: 'shadow'};
      </script>

      <script src="bower_components/webcomponentsjs/webcomponents-lite.js">
      </script>
      <link rel="import" href="extra-styles.html">

      <style is="custom-style" include="extra-styles"></style>

      <style>
        h1 {
          color: blue;
        }
      </style>

      <title>Extra CSS styles</title>
    </head>
    <body>
      <h1>What colour am I?</h1>
    </body>
  </html>

And extra-styles.html is:

<link rel="import" href="bower_components/polymer/polymer.html">

<dom-module id="extra-styles">
  <template>
    <style>
      h1 {
        color: red;
      }
    </style>
  </template>
  <script>
    Polymer({
      is: 'extra-styles'
    });
  </script>
</dom-module>

You will see that:

1. Using shadow DOM, the writing is blue
2. Using shady DOM, the writing is red.

This is because the style set in extra-styles is more specific:

h1:not([style-scope]):not(.style-scope)

Copied from original issue: Polymer/polymer#3758

See http://jsbin.com/cusozof/edit?html,console.

A slot can have direct children that the slot can render as default content if no nodes are assigned to the slot:

<template>
  <slot>
    <div>I'm default content.</div>
  </slot>
</template>

Here, the div is default content. If a component uses the above template as a shadow tree, and if an instance of that component has no children, this default content should render.

In that case, the default content should not be returned in the assignedNodes for the slot. This is per the spec, at least as I read https://dom.spec.whatwg.org/#assigning-slotables-and-slots, which makes no mention of light DOM children. This is how native Shadow DOM behaves in both Chrome and Safari. The polyfill appears to incorrectly report default content as assigned nodes.

This issue is breaking one of the Elix components.

The uncompressed bundle is not published and main points to the compressed version. This becomes problematic when included in apps that have their own compression step as it will be double-minified.

To get around this one has to depend directly on src which can also be problematic because it:

1. Makes use of non-API file-structure
2. Forces the consumer to be concerned with how the source is written so they can transpile it accordingly

Another work around is to use it from something like rawgit, or unpkg (once versions are published). However, this severely limits the consumption methods.

This also affects ShadyDOM and ShadyCSS. I'd like to get the initial feelings and proposals prior to raising issues there.

Thoughts?

I intend to use webcomponents-loader.js within my project which uses Webpack and webpack has its own dependency graph which requires explicit declarative import everything we need to use within the application and that means the current file structure doesn't get copied out as is which is the expectation for the current loader to work. However, I still want the polyfills to be loaded dynamically as I hope that most of the people in future who use the program will have latest browsers, so this will lead to major size reduction and load the polyfills only when needed.

Webpack's dynamic import can be used here and a new file created for the purpose of webpack can help solve the issues. I would like to know the thoughts of the polyfill maintainers if they are willing to accept it in this repo or if I should create a fork since it's something very build tool specific, since the dynamic imports are in stage 3 of the TC39 proposal maybe it's not that much specific to webpack now.

Focus events are not dispatched to elements when their focus and blur functions are called if they are not displayed because they are still waiting on ShadyDOM updates. (demo here) Given that the effects of focus and blur are specifically defined in terms of whether or not the element is being rendered (a condition for being focusable area), it might be useful to automatically flush before calling focus or blur.

As a stop-gap solution to #134, allow multiple calls to prepareTemplate to support multiple templates with stylesheets to operate on the same custom element.

Related to lit/lit#249

After trying to follow this article and adding a custom button element I found that extend is not currently supported. Am I missing something? Are there any estimates on when it will be?
This seems very important but it's not even mentioned in https://github.com/webcomponents/custom-elements#differences-from-spec.

See repro on IE/Edge: http://jsbin.com/bodaku/2/edit?html,output

  <custom-style>
    <style>
      div.blue {
        --div-bg-color: #6699ff;
      }
      div {
        background-color: var(--div-bg-color);
      }
    </style>
  </custom-style>
  
  <div>I am just a div</div>
  <div class="blue">I'm blue</div>

I'd expect the second div to be blue, but that's not the case.

https://github.com/webcomponents/custom-elements/blob/6ad9993949a4f25c05b50b27a031a2ebfc49df89/src/Patch/Node.js#L151-L161

The ordering of reactions triggered by this snippet is incorrect, both in terms of when the spec text triggers enqueues the reactions and what order they would be called when the queue is being flushed.

The spec text ordering - described here, in 'replace' - would be:

1. disconnect nodeToInsert.
2. disconnect nodeToRemove.
3. connect nodeToInsert.

Which, when flushed, would be:

1. nodeToInsert's disconnectedCallback.
2. nodeToInsert's connectedCallback.
3. nodeToRemove's disconnectedCallback.

Hello, I am having some troubles with jsdom. I found this bug jsdom/jsdom#1737 that is related to this piece of code: https://github.com/webcomponents/custom-elements/blob/master/src/CustomElementRegistry.js#L64

It seems that lot of sandboxing by jsdom is necessary to emulate the instanceof behavior.

This check is related to the specs? Every custom element class should really be instanceof Function?

For example, I don't want to learn extra APIs in order to make scoped ShadowDOM style work. I'd just like to do this:

class MyElement extends HTMLElement {
  constructor() {
    this.root = this.attachShadow({mode: 'closed'})
    this.root = `
      <style> ... encapsulated styles here ...</style>
      <div> ... content here ... </div>
    `
  }
}

customElements.define('my-element', MyElement)

and I'd like for that to have encapsulated styling just like it would with regular ShadowDOM. Does it work this way with ShadyCSS? I'm just wondering because the README makes it seem like I have to call ShadyCSS APIs to make the functionality happen, which is obviously not compatible with regular ShadowDOM.

REF Polymer/polymer#4115
Distributed nodes appear to be styled with mixins defined in the host, providing they are applied after the host has been defined.

Please note the following demo: http://codepen.io/oridan/pen/edqMPO?editors=1000
Item B simply extends Item A with no other changes. Therefore they should both display exactly the same. The expected result as I understand it should be per as the following image:

RFC:
I have resolved this where nativeCssVariables == true by applying the following two diffs:
webcomponents/shadycss@master...TomK:apply-host-descendants - quite inefficient
webcomponents/shadycss@master...TomK:refresh-invalid-shim

I understand this is not a complete resolution, and possibly this implementation is not feasible. So I am hoping for comments/suggestions to steer towards a viable solution.

From @cdata on September 21, 2015 20:33

Consider the following test case...

with ShadowDOM: http://output.jsbin.com/picixu/6?dom=shadow
with ShadeyDOM: http://output.jsbin.com/picixu/6

The problem is that, depending on content projection, the composed tree in ShadeyDOM may cause adjacency selectors not to match in some cases. In this case, an adjacency selector that should match and color some text red fails to match in ShadeyDOM.

/cc @sorvell

Copied from original issue: Polymer/polymer#2463

From @eeid26 on April 9, 2015 2:17

sample showing the issue
http://jsbin.com/furenogase/2/edit

Please note the insertNode should work with document fragment also.

A PR for this issue is ready to be checked in.

Copied from original issue: webcomponents/webcomponentsjs#277

Description

Compound selectors for slot, like .querySelector('div>slot') are not working and returns null even thought there are matching elements.

<div id="shadowHost"></div>
<script>
  shadowHost.attachShadow({mode:'open'}).innerHTML = `<div><slot></slot></div>`;
  console.assert(shadowHost.shadowRoot.querySelector('div>slot') !== null, 'there should be `div>slot`');
  setTimeout(()=>{
    console.assert(shadowHost.shadowRoot.querySelector('div>slot') !== null, 'there should be `div>slot`');
  }, 500);
</script>

Live Demo

https://glitch.com/edit/#!/fossil-freeze?path=index.html:7:18

https://fossil-freeze.glitch.me/

Steps to Reproduce

1. Create my-host element - a shadow host
2. Attach shadow to the host,
3. Create div with a slot inside,
4. Append div to my-host
5. Call myHost.shadowRoot.querySelector('div>slot')
6. Call it after few ms

Expected Results

Slot element is returned in both cases.

Actual Results

The first call returns the slot, but after (microtask?) some time, the selector returns null

Browsers Affected

• Chrome
• Firefox
• Edge
• [?] Safari 9
• [?] Safari 8
• [?] IE 11

Versions

• webcomponents: v2.0.2

As briefly suggested at README.md#usage, to support VanillaJS elements I need to use ShadyCSS API manually.

1. First, call ShadyCSS.prepareTemplate(template, name) on a <template> element that will be imported into a shadowRoot

The problem is, I usually don't use a <template> to create shadowRoot (see https://github.com/webcomponents/shadycss/issues/144). Creating HTMLTemplateElement for every single string or DocumentFragment I want to put into my Shadow, seems like an overhead.

Could ShadyCSS expose a method to process DocumentFragment or string? Like StyleTransformer ;)

From @jehna on March 22, 2017 12:50

Description

Polymer 2 objects cannot be inspected with IE11's developer tools.

Live Demo

http://run.plnkr.co/plunks/U3hRP96zlpVhN4aH8E5e/

Steps to Reproduce

1. Open the plnkr link in IE11
2. Open Developer tools by pressing F12
3. Press "Select Element" button (ctrl+b)
4. Click "This is not inspectable on IE11"

Expected Results

The developer tools' Dom Explorer tool should show a div element that has the string "This is not inspectable on IE11" text node in it.

Actual Results

The Dom Explorer tool highlights the string <!DOCTYPE html> and there is nothing inside the <polymer-test-app> tag in the Dom Explorer.

Browsers Affected

• Chrome
• Firefox
• Edge
• Safari 9
• Safari 8
• IE 11 Windows 7
• IE 11 Windows 8.1
• IE 11 Windows 10

Versions

• Polymer: 2.0.0-rc.2
• webcomponents: v1.0.0-rc.5

Source code for the sample

You can see the source code for the plnkr here:

https://github.com/jehna/polymer-ie11-dom-explorer-bug

Copied from original issue: Polymer/polymer#4452

Description

CustomElementInternals.js causes an error in IE.

Live Demo

Run this pen in IE11:

https://codepen.io/anon/pen/dJerjB

Steps to Reproduce

See the pen in IE11. You can use http://crossbrowsertesting.com to test the pen in IE11 for free (click "Change View" in the pen to see a link to "Open on CrossBrowserTesting".

Expected Results

no error

Actual Results

You'll get an error

SCRIPT5022: The custom element being constructed was not registered with `customElements`.

pointing to this line:

https://github.com/webcomponents/custom-elements/blob/134c58e6b21a6788f18b715ac5d70ede0cad779f/src/CustomElementInternals.js#L275

(on column 7, and based on the source map)

Browsers Affected

• Chrome
• Firefox
• Edge
• Safari 9
• Safari 8
• IE 11

Versions

• [email protected], using https://unpkg.com/@webcomponents/[email protected]/webcomponents-sd-ce.js

I am using Angular 4 and Polymer 2. The problem is that Polymer 2 supports css-mixins but Angular doesn't. So I need to parse css-mixins and @apply rules in Angular component-level styles. When I tried to use <custom-style> feature from Polymer 2, the css-mixins worked fine but the styles were messed up. :not(.style-scope) was appended to all style selectors and elements were decorated with style-scope class. I know that's how ShadeCSS emulates ShadowDOM v1 spec. But as I know, Angular also applies different scoping with ShadeCSS, so I only need to handle what Angular missed - css-mixins and @apply rules. So I am asking if there is any way to parse them only from the styles inside a certain element which can be retrieved like as document.querySelector()?

Description

After upgrading to webcomponents lite 1.1.1 a MutationObserver listening to a shadowRoot no longer work in polyfilled environments.

This commit looks to be a likely cause.

Live Demo

• BROKEN: https://codepen.io/trescenzi/pen/ZoKbOa?editors=1111
• WORKING: https://codepen.io/trescenzi/pen/VxbvbJ?editors=1111

Steps to Reproduce

To see expected behavior open the working demo. To see the broken behavior open the broken demo.

The only difference between these demos is the version of webcomponents-lite that is included. This issue is also reproduced in 1.2.0 although I stuck with the version where it was first noticed.

Expected Results

Text Observer Hooked Up is displayed.

Actual Results

Text TypeError: Argument 1 of MutationObserver.observe does not implement interface Node. is displayed. (This differs in IE and Edge where a slightly different error is thrown, but an error it thrown none the less).

Browsers Affected

• Chrome
• Firefox
• Edge
• Safari 9 (I don't have access to Safari 9 or 8 to test)
• Safari 8
• IE 11

Versions

• webcomponents: ^v1.1.1
• shadydom: ^v1.0.13

Description

On IE11, Safari 9, iOS9 the CSS variables that are set to component's :root selector from <styl import="..."> imported CSS are not applied.

How to reproduce

1. Clone https://github.com/jehna/polymer-css-variable-bug
2. Build & run the project
3. Open http://localhost:8081/ in IE11, Safari 9 or iOS9 Safari

Result

The line that says "This should also be red" does not have a red background

Expected result

The line that says "This should also be red" should have a red background

Result in different browsers

• Chrome (latest): Backround is red ✅
• Firefox (latest): Backround is red ✅
• Safari 10: Backround is red ✅

If in constructor used code like

this.shadowRoot.querySelector("section").innerHTML = ...

tags from string not styling.

For it work, need delay ~40ms, like this:

setTimeout(() => {
  this.shadowRoot.querySelector("section").innerHTML = ...
}, 40);

demo: https://codepen.io/anon/pen/ypjrvG?editors=1010

How can this be solved correctly?

See https://github.com/webcomponents/webcomponentsjs/blob/v2/webcomponents-loader.js#L87

    return Promise.all(whenLoadedFns.map(function(fn) {
      return fn instanceof Function ? fn() : fn;
    })).then(function() {
      done();
    }).catch(function(err) {
      console.error(err);
    });

Promise.all will only either call the then or catch callback, and it'll call the catch callback as soon as it sees the first error, and then done() will never be called.

This is probably a very rare problem to hit, it requires multiple waitFor callbacks, one of which fails.

<outer-element> has a shadowRoot that looks like this (notice it wraps the slot with a div, "for reasons"):

<inner-element>
  <div>
    <slot></slot>
  </div>
</inner-element>

and <inner-element> has a shadowRoot with a <slot> in it.

With ShadyCSS enabled, content distributed into <outer-element> is wrongly scoped to it, nullifying styles set from the scope above, e.g. http://jsbin.com/mipoci/1/edit?html,output

<custom-style>
  <style>
    .bg-color { background: orange; }
  </style>
</custom-style>

<outer-element>
  <div class="bg-color">am I orange?</div>
</outer-element>

results in the div having the classes bg-color style-scope outer-element instead of just bg-color

Selectors like .foo .classy-slot::slotted(*) does not work.

Steps to reproduce

0. Define custom element as Shadow DOM per element is not supported,

1. Create Shadow Root.

2. Add <slot> element with a class on it,

3. Add <style> element that (according to the README)

   have a selector to the left of the ::slotted pseudo-element.

   Precisely have a selector for the slot element itself, like .foo slot.bar::slotted(*)

4. Create an instance of this element (shadow host), add a child element inside.

Expected behavior

The selector should match child element, and apply rules to it.

Actualbehavior

The rules are not applied

Live example

https://jsbin.com/yayoyaw/edit?html,output

It should be possible to switch from -loader to -bundle a little more easily. waitFor() in bundle could either just work, or produce a nice error message.

Description
If you nest custom elements and attach them to a node via innerHTML the custom elements are not constructed anymore (works with webcomponents 1.0.14)

Live Demo
https://github.com/mzeiher/webcomponentjs-bug

git clone
npm install
startstatic
http://127.0.0.1:8088 and click a button, in chrome everything works in polyfilled browsers the nested elements are not constructed

-> switch webcomponentjs version to 1.0.14
everything works as expected

Steps to Reproduce
attach a custom element to DOM, get the elements reference and try to append elements wit innerHTML ->custom elements within the innerHTML are not styled/parsed/constructed

Affected Browsers

• Chrome
• IE11
• FF 58
• Safari11
• Edge 40.15063.674.0

Versions
webcomponents: v1.1.0

works in 1.0.14

Is it possible to use this without custom elements? It would be nice to have a custom css properties polyfill on its own :)

I'm trying to load the polyfills conditionally, async and am not able to shim styles.

http://jsbin.com/qaxifecapa/edit?html,output works in Canary, but not in other browsers.

If you uncomment the <script> tags in that jsbin that load the polyfills and replace this:

lazyLoadWCPolyfillsIfNecessary().then(function(events) {
  if (!supportsShadowDOMV1) {
    ShadyCSS.prepareTemplate(CardSwiper.template, CardSwiper.is);
  }
  window.customElements.define(CardSwiper.is, CardSwiper);
});

with:

ShadyCSS.prepareTemplate(CardSwiper.template, CardSwiper.is);
window.customElements.define(CardSwiper.is, CardSwiper);

then the demo works as expected.

Hey,

so form a performance point of view it would make sense to only load shadycss in browser that do not support the shadowdom.

However, this means they will break if you add things like ShadyCSS.applyStyle(this).
My current solution is to add a check to see if ShadyCSS exists. But I was wondering if this is really the best solution?

We have 2 custom elements defined in the respective files:

// x-parent.html
  window.customElements.define('x-parent', class extends HTMLElement {
    connectedCallback() {
      console.log(this.localName, 'connected');
    }
  });

// x-child.html
  window.customElements.define('x-child', class extends HTMLElement {
    connectedCallback() {
      console.log(this.localName, 'connected');
    }
  });

They get imported and used in the main document:

<link rel="import" href="x-child.html">
<link rel="import" href="x-parent.html">

<x-parent>
  <x-child></x-child>
</x-parent>

In native CustomElements v1, the order of imports affects the order of connectedCallback calls, meaning that if x-child is imported before x-parent (like in the above example), its connectedCallback will be invoked before the x-parent one

x-child connected
x-parent connected

This does not happen with the v1 polyfill, which will output

x-parent connected
x-child connected

Demo: http://jsbin.com/cicujedimi/1/edit?html,js,output

Fails in Firefox, IE11, MS Edge, and Chrome when ShadyDOM = {force: true}. Emits a big AngularJS stacktrace:

TypeError: linkNode is undefined
Stack trace:
nodeLinkFn@https://unpkg.com/[email protected]/angular.js:9928:11
compositeLinkFn@https://unpkg.com/[email protected]/angular.js:9174:13
nodeLinkFn@https://unpkg.com/[email protected]/angular.js:9928:11
compositeLinkFn@https://unpkg.com/[email protected]/angular.js:9174:13
nodeLinkFn@https://unpkg.com/[email protected]/angular.js:9928:11
compositeLinkFn@https://unpkg.com/[email protected]/angular.js:9174:13
nodeLinkFn@https://unpkg.com/[email protected]/angular.js:9928:11
compositeLinkFn@https://unpkg.com/[email protected]/angular.js:9174:13
compositeLinkFn@https://unpkg.com/[email protected]/angular.js:9177:13
publicLinkFn@https://unpkg.com/[email protected]/angular.js:9039:30
bootstrapApply/<@https://unpkg.com/[email protected]/angular.js:1954:11
$RootScopeProvider/this.$get</Scope.prototype.$eval@https://unpkg.com/[email protected]/angular.js:18423:16
$RootScopeProvider/this.$get</Scope.prototype.$apply@https://unpkg.com/[email protected]/angular.js:18523:20
bootstrapApply@https://unpkg.com/[email protected]/angular.js:1952:9
invoke@https://unpkg.com/[email protected]/angular.js:5040:16
bootstrap/doBootstrap@https://unpkg.com/[email protected]/angular.js:1950:5
bootstrap@https://unpkg.com/[email protected]/angular.js:1970:12
angularInit@https://unpkg.com/[email protected]/angular.js:1855:5
@https://unpkg.com/[email protected]/angular.js:33884:5
trigger@https://unpkg.com/[email protected]/angular.js:3468:5
Cb/g@https://unpkg.com/@webcomponents/[email protected]/shadydom.min.js:57:181
  angular.js:14700:16

This appears to be the same issue as referenced in webcomponents/webcomponentsjs#777 and webcomponents/shadydom#122. I can reproduce it with AngularJS by creating a component inside an ng-switch statement. The issue goes away when I remove shadydom.

AngularJS produces this markup, including a few comment nodes:

<div ng-switch="$ctrl.valueClicked">
  <!-- ngSwitchWhen: true -->
  <!-- ngSwitchDefault: --><div ng-switch-default="" class="ng-scope">
    <another-comp val="Not clicked!" class="ng-binding ng-isolate-scope">Not clicked!</another-comp>
  </div><!-- end ngSwitchWhen: -->
</div>

I'm wondering if those are the culprit, but I'm not familiar enough with shadydom to be certain, unfortunately.

Possibly related: webcomponents/shadydom#170

Description

surrounding light dom form is leaked to ShadowDOM elements.

Live Demo

http://jsbin.com/nawizajaro/1/edit?html,console,output

Steps to Reproduce

1. create a new element
2. put a form item element such as <select> into the shadow root
3. access the form items .form property

Expected Results

.form should return null

Actual Results

.form returns the surrounding light dom form

Browsers Affected

• Chrome
• Firefox
• [?] Edge
• [?] Safari 9
• [?] Safari 8
• [?] IE 11

Versions

• webcomponentsjs: v1.1.0

From @nevir on March 13, 2015 17:27

Things like:

.foo:after {
  content: '{';
}

Copied from original issue: Polymer/polymer#1291

ShadyCSS v1 has a lot of limitations that keep hitting users right in the face.

It's time to fix that, and make ShadyCSS totally (mostly) transparent.

Current API should probably stay the same, but will become entirely optional performance enhancements. However, the behavior change is probably enough to warrant a breaking change.

Enhancements:

• Automatically handle top-level styles
  • No more need for <custom-style> or CustomStyleInterface
• Let arbitrary elements like <div> have scoped shadowroots
  • Only custom elements are supported right now
• Handle multiple stylesheets
  • Better for everyone!
• Make ::slotted work better
  • Handle redistribution sanely
  • Remove as many of the weird corner cases with the current scheme as possible
• Handle dynamic changes to # of stylesheets
  • Scope the root based on the ordered set of stylesheets contained in the root