Adds `static get styles()` #401

sorvell · 2018-12-22T03:19:54Z

Fixes #391.

This should be implemented to return an array of styles defined using the css tag function. These styles will be applied with adoptedStyleSheets where available and shimmed when not.

This should be implemented to return an array of styles defined using the `css` tag function. These styles will be applied with `adoptedStyleSheets` where available and shimmed when not. WIP: needs tests.

daKmoR · 2018-12-22T09:18:08Z

Questions: why is it an array? and not just

return css`
  h2 { color: orange; }
`;

using only a css tagged template literal you can do more advanced stuff like duplicate css.

e.g.

// somewhere
const headerColor = css`h2 { color: orange; }`;

// myBase.js
static get styles() {
  return css`
     ${headerColor}
     .footer { border-top: 1px solid green; }
  `;
}

// myEl.js
static get styles() {
  return css`
     ${super.styles}
     ${headerColor}
     .some { color: yellow; }
  `;
}

Output of myEl css

h2 { color: orange; }
.footer { border-top: 1px solid green; }
h2 { color: orange; }
.some { color: yellow; }

Output of myEl css WITH dedupe

h2 { color: orange; }
.footer { border-top: 1px solid green; }
.some { color: yellow; }

I am telling this as we have been using a BaseClass that supports style deduping for a while now and this is a really powerful feature and it makes the life of the css parser/shadycss just simpler by not needing to process as much css.

In this simple example it's not much but really if you have huge css blocks then deduping css improves performance a lot.

So I am really interested what the reasoning for using an array is.

PS: lit-css already supports this see https://github.com/lit-styles/lit-styles/blob/master/packages/lit-css/test/lit-css.spec.js#L29

bashmish · 2018-12-22T09:57:06Z

I'm happy to see that you folks take a step forward to support this. Would be nice if you take lit-css as an inspiration for your implementation. I personally always thought this should be part of the LitElement core. I do understand that tagged templates are not designed for such a use case or at least this use case with deduping is uncommon, but so far there were some users happy with it, for example, @web-padawan who prototypes new vaadin components.

bashmish · 2018-12-22T12:18:09Z

Also some ideas behind such a design I presented in this talk a few weeks ago https://youtu.be/wNKyEtLRTe4?t=2373 (will start at the most interesting part of the talk).

Between the lines it explains the motivation for lit-css and why the getter for styles in LitElement is static (we agree here anyway which is a good sign).

justinfagnani · 2018-12-22T18:23:43Z

src/lib/updating-element.ts

+   * Array of styles to apply to the element. The styles should be defined
+   * using the `css` tag function.
+   */
+  static get styles() {


Add type of Array<CSSStyleSheet|LiteralString>

Added specific type for this and used it here.

justinfagnani · 2018-12-22T18:24:08Z

src/lib/css-tag.ts

+*/
+export const supportsAdoptedStyleSheets = ('adoptedStyleSheets' in Document.prototype);
+
+class LiteralString {


I would name this CSSLiteral

justinfagnani · 2018-12-22T18:27:54Z

src/lib/css-tag.ts

+  }
+};
+
+export const css = (strings: string[], ...values: any[]) => {


I think we should consider having this return an object with an optional .styleSheet and .cssText so that there's a consistent return type for the css tag and so the static style property has a single item type.

This would change below to just:

const cssText = values.reduce((acc, v, idx) => acc + literalValue(v) + strings[idx + 1], strings[0]); return new CSSResult(cssText);

justinfagnani · 2018-12-22T18:31:37Z

src/lib/css-tag.ts

+    return value.value;
+  } else {
+    throw new Error(
+        `non-literal value passed to 'css' function: ${value}`


It'd be nice to allow user-provided values in safe contexts with context-aware auto-escaping. Not sure how far we can go purely client-side. We may be able to allow directive-like functions that return a sentinel value that parses correctly for a particular context, then replace it, lit-html style. Soy does interesting things here at compile time. Maybe @mikesamuel has ideas.

justinfagnani · 2018-12-22T18:35:25Z

src/lib/updating-element.ts

+        styles.forEach((s) => {
+          const style = document.createElement('style');
+          style.textContent = s;
+          shadowRoot.appendChild(style);


to match Constructible StyleSheet ordering these have to come first in the ShadowRoot. Is that happening because you're directly waiting _updatePromise? Comment if so.

Yup, comment added. Note, they come last in the shadowRoot.

Don't they have to come first in case there are <style> tags in the rest of the shadow content?

Ok, I see: https://wicg.github.io/construct-stylesheets/#using-constructed-stylesheets Let's include a link to the spec

justinfagnani · 2018-12-22T18:36:21Z

src/lib/updating-element.ts

@@ -462,7 +472,25 @@ export abstract class UpdatingElement extends HTMLElement {
   * @returns {Element|DocumentFragment} Returns a node into which to render.
   */
  protected createRenderRoot(): Element|ShadowRoot {
-    return this.attachShadow({mode : 'open'});
+    const shadowRoot = this.attachShadow({mode : 'open'});
+    const styles = (this.constructor as typeof UpdatingElement).styles;


I (weakly) feel like all this should be in LitElement, since it does the actual rendering.

It seems like the shadowRoot rendering (creation + styles) should go together, but I think it's reasonable that this go into LitElement and not UpdatingElement. Let's discuss separately.

justinfagnani · 2018-12-22T18:37:30Z

src/lib/updating-element.ts

-    return this.attachShadow({mode : 'open'});
+    const shadowRoot = this.attachShadow({mode : 'open'});
+    const styles = (this.constructor as typeof UpdatingElement).styles;
+    if (window.ShadyCSS !== undefined && !(window.ShadyCSS as any).nativeShadow) {


comment the three cases a little

justinfagnani · 2018-12-22T18:47:06Z

@daKmoR styles is an array because elements may be sharing styles, and in a Constrctible StyleSheet supporting browser the css tag will return an actual StyleSheet object. We don't want to (and can't easily in all cases) merge these into each other with interpolations because adoptedStyleSheets is an array - we want to pass a reference to each StyleSheet object individually.

A modified version of your example:

const sharedStyles = css`
  h2 { color: orange; }
`;

class Base extends LitElement {
  static get styles() {
    return [
      sharedStyles,
      css`
        .footer { border-top: 1px solid green; }
      `
    ];
  }
}

class El extends LitElement {
  static get styles() {
    return [
      ...super.styles,
      // you probably know this is included in the parent, so this is dubious
      // we can still dedupe the arrays before setting `adoptedStyleSheets` but that
      // can change the cascade
      sharedStyles,
      css`
        .some { color: yellow; }
      `
    ];
  }
}

b-strauss · 2018-12-22T19:19:31Z

Is createRenderRoot the right place for this code?

Having a custom implementation for createRenderRoot for example here with custom options for attachShadow will require you to duplicate all the code.

daKmoR · 2018-12-22T21:44:44Z

// you probably know this is included in the parent, so this is dubious

unfortunately, you can not know that always... for example if you are a mixin.

So sometimes you have shared stylings for two mixins but each needs it to work on its own. However, you can also apply both mixins and then you will get duplicate css.

const srOnlyClass = css`.sr-only { ... }`;

const DescriptionMixin = ... // applies srOnlyClass so
class foo extends DescriptionMixin(BaseElement) // works
const DetailsMixin = ... // applies srOnlyClass so
class foo extends DetailsMixin(BaseElement) // works

// now this will apply srOnlyClass 2 times
class bar extends DescriptionMixin(DetailsMixin(BaseElement)) {}

we have this actually quite often in our codebase that there is shared stylings.

// we can still dedupe the arrays before setting adoptedStyleSheets but that
// can change the cascade

true so for us we always import the (parent) stylings at the top... which worked really nicely for us.

So overall arrays should work as well... I do find it a little bit more cumbersome but if it's more future proof then it's worth it.

But deduping should still be done... and for a css tagged template it was nicely part of the css tag itself... for array we either have to do return dedupeStyles([...super.styles, myStyleB]) or do "magic" with the array...

PS: I am off work till next year so the above example I made up... if need be I could see if I can look up some of our real examples

LarsDenBakker · 2018-12-29T12:49:20Z

I really like this direction!

I think it's important to consider how to compose style modules:

const typographyStyles = css`...`;
const buttonStyles = css`...`;

// a standalone style module
const styleModuleA = css`...`;
// a style module that composes with another
const styleModuleB = [typographyStyles, css`...`];

class MyElement extends LitElement {
  static get styles() {
    return [
      typographyStyles,
      buttonStyles,
      styleModuleA,
      ...styleModuleB,
    ];
  }
}

I think this creates two challenges:

Deduplication: Like @daKmoR mentioned you don't want to include the same styles twice. In this case typographyStyles will be included twice. You don't want to need to know within MyElement how styleModuleB is constructed internally so that you can leave out typographyStyles. Also if styleModuleB every changes internally, it will break your element.
Composition: You don't want to have to know in MyElement which style modules are arrays and should be destructured, it's a cumbersome process and it exposes an extra implementation detail. Perhaps the same approach as Polymer 1 behaviors can be used here, where the final styles array is flattened. On modern browsers Array.prototype.flat is enough.

justinfagnani · 2019-01-07T20:11:26Z

src/lib/css-tag.ts

+    result.styleSheet = new CSSStyleSheet() as ConstructableStyleSheet;
+    result.styleSheet.replaceSync(cssText);
+  } else {
+    result.cssText = new CSSLiteral(cssText);


you can always assign this field

Removes duplicate styles in the `static get styles` array. This is useful when styles are cmposed via mixins/subclasses. To try to preserve cascade ordering, the last duplicate style in the list is preserved.

blikblum · 2019-01-08T00:29:10Z

Having a custom implementation for createRenderRoot for example here with custom options for attachShadow will require you to duplicate all the code.

Not only that, but just disabling shadowDom by returning this in createRenderRoot, as recommended in documentation, will break styles.

justinfagnani · 2019-01-08T01:10:57Z

Not only that, but just disabling shadowDom by returning this in createRenderRoot, as recommended in documentation, will break styles.

That's just going to be true of any styles. If you have styles that assume ShadowDOM scoping, they're going to do the wrong thing if you don't render to a ShadowRoot. In this case at least nothing will happen with the styles unless you do something yourself, which is probably better than them being applied globally by default.

justinfagnani · 2019-01-08T01:13:26Z

src/lib/css-tag.ts

+
+class CSSLiteral {
+
+  value: string;


justinfagnani · 2019-01-08T01:13:53Z

src/lib/css-tag.ts

+  value: string;
+
+  constructor(value: string) {
+    this.value = value.toString();


Why the .toString()? If value can be something other than a string, update the type.

justinfagnani · 2019-01-08T01:16:08Z

src/lib/updating-element.ts

+   * property. Styling will apply using `shadowRoot.adoptedStyleSheets` where
+   * available and will fallback otherwise.
+   */
+  protected createRenderRootStyles(shadowRoot: ShadowRoot) {


The name is too generic, since this doesn't work with any render root, but only ShadowRoots. How about adoptStyles or applyStyles?

Changed to adoptStyles

justinfagnani · 2019-01-08T01:19:37Z

src/lib/updating-element.ts

+   */
+  protected createRenderRootStyles(shadowRoot: ShadowRoot) {
+    let styles = (this.constructor as typeof UpdatingElement).styles;
+    // de-duplicate styles preserving the last item in the list.


Add why this is important

Added note, for performance.

justinfagnani · 2019-01-08T01:28:19Z

src/lib/updating-element.ts

+  protected createRenderRootStyles(shadowRoot: ShadowRoot) {
+    let styles = (this.constructor as typeof UpdatingElement).styles;
+    // de-duplicate styles preserving the last item in the list.
+    const stylesSet = new Set();


Not sure if this is better, but it gets rid of the deletes (which involve hashes) in exchange for a reverse:

const stylesSet = new Set(); for (const i = styles.length - 1; i >= 0; i==) { s.add(styles[i]); } styles = [...styleSet].reverse();

or:

styles = [...new Set([...styles].reverse())].reverse();

Used reduceRight + reverse

justinfagnani · 2019-01-08T01:32:14Z

src/lib/updating-element.ts

+        styles.forEach((s) => {
+          const style = document.createElement('style');
+          style.textContent = s;
+          shadowRoot.appendChild(style);


Ok, I see: https://wicg.github.io/construct-stylesheets/#using-constructed-stylesheets Let's include a link to the spec

justinfagnani · 2019-01-08T01:33:25Z

src/lib/updating-element.ts

+  /**
+   * Applies styling to the element shadowRoot using the `static get styles`
+   * property. Styling will apply using `shadowRoot.adoptedStyleSheets` where
+   * available and will fallback otherwise.


Let's describe the fallback. Specifically that it appends <style> elements to the ShadowRoot after the first render. This will be important for other rendering libraries.

justinfagnani · 2019-01-08T01:36:43Z

src/lib/updating-element.ts

+export * from './css-tag.js';
+
+// Augment existing types with bleeding edge API.
+declare global {


I think we may want these here: https://github.com/Polymer/lit-element/blob/master/src/env.d.ts

Added types to env.d.ts

justinfagnani · 2019-01-08T01:39:14Z

src/lib/css-tag.ts

+*/
+export const supportsAdoptedStyleSheets = ('adoptedStyleSheets' in Document.prototype);
+
+interface ConstructableStyleSheet extends CSSStyleSheet {


According to w3c/csswg-drafts#3433 these additions are going to be merged into CSSStyleSheet, so add them globally as with adoptedStyleSheets.

justinfagnani · 2019-01-08T01:40:00Z

src/lib/css-tag.ts

+  }
+};
+
+export type CSSStyleSheetOrCssText = {


I don't think Or is the best naming anymore. It's really specific to this operation, so something like CSSResult seems fine.

blikblum · 2019-01-08T01:51:40Z

src/lib/updating-element.ts

+   * available and will fallback otherwise.
+   */
+  protected createRenderRootStyles(shadowRoot: ShadowRoot) {
+    let styles = (this.constructor as typeof UpdatingElement).styles;


Check if styles is undefined and return to avoid extra works on elements that don't declare styles?

Thanks, done.

kenchris · 2018-12-22T03:24:01Z

src/lib/css-tag.ts

@@ -0,0 +1,52 @@
+/**
+@license
+Copyright (c) 2017 The Polymer Project Authors. All rights reserved.


Should be 2019 I assume

* simplified `css` function and removed `cssLiteral`; values must be `css` results * updated types and put into `env.d.ts` * memoized unique-ifying `styles` * `adoptStyles` now does the style adoption and is called separately from `createRenderRoot` and only if the root is a ShadowRoot. * updated changelog.

kenchris · 2019-01-08T20:14:29Z

src/lib/updating-element.ts

@@ -415,6 +444,12 @@ export abstract class UpdatingElement extends HTMLElement {
   */
  protected initialize() {
    this.renderRoot = this.createRenderRoot();
+    // Note, tf renderRoot is not a shadowRoot, styles would/could apply to the


"tf" should be "if"

justinfagnani

LGTM! (when the ShadyCSS change is in)

justinfagnani · 2019-01-08T20:16:46Z

src/lib/css-tag.ts

+
+  _styleSheet?: CSSStyleSheet|null;
+
+  constructor(public readonly cssText: string) {


I prefer not to use parameter properties, because it's non-standard JS outside of the type system. I collected guidance in the lit-html repo: https://github.com/Polymer/lit-html/blob/master/CONTRIBUTING.md#typescript

justinfagnani · 2019-01-08T20:17:58Z

src/lib/css-tag.ts

+    if (this._styleSheet === undefined) {
+      // Note, assume that if adoptedStyleSheets is supported,
+      // constructable stylesheets are as well.
+      if (supportsAdoptedStyleSheets) {


Maybe rename to supportsCSSShadowParts?

Changed to supportsAdoptingStyleSheets and added explicit check for construct-able stylesheet support.

justinfagnani · 2019-01-08T20:24:25Z

src/lib/updating-element.ts

+   */
+  protected adoptStyles() {
+    const styles = (this.constructor as typeof UpdatingElement)._uniqueStyles;
+    if (!styles.length) {


I prefer if (style.length === 0)

blikblum · 2019-01-09T00:11:15Z

src/lib/updating-element.ts

+    // Note, if renderRoot is not a shadowRoot, styles would/could apply to the
+    // element's getRootNode(). While this could be done, we're choosing not to
+    // support this now since it would require different logic around de-duping.
+    if (this.renderRoot instanceof window.ShadowRoot) {


Will fail in a env that does not supports shadow dom and not is pollyfied. Such env would be supported at all?

Thanks, fixed.

* moves `renderRoot` and all styling features from UpdatingElement to LitElement * remove unncessary checking for constractable stylesheet support

kevinpschaaf · 2019-01-09T02:11:54Z

src/lib/css-tag.ts

+})();
+
+export const supportsAdoptingStyleSheets = supportsConstructableStyleSheets &&
+    ('adoptedStyleSheets' in Document.prototype);


I think adoptedStylesheets is sufficient because it's unlikely a browser would ever ship that without constructable stylesheets.

kevinpschaaf · 2019-01-09T02:38:30Z

src/lib/updating-element.ts

+      // This matches the spec'd behavior of `adoptedStyleSheets`.
+      // Ensure an updated is requested and then render styling directly after the update.
+      this.requestUpdate();
+      this._updatePromise.then(() => {


Changing lit-html to have a render option that allows the user to specify a "before reference" to create the part before would allow us to remove this timing code here and instead put the <style>s in synchronously and just say render(result, this.renderRoot, {beforeRef: this.renderRoot.firstChild})

Since part is cached off the container, avoiding this. However, moved this case to update to avoid the fancy waiting here.

kevinpschaaf · 2019-01-09T18:26:04Z

src/lib/updating-element.ts

+      // preserving the last item in the list. The last item is kept to
+      // try to preserve cascade order with the assumption that it's most
+      // important that last added styles override previous styles.
+      const styleSet = styles.reduceRight((set, s) => {


can just be styles.reduceRight((set, s) => set.add(s), new Set())

(set.add returns the set)

kevinpschaaf · 2019-01-09T18:33:04Z

CHANGELOG.md

@@ -17,6 +17,8 @@ and this project adheres to [Semantic Versioning](http://semver.org/).
 ## Unreleased

 ### Added
+* Added `static get styles()` to allow defining element styling separate from `render` method.
+This takes advantage of [`adoptedStyleSheets`](https://wicg.github.io/construct-stylesheets/#using-constructed-stylesheets) when possible ([#391](https://github.com/Polymer/lit-element/issues/391)).
 * Added the `performUpdate` method to allow control of update timing ([#290](https://github.com/Polymer/lit-element/issues/290)).
 * Updates deferred until first connection ([#258](https://github.com/Polymer/lit-element/issues/258)).
 ### Changed


Add [breaking] change notice about moving createRenderRoot and related functionality from UpdatingElement to LitElement

kevinpschaaf · 2019-01-09T18:40:54Z

src/lit-element.ts

+    // (1) shadowRoot polyfilled: use ShadyCSS
+    // (2) shadowRoot.adoptedStyleSheets available: use it.
+    // (3) shadowRoot.adoptedStyleSheets polyfilled: append styles after rendering.
+    if (window.ShadyCSS !== undefined && !window.ShadyCSS.nativeShadow) {


Is it worth moving more of the prep steps to the static one-time spot (_uniqueStyles)? Basically, move the map calls out of instance-time work, and possibly also create a template of styles to clone for the final case?

Doesn't seem worth it.

Cleans up the Shadow DOM + shim adoptedStyles case: * avoids making the `updatePromise` protected * handles stamping styles into shadowRoot after render.

motss · 2019-01-19T08:42:57Z

<style> tags no longer showing inside SD of a CE in DevTools on Chrome 73. Is that expected behavior with native support of Constructible Stylesheet?

Adds static get styles()

670eb4c

This should be implemented to return an array of styles defined using the `css` tag function. These styles will be applied with `adoptedStyleSheets` where available and shimmed when not. WIP: needs tests.

sorvell added this to the 1.1.0 milestone Dec 22, 2018

sorvell requested a review from kevinpschaaf December 22, 2018 03:19

sorvell requested a review from justinfagnani as a code owner December 22, 2018 03:19

googlebot added the cla: yes label Dec 22, 2018

justinfagnani requested changes Dec 22, 2018

View reviewed changes

Steven Orvell added 2 commits January 7, 2019 11:35

Address review feedback.

b593e1d

Adds tests.

fd881dc

justinfagnani reviewed Jan 7, 2019

View reviewed changes

sorvell modified the milestones: 1.1.0, 1.0.0 Jan 7, 2019

De-duplicate styles in static get styles

8ae6692

Removes duplicate styles in the `static get styles` array. This is useful when styles are cmposed via mixins/subclasses. To try to preserve cascade ordering, the last duplicate style in the list is preserved.

sorvell changed the title ~~WIP: Adds static get styles()~~ Adds static get styles() Jan 7, 2019

Address review feedback.

8faa0c7

justinfagnani reviewed Jan 8, 2019

View reviewed changes

blikblum reviewed Jan 8, 2019

View reviewed changes

kenchris reviewed Jan 8, 2019

View reviewed changes

ghost mentioned this pull request Jan 8, 2019

[docs] Document style api #418

Closed

justinfagnani approved these changes Jan 8, 2019

View reviewed changes

Steven Orvell added 2 commits January 8, 2019 12:51

Address review feedback.

58bd5be

Address review nit.

6a4649e

blikblum reviewed Jan 9, 2019

View reviewed changes

Address review feedback

ca6206d

* moves `renderRoot` and all styling features from UpdatingElement to LitElement * remove unncessary checking for constractable stylesheet support

kevinpschaaf requested changes Jan 9, 2019

View reviewed changes

Steven Orvell added 4 commits January 9, 2019 11:20

Address review feedback

dcbffef

Cleans up the Shadow DOM + shim adoptedStyles case: * avoids making the `updatePromise` protected * handles stamping styles into shadowRoot after render.

Add [breaking] not about createRenderRoot moving to LitElement

583f515

Update deps and format.

352494a

Update to latest ShadyCSS API

6f6afec

kevinpschaaf approved these changes Jan 9, 2019

View reviewed changes

Steven Orvell added 2 commits January 9, 2019 16:16

IE specific fixes

80737c0

Update deps.

27eb2ad

sorvell merged commit 22eca24 into master Jan 10, 2019

sorvell deleted the static-styles branch January 10, 2019 02:42

kevinpschaaf mentioned this pull request Jan 14, 2019

Integrate Constructable Stylesheet support lit/lit#689

Closed


		_styleSheet?: CSSStyleSheet\|null;

		constructor(public readonly cssText: string) {

Adds static get styles() #401

Adds static get styles() #401

Conversation

sorvell commented Dec 22, 2018 • edited Loading

daKmoR commented Dec 22, 2018 • edited Loading

bashmish commented Dec 22, 2018

bashmish commented Dec 22, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

justinfagnani commented Dec 22, 2018

b-strauss commented Dec 22, 2018

daKmoR commented Dec 22, 2018 • edited Loading

LarsDenBakker commented Dec 29, 2018 • edited Loading

Choose a reason for hiding this comment

blikblum commented Jan 8, 2019

justinfagnani commented Jan 8, 2019

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

kenchris Dec 22, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

justinfagnani left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

kevinpschaaf Jan 9, 2019 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

motss commented Jan 19, 2019 • edited Loading

Adds `static get styles()` #401

Adds `static get styles()` #401

sorvell commented Dec 22, 2018 •

edited

Loading

daKmoR commented Dec 22, 2018 •

edited

Loading

bashmish commented Dec 22, 2018 •

edited

Loading

daKmoR commented Dec 22, 2018 •

edited

Loading

LarsDenBakker commented Dec 29, 2018 •

edited

Loading

kenchris Dec 22, 2018 •

edited

Loading

kevinpschaaf Jan 9, 2019 •

edited

Loading

motss commented Jan 19, 2019 •

edited

Loading