Skip to content

Imports Reloaded #23

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

Closed
wants to merge 8 commits into from
Closed

Imports Reloaded #23

wants to merge 8 commits into from

Conversation

ju1ius
Copy link

@ju1ius ju1ius commented Sep 13, 2011

  • Encodings are now detected according to the spec: http://www.w3.org/TR/CSS2/syndata.html#charset
  • When resolving an import, the file encoding is detected and then converted to the encoding of the parent stylesheet.
  • New API for options.
  • More tests, more docs
  • Bonus bugfix: the parser is now able to handle files with a BOM.

@sabberworm
Copy link
Collaborator

I think I owe you an apology for not having replied to this sooner but I was a bit unsure how to react. I’m still very hesitant of this change.
First of all, I think that this is, conceptually, the wrong approach: resolving @import statements should be a simple call on the parsed output, not something you have to decide on before making the call to parse().
Secondly, I think URL absolutizing and resolving imports should be cleanly separated as they are two independant functions (with one concerning all url() functions and the other one only @imports). Also, I think absolutizing local paths does not make any sense and rather than trying to do so, one should have to give a full url to use as base. That way, the URL resolve parts could be kept mostly alike for local and remote paths. I don’t have a definite answer but this whole subject would warrant some more attention.
There are also some other issues I’m seeing:

  • data: URIs should be supported.
  • URLs starting with // should resolve to whatever the protocol of the including file is.
  • I really think typing ->encoding('utf-8') is better (and a lot more convenient) than ->setOption('encoding', 'utf-8'). It might be an API change but I don’t see the big problem there. If I want to use a new option, I need to change my code anyhow…

Finally, my biggest “problem” is with the whole can of worms this change is opening: resolving imports is not something I’ll ever be using but I’ll still be maintaining it, considering it in newly added unit tests, providing “support” for it, etc.

In short, I don’t think this will ever make it into my repo, especially since it is possible to factor this out into a separate function that works on an already-parsed CSSDocument instance.

@sabberworm sabberworm closed this Mar 7, 2013
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants