Why not use a regular CSS file?

[gaurav21r]

We aren't using any CSS variables or CSS Mixins here. And the https://github.com/PolymerElements/iron-flex-layout/blob/master/iron-flex-layout-classes.html contains no Polymer specific syntax except for the <style>s to be wrapped inside <dom-module>s.

Why not just take it out in a regular CSS file? Not only will it be a great boon for non-Polymer projects (greater interops will lead to greater contributions, in my opinion), but also the syntax becomes cleaner in Polymer Projects. No more

<link rel="import" href="../iron-flex-layout/iron-flex-layout-classes.html">
<style is="custom-style" include="iron-flex iron-flex-alignment"></style>

[notwaldorf]

Here is a very detailed answer, because the problem is actually very complicated.

First, the "use an external stylesheet" bit:

• custom elements cannot import external stylesheets using the "usual way" (<link rel="stylesheet">) because that does not work in the shadow DOM (i.e. the styles do not get applied at all, it's like you never included the stylesheet at all)
• there's an alternate approach, using the @import rule, but this actually fetches the stylesheet for every instance of your element that uses it, which is wicked expensive
• prior to 1.1.0 and <style include>s, external stylesheets were included via an HTML import. HTML imports are great because they both put the styles in the shadow DOM and do deduping (so the external stylesheet is only fetched once), but HTML imports for CSS have security risks, so they are not recommended (and we will eventually be deprecating the ability to do this in Polymer, since it's bad). More info on that: https://www.polymer-project.org/1.0/docs/devguide/styling.html#style-modules)

Now that we know we have to use a <style include>:

• the reason why we split the styles in separate modules is to make it less expensive -- these styles will be available in every element importing iron-flex-layout. If we didn't split them up, you'd include a whole bunch of styles that need to be parsed, but you might realistically not need in that element (for example, I've noticed that 90% of the time I only need the iron-flex layout, and very rarely any of the other ones). By having the granular dom-modules you can import only the flex styles you actually need (which means there's less CSS for the parser)

TL; DR: we couldn't use an external stylesheet, so maintaining one is not feasible for the Polymer elements team :)

Hope this clears things up!

[dotnetCarpenter]

@notwaldorf Can you point me to a resource that explains why this is a security risk? This is is a huge obstacle when you already have a nice UI library written and neatly organized in BEM blocks but have to either:

a. Create a tool that wrap each BEM block in a dom-module
b. Inline the needed CSS in a web component which result in a maintenance nightmare or at least a lot of duplicated CSS
c. Use @import as you mentioned, which unless we create Service Workers mention in the PRPL pattern, which we just can not do in a feasible amount of time before launching our web site, will result in myriads of HTTP requests. - this is untested but I take your word for it.

[dotnetCarpenter]

I still don't understand why this can be a security risk but I found another answer which makes sense.

[...] as soon as the browser hits the <link rel="stylesheet">, it downloads the stylesheet, parses the styles, and injects them into the document head. So they may already affect the display of the document before Polymer can do anything about them.
Polymer/polymer#2429 (comment)

That means scoped styles goes out the window and I can understand why that is bad for a web component.

So for now, we will go with option a.

PS. Any idea why the implementation of shady DOM result in a bad case of classitis? It seems like a poor design choice.

[notwaldorf]

paging @sorvell who knows the details, but my understanding is that it would lead to parsing the external css file as an html document, which isn't great (and since you're expecting css and getting html, and maybe js since nobody is stopping you, this could be unsafe).

[dotnetCarpenter]

Ah, you mean if we use HTML imports natively in the browser, which can not be restricted to only import CSS. At first glance that seems no different from importing a Web Component which could contain malicious code but we do it anyway.

Anyway, looking forward to @sorvell answer. Thanks for your speedy reply.

[profhase]

@dotnetCarpenter @sorvell @notwaldorf

This issue seems very actual for me. I would like to use some webcomponents in an existing bootstrap project.
The way that I ve chosen for now is:

<dom-module id="shared-styles">
    <link rel="import" type="css" href="/static/bootstrap/css/glyphicons.css">
    <link rel="import" type="css" href="/static/bootstrap/css/bootstrap.min.css">
    <template>
        <style>...</style>

    </template>
</dom-module>

With a <style include="shared-styles"></style> in every component.

• Is it the way it is supposed to be?
• What will I do when rel=import type=css finally gets removed from polymer?

[bolerap]

Same question as @profhase and a little question is with some front end UI libraries contain both css and js such as Bootstrap and Semantic, How can i include its js parts?
For this

What will I do when rel=import type=css finally gets removed from polymer?

This will soon deprecate as mentioned at https://www.polymer-project.org/2.0/docs/devguide/style-shadow-dom#style-modules . When it deprecated do we copy all content of css libray into module like this ?

<dom-module>
    <template>
        <style>
            ... paste css library content here
        </style>
    </template>
</dom-module>