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

Imported styles are in the wrong order regarding non-imported styles #113

Closed
spassarop opened this issue Oct 23, 2021 · 7 comments
Closed

Comments

@spassarop
Copy link
Collaborator

spassarop commented Oct 23, 2021

When embedStyleSheets is true and there are imported styles with @import, the imported style result is at the end. This means that if there is a style tag like this:

<style type='text/css'>
	@import url(https://owasp.org/www--site-theme/assets/css/styles.css);
	h1 {font: 15pt "Arial"; color: blue;}
</style>

Results are like:

<style type="text/css"><![CDATA[h1 {
	font: 15.0pt Arial;
	color: blue;
}
*.hide-el {
...
}
*.remove-el {
...
}
]]></style>

Leaving the h1 style at the beginning when it should be at the end to override any previously defined style for that element in the imported style sheet.

Current behavior is:

  1. The CSS parser first reads and validates the whole style tag.
  2. In the process, when it finds an import tag, it validates the URL and stores it for future processing.
  3. After getting a result for the styles (without imports), AntiSamy iterates over the import URLs and for each one downloads the corresponding CSS file, parses it, validates it and appends the result in the previous one which holds the accumulated validated styles.
    A way to change the order to prepend imported styles should be found, but also respecting the import order.
@davewichers
Copy link
Collaborator

@spassarop - This has been open for several months. Is this fixable? (Easily?).

@spassarop
Copy link
Collaborator Author

This was fixed with #114, the imports are now in the right order.

@davewichers
Copy link
Collaborator

This fix will be included in the 1.6.5 release.

@davewichers davewichers reopened this Dec 31, 2021
@spassarop
Copy link
Collaborator Author

Sorry for closing, I better leave that to you hehe

@davewichers
Copy link
Collaborator

No problem. I keep 'fixes' like this open so I know what to report in the release notes as fixed AND so anyone coming here can find the open issue and know it is still open in the latest release.

@kwwall
Copy link
Contributor

kwwall commented Dec 31, 2021 via email

@davewichers
Copy link
Collaborator

Closing this issue as these changes went out with the 1.6.5 release I just pushed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants