Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CSS @apply not working when parent has same component as sibling #4410

Closed
1 of 6 tasks
jehna opened this issue Mar 10, 2017 · 8 comments
Closed
1 of 6 tasks

CSS @apply not working when parent has same component as sibling #4410

jehna opened this issue Mar 10, 2017 · 8 comments
Assignees

Comments

@jehna
Copy link

jehna commented Mar 10, 2017

Description

@apply'ed CSS property from native CSS mixin is not getting applied on component, when the component has been used previously in the DOM without the CSS property.

Live Demo

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

Steps to Reproduce

  1. Create my-element
  2. Append my-element to document.body
  3. Create wrapper-element that also has my-element inside it.
  4. Append wrapper-element to body after my-element
  5. @apply a css variable called --css-variable in my-element
  6. Try to set any CSS property to the --css-variable block inside the wrapper-element

Expected Results

The CSS property should be applied to the my-element component inside wrapper-element

Actual Results

The CSS property is not applied.

Browsers Affected

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

Versions

  • Polymer: 2.0-preview
  • webcomponents: v1
@jehna
Copy link
Author

jehna commented Mar 10, 2017

Known workaround:

Add the same CSS property to the component that was first introduced in the DOM. (see comment in the jsbin example)

@dfreedm
Copy link
Member

dfreedm commented Mar 12, 2017

Can reproduce without Polymer, so this is probably a ShadyCSS bug: http://jsbin.com/medaday/edit?html,output

@dfreedm
Copy link
Member

dfreedm commented Mar 12, 2017

This issue was moved to webcomponents/shadycss#69

@TomK
Copy link

TomK commented Apr 1, 2017

I think this should be reopened here. I'm unable to reproduce it directly in shadycss, can anyone else get it to fail there?

Failing polymer codepen:
http://codepen.io/oridan/pen/jBQodm

@TomK
Copy link

TomK commented Apr 1, 2017

@azakus is it possible to write a unit test against shadycss that fails as per your example? It seemed to work for me, but it's possible I set it up wrong. I might get chance to have another crack at it over the weekend.

@dfreedm
Copy link
Member

dfreedm commented Apr 5, 2017

@TomK looks like #4399 caused stamping the template to move to ready() which worked around #4486

@dfreedm
Copy link
Member

dfreedm commented Apr 5, 2017

Per findings in webcomponents/shadycss#69 (comment) and webcomponents/shadycss#69 (comment), reopening this issue and closing webcomponents/shadycss#69

@dfreedm dfreedm reopened this Apr 5, 2017
@dfreedm
Copy link
Member

dfreedm commented Apr 5, 2017

Updated JSBin with master branches: http://jsbin.com/tajusit/edit?html,output, seems to work correctly.

However, I'm going to leave this open for a bit to make this a test in Polymer so we don't regress accidentally

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants