Styles do not exist on an element, how could the element "import" them?

[Westbrook]

You suggest the following:

<template>
    <style export="/component-resets.css">
        button {
            color: red;
        }
    </style>
</template>

<icon-button import="/component-resets.css">
    <template shadowrootmode="open">
        <button>
            <span>👍 In shadow!</span>
        </button>
    </template>
</icon-button>

However, icon-button does not hold styles, it's shadow root does, would it not need to be more like:

<icon-button>
    <template shadowrootmode="open" import="/component-resets.css">
        <button>
            <span>👍 In shadow!</span>
        </button>
    </template>
</icon-button>

Then you fun into the issue that you may want to import multiple things, is this possible?

<icon-button>
    <template shadowrootmode="open" import="/component-resets.css, /icon-button.html">
    </template>
</icon-button>

Would the discerning factor simply be the presence of .css or .html? Would it be more explicit and less work for the parse for there to be separate attributes for the various types of imports?

[robglidden]

The explainer/proposal assumes multiple specifiers: "Another advantage of this proposal is that it can allow multiple module specifiers in the adoptedstylesheets property".

Giving examples:

<template shadowrootmode="open" adoptedstylesheets="/foo.css, /bar.css"> 

and:

<template shadowrootmode="open" shadowrootadoptedstylesheets="/foo.css" shadowroothtml="/foo.html"></template>

It is my understanding of the explainer/proposal that the mime type of the resource (deduced from the extension .css, .html, etc. in the importing attribute) is what would allow the synchronizing and coordinating between the ES module graph (as .css files in CSS Module Scripts) for exporting/importing either declaratively from HTML or imperatively from an Javascript ES module file.

The explainer/proposal does use different attribute names for exporting and importing different resource types. I am not sure that is for any particular need (other than mime type identification described above, which seems to require the file extension), so it appears that the multiple attribute names are duplicative. Personally I find it confusing to have a combinatorial explosion of inconsistent naming conventions, which is one reason why I am suggesting starting from a simpler what-it-does "import/export" terminology.

The explainer/proposal assumes the importing attribute would be on the defining declarative shadow template, which is the obvious, intuitive place. I am suggesting broadening in ways and for reasons in this slide deck. Perhaps there may also be use cases for importing into other non-shadow-DOM locations.