Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Define behavior when @import fails #27

Closed
TakayoshiKochi opened this issue May 31, 2018 · 7 comments
Closed

Define behavior when @import fails #27

TakayoshiKochi opened this issue May 31, 2018 · 7 comments
Labels
needs resolution Needs consensus/resolution before shipping

Comments

@TakayoshiKochi
Copy link
Member

From @calebdwilliams #25 (comment)

A follow up question is what happens when an @import fails? Does the rest of the stylesheet still parse? Say, your imported sheet is for CSS custom properties as I've outlined in #24 and the importer has fallbacks set up? For the record, this is my primary interest in @import for constructible stylesheets (composing constructed stylesheets).

@tabatkins
Copy link
Contributor

I think the sheet should still parse; that matches current CSS behavior, and I don't know of anyone having trouble with that. (If we're dispatching load events, it can send an event alerting you to this failure, but that's the extent of it.)

@calebdwilliams
Copy link

In what scenario would something like StyleSheet.createFromString : Promise<StyleSheet> fail then? How would we be informed that the load has failed if we can't target the imported sheet?

@tabatkins
Copy link
Contributor

I wasn't intending for it to failable; it returns a Promise just so that we don't block the script on a potentially-large CSS parse.

How would we be informed that the load has failed if we can't target the imported sheet?

As I said in my comment, this could be communicated thru load events fired on the stylesheet, maybe?

@TakayoshiKochi TakayoshiKochi added the needs resolution Needs consensus/resolution before shipping label Jun 1, 2018
@tabatkins
Copy link
Contributor

Just to make sure: in JS, if you import a module that imports sub-modules, and one of the sub-modules fails, the import as a whole still succeeds, right? If so, then great, that's consistent with my expressed opinion (always succeed if the top-level load succeeds, maybe communicate sub-resource failures on the load event).

Whichever way it goes, tho, we should be consistent with the JS module story.

@rakina
Copy link
Member

rakina commented Aug 28, 2018

Just to make sure: in JS, if you import a module that imports sub-modules, and one of the sub-modules fails, the import as a whole still succeeds, right? If so, then great, that's consistent with my expressed opinion (always succeed if the top-level load succeeds, maybe communicate sub-resource failures on the load event).

Whichever way it goes, tho, we should be consistent with the JS module story.

So I just tried it here https://glitch.com/edit/#!/simple-show and it seems like the import fails (script.js imports uppercase.js which tries to import from invalid.js that doesn't exist) and the console doesn't show the uppercase text as it should. So I guess for our case we should also not suceed? (or am I doing something wrong with the code?)

@tabatkins
Copy link
Contributor

Your code looks good - if I fork it and remove the offending import, it successfully logs to the console.

So to be consistent, that suggests that any failed imports should cause the parent stylesheet's load promise to reject.

@rakina
Copy link
Member

rakina commented Sep 12, 2018

#35 resolves this - Failing @import means the promise is rejected.

@rakina rakina closed this as completed Sep 12, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
needs resolution Needs consensus/resolution before shipping
Projects
None yet
Development

No branches or pull requests

4 participants