External stylesheets cause message to be logged in browser.

[bjackson]

When using an external stylesheet in Chrome, an info message is printed to the console that says:
Resource interpreted as Document but transferred with MIME type text/css

[zishanj]

My conclusion is that when you open a component file (.css, .js) in Chrome, it will try to interpret as document (showing output on the screen), instead of interpreting it as its native MIME type.

[imskull]

Did you have a <style>... in your css file? remove type="css" from the <link import...> .

[askibinski]

@imskull type="css" should NOT be removed, otherwise the CSS does not load. See also documentation.

Isn't this a Chrome issue? Or should we just live with it?

[imskull]

I do not think it's correct with a <style> tag in css file, actually it does like a html file more. In my case, it is no problem after I removed <style>, just tested on Chrome.

[tregoning]

Just for the record using paper-drawer-panel is affected by this issue due to this line

[ValueBC]

I get this issue on browser reload, but not inital load.

[moso]

It seems to happen randomly. Sometimes I get zero "errors" in my console, sometimes Chrome spasses out and shows "errors" for some or every element, including Polymer's own elements, that uses <link rel="import" type="css" href="...">

Is this another way of telling us to vulcanize our Polymer webapplications? Or does this happen when one has vulcanized aswell?

[gertcuykens]

Confirmed for me too

Resource interpreted as Document but transferred with MIME type text/css: "http://localhost:8080/bower_components/paper-checkbox/paper-checkbox.css".
Resource interpreted as Document but transferred with MIME type text/css: "http://localhost:8080/bower_components/paper-radio-button/paper-radio-button.css".

[ssiano]

Is the message a warning or an error? In other words, is the element's CSS applied?

[moso]

@ssiano: Neither, it's just a regular message. The CSS is applied.
I could understand if it was only for CSS from <link ... imported by user-created elements. But it's also happening with, eg, paper-drawer-panel, paper-item, etc

[ssiano]

Thanks @mdevdk.

Among the iron and paper elements, the following have external stylesheets:

$ grep -lr '<link rel="import" type="css"' . | grep -v 'demo|test' | sort
./iron-component-page/iron-component-page.html
./iron-doc-viewer/iron-doc-property.html
./iron-doc-viewer/iron-doc-viewer.html
./paper-checkbox/paper-checkbox.html
./paper-dialog/paper-dialog.html
./paper-drawer-panel/paper-drawer-panel.html
./paper-item/paper-icon-item.html
./paper-item/paper-item.html
./paper-radio-button/paper-radio-button.html
./paper-slider/paper-slider.html
./paper-spinner/paper-spinner.html
./paper-toggle-button/paper-toggle-button.html

[adalinesimonian]

I'm a little confused here as to why this is concerning - it's just a warning, no?

And secondly, isn't this basically a fundamental limitation behind the way that the new shim works in order to do its work?

As long as <link rel="import" type="css" href="styles.css"> is used instead of <link rel="stylesheet" href="styles.css">, I don't see this message going away, because the browser/web components polyfill will be loading styles.css the same way as an HTML import, hence the warning.

If I'm wrong in my assumptions or I just flat-out missed the whole point, please let me know! 😄

[tregoning]

@vsimonian The fact that there is a warning indicates that at the very least that there is something unusual happening.

I understand why it's happening. I don't think simply ignoring the warning is a good long term solution. Probably a bug report should be opened against Chromium if this is in fact the correct long term solution.

If my project is vulcanized with everything inlined into 1 file this problem will go away, but I don't think this is documented anywhere. Again it's obvious as to why this is happening once you have some basic fundamentals under your belt but I believe that one of Polymer strengths is to allow non-professional front-end developers to create great, beautiful UIs. This console message might be concerning/misleading to newcomers.

[adalinesimonian]

@tregoning I think I'm beginning to understand! Thanks for taking the time to explain.

Perhaps, then, if I'm understanding this correctly, this should be a docs issue in the meantime?

I feel we need input (maybe you've got a bit of insight to share?) as to what's a realistic time/point at which the way this shim works can be changed to follow a less "alarming" route. My gut feeling is that this has a lot to do with browser support for web components/shadow DOM/HTML imports, which right now is still in its infancy in practical terms (except Chrome, gotta love Chrome).

[gertcuykens]

PS Chrome is the one complaining here :)

[adalinesimonian]

Funnily enough, yes. :) To sum up what I'm getting out of this discussion is:

• Chrome doesn't(?) support CSS custom properties or the more recent extensions
• Neither do any of the other browsers
• However, Chrome is the only browser with proper HTML import support
• Therefore, it complains because it sees an HTML import leading to a file served with a text/css MIME type
• Other browsers don't know what an import even is, and the webcomponents.js polyfill doesn't care enough to throw a warning

[moso]

Would a solution be to create a -styles element, similar to paper-styles where it's basically an empty element but with a collection of common styles inside <style></style> and then make that common practice?

[adalinesimonian]

@mdevdk I think that may be a possible solution, but I have a few concerns.

I'm still torn here. Ideally, I'd like to wait for browser support and see this as a documentation issue in the meantime.

However, the negotiation between Google, Mozilla, Apple, and Microsoft around the Web Components standard has been fraught with tension, and, in my observation, agreements have been hard to come by. Thus, realistically speaking, even waiting for browser support may become a long-term proposition.

It would be easier from the side of implementation complexity to live with the warning. However, as @tregoning pointed out, the reason the warning is a problem is that unless you know why the error is happening, it can be confusing and potentially lead to a developer wasting their time trying to fix a problem that isn't really there.

Now, let's say we make some sort of custom element. This may avoid the warning, but I'm concerned as to:

1. Whether or not deviating so far from standard syntax would become an adoption problem. <link rel="import" type="css" href="..."> already is a deviation, but by contrast it is a nearly in-place replacement for <link rel="stylesheet" href="..."> whereas placing all the styles in an HTML import in and of itself is an entirely new step (and prevents the CSS file from being available for use standalone without involving a duplicate).
2. Whether or not this would cause issues with style scoping. paper-styles is a collection of custom property and mixin definitions, none of which target any particular element within a particular context. However, if we start targeting members of a custom element from a disconnected import, how will Polymer know how to shim the styles properly for the shady DOM? How will :host be possible?
3. If a workaround is found to address the 2nd potential problem, how performant is it, and just how much complexity will have been added to the process to combat a warning in the console? Could it potentially become more confusing to use than dealing with the warning for which the workaround was created in the first place?

If there's an easy way around the warning, hats off to whoever puts it in. However, I'm not so sure there's such a silver bullet, and I am leaning on the side of believing that trying to avoid this warning may end up with a significantly more complex or confusing result than the warning itself.

I'd love to hear some input from one of the Polymer engineers and see what they have to say.

[richardaum]

<link rel="import" type="css" ...

Replacing rel="import" for rel="stylesheet" works.

[arthurevans]

Note that starting in 1.1.0, <link rel="import" type="css"> is no longer recommended, and there's an alternate mechanism for importing styles:

https://www.polymer-project.org/1.0/docs/release-notes.html#release-110httpsgithubcompolymerpolymertreev110-2015-08-13

It does have some drawbacks (most significant of which is that it doesn't accept bare CSS files, they have to be wrapped in a <dom-module> and <template>. We hope to build some tooling to package CSS files for you.

However, I think we can close this bug since the offending mechanism is deprecated.

[pensierinmusica]

Polymer needs to support bare external CSS files generated by CSS preprocessors. Let's continue this conversation on #2429.