Skip to content

define behavior of @import in Cascading Style Sheet (CSS) modules #870

Description

@dbaron

There was a long discussion running from #759 (comment) (in which @dandclark lays out three options) through #759 (comment) on what the behavior of @import in CSS modules should be. This discussion didn't lead to a resolution.

Since that issue feels like it's getting too large for a single issue, I'm splitting it out into its own issue. (Sorry if that's not the preferred way of dealing with things here.)

The lack of a resolution of that issue is becoming problematic. Because Constructable Stylesheets wants to match the behavior of CSS modules, this led to a extended discussion in last week's CSS teleconference that could have been avoided if this issue had been settled. And as far a I can tell what it's waiting on is primarily the choice between whether option 2 or option 3 is preferable.

Personally I found @tabatkins's arguments in favor of option 2 relatively persuasive, because it requires less change to the CSS OM, and because many of the theorized advantages of option 3 address issues already handled in existing @import handling (even if it's not well specified today). (And I'd note that CSS always has the option of introducing a new syntax for doing an import as a module.)

cc @matthewp @justinfagnani @emilio @argyleink @domenic @rniwa @chrishtr who also participated in that discussion.

I'd note that I'm also filing this as an effort to get w3ctag/design-reviews#405 finished up.

Metadata

Metadata

Assignees

No one assigned

    Labels

    tag-trackerGroup bringing to attention of the TAG, or tracked by the TAG but not needing response.

    Type

    No type

    Fields

    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions